Stdio MCP servers cascade-die within seconds of connection (v2.1.150) — multiple related open issues, zero team responses

Summary

stdio MCP servers cascade-die within seconds of successful connection in v2.1.150. Affects every project that loads more than 3-4 stdio MCPs simultaneously. Issue is severe enough that the editor is effectively unusable for work that depends on MCP-backed tools (Supabase, Retell, GitHub, etc).

Environment

• Claude Code: 2.1.150 (Cursor extension + standalone CLI both affected)
• macOS: Darwin 24.6.0 (Mac Mini M4, 16 GB RAM)
• Node: v22.22.0 (nvm)
• 10 stdio MCP servers configured in ~/ClaudeCode/.mcp.json
• Each launcher is a thin bash wrapper around a globally-installed npm MCP server (e.g. mcp-server-supabase, context7-mcp, retellai-mcp-server, etc.)

Reproduction

1. Configure 8-10 stdio MCP servers in a project .mcp.json
2. Open the project in Claude Code
3. Run /mcp immediately on startup — servers show connected with tool counts
4. Wait 10-60 seconds and run /mcp again — most or all stdio servers show failed
5. HTTP-based MCPs in the same config (vercel via mcp-remote, ghl via mcp-remote) stay connected
6. User-level HTTP MCPs in ~/.claude.json (supermemory, higgsfield) stay connected

Direct Process-Level Verification

Each launcher was verified to respond correctly to a JSON-RPC initialize request via stdio outside Claude Code:

echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' | timeout 5 bash ~/ClaudeCode/scripts/mcp-launchers/supabase-admin.sh
# returns valid initialize result, server stays alive while stdin is held open

Launching the server with < /dev/null exits cleanly on EOF in ~1s (expected stdio behavior). Launching with an open stdin keeps the server alive indefinitely. So the servers themselves are healthy — Claude Code is closing stdin (or sending SIGTERM) after initial connection.

Pattern

• stdio MCPs: connect → die within 10-60s → never auto-reconnect
• HTTP MCPs (mcp-remote based): connect → stay alive → auto-reconnect on transient drops
• User MCPs (HTTP in ~/.claude.json): stable

Related Open Issues (all unresolved, no Anthropic team responses)

• #40207: stdio MCPs receive SIGTERM 10-60s after handshake (Linux, macOS, Windows confirmed; v2.1.81 through current)
• #43177: stdio MCPs never auto-reconnect; community pinpointed one-line fix in src/services/mcp/useManageMCPConnections.ts:354-356 ("Skip stdio and sdk - they don't support reconnection" comment is incorrect, reconnectMcpServerImpl already works for stdio, just isn't called)
• #39486: MCP servers disconnect in one session when another session connects to the same MCP server
• #37482: stdio stdin pipe breaks after 10-20 min, process orphaned to PID 1
• #61684: stdio MCPs disconnect on /clear, require manual reconnection

What Already Tried (None Worked)

• MCP_TIMEOUT=60000, MCP_TOOL_TIMEOUT=300000 in settings.json
• "alwaysLoad": true per-server in .mcp.json
• Globally installing every MCP package (vs npx -y)
• bash wrapper that traps SIGTERM and respawns child (Claude Code closes stdin, not just SIGTERM, so the parent exit-zeroes out and child dies)
• Reverting to v2.1.148
• Reducing simultaneous terminals
• Clearing ~/.claude/projects/*/mcpServers cache state
• Killing all orphan MCP processes before reopening

Asks

1. Apply the one-line fix in useManageMCPConnections.ts so stdio gets the same reconnect logic as HTTP/SSE (already implemented in reconnectMcpServerImpl, just isn't being called)
2. Document the actual cause of mid-session SIGTERM/stdin-close in #40207 — currently invisible to users with no --debug output explaining why
3. Either fix the cross-session contention in #39486 or document that running >1 terminal disconnects MCPs in the other terminals

This has been broken for months. Multiple GitHub issues, zero Anthropic responses. Claude Code MCP support is functionally unusable for projects that need more than 2-3 stdio servers.