MCP stdio servers never auto-reconnect after disconnect

Bug

When a stdio-type MCP server process dies or disconnects, Claude Code marks it as failed and never attempts reconnection. HTTP/SSE/WebSocket servers get automatic reconnection with exponential backoff (5 attempts), but stdio servers are explicitly excluded. Users must manually run /mcp to reconnect.

Root Cause

File: src/services/mcp/useManageMCPConnections.ts
Lines: 354-356

// Handle automatic reconnection for remote transports
// Skip stdio (local process) and sdk (internal) - they don't support reconnection
if (configType !== 'stdio' && configType !== 'sdk') {

The comment says "they don't support reconnection" but this is incorrect. reconnectMcpServerImpl() in src/services/mcp/client.ts:2137 works for ALL transport types — it calls connectToServer() which handles stdio by spawning a new subprocess. Reconnecting a stdio server just means respawning the process.

On the else branch (line 466), stdio servers are simply marked as failed with no retry:

} else {
    updateServer({ ...client, type: 'failed' })
}

The Fix

One-line change at line 356 of useManageMCPConnections.ts:

Before:

if (configType !== 'stdio' && configType !== 'sdk') {

After:

if (configType !== 'sdk') {

The existing exponential backoff logic (5 attempts, 1s → 2s → 4s → 8s → 16s) and reconnectMcpServerImpl() already handle stdio correctly. They just need to be allowed to run.

Impact

This primarily affects Playwright MCP (npx @playwright/mcp@latest), the most common stdio MCP server. The subprocess frequently dies due to browser tab crashes, timeout errors, idle timeouts, or macOS sleep/wake cycles. Every disconnect requires manual /mcp intervention, which breaks workflow — especially during multi-step automated tasks.

Any custom stdio MCP server is equally affected.

Environment

• Claude Code 2.1.x (CLI and VS Code extension)
• macOS (Darwin 25.3.0)
• Playwright MCP configured as stdio type