Auto-reconnect (or provide `claude mcp reconnect <name>`) for dead stdio MCP servers — they currently wedge with no in-session recovery

Summary

When a stdio MCP server subprocess dies or gets into a bad state mid-session, Claude Code marks it failed and never respawns it. Every subsequent tool call to that server fails until the user fully restarts Claude Code. HTTP/SSE servers already auto-reconnect with backoff; stdio servers do not. In practice this hits npx @playwright/mcp@latest hardest, because it's the most common stdio server and its browser subprocess wedges relatively often (crashed tab, profile lock, macOS sleep/wake).

There are several related reports (#43177, #57207, #38138, #36308) — all of which have been auto-closed (not planned / duplicate) despite clear demand and an identified fix location. This issue consolidates them with a concrete real-world reproduction from a persistent-profile setup and a specific ask.

Real-world reproduction

Setup: Playwright MCP configured as a persistent profile (default — to keep logins alive across sessions).

1. A browser session gets into a bad state (in our case a profile lock held after a prior session didn't cleanly release — Chromium SingletonLock).
2. Every browser_navigate call then returns:

``
Error: Browser is already in use for /Users/<user>/Library/Caches/ms-playwright/mcp-chrome-<hash>,
use --isolated to run multiple instances of the same browser
``

1. This never recovers within the session. Retrying does nothing. The tool is effectively dead for the rest of the conversation.
2. The only fix is a full Claude Code restart.

We hit this across an extended multi-turn session — the browser was unusable start to finish, with no way to bring it back without abandoning the session.

Why the existing workarounds don't solve it

• Deleting the lock files (SingletonLock/SingletonSocket/SingletonCookie) doesn't help — see microsoft/playwright-mcp#1245: the MCP server's internal state stays "in use" even after the lock is gone. Only restarting the server process fixes it.
• --isolated avoids the lock but throws away persistent logins on every launch — a non-starter for anyone relying on saved authenticated sessions (the whole reason to use a persistent profile).
• Full Claude Code restart works but is a sledgehammer: it also restarts every other MCP server and interrupts any other work running in that window.
• Per-lane isolation (a distinct --user-data-dir per server, the maintainer-recommended pattern in microsoft/playwright-mcp#1294) reduces frequency and blast radius, but a single wedged lane still can't be recovered in-session.

Root cause (as noted in the now-closed #43177)

The disconnect handling doesn't respawn stdio transports. As #43177 points out, the reconnect machinery (reconnectMcpServerImpl() and the existing exponential-backoff logic used for HTTP/SSE) already spawns a fresh subprocess for stdio when invoked — it's simply never triggered for stdio on failure. So the fix appears to be wiring existing reconnect logic to stdio, not building something new.

Proposed fix (any one helps; ideally 1 + 2)

1. Auto-reconnect stdio servers on the next tool call. If a stdio server is marked failed/disconnected, transparently respawn it (reusing the existing backoff: 1s → 2s → 4s …) before failing the call. This makes the wedge self-healing.
2. Add claude mcp reconnect <name> / a /mcp reconnect action for a targeted recovery that restarts only the one wedged server — leaving other servers and in-flight work untouched. (Requested in the closed #57207, #38138.)
3. Optional: keep-alive health pings to detect a dead stdio subprocess proactively rather than on next use.

Impact

• Affects the single most common MCP server (Playwright), so it's high-frequency across the user base.
• Especially painful for persistent-login / multi-lane setups, where --isolated isn't an acceptable workaround.
• Turns an otherwise-recoverable transient failure into a session-ending one.

Environment

• Claude Code: native install (current as of 2026-07-30)
• OS: macOS 14.6.1, Apple M2
• Node: v25.8.1
• MCP server: npx @playwright/mcp@latest (stdio), persistent profile

Related (all currently closed)

• anthropics/claude-code#43177 — stdio servers never auto-reconnect (closed: not planned)
• anthropics/claude-code#57207 — claude mcp reconnect <name> (closed: not planned)
• anthropics/claude-code#38138 — claude mcp restart command (closed: duplicate)
• anthropics/claude-code#36308 — auto-reconnect mid-session (closed: duplicate)
• microsoft/playwright-mcp#1245 — state not released after close (lock deletion insufficient)
• microsoft/playwright-mcp#1305 — stuck "already in use" after failed sequence
• microsoft/playwright-mcp#1294 — per-user-data-dir isolation (recommended mitigation)