MCP servers don't respawn after process death mid-session

Description

When an MCP server process dies (killed, crashed, OOM, or stale code cleanup), the session permanently loses access to that server's tools. There is no recovery mechanism — the user must start a new session.

Reproduction

1. Start a Claude Code session with MCP servers configured (e.g., a custom Substack MCP server)
2. Use pkill or kill to terminate the MCP server process
3. Attempt to use any tool from that MCP server
4. Result: "MCP server disconnected" — tools are gone for the rest of the session

Expected Behavior

Claude Code should detect MCP server process death and attempt to respawn the server using the original configuration from .claude.json or .mcp.json. If respawn fails after N retries, report the failure clearly.

Context

This is a significant pain point in environments where:

• MCP server code is actively being developed and updated (stale processes cache old code)
• Multiple Claude Code sessions share MCP servers and one kills a shared process
• MCP servers crash due to transient errors (network timeouts, API rate limits)
• Long-running sessions need persistent tool access

Currently the only workaround is starting a new session, which loses all conversation context.

Related Issues

This compounds with other MCP connection fragility:

• Playwright MCP hardcodes WebSocket UUIDs that go stale on browser restart (workaround: --cdp-endpoint http://localhost:PORT)
• Claude-in-Chrome native messaging host conflicts between Claude Desktop and Claude Code (Desktop's host wins the race)

Environment

• Claude Code v2.1.96
• macOS Darwin 25.3.0
• MCP servers: stdio-based (Python, Node)