[Feature]: CLI - ACP: select the account profile at launch (personal and work token plans in one editor)

Start with packages/tui/src/cli/run-acp-command.ts, packages/config/src/config.ts, and packages/tui/src/acp/agent.ts to trace profile resolution, ACP startup, and initialize output. Verify the CLI accepts --profile, binds the selected data directory without changing the interactive TUI, rejects unsafe names, and reports the active profile during initialize.

Product or interface

CLI - ACP

---

中文摘要：mcode acp 启动时只调用一次 prepareTuiDataDir()，整个 stdio server 的所有 session 共享同一个 runtime、同一个账号。目前选择账号的唯一手段是 MINIMAX_DATA_DIR / MAVIS_DATA_DIR，但它是机器级全局变量 —— 给编辑器配了它，交互式 TUI 的账号也会一起被改掉。而 main 上并没有 --profile 标志：内部虽然有 profile 概念（getProfile() → ~/.minimax-<profile>），但 commander 从未注册该选项，因此 mcode acp --profile work 报 unknown option。建议让 ACP 支持按 profile 启动，并让客户端能看出当前 agent 用的是哪个账号。

Use case and problem

I build an ACP client, and I also use mcode interactively on the same machine. The two need different accounts: a personal token plan for the interactive TUI, and a work token plan for the agent inside my editor.

The account is bound once per ACP process, before the client speaks. runTuiAcpCommand resolves the data directory a single time and builds one runtime around it, and that runtime serves every session on that stdio connection:

• packages/tui/src/cli/run-acp-command.ts:59 — const dataDir = await prepareTuiDataDir()
• packages/tui/src/cli/run-acp-command.ts:60-66 — one createRuntime({ dataDir, ... surface: 'acp' }) for the whole server

So the account is decided when the editor spawns the process, and no session on that connection can be anything else. An ACP server is long-lived — an editor may keep one alive across many threads, projects, and days — so "one account per server" means "one account per machine, in practice".

The only existing lever is a machine-global environment variable. The TUI resolves its data directory as readDataDirOverride(environment) ?? getDefaultDataDir() (packages/tui/src/runtime/data-dir.ts:39-44), and the override reads MINIMAX_DATA_DIR / MAVIS_DATA_DIR from process.env (packages/config/src/config.ts:1316-1320). Setting it in my editor's agent config to give the ACP server a work account also changes the account that the interactive TUI, mcode login, and every other mcode process on that machine use. There is no per-invocation alternative today.

And --profile does not exist on main. The profile concept is already in the resolution chain — getExplicitProfileEnv() reads --profile from raw argv and resolveDataDir({ profile }) produces ~/.minimax-<profile> — but no CLI surface registers the option. getExplicitProfileEnv is cliArgValue("profile") ?? runtimeEnv("PROFILE") (packages/config/src/config.ts:1333-1336), and cliArgValue is a raw-argv scan (packages/config/src/config.ts:1220) that runs whether or not commander knows the flag. The env fallback is behind isLegacyRuntimeEnvAllowed() (packages/config/src/config.ts:83-85), so it is off unless __MAVIS_ALLOW_LEGACY_RUNTIME_ENV=1.

I verified on 0.5.8 that mcode acp --profile work is rejected as an unknown option, while the internal scanner already understands --profile — the two disagree about what the flag is.

The protocol gives the client no way to see which account it got. initialize advertises exactly one authentication method, with no account dimension:

"authMethods": [
  { "type": "terminal", "id": "minimax-code-login",
    "name": "Sign in to MiniMax Code", "args": ["login"] }
]

That is the same single entry whether the server was started on the default profile or a named one. agent/authenticate rejects any other methodId with Unknown authentication method. (packages/tui/src/acp/agent.ts:45, :461-468, :486-492), and an unauthenticated runtime fails with authRequired and the message "Run mcode login and try again." (packages/tui/src/acp/agent.ts:2110-2115).

So an ACP client can ask the user to sign in, but it cannot express which sign-in, cannot display which account is live, and cannot host a personal thread and a work thread in the same editor.

Current chain

The data-directory resolution is already profile-aware end to end; only the ACP edge and the CLI surface are missing.

• packages/config/src/config.ts:1333-1336 — getExplicitProfileEnv() = cliArgValue("profile") ?? runtimeEnv("PROFILE")
• packages/config/src/config.ts:1506 — resolveDataDir({ profile: explicitProfile })
• packages/config/src/data-dir.ts:36-42 — basenameForProfile → getPrimaryDataDirPath returns ~/.minimax-<profile>
• packages/oauth-core/src/namespace.ts:21-41 — the OAuth namespace derives both its paths and its credential key from that data directory, so a different data directory is a different token
• packages/tui/src/cli/run-acp-command.ts:59 — the single point where ACP binds it

Desired behavior

Let the ACP server start on a named profile, and let the client see which one it has.

Acceptance criteria

1. mcode acp --profile <name> starts the server bound to that profile's data directory and its stored credential. The flag is accepted on acp and on session-taking subcommands, so a client can set it in its agent args with no new protocol method.
2. initialize reports the active profile (in _meta or alongside agentInfo), so a client can display which account the agent is signed into. Today the client cannot tell a personal agent from a work agent, which is the actual problem — a wrong-account session is invisible until it bills or writes to the wrong tenant.
3. Selecting a profile never mutates another profile's directory, and never changes the account the interactive TUI uses. This is the same isolation criterion PR #227 and issue #384 held model selection to.
4. A profile name that is not usable is refused with an error, not silently replaced by the default profile. The name becomes a path segment under $HOME, so an unchecked value must not resolve outside the home directory, and a silent fallback would open the wrong account.
5. Nice to have: a per-session profile. sessionCapabilities already advertises list, fork, resume, and close (packages/tui/src/acp/agent.ts:452-457), so one long-lived server could host a personal thread and a work thread side by side instead of requiring one server per account. Baseline is (1) + (2); this is the larger win.

Interaction example

# editor agent config — baseline
command: mcode
args:    ["acp", "--profile", "work"]

initialize
  → _meta: { "minimax-code/profile": "work" }
  → authMethods: [ { id: "minimax-code-login", ... } ]   # unchanged shape

# two servers, one editor
server A: mcode acp                        → personal, threads for side projects
server B: mcode acp --profile work         → work, threads for client work

Platform

macOS (macOS 15 arm64, mcode 0.5.8, source at 9b9c07b). The gap is in the CLI/protocol surface, so it should apply to every platform.

Alternatives and additional context

• MINIMAX_DATA_DIR per client instance. Already works, and is what I use today. The problem is that it is read from process.env and is therefore machine-global in practice: the editor's agent config either leaks the work account into the interactive TUI or cannot be set without a wrapper. A first-class flag is the same isolation as mcode exec --config <path> but scoped to the account.
• A separate binary or a --lane-style internal switch. mcode --lane already exists as an internal separation mechanism, but it is rejected in the public build and is documented as internal; it is not a user-facing account selector.
• Related: #88 asks for switching between a personal and a team token plan, which is the same underlying need on the Desktop side. #384 and #176 are the same ACP surface this touches.
• I have a working implementation of criteria 1–4 on a branch (core module, the CLI flag, a mcode profile list|current|remove command, the login-restart fix, and tests) and can share a patch or a branch if that is useful. I am not a collaborator, so per CONTRIBUTING.md I am not opening a PR — happy to provide the diff for someone with push access.

Verification: mcode 0.5.8; the authMethods transcript above is a live initialize over stdio. No private project content included.