[BUG] After --resume, the deferred tools delta reports a connected MCP server as "disconnected" and never re-lists its tools

Status Open
Reported on v2.1.295
Maintainer reply None cached
Activity 0 comments · opened Oct 9, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When I resume an older session with claude -r, the deferred tools delta can tell the model that a connected MCP server is gone:

165 deferred tools are no longer available (MCP server disconnected): mcp__beeper__*, mcp__firefox-devtools__* (5), mcp__happyscribe__* (6), mcp__immich__* (110), mcp__libreoffice__* (14), mcp__plugin_chrome-devtools-mcp_chrome-devtools__* (29). Do not search for them — ToolSearch will return no match.

The Beeper server was connected the whole time. The "now available" list in the same delta did not include its tools either, so nothing told the model they were usable. No later delta re-added them. The model believed the reminder, told me the server was disconnected and started working around it via the server's REST API. Three minutes later, without any /mcp reconnect, ToolSearch with select:mcp__beeper__list_messages returned the tool and the call succeeded.

The same reminder also lists mcp__libreoffice__*, a server I removed from my config in July. So the list seems to be computed against the tool set recorded in the old transcript, not against what is connected now.

I checked my transcripts from the last weeks for this pattern: a "no longer available (MCP server disconnected)" reminder for a server, followed by a successful call to the same server with no /mcp in between. Four clear cases, all right after a resume:

| Server | Transport | Gap before resume | First successful call after the reminder |
|---|---|---|---|
| Beeper Desktop | HTTP, localhost | minutes | 3 min |
| Perplexity | stdio via npx | 3 days | 7 min |
| internal SQL server | remote HTTP | 1 day | same minute |
| internal SQL server | remote HTTP | 7 days | same minute |

My guess, not verified: the delta is computed at resume before slower servers (HTTP, npx) finish connecting, and nothing sends a new delta when they do connect.

What Should Happen?

A server that is still connecting should not be reported as "disconnected" with the instruction not to search for its tools. Either the delta should wait for the initial connections to settle, or a follow-up delta should list the tools as available once the server connects. Servers removed from the config should not appear in the "disconnected" list.

Error Messages/Logs

The reminder quoted above. There is no error. The server works and the calls succeed.

Steps to Reproduce

  1. Configure an MCP server that takes a moment to connect (HTTP or npx stdio).
  2. Use one of its tools in a session, then exit.
  3. Later, resume that session with claude -r.
  4. Look at the first deferred tools delta: the server is listed under "no longer available (MCP server disconnected)" and its tools are not in the "now available" list.
  5. Run ToolSearch with select:mcp__<server>__<tool>: the tool is found and works.

I have not reproduced this on demand. It happened on 4 of the resumes I checked, so it may be timing dependent.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.295 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Konsole (KDE), bash

Additional Information

Possibly related to #97369 (the deferred tools record is replayed on resume), but the symptom here is a connected server announced as disconnected, not a stale tool description.

View original on GitHub ↗