v0.64.0 — the red row that lied

moshcode mcp install has been registering servers with Claude Code since the day the command shipped. It just spent that whole time telling people it hadn't.

What it looked like

Run an install twice — which is the normal way to use it, because you re-run it whenever you add an engine or a new machine:

· registering rssamplifier → https://rssamplifier.com/mcp across MCP engines…
   claude    ✗ failed (code 1)
   gemini    not installed — /install gemini
   codex     ✓ added
   opencode  ✓ added
   privacycode ✓ added

One red row, in a column of green ones. Read from a box that already had the server, that summary says exactly one thing: moshcode cannot register with Claude Code. So you go and type claude mcp add --transport http rssamplifier https://rssamplifier.com/mcp by hand — registering a server that was already registered, to fix a bug that did not exist.

Why it said that

Claude Code exits 1 when the server is already there, with MCP server rssamplifier already exists in user config. So does Gemini. OpenCode, for the identical no-op, prints a cheerful green box and exits 0.

The fan-out only had the exit code to go on, and an exit code cannot tell "I refused" from "there was nothing to do". Every engine that reports a duplicate honestly got painted as a failure, and the whole command exited 1 along with it — so any script gating on moshcode mcp install broke the second time it ran.

runCmd inherited the child's stdio, which is right for installers whose output nobody parses but left no way to read the one line that settles it. It now has an opt-in capture that tees — the terminal sees exactly what it saw before, and the fan-out gets the text. An engine that says the server is already there is reported as already registered, in grey, alongside the other rows where nothing needed doing. A failure for any other reason is still a failure, in red, and still exits 1.

   claude    already registered
   gemini    not installed — /install gemini
   qwen      ✓ added
   codex     ✓ added
   opencode  ✓ added
   privacycode ✓ added

qwen joins the fan-out

Chasing the above meant checking every agent CLI on the box against its own --help rather than against what moshcode believed about it, and one engine had been misfiled. Qwen Code is a Gemini CLI fork and kept the entire mcp add surface — same -s/-t/-e/-H, same "URL or command" positional — while moshcode listed it under no MCP support. It now shares gemini's argv builder outright, so the two can only drift on purpose.

The rest of the roster was checked and left alone, which is worth stating so nobody re-checks it: kimi still has no mcp subcommand at all, openagents exposes an MCP server rather than registering one, deepseek-code exits silently even for --help, and aider genuinely has none.

The flag that did nothing, loudly

One more thing surfaced while testing, and it is the sharpest of the three. mcp install <url> --dry-run wrote to every engine's config.

--dry-run is not an mcp flag. Typed after a remote URL it was never matched as a flag, so it fell through into args — and args is what every remote builder discards, because a URL server takes no command arguments. The flag vanished with no error and the install proceeded at full speed. Someone asking for a preview got five config files written instead.

Anything left over after a remote URL is now an error, raised before a single engine runs. Arguments after -- are still the user's own command line and are still not second-guessed.

Note

If you hand-added an MCP server to Claude Code because moshcode said it failed, nothing is broken — you registered what was already there. claude mcp get <name> will confirm it, and re-running moshcode mcp install now says so plainly.