MiniMax Code: a terminal coding agent that splits TUI, headless and ACP into separate entry points

One CLI with three ways to be driven

The interesting design decision in this repository is visible in a table near the end of the README. Three entry points share one binary:

mcode [prompt]
mcode exec [prompt]
mcode acp

The interactive TUI is for exploring code, continuing a conversation, and reviewing changes or permission requests. `exec` is the headless mode, and the README names its audience plainly: shell scripts, CI, batch work and evaluations. `acp` speaks the Agent Client Protocol, which is how editors and other clients drive an agent.

Most coding agents ship one of these well. Splitting all three is a deliberate bet that the same session store, the same permission model and the same provider config should work whether a human is watching or a pipeline is not. The rest of the architecture follows from that. `package.json` describes the product as a standalone TUI with managed accounts, BYOK models, cloud tools, plugins and ACP, and the repository tree is a pnpm workspace with `packages/`, `scripts/`, `test/`, `docs/`, `examples/` and a `release/` directory.

A couple of local details make this more than a wrapper. There is an `.agents/` directory and an `AGENTS.md`, plus a `mcode init .` command that generates or updates project guidance in that file, so per-project instructions are part of the design rather than an afterthought.

Installing on Node 22 or 24 and why 23 is excluded

The official installer is the shortest path, and it does more than copy a binary. It installs the latest CLI, prepares a compatible Node.js runtime when needed, and does not require `sudo` or administrator privileges:

curl -fsSL https://filecdn.minimax.chat/public/install.sh | bash

On Windows the README gives the PowerShell equivalent. It installs into `~/.minimax-code` on macOS, Linux and WSL, and into `%USERPROFILE%\.minimax-code` on Windows, with launchers named `bin/mcode` and `bin/mcode-tools` on POSIX. Setting `MCODE_INSTALL_DIR` before installation moves it. The README also states a flat limitation: Alpine and musl Linux are not supported by the one-command installer.

If you already run a supported Node.js, npm is the alternative. The version requirement is the part worth reading twice, because it is not a simple floor:

"engines": {
  "node": ">=22.19 <23 || >=24.2 <27"
}

That excludes Node 23 entirely and starts 22 at a patch level. The README's compatibility badge lists Node.js 22.19+, 24.2+, 25 and 26, which matches. The npm command is unusually long, and every piece of it is deliberate: the public registry is named explicitly, the optional SQLite dependency is included, and install scripts are permitted for exactly two packages, `@minimax-ai/code` and `better-sqlite3`.

Signing in versus bringing your own key

Two account paths, and the second one does not need MiniMax at all. For a mainland China account the command is `mcode login`, and for a global account it is `mcode login --region global`. You complete sign-in in a browser, then open `mcode`, run `/status` to check the account and `/provider` to pick a model. `mcode logout` signs out. Token Plan needs an account with credits available.

BYOK works by exporting a key and adding a provider:

mcode provider add --name my-provider --base-url https://example.com/v1 \
  --api-format openai-completions --model my-model \
  --api-key-env MCODE_PROVIDER_API_KEY --use
mcode

Three API formats are supported: `openai-completions`, `openai-responses` and `anthropic-messages`. That list is the real portability story here, since it means a self-hosted or third-party endpoint speaking any of those shapes can stand in for the official API. The `--use` flag is a nice touch: it tests the first listed model before saving and selecting it, and a failed connection test saves nothing.

For custom or local models there are `--context-limit 32768 --output-limit 4096` flags, with the README noting you should use your server's actual limits. Inspect what is set with `mcode provider list --json`. Providers added this way live under `custom_provider` in the active profile's `config.yaml`, while `minimax_api` stays reserved for the official endpoint. Relays needing an `Authorization: Bearer` header on an Anthropic-compatible endpoint can set custom headers in that same file.

Where sessions live, and the data directory split

There are two different directories and they are easy to confuse. `~/.minimax-code` is the installation directory the installer creates. `~/.minimax` is the user data directory for builds from this repository and for the published npm CLI `@minimax-ai/[email protected]`, or `~/.minimax-<profile>` when a profile is selected. `MINIMAX_DATA_DIR` or `MAVIS_DATA_DIR` can override the data directory, and the README links to an accounts-and-data section before you go looking for configuration and sessions.

