[Bug]: [Windows] 3.1.7 removes the bundled `mavis` CLI but leaves orphaned PATH launchers, and the shipped mavis-doctor skill still sends agents to the deleted `mavis doctor` command

Start by locating the installer logic that refreshes mcode-tools*.cmd and mavis-trash.cmd, then trace how it handles mavis.cmd and minimax.cmd when the daemon CLI is removed. Also inspect the shipped mavis-doctor, mavis-team, and skill-evolve-nightly skill files named in the report. Define done by ensuring upgrades leave no silent launchers and the shipped skills no longer direct users to retired commands.

Product or interface

Desktop app

Version

3.1.7.194 (Electron 42.8.0), Windows x64

Platform

Windows

OS version and architecture

Windows 11 Pro x64 (build 26300)

Issue area

Startup / install / update

Steps to reproduce

1. Upgrade the MiniMax Code desktop app from 3.1.4 to 3.1.7 on Windows (per-user install into %LOCALAPPDATA%\Programs\MiniMax Code).

2. Open any shell and run a retired mavis CLI subcommand:

   mavis doctor
   

3. The command exits with code 1 and prints nothing at all — no error, no usage text, no stack trace.

4. The same silent exit-1 happens for every other retired subcommand: mavis agent list, mavis session list, mavis session messages, mavis skill ..., mavis communication ..., mavis cron ..., mavis memory ..., mavis hook ..., mavis spawn ... and mavis team ....

5. Meanwhile the in-app native mavis tool works normally — agent list and session list both answer correctly, and the runtime is healthy (PRAGMA integrity_check = ok, runtime logs writing live, 69 sessions in local_runtime_sessions).

Expected and actual behavior

Expected: either (a) the retired CLI still runs, or (b) the launcher tells the user clearly that the command was removed and what to use instead. A command that dies silently with exit 1 gives the user nothing to act on — and, worse, agents following shipped instructions treat it as a transient failure.

Actual: mavis and minimax on PATH are orphaned launchers that point at a file the app no longer ships, so they exit 1 with no output.

Root cause

There are two independent defects. The first produces the silent exit-1; the second is why nobody noticed that the first one had already happened.

(a) The installer refreshes some PATH launchers but leaves the retired ones pointing at a deleted file

3.1.7 no longer ships resources\resources\daemon\, which is where the daemon CLI lived. Searching all 353 MB of resources\app.asar confirms:

• there is no daemon/cli.js anywhere in the archive,
• there is no cli.js for the daemon (the only cli.js files left belong to third-party packages),
• and there is no code path in the app that writes mavis.cmd or minimax.cmd — nothing recreates them.

But the launchers survive in the user profile, pointing at the file that is gone:

@echo off
chcp 65001 > nul
set ELECTRON_RUN_AS_NODE=1
"C:\Users\<user>\AppData\Local\Programs\MiniMax Code\MiniMax Code.exe" "C:\Users\<user>\AppData\Local\Programs\MiniMax Code\resources\resources\daemon\cli.js" %*

The file timestamps show the installer updated the other launchers and skipped these two:

Launcher in %USERPROFILE%\.minimax\bin\	Last written	Target still exists?
mcode-tools.cmd	2026-10-30 17:26	yes
mcode-tools-global.cmd	2026-10-30 17:26	yes
mavis-trash.cmd / mavis-trash.js	2026-10-30 17:27	yes
mavis.cmd	2026-07-11 09:57	no
minimax.cmd	2026-07-11 09:57	no

So a 3.1.4 install writes five launchers, and the 3.1.7 installer refreshes three of them and leaves the two that point at removed code.

The retirement is clearly intentional — 3.1.7 ships dist/service/turn-system/persistence/cli-sunset-notice.js:

const REMOVED_CLI_PATTERN = /\bmavis\s+(?:agent|communication|cron|session|memory|skill|hook|spawn)\b/;
const TEAM_CLI_PATTERN = /\bmavis\s+team\b/;
const NOTICE_WINDOW_MS = 30 * 24 * 60 * 60 * 1000;

That module scans the user's files and fires a 30-day compatibility notice when it finds text still instructing the removed subcommands. It is the right mechanism for instructions, but it does not cover the launchers themselves — nothing rewrites, removes, or even explains mavis.cmd.

(b) The shipped mavis-doctor skill still sends every agent to the deleted command

mavis-doctor is a skill shipped inside the app itself, at node_modules/@mavis/local-runtime-v2/assets/agents/mavis/skills/mavis-doctor/. Its SKILL.md opens with the routing rule:

