[Bug] /mcp reconnect kills already-connected stdio servers via shared batch deadline (-32000)

Bug Description

/mcp reconnect inside a live Claude Code session sends SIGINT to already-successfully-connected stdio MCP servers, producing MCP error -32000: Connection closed — but the same servers connect reliably when health-checked outside the live session (claude mcp get <name>, claude mcp list). This points to a race condition specific to the interactive /mcp reconnect flow, distinct from server-startup-time or per-server-timeout issues.

This looks like the same underlying class of bug as #20713 and #30147, but both are now closed/locked, and the symptom is still present. Filing fresh with concrete log evidence pinpointing the failure to the interactive reconnect path specifically.

Steps to Reproduce

1. Configure two stdio MCP servers with different (but both multi-second) startup times — in my case one waits ~6s on a post-initialize roots/list round trip (chrome-devtools-mcp), the other has a ~7s cold-start (google_workspace, a uv/Python-based server).
2. Start a Claude Code session, run /mcp, choose reconnect for both servers (or trigger a reconnect-all).
3. Observe Failed to reconnect to <server>: -32000 for both, even though each server's handshake completed successfully according to the debug logs.
4. Immediately after, run claude mcp get <server> (standalone) or claude mcp list for the same servers — both connect successfully every time.

Debug Log Evidence

From ~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-chrome-devtools/*.jsonl and mcp-logs-google-workspace/*.jsonl for the same /mcp reconnect invocation (same sessionId, log file created at 02:05:14.971Z):

# chrome-devtools — fully connects, then sits idle, then killed
{"debug":"Successfully connected (transport: stdio) in 2193ms", "timestamp":"...02:05:20.287Z"}
{"debug":"Connection established with capabilities: {...}", "timestamp":"...02:05:20.291Z"}
{"debug":"Received ListRoots request from server", "timestamp":"...02:05:20.342Z"}
{"debug":"Sending SIGINT to MCP server process", "timestamp":"...02:05:26.758Z"}
{"debug":"UNKNOWN connection closed after 6s (cleanly)", "timestamp":"...02:05:26.796Z"}

# google_workspace — slow cold start, connects, killed 80ms later
{"debug":"Starting connection with timeout of 30000ms", "timestamp":"...02:05:19.403Z"}
{"debug":"Successfully connected (transport: stdio) in 7275ms", "timestamp":"...02:05:26.677Z"}
{"debug":"Connection established with capabilities: {...}", "timestamp":"...02:05:26.678Z"}
{"debug":"Sending SIGINT to MCP server process", "timestamp":"...02:05:26.759Z"}

Key observations:

• Both servers receive SIGINT within 1ms of each other (02:05:26.758 vs 02:05:26.759), despite chrome-devtools having been idle/connected for 6.4s and google_workspace having just connected 0.08s earlier. This is not each server hitting its own timeout — it's a shared deadline across the whole reconnect batch.
• The per-server "Starting connection with timeout of 30000ms" log line shows the individual connection timeout is 30s, so the ~12s-from-batch-start kill is coming from somewhere else (a batch-level or UI-level deadline), not the documented per-connection timeout.
• ListRoots (server→client roots/list request) is not new/broken behavior — the same request appears in this project's chrome-devtools logs from before the regression (June, on an earlier Claude Code version) with no subsequent kill; the connection just continued working normally.
• Isolated re-tests immediately after the failed reconnect, using claude mcp get chrome-devtools, claude mcp get google_workspace, and claude mcp list (all 14 configured servers at once), succeeded every time — ruling out .mcp.json misconfiguration, server bugs, or general batch size/resource contention as the cause.

Interpretation

The interactive /mcp reconnect command appears to apply some kind of overall deadline to the reconnect batch and force-kill (SIGINT) every server process still tracked as part of that batch once the deadline passes — even servers whose connection already completed successfully moments earlier. Servers with multi-second handshake/startup time (slow cold boot, or a request/response round trip like roots/list right after initialize) are the ones affected, since they're the ones still "in flight" when the deadline fires.

Environment

• Claude Code: 2.1.214 (auto-updated from 2.1.212 on 2026-07-18; symptom onset coincides with this update)
• OS: macOS (Darwin 25.5.0)
• Node: v22.22.3
• Affected servers reproduced with: chrome-devtools-mcp@1.6.0 (stdio, npx-launched wrapper), a uv/Python-based google_workspace MCP server (stdio)

What Should Happen

/mcp reconnect should not kill a server connection that has already completed its MCP handshake, and any batch-level deadline should be scoped per-server (matching the existing 30s per-connection timeout) rather than applied as a hard wall-clock cutoff across the whole reconnect batch.

Related

• #20713 (closed/locked, same -32000 symptom, race-condition theory, never actually fixed across 4 prior re-filings)
• #30147 (closed, stdin closed before initialize — same family of "kills a server that's actually fine" bug)