STDIO MCP servers not re-registered on `claude --resume`, causing `No such tool available: mcp__…`

Summary

When a session is resumed with claude --resume <id>, STDIO MCP servers — which are spawned as child processes per claude invocation — die with the prior process and are not reliably re-spawned/re-registered before the agent issues its first tool call. The agent then fails MCP tool calls with No such tool available: mcp__<server>__<tool> and effectively no-ops the turn.

Critically, claude mcp list (the natural pre-flight check) reports the server connection configuration, not the tool catalog the resumed agent process actually sees — so a startup probe cannot detect this. The catalog truth only shows up in the session stream's system init message and in the failing tool call.

Environment

• Claude Code CLI 2.1.111
• Linux (also observed under WSL2)
• STDIO MCP servers launched via uv / npx from a project .mcp.json

Expected

On --resume, STDIO MCP servers declared in the project's .mcp.json are re-spawned and their tool catalog re-registered before the first agent turn, identical to a cold start. Resumed and fresh sessions should expose the same MCP tool catalog.

Actual

A resumed session sometimes has an empty or partial MCP tool catalog. Tool calls no-op with No such tool available: mcp__<server>__<tool>, and/or a type:"system" init message reports the expected STDIO server failed/absent.

Reproduction

1. Register a STDIO MCP server in .mcp.json (e.g. one launched via uv or npx).
2. Start a session and confirm mcp__<server>__<tool> is callable.
3. End the session, then resume it: claude --resume <id> -p "<prompt that calls the MCP tool>".
4. Observe No such tool available: mcp__<server>__<tool> and/or a system init message reporting the STDIO server absent.

Impact

In an autonomous loop, a resumed iteration that depends on MCP tools no-ops entirely — the agent cannot reach the tools it needs and produces no useful work for that turn.

Downstream workaround (for context, not a fix)

We detect the catalog-loss signature (No such tool available: mcp__, or a system init reporting an expected STDIO server absent) on the post-run stream and retry the loop once with a fresh, non-resumed session, dropping the poisoned session id. This is a harness band-aid; the durable fix belongs in the CLI's --resume path. Happy to share more detail or test a fix.