启动、认证、运行时归属、dataDir 或全局故障：先运行 mavis doctor --json，再读 references/global-triage.md。

and references/global-triage.md repeats it as the very first step of the whole global triage:

Start with runtime truth

先运行：

mavis doctor --json

JSON 顶层包含 requestSurface 与 runtime；记录并使用 .runtime.runtimeOwner、.runtime.runtimeMode、.runtime.paths.dataDir、.runtime.observability.runtimeLogDir、.runtime.observability.runtimeEventsDir…

So the skill's single documented entry point is a command that no longer exists, and the JSON fields it tells you to read (.runtime.paths.dataDir, .runtime.runtimeOwner) are not reachable by any other shipped route. I could not find a surviving implementation: there is no daemon/cli.js, no requestSurface symbol in the archive, and mcode is not installed on this machine either.

The practical effect is that any agent asked to diagnose a runtime, startup, dataDir or permission problem is directed at a dead command on its first instruction, and then has to rediscover the layout by hand.

(c) Two shipped skills still teach the removed subcommands

The same cli-sunset-notice.js patterns match files that ship with the app:

• agents/mavis/.builtin-skills/mavis-team/SKILL.md and its references/commands-windows-powershell.md / commands-macos-linux.md use mavis agent list, mavis communication peers, mavis session messages and the whole mavis team plan … surface.
• .internal-skills/skill-evolve-nightly/SKILL.md uses mavis skill signal list, mavis skill proposal list/mark-acted/cancel/info and mavis communication send. Its own header says it is "Managed by daemon's internal scheduler" on a 0 2 * * * schedule — the nightly job it describes can no longer run.

Redacted error summary

> mavis doctor

> echo %ERRORLEVEL%
1

There is no output to redact — the failure is silence. The launcher content is:

@echo off
chcp 65001 > nul
set ELECTRON_RUN_AS_NODE=1
"C:\Users\<user>\AppData\Local\Programs\MiniMax Code\MiniMax Code.exe" "C:\Users\<user>\AppData\Local\Programs\MiniMax Code\resources\resources\daemon\cli.js" %*

MiniMax Code.exe starts with ELECTRON_RUN_AS_NODE=1 and is handed a path that does not exist, so it exits 1 immediately with nothing on stdout or stderr.

Runtime health, for contrast — all of this is fine:

PRAGMA integrity_check            -> ok
local_runtime_sessions            -> 69 rows, current session status=started
v2/observability/logs/runtime-*.log -> writing live
native mavis tool: agent list     -> ok
native mavis tool: session list   -> ok

Impact

• Every Windows user who upgrades to 3.1.7 silently loses the mavis and minimax commands, with no indication that they were retired.
• Any workflow, script, scheduled task or skill that shells out to mavis <subcommand> starts failing with an opaque exit 1.
• The shipped diagnostic skill points at the removed command, so runtime diagnosis is broken exactly when it is needed.
• The mavis-team and skill-evolve-nightly skills instruct subcommands that no longer exist, and will trip the 30-day sunset notice for their own users.

Suggested fixes

1. Make the updater retire the launchers it invalidates. When 3.1.7 removes resources\resources\daemon\, the installer should delete (or rewrite) mavis.cmd / minimax.cmd in %USERPROFILE%\.minimax\bin\, exactly as it already refreshes mcode-tools*.cmd and mavis-trash.cmd. A launcher that survives pointing at removed code is the bug.
2. If the launchers must survive, make them fail loudly. A one-line explanation plus the replacement (in-app native mavis tool) is strictly better than a silent exit 1. A minimal local workaround is to resolve the target at runtime and print a retirement notice when it is missing:

   if exist "%MAVIS_CLI%" goto run_cli
   echo The 'mavis' CLI was removed from the desktop app in 3.1.7; use the in-app 'mavis' tool.
   exit /b 1
   :run_cli
   "%MAVIS_APP%" "%MAVIS_CLI%" %*
   

3. Update the shipped mavis-doctor skill so it no longer routes agents to mavis doctor --json. It should point at surfaces that actually exist in 3.1.7 — the v2 SQLite (v2/sqlite/runtime-state.sqlite), v2/observability/logs/runtime-*.log, v2/observability/events/*.jsonl, v2/runtime-owner-leases/ and the native mavis tool — and document how to read .runtime.paths.dataDir without the CLI.
4. Refresh the shipped skills that teach removed subcommands (mavis-team, skill-evolve-nightly), so the app does not ship instructions it has itself retired.

Before submitting

• I have searched existing issues.
• I have included my version and removed sensitive information.