That the environment variable is called `MAVIS_DATA_DIR` is a naming artefact worth noticing. It is an alias kept alongside the newer name, and the existence of two spellings is a small signal about how the project evolved.

Session handling in the TUI is ordinary once you know where it is. `mcode --continue` resumes the latest session in the current workspace and `mcode --session` opens a picker; inside the TUI, `/sessions` finds previous sessions and `/help` lists commands and shortcuts. The keyboard table in the README is worth reading because it tells you what the TUI is actually optimised for: `Alt+Enter` queues a follow-up while a task runs, `Shift+Enter` inserts a newline, `@` references a workspace file, `Shift+Tab` toggles Plan Mode, and `Alt+M` switches permission modes.

A private package.json that ships a public npm CLI

Here is an internal tension worth naming rather than resolving. In `package.json`, the root declares `"private": true` and `"name": "minimax-code"`, which is the standard way to say the workspace root should never be published. At the same time, the README instructs you to install `@minimax-ai/code` from the public npm registry, and refers to the published npm CLI at version `0.4.12`, which matches the version field in the root manifest. The `release/` directory and the `release:cli` script are how those two facts coexist: the root is a workspace, the publishable artifact is built out of `packages/`.

The build tooling gives the project a specific character. It uses esbuild for bundling, TypeScript 5.9.3 for types, Vitest 4.1.11 alongside plain `node --test` files, and pnpm 9.12.0 as the package manager. There are two tsconfig files, `tsconfig.node.json` and `tsconfig.standalone.json`, and a `gen:tsconfig` script that regenerates path mappings, which suggests generated config rather than hand-maintained path lists.

The test script names are unusually revealing about what the maintainers worry about. Alongside the obvious `typecheck`, `verify` and `test:smoke`, there are `test:policy`, `test:sandbox`, `test:status-contract`, `test:capabilities` and `test:artifact`, plus `check:standalone` and `check:source`. A standalone boundary check and a policy suite in a coding agent usually mean permissions and sandbox escape are the hard problems, and that is worth knowing before you point one at a real repository.

Licensing, versioning and what the docs do not hold

The licence file says MIT, and the README badge labels it as the first-party default licence. That word default is doing real work. Alongside `LICENSE` and `NOTICE` sit `LICENSE-STATUS.md` and `THIRD_PARTY_NOTICES.md`, and a `third_party/` directory appears in the tree, so vendored or bundled components carry their own terms. Read `THIRD_PARTY_NOTICES.md` before redistributing rather than assuming the MIT grant covers the whole artefact.

Versioning is the weakest documented axis. The repository has no GitHub releases at all, and `package.json` gives the current version as `0.4.12` with the README referencing the same number for the npm CLI. A `0.x` version with no release notes in the repository means there is no changelog telling you what broke between versions, and the pinned-installation story is delegated to the installation guide, which the README links for version pinning and Node.js compatibility.

The last push was on 2026-09-20, so this is a project with recent commits behind a version number that has not yet reached 1.0. Most of the documentation is one hop away on agent.minimax.io: quick start, features, troubleshooting, model examples and installation. The repository itself holds the source, the tests and `docs/`, which includes `examples.md` and a demo page. That split is normal for a commercial-backed CLI, and it means evaluating it properly means reading both.

Editorial conclusion

MiniMax Code is worth a look if you want a coding agent that can be driven three ways without changing tools, because the same CLI answers to a prompt typed into a TUI, to `mcode exec` in a shell script, and to `mcode acp` from an editor, and the BYOK path means you are not locked into a MiniMax account to try it. The repository is honest about its sharp edges: it needs a specific set of Node.js majors, the one-command installer does not cover Alpine, and the docs live on agent.minimax.io rather than in the repo. `package.json` pins the Node range, `pnpm-workspace.yaml` describes the layout, and the `test:policy`, `test:sandbox` and `check:standalone` scripts show what the maintainers consider fragile. Start with `mcode --version` after the npm install, then decide whether `~/.minimax` or `MINIMAX_DATA_DIR` is where you want your sessions to live.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MiniMax-AI/minimax-code on GitHub
4. Project website
5. README