[BUG] ### Title Plugin MCP server tools intermittently never register in-session despite `claude mcp list` showing "Connected"

I've seen this pattern a lot. The tools ARE connecting initially (hence claude mcp list shows "Connected") but the actual ools/list response during session initialization fails or arrives late.

Quick way to verify: wrap the server with a transcript proxy to capture the full JSON-RPC exchange during session start:

ash
pip install mcp-debug-proxy
mcp-debug --out session.json -- python your_server.py


Then connect Claude Code. After it fails, check the report — it'll show whether ools/list was called, what it returned, and how long it took. If the response arrives after Claude's timeout window (common with slow-starting servers), that explains the intermittent behavior.

The fix is usually: make sure your server's ools/list handler returns within Claude's timeout (around 10s). Adding a warmup phase before listing tools helps.

Here's what Claude debugged.

Agent-view worktree sessions fail to launch: plugin MCP bootstrap is fail-closed (sendFailed: Server not found: <server>)

<!--
Repo: https://github.com/anthropics/claude-code/issues
Suggested labels: bug, vscode-extension, mcp, worktrees
-->

Summary

Launching a worktree-isolated agent from the VSCode extension's agent view fails on the very
first turn with:

Error: (sendFailed) Error: Server not found: <plugin MCP server name>

The worktree and its branch are created, but the session dies immediately. The session appears to
receive the manifest of plugin-provided ("Workspace"-scoped) MCP servers it should have, but never
connects them, and the bootstrap is fail-closed: it aborts the first send on the first
unconnected server. Persistently disabling that server just advances the identical error to the
next plugin MCP server in line. The main (non-worktree) window connects the same servers without
issue, and the CLI / subagent worktree path works perfectly - so this is specific to the
agent-view worktree launcher, not git, not the OS, and not the model/agent chosen.

Environment

| | |
|---|---|
| Claude Code VSCode extension | 2.1.219 (win32-x64) |
| Claude CLI | 2.1.219 |
| VSCode | 1.130.0 |
| OS | Windows 11 Pro 10.0.22631 |
| Node | v18.20.8 via nvm-for-Windows (C:\nvm4w\nodejs); plugin MCP servers launch via npx |
| Plugin MCP servers enabled | context7, cwm-roslyn-navigator (dotnet-claude-kit), roslyn-lsp |

Steps to reproduce

