stdio MCP servers stop responding after system sleep/wake; require full session restart to recover

stdio MCP servers stop responding after system sleep/wake; require full session restart to recover

Environment

• Claude Code: 2.1.258 (native install)
• OS: macOS 26.6.2 (Build 25G83), Apple Silicon
• Shell: zsh

Summary

When the machine goes to sleep and wakes back up, stdio-type MCP servers stop responding (their tools silently stop working / become unavailable) while the Claude Code session is otherwise still running. The only fix I've found is fully exiting and restarting the claude session — reconnecting via /mcp was not sufficient in my case. This happens repeatedly across many working sessions per day, since I put my laptop to sleep multiple times daily.

My MCP config (illustrative — multiple independent stdio servers affected)

workspaces/jl-duty/.mcp.json:

{
  "mcpServers": {
    "fff-api": { "type": "stdio", "command": "fff-mcp", "args": ["<repo path>/api"], "env": {} },
    "fff-k8s-clusters": { "type": "stdio", "command": "fff-mcp", "args": ["<repo path>/k8s-clusters"], "env": {} },
    "fff-config-state": { "type": "stdio", "command": "fff-mcp", "args": ["<repo path>/config-state"], "env": {} },
    "fff-datasci": { "type": "stdio", "command": "fff-mcp", "args": ["<repo path>/datasci"], "env": {} }
  }
}

I also have http-type MCP servers configured in the same project, which appear unaffected — only the stdio ones (fff-*, using the fff-mcp binary) break. This matches the behavior described in #43177: stdio transports have no reconnect/backoff logic, unlike HTTP/SSE/WebSocket.

Reproduction

1. Start a Claude Code session in a project with one or more stdio MCP servers configured.
2. Use an stdio MCP tool successfully (e.g. mcp__fff__find_files).
3. Put the Mac to sleep (lid close or explicit sleep), wait, then wake it.
4. Try to use the same MCP tool again.

Expected

The stdio MCP server subprocess is detected as dead/unresponsive and is automatically respawned/reconnected — same as what happens for HTTP/SSE/WebSocket servers.

Actual

The tool stops working. No visible tool-call error is surfaced in the conversation transcript when this happens (I checked my local session logs under ~/.claude/projects/*/*.jsonl for the affected project and found no isError/error entries referencing the fff tools around the time of the break — the tools just silently become unusable, which also makes this hard to notice/diagnose in the moment). The only reliable recovery is quitting and restarting the claude session.

Notes

• I'm on Claude Code 2.1.258, which per the docs should already include "re-init MCP servers on focus return" (said to be default-on since v2.1.128+), but I still need a full restart, not just refocusing the window/terminal.
• This looks like the same root cause already tracked in:
• #43177 — MCP stdio servers never auto-reconnect after disconnect (closed as "not planned")
• #54136 — Reconnect/restart MCP servers from Claude Code in Desktop
• #32116 — CLI unresponsive for ~5 minutes after laptop resume

I'm filing this as a fresh report (rather than just +1'ing #43177) because it's specifically about the sleep/wake trigger and the fact it now happens on a version that's supposed to have the focus-return re-init fix, plus the fact that no error is surfaced to the user when it happens — if this is a dup, please close in favor of the more relevant existing issue and let me know which one.

Suggested fix

Apply the same auto-reconnect/backoff logic already used for HTTP/SSE/WebSocket MCP transports to stdio transports as well — i.e. detect a dead child process and respawn it, rather than excluding stdio/sdk types from reconnection entirely.