[BUG] MCP connector tools logged as "added" but unresolvable via ToolSearch for the rest of the session

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?

Summary

In a Claude Code session (VSCode extension), the session-start transcript records a deferred_tools_delta event that successfully added 341 tools — including a full set of Atlassian Rovo (Jira/Confluence) tools and tools from six other claude.ai MCP connectors (AccuWeather, Indeed, Microsoft 365, Pilcrow, Pocket, Shutterstock, WordPress) — to the session's deferred-tool pool, with no entries in that event's pending, failed, or needsAuth lists. Despite that, every one of those 341 tools was permanently unresolvable via ToolSearch for the remainder of the session — including exact select:<toolName> queries using names copy-pasted from the log itself. A sibling session in the same IDE window, started separately, had the same connectors working normally, which rules out an account-wide connector/auth outage.

Environment

• Client: Claude Code VSCode extension (entrypoint: claude-vscode)
• Version: 2.1.258
• Session ID: 8b598963-9946-45c8-b689-92796cbcb62e
• Working directory: d:\develop\diacratic
• Git branch: main
• Event timestamp: 2026-09-03T17:12:37.527Z

Symptom

Any attempt to use a claude.ai MCP connector tool in this session fails at the discovery step:

ToolSearch({ query: "select:mcp__claude_ai_Atlassian_Rovo__getJiraIssue" })
→ "No matching deferred tools found"

This was tried repeatedly over the course of the session with both keyword queries ("jira issue get", "atlassian jira mcp", "getJiraIssue addCommentToJiraIssue transitionJiraIssue rovo") and exact select: queries against tool names taken directly from the session's own transcript, including:

• mcp__claude_ai_Atlassian_Rovo__getJiraIssue
• mcp__claude_ai_Wordpress__wp_get_categories
• mcp__claude_ai_AccuWeather__widgets-current-claude

All returned "No matching deferred tools found." No mcp__claude_ai_* tool of any kind was resolvable, for any connector, at any point in the session.

Evidence

The session's JSONL transcript (~/.claude/projects/d--develop-diacratic/8b598963-9946-45c8-b689-92796cbcb62e.jsonl) contains exactly one deferred_tools_delta attachment event in the whole session, at line index 4:

{
  "type": "deferred_tools_delta",
  "addedNames": [ /* 341 names, including CronCreate, DesignSync, ...,
                     mcp__claude_ai_Atlassian_Rovo__getJiraIssue,
                     mcp__claude_ai_Atlassian_Rovo__addCommentToJiraIssue,
                     mcp__claude_ai_Atlassian_Rovo__transitionJiraIssue,
                     mcp__claude_ai_Atlassian_Rovo__getTransitionsForJiraIssue,
                     ... 41 Atlassian_Rovo tools total ...,
                     mcp__claude_ai_Wordpress__* (many),
                     mcp__claude_ai_AccuWeather__* (9),
                     mcp__claude_ai_Indeed__* (4),
                     mcp__claude_ai_Microsoft_365__* (many),
                     mcp__claude_ai_Pilcrow__* (12),
                     mcp__claude_ai_Pocket__* (7),
                     mcp__claude_ai_Shutterstock__search ],
  "removedNames": [],
  "wireHiddenNames": [],
  "readdedNames": [],
  "pendingMcpServers": [],
  "needsAuthMcpServers": ["claude.ai Expedia", "claude.ai Gmail", "claude.ai Google Calendar", "claude.ai Google Drive"],
  "failedMcpServers": []
}

Key point: Atlassian_Rovo (and every other connector whose tools were added) appears in none of pendingMcpServers, needsAuthMcpServers, or failedMcpServers — i.e. per the session's own bookkeeping, registration fully succeeded. No later event in the transcript modifies, removes, or hides any of these names. Scanning the entire transcript for every deferred_tools_delta event confirms this is the only such event in the session.

Yet ToolSearch never surfaced any of these 341 tools, including on exact-name select: queries, from session start through end.

What this rules out

• Not an OAuth/connector-auth problem — nothing Atlassian-related appears in needsAuthMcpServers; other connectors that share that bucket (Expedia, Gmail, Calendar, Drive) are visibly distinguished from the ones that "succeeded."
• Not a Jira-specific problem — WordPress and AccuWeather tools, logged as added in the same event, are equally unresolvable.
• Not a per-repo/project config problem — this project's mcpServers config (in the global ~/.claude.json projects entry) is empty, as expected; claude.ai connectors aren't repo-scoped.
• Not an account-wide connector outage — a sibling Claude Code session, running concurrently in the same IDE window under the same account, had the Atlassian Rovo tools working normally (confirmed live: it successfully invoked getJiraIssue, though that specific call was separately blocked by the permission classifier — see below).
• Not the CLI-level /mcp command's domain — /mcp reports on locally-configured servers added via claude mcp add / project .mcp.json (it returned "No MCP servers are configured," which is correct for this repo — there are none). claude.ai account connectors are a separate subsystem from what /mcp inspects.

Root cause (best available diagnosis from inside the session)

A split between what gets logged as added to a session's deferred-tool pool (deferred_tools_delta.addedNames) and what actually gets committed to the live registry that ToolSearch queries against. In this session, the delta was written to the transcript as a successful add for all 341 tools, but the live registry never actually received (or subsequently dropped, with no compensating delta event) the entries — leaving every one of those tools permanently invisible to ToolSearch for the rest of the session, with no error surfaced to the model or user at the time it happened.

This is consistent with the user's report that this is a recurring ("ongoing") issue, and with it being session-scoped rather than account- or project-scoped: each Claude Code session appears to perform its own registration handshake at startup, and this session's registration desynced between its log and its live backing store.

Impact

Any workflow depending on a claude.ai MCP connector tool is silently unusable for the lifetime of an affected session, with no error message pointing at the actual cause — from the model's perspective, ToolSearch behaves identically to "this tool was never granted," which is indistinguishable from a legitimate permission/connector-disabled state without transcript-level forensics. In this instance it blocked implementing a Jira-tracked ticket (PIL-60) because the ticket's content couldn't be fetched.

Related secondary finding (unverified by this session, reported by a peer session)

A second, working session (with Atlassian Rovo tools correctly resolvable) attempted getJiraIssue for the same ticket (PIL-60) and reported that the call was blocked by the Claude Code auto-mode permission classifier before it reached Jira — i.e., a read-only Jira lookup was refused at the client-side permission layer rather than requiring a normal approval prompt. This may be a separate bug (an overly aggressive auto-mode classifier rule for Atlassian Rovo tools) or working as intended pending explicit user approval; it's included here because it compounded the same underlying task failure and may be relevant to the same investigation. This detail was relayed secondhand and not independently reproduced or inspected by this session.

Suggested next steps

1. Investigate why deferred_tools_delta.addedNames can report success for MCP connector tools that never become queryable via ToolSearch, and add a visible error/warning when this desync happens instead of silent unresolvability.
2. Confirm whether this is a race condition at session startup (e.g., the delta being logged optimistically before the registry write is confirmed) versus a registry entry being dropped later without a corresponding removedNames/failedMcpServers update.
3. Separately investigate the auto-mode permission classifier's handling of read-only Atlassian Rovo calls (getJiraIssue), reported above.

What Should Happen?

The tools should be loaded and useable in all sessions in this IDE.

Error Messages/Logs

Steps to Reproduce

Open a new session, run /mcp
Occasionaly nothing will be loaded.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code VSCode extension, version 2.1.258

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_