stdio MCP server: tools are not re-registered after an automatic respawn — one call succeeds, then "No such tool available" for the rest of the session

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 0 comments · opened Aug 4, 2026

Summary

When a stdio MCP server process dies mid-session, Claude Code notices, respawns
it, and logs a successful reconnect — but the conversation never gets the
server's tools back. Exactly one call (the client's retry of the failed one) is
served, and every call after that fails with

Error: No such tool available: mcp__<server>__<tool>

for the rest of the session, while that same server process stays alive and
connected. Later user messages do not restore the tools. claude mcp ... is
config-only. The only recovery is /mcp → Reconnect, typed by a human in the
pane.

Environment

  • Claude Code 2.1.221, native binary install, Linux 6.8, tmux
  • Local stdio MCP servers declared in a project .mcp.json

Steps to reproduce

  1. Configure a stdio MCP server in .mcp.json and start a session.
  2. Make the server process exit while it is handling a tools/call (a crash, or

kill <pid> from another shell).

  1. The call fails with MCP error -32000: Connection closed; the client

respawns the server and reconnects.

  1. Call a tool of that server twice.

Expected: once the client logs Successfully connected, that server's tools
are usable again.

Actual: the first call is served; every later call returns
No such tool available.

Evidence — two independent occurrences

Occurrence A — client MCP log plus the session transcript, one session:

18:49:13  Tool 'session' failed after 41s: MCP error -32000: Connection closed
18:49:15  Starting connection with timeout of 30000ms
18:49:18  Successfully connected (transport: stdio) in 2508ms
18:49:2x  tools/call  ->  served normally  (the client's retry)
18:49:41  tools/call  ->  Error: No such tool available: mcp__<server>__session

That same process stayed connected until the session exited at 20:05:37 (clean
SIGINT). Four further user messages were sent after 18:49:41, and not one
produced a successful call to that server.

Occurrence B — different session, same server, next day:

03:09:21  Tool 'session' failed after 12s: MCP error -32000: Connection closed
03:09:23  Starting connection with timeout of 30000ms
03:09:25  Successfully connected (transport: stdio) in 1606ms
03:09:25  one tools/call served
          ... then zero calls to that server for the remaining 7.5 h of the
          session

Why it reads as intermittent

The single retried call succeeding immediately after the reconnect makes the
recovery look complete. The loss only surfaces on the next call, which can be
minutes later and in the middle of unrelated work — so it presents as "the tools
vanished on their own", not as a consequence of the earlier crash.

Impact

A session silently loses a whole tool server. Work continues only by invoking,
by hand, the CLI that the tools wrap.

Note on the trigger

The crash that triggered both occurrences was a bug in our own MCP server (a
channel torn down while a worker thread still held a reference), and it is
fixed. This report is only about the client-side recovery gap: the respawn
restores the process but not the tool registry the running conversation uses.

Relevant logs: ~/.cache/claude-cli-nodejs/<project>/mcp-logs-<server>/*.jsonl
— the reconnect lines quoted above are verbatim from there.

View original on GitHub ↗