Skip to content

minimax-code.md

Latest commit

 

History

History
190 lines (145 loc) · 7.64 KB

minimax-code.md

File metadata and controls

190 lines (145 loc) · 7.64 KB
Raw

MiniMax Code Provider

Overview

The mcode provider runs the interactive MiniMax Code CLI (mcode) as a long-lived, multi-turn agent in a CAO tmux window. CAO injects the selected agent profile and skill catalog in a bootstrap turn, then exposes orchestration tools such as handoff, assign, and send_message through a terminal-local MiniMax Plugin.

The provider targets the public @minimax-ai/code package and its full-screen TUI. Status and response extraction are calibrated against 0.1.2; a later release can require fixture updates if its visible markers change.

Install and authenticate

Install the public package and authenticate once outside CAO:

npm install -g @minimax-ai/code
mcode login
mcode --version

MiniMax Code can also use provider credentials configured in its normal config.yaml. Never put access tokens or API keys in a CAO profile or commit them to a repository.

Quick start

cao install developer --provider mcode
cao-server
cao launch --agents developer --provider mcode

Pin a profile to this provider with frontmatter:

---
name: minimax_developer
description: Developer backed by MiniMax Code
provider: mcode
role: developer
---

Implement the requested change and verify it.

CAO sets defaultModel only in the terminal-local copy of config.yaml. Selection precedence is an explicit session/terminal API model parameter, then the profile's model:, then the user's saved defaultModel. If none is set, CAO uses minimax/MiniMax-M3. The user's normal configuration is not modified. Saved legacy and custom selections, already-qualified model keys, and provider settings are preserved. Any explicit bare model ID is normalized to a minimax/<model-id> key; for example, MiniMax-M3 becomes minimax/MiniMax-M3. The qualified key follows MiniMax Code's configured managed or API-key model source.

For example, add this frontmatter to an mcode agent profile and launch it with cao launch --agents <profile-name> --provider mcode:

provider: mcode
model: minimax/MiniMax-M3

cao launch has no --model option. Model selection is configured through the profile or the session/terminal API instead.

M3 is the verified default for this adapter. The public @minimax-ai/code@0.6.12 package requires qualified provider/model keys and includes M3 in its managed and API-key catalogs. Its Flash entry is MiniMax-M3.1-Flash-Preview, not the final MiniMax-M3.1-Flash key, so CAO does not advertise final Flash support or alias that key to Preview. The CLI owns model discovery and inference; the CAO /agents/providers response retains its common name, binary, installed shape.

Runtime behavior

CAO launches a command equivalent to:

env MINIMAX_DATA_DIR=<private-terminal-data> TERM=xterm-256color \
  mcode '<profile, skill catalog, policy, and bootstrap instruction>'

The bootstrap asks MiniMax Code to retain the supplied instructions and reply with CAO_MCODE_READY. CAO waits for that turn to settle before delivering the first task. Later inbox messages use one Enter after bracketed paste. MiniMax Code can queue input while it is processing, so eager inbox delivery is supported.

CAO recognizes the TUI's Loading or Running activity line as processing, the approval picker as waiting for a user answer, and Completed in followed by the composer as completion. Last-message extraction returns the final assistant block only; thinking rows, tool chrome, duration notes, and the composer are omitted.

Authentication and Plugin isolation

Every terminal receives a deterministic private directory below:

<CAO_HOME_DIR>/providers/minimax_code/<sha256-terminal-id>/

CAO copies only these existing authentication/configuration paths from MINIMAX_DATA_DIR (or ~/.minimax):

  • config.yaml
  • local-runtime.auth.json
  • cli-auth/

It does not copy user-installed Plugins. The private root and directories use mode 0700; copied and generated files use mode 0600. CAO deletes the exact terminal directory during normal cleanup and can reconstruct that cleanup after a cao-server restart.

For profiles with mcpServers, CAO generates a local MiniMax Plugin containing servers.mcp.json. Stdio servers receive the terminal-specific CAO_TERMINAL_ID; URL-based http and sse profile entries are serialized as MiniMax Code's streamable-http and sse transports with their headers intact. Tool-call timeout is set to 600 seconds so synchronous handoffs are not cut off by the default MCP timeout. Absolute executable paths are converted to a bare command plus a terminal-local PATH prefix because the MiniMax Plugin schema requires PATH-resolved commands.

MCP servers declared by installed agent plugins are merged into that generated Plugin at launch time, alongside the profile's own — recomputed on every terminal creation rather than persisted, so the paths never go stale. One constraint is specific to this provider: the MiniMax Plugin schema accepts only server names matching ^[a-z][a-z0-9]*(?:[._-][a-z0-9]+)*$, so an agent-plugin server named e.g. Acme is skipped for mcode with a report and delivered normally to other providers. It is skipped rather than passed through because the serializer rejects such a name while the terminal is being created, which would cost you the agent rather than one tool.

Tool restrictions

MiniMax Code has no public native flag for CAO's allowedTools vocabulary. Restricted profiles receive the shared CAO security instructions in the bootstrap prompt. This is soft, advisory enforcement: the model can ignore the instructions, so do not use mcode for security-critical restricted workers. --yolo still resolves the CAO profile to unrestricted ['*'].

The generated Plugin includes only MCP servers declared by the selected profile. This narrows the injected Plugin surface but does not hard-disable MiniMax Code's built-in tools.

Troubleshooting

Login screen or authentication error

Run mcode login in a normal terminal and confirm mcode starts successfully. If MINIMAX_DATA_DIR is set, authenticate in that same data directory.

Orchestration tools are missing

Confirm cao-mcp-server is installed in the same Python environment as cao-server, then recreate the terminal. CAO regenerates the Plugin and its terminal ID at launch.

Terminal remains processing or output is incomplete

Attach to the tmux session and inspect the visible Loading, Running, approval, and Completed in markers. Include a scrubbed pane capture and mcode --version when reporting a parsing regression.

Validation

PYTHONPATH=src .venv/bin/python -m pytest \
  test/providers/test_minimax_code_unit.py \
  test/providers/test_provider_manager_unit.py -k minimax_code \
  -q -o 'addopts='

PYTHONPATH=src .venv/bin/python -m pytest -m e2e \
  test/e2e/test_handoff.py test/e2e/test_assign.py \
  test/e2e/test_send_message.py test/e2e/test_allowed_tools.py \
  test/e2e/test_supervisor_orchestration.py \
  -k MiniMaxCode -v -o 'addopts='

Agent-plugin MCP working directory

Its MCP config format has no working-directory key (checked against the vendor's own MCP documentation, 2026-09-16), so CAO carries an agent plugin's declared cwd by launching the server through /bin/sh -c 'cd -- "$1" && shift && exec "$@"'. exec replaces the shell, the environment passes through, and argument boundaries survive because each argument stays a separate argv element. On a host with no /bin/sh such a server is skipped with mcp.cwd_unsupported rather than started in the wrong directory. See Agent Plugins for the full per-provider table.