1. Enable one or more plugin-provided MCP servers (they appear under Workspace in the agent

view's MCP Servers panel).

1. In the agent view, start any agent with worktree isolation.
2. Observe: "Created isolated worktree for branch agents/<name>", immediately followed by

Error: (sendFailed) Error: Server not found: <first plugin MCP server>.

1. Persistently disable that plugin (session-scoped "Disable (Session)" is not sufficient - see

defect #2). Relaunch. The error advances to the next plugin MCP server.

1. Switching the selected agent or model makes no difference - the failure is agent-independent.

Observed progression in our testing: context7 -> (disabled) -> cwm-roslyn-navigator -> ...

Expected

The worktree session should start successfully, connecting the same plugin MCP servers the main
window connects (or degrading gracefully / fail-open if one cannot start), exactly as the main
window and the CLI worktree path already do.

Actual

The first send is aborted with sendFailed: Server not found: <server> and the session is dead.

Evidence

<details>
<summary>Main window connects the same server fine (extension-host log)</summary>

[ERROR] MCP server "plugin:context7:context7" Server stderr: Context7 Documentation MCP Server v3.2.4 running on stdio
[DEBUG] MCP server "plugin:context7:context7": Successfully connected (transport: stdio) in 2118ms
[DEBUG] [MCP] Server "plugin:context7:context7" connected with subscribe=false

Note the server registers under the fully-qualified id plugin:context7:context7, but the
agent-view error reports the bare display name (context7, cwm-roslyn-navigator). This
name-resolution mismatch may be the direct cause of "not found".
</details>

<details>
<summary>The plugin packages themselves are healthy</summary>

Launching context7 standalone under the same Node succeeds:

Context7 Documentation MCP Server v3.2.4 running on stdio

</details>

<details>
<summary>Control case: the CLI / subagent worktree path works perfectly</summary>

A worktree-isolated subagent created and used an isolated worktree with all MCP tools intact:

$ git rev-parse --show-toplevel
D:/Dev/Atlas/.claude/worktrees/agent-xxxxxxxx
$ git worktree list
D:/Dev/Atlas                                  7e25464 [dev]
D:/Dev/Atlas/.claude/worktrees/agent-xxxxxxxx 7e25464 [worktree-agent-xxxxxxxx] locked
$ git status -sb    # after creating a probe file
## worktree-agent-xxxxxxxx
?? WORKTREE_PROBE.txt

Only the agent-view worktree launcher fails.
</details>

<details>
<summary>The failure is surfaced above the extension-host log layer</summary>

The strings sendFailed, Server not found, and the dead session id never appear in
.../exthost/Anthropic.claude-code/Claude VSCode.log. They are produced only by the
webview / SDK session layer, which is why the extension-host log shows the servers connecting
"successfully" while the agent-view session reports them "not found".
</details>

Root-cause hypothesis

Worktree/agent-view sessions receive the plugin-MCP manifest but do not actually spawn/connect the
servers for that session (or the first send fires before they connect). The bootstrap then treats
any not-yet-connected required server as fatal, aborts the send, and reports the bare server
name. Two candidate mechanisms, not mutually exclusive:

• Name resolution: the session references servers by bare display name (context7) instead of

the fully-qualified id (plugin:context7:context7) they register under.

• Startup race / fail-closed: plugin servers (npx cold start ~2s) aren't awaited, and the

bootstrap is fail-closed instead of fail-open like the main window.

Secondary defects observed during diagnosis

1. Unresumable dead session. A turn-1 failure does not persist a session transcript, so a

follow-up message fails with Cannot resume unknown session: <id> (not present in SDK transcript
store). The session is permanently unresumable.

1. No persistent per-server disable. The MCP Servers panel's per-server menu offers only

"Disable (Session)". A session-scoped disable does not propagate to a newly-spawned worktree
session, so it cannot be used to work around this bug. The only persistent lever is disabling the
entire plugin (which also removes that plugin's skills/tooling).

1. Copy button non-functional. The copy control on agent-view messages does nothing.
2. Orphan branch on session delete. Deleting a dead session removes the worktree files

(expected) but leaves an orphan git branch (agents/<name>) behind.

Impact

The agent-view worktree feature is effectively unusable for any user with plugin-provided MCP
servers enabled - the default for anyone using context7, the dotnet/Roslyn kit, etc. Because
"Disable (Session)" cannot reach the new session, there is no in-UI workaround short of disabling
whole plugins.

Workarounds (current)

• Use worktree-isolated agents via the CLI / normal subagent mechanism instead of the agent view.
• Or persistently disable every plugin-provided ("Workspace") MCP server before using the agent

view, accepting the loss of those plugins' tools/skills.

Hitting what looks like the same underlying bug, with a different connector type — the hosted claude.ai Atlassian Rovo connector (https://mcp.atlassian.com/v1/mcp), not a plugin-launched server. Adding in case the extra data point about status inconsistency helps narrow it down.

Environment

• Claude Code 2.1.273
• Reproduced both in the VSCode extension and in a plain terminal claude session

Symptoms

• claude mcp list reports the connector as ✔ Connected (occasionally ! Connected · tools fetch failed — Request timed out, but clean on retry most of the time).
• No Jira/Confluence tools are ever discoverable or callable in that session — searched for jira, atlassian, confluence, and common guessed tool names (getJiraIssue, searchJiraIssuesUsingJql, etc.), nothing surfaces.
• Confirmed the OAuth grant itself is valid and correctly scoped: id.atlassian.com/manage-profile/apps shows Claude/Rovo authorized with "Read Jira project and issue data..." and "Create and edit issues in Jira..." permissions.
• Ruled out: stale session (retried across multiple new sessions), stale extension state (full VSCode restart), stale OAuth grant (disconnected/reconnected the connector on claude.ai), stale CLI version (updated to 2.1.273 mid-troubleshooting — no change).

New data point: inconsistent status across code paths

Within the same Claude Code install/login, two different invocations disagree about whether the connector is even authorized:

• Interactive session: claude mcp list → ✔ Connected.
• A separate one-shot claude -p "<query about available jira tools>" invocation → reports the same server as requiring authentication and never having been authorized.

So it's not just "Connected but tools missing" — the authorization state itself isn't consistently tracked across how the CLI is invoked, which suggests the bug may be in session/auth-state handling rather than (or in addition to) tool registration specifically.

Expected behavior

If mcp list reports a connector as ✔ Connected, its tools should be discoverable and callable in that same session. If authorization is actually incomplete, mcp list should reflect that (e.g. ! Needs authentication, consistent with how other unauthenticated connectors like Slack/Zoom are shown) instead of showing Connected with silently zero tools — and that status shouldn't differ depending on which code path (interactive vs -p) checks it.