Windows: `claude --continue` does not re-spawn stdio MCP servers

Summary

On Windows, claude --continue (session resume) does not re-spawn stdio MCP child processes that were registered in the previous session. The session reports "Failed to reconnect to <server>" in /mcp output, the tools are not available in the session (not even as deferred), but claude mcp list reports the server as ✓ Connected.

Repro

1. Configure a stdio MCP server in ~/.claude.json (any working command/args will do).
2. Run claude in any project, use the MCP server's tools successfully.
3. /exit.
4. claude --continue in the same project.
5. Type /mcp.

Expected: server reconnects, tools available.
Actual: /mcp prints Failed to reconnect to <server>, no mcp__<server>__* tools registered for this session.

Evidence (specific to my setup)

I have a stdio MCP server emacs-mcp whose stdio bridge logs every spawn to /tmp/emacs-mcp.log. After a clean /exit followed by claude --continue, the log shows no new bridge spawn during the resume — i.e. the harness never even started the child process. A subsequent claude mcp list (which spawns its own probe out-of-band) does produce a log entry and reports ✓ Connected. /mcp's in-session "Reconnect" button also produces no spawn.

[12:51:47] bridge starting   ← my manual probe before /exit
[12:51:48] bridge exiting
                              ← /exit, then `claude --continue`, then /mcp Reconnect
                              ← no bridge spawn at all
[12:54:34] bridge starting   ← `claude mcp list` (separate process)

Driving the bridge manually outside the harness (echo '<initialize-rpc>' | bash bridge.sh) returns the full tool list normally — the server itself is healthy.

Environment

• Claude Code 2.1.138
• Windows 11 Pro 26200 (Git Bash + MSYS, native Emacs daemon)
• Stdio server config: { "type":"stdio", "command":"bash", "args":["…/bridge.sh"] }

Workarounds attempted

• Fresh restart of the MCP server's underlying process — no effect (server was healthy all along).
• Removing a startup-blocking warmup probe from the bridge so the read loop wakes immediately — no effect, because the harness never spawns the bridge in the first place.

Workarounds that probably help

• claude --continue --fork-session (forces a new session ID; expected to trigger fresh MCP init — untested).
• claude (fresh session, no resume) — confirmed-working, but loses prior conversation context.

Notes

• Other stdio servers (perplexity, obsidian-mcp-tools) seem to reconnect fine, so this may be specific to bash-spawned bridges or to scripts that print to stderr during startup. Worth checking whether stdio servers spawned via bash <script> (as opposed to native .exe) are the trigger.
• MCP_TIMEOUT env var did not appear to affect the outcome.