[Feature]: Official Linux build for the MiniMax Code desktop app #510

Product or interface

Desktop app

Use case and problem

MiniMax Code 3.1.4 ships only for macOS and Windows. On Linux there is no
official build, so the desktop agent is unavailable to Linux users even
though the application itself is already platform-agnostic.

I unpacked the official Windows installer (3.1.4) to check how much work a
Linux build would actually be, and built a working port to confirm it. The
result is that the desktop app is much closer to Linux-ready than the release
matrix suggests — the only things that are platform-specific are the Electron
runtime and seven native addons, and every one of them already has an
upstream Linux build.

What I found in the shipped 3.1.4 payload:

• The runtime is Electron 42.8.0 (Chromium 148) — the same Electron
  version on macOS and Windows, so the official
  electron-v42.8.0-linux-x64 runtime is a drop-in shell.
• The application code lives in a platform-agnostic app.asar (32,000 files,
  397 MB). There is no platform-specific JavaScript in the main or
  preload bundles.
• The only native addons are better-sqlite3, node-pty, node-screenshots,
  @mariozechner/clipboard, @vscode/ripgrep, @trycua/cua-driver and
  @earendil-works/pi-tui. All of them publish Linux builds, and the app
  already pins versions that exist for Linux.
• Two pieces of the shipped payload are already Linux-targeted, which
  suggests the build pipeline treats Linux as a first-class target:
  bare-fs / bare-os / bare-url ship prebuilds/linux-x64/*.bare ELF
  binaries inside the archive, and @minimax/mcode-sandbox-runtime ships
  linux-sandbox-utils.js, linux-violation-monitor.js and a
  vendor/seccomp/x64/apply-seccomp helper.
• The Rust/uniffi layer already has a case 'linux' branch that detects
  gnu vs musl and resolves linux-<arch>-<libc> cargo triples.

So the remaining work for a first-party Linux build is a packaging target,
not a port.

Desired behavior

An official Linux build of the MiniMax Code desktop app, for example as a
.deb / .rpm / AppImage alongside the existing Windows and macOS
artifacts.

Concretely, on the packaging side:

• A linux target in the electron-builder configuration, using the same
  Electron version as the other platforms so the runtime and the app's
  native addons stay ABI-matched.
• The platform-specific npm packages are already published for Linux at the
  versions the app pins (@trycua/cua-driver-linux-x64-gnu@0.22.1,
  @ubjs/node-linux-x64-gnu@0.31.0-3, node-screenshots-linux-x64-gnu,
  @vscode/ripgrep-linux-x64, @mariozechner/clipboard-linux-x64-gnu), so
  no new build artifacts are needed for them.
• better-sqlite3 has no npm prebuild for Electron 42, but the upstream
  project publishes an ABI-matched one:
  better-sqlite3-v12.11.1-electron-v146-linux-x64.tar.gz
  (Electron 42 is NODE_MODULE_VERSION 146). This avoids compiling
  better-sqlite3 from source on every build.
• node-pty publishes no Linux prebuilds by design
  (chore: exclude Linux prebuilds, chore: exclude Linux prebuilds microsoft/node-pty#805), so it has to be
  compiled against the Electron headers. Note that on Linux node-pty uses
  forkpty(3) directly and does not need the macOS-only spawn-helper
  binary.
• The session-transfer helper is currently shipped per platform
  (session-transfer/win32-x64/, session-transfer/darwin-arm64/), so a
  linux-x64 build would be needed for session handoff to work.

Acceptance criteria: the app launches on a current Linux distribution, the
agent can run turns, sessions persist, and the terminal/integrated-pty
feature works.

Alternatives and additional context

I have a working Linux build of 3.1.4 and can share the whole pipeline if it
is useful:

• A reproducible build script that takes the official Windows installer,
  swaps the Electron runtime for the official linux-x64 build, replaces
  the platform-specific native addons with their upstream Linux packages,
  and repacks the archive with the correct unpack layout.
• A .deb that installs to /opt/minimax-code with a launcher, a desktop
  entry and hicolor icons, verified on Ubuntu 24.04: 23 of 23 startup
  subsystems initialise with zero failures, the local runtime and its
  SQLite migrations work, and all seven native addons load and function
  (including the terminal pty and the computer-use driver).

The one sharp edge worth recording for whoever builds this: Electron's
app.asar cannot hold native libraries, because dlopen does not go
through Electron's ASAR-aware fs redirection. The files have to be marked
unpacked, and electron-builder unpacks whole packages rather than just the
.node files. Getting that set wrong produces a build that packages
cleanly and then fails at runtime with
cannot open shared object file: Not a directory.

I also hit what looks like a genuine bug in the library this app uses for
its Rust bindings, @ubjs/node, and have opened a fix upstream:
jhugman/uniffi-bindgen-react-native#501 — it returns
an in-archive path for a library that is only present unpacked, and the
existence check passes anyway because Electron's fs shim reports archived
files as present.

For reference, there is already a community effort packaging the official
macOS build for Linux: https://github.com/unfallenwill/minimax-code-linux
(it is what I would start from rather than the Windows installer, since it
already solves the native-addon swap, the session-transfer client and the
packaging). I have contributed the node-pty spawn-helper correction to it
as well.

Happy to open a pull request with the packaging target and the native-addon
wiring if that is the preferred route — I understand external PRs are
restricted to collaborators, so I am happy to prepare a branch and a patch
series for a maintainer to land instead. Please let me know which you
prefer.