[BUG] Claude Code Web interactive sessions lost all claude.ai MCP connectors ~April 23, 2026 while routines retain them

Status Fixed / completed
Maintainer reply ✓ Yes — igorkofman
Activity 14 comments · opened Apr 26, 2026 · closed Apr 29, 2026
💡 Likely answer: A maintainer (igorkofman, collaborator) responded on this thread — see the highlighted reply below.

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?

Starting on or around April 23–24, 2026, all account-level claude.ai MCP connectors stopped being available in interactive Claude Code Web sessions (claude.ai/code, and the "Code" tab in Claude Desktop on Windows). The repo-scoped GitHub MCP server (mcp__github__*) is the only MCP server present at session start. All other connectors (Atlassian Rovo, Hugging Face, Google Drive, etc.) are absent. Connectors remain findable and functional for Claude _CHAT_ and Claude Code _ROUTINES_.

The asymmetry that distinguishes this from prior reports

  • Interactive sessions on claude.ai/code: only mcp__github__* is wired up. ToolSearch sweeps across keywords like atlassian, rovo, jira, confluence, huggingface, slack, linear, notion, sentry, and a broad mcp query all return zero matches beyond GitHub. Direct invocation of a connector tool ("Use the Atlassian Rovo MCP to find Jira issues assigned to me") fails with no Atlassian Rovo MCP connector available in this session.
  • Routines launched from the same UI on the same account: connectors resolve correctly. Atlassian Rovo, Hugging Face, etc. work as expected inside routine sessions.
  • Claude Chat from the same UI on the same account: connectors can be attached via the "+" UI option (which Code does not have), after which they are discoverable and usable normally too.
  • Same symptom on Claude Desktop's "Code" tab on Windows.

Things tried, no effect on interactive sessions

  • Disconnect + reconnect of Atlassian Rovo and Hugging Face at claude.ai/customize/connectors
  • Remove + reinstall of the same connectors
  • Multiple fresh sessions, across both Claude Desktop and Claude Web
  • Multiple explicit ToolSearch prompts across many keywords
  • Closing and reopening Claude Desktop

Related issues (none describe this exact inverted symptom)

  • #43397 -Cloud routines cannot access MCP connectors. Directional inverse of this report. The sub-agent-dispatch workaround documented there does not apply here.
  • #28695 - Cowork tokens lacking user:mcp_servers scope. Closest mechanical precedent - possibly the same class of bug surfacing in a different surface.
  • #42243 - Claude Code Web inconsistently provides GitHub MCP tools for private repos. Same surface, narrower scope.
  • #49203 - "Connectors not found" on new desktop/mobile sessions. Same symptom shape, predates this regression.
  • #51736 - After v2.1.116, ToolSearch returns No matching deferred tools found. Symptom-shape match.
  • #47485 - Cloud connectors bulk-lose authentication simultaneously. Possible related infrastructure event.

Possible triggers in the April 20–24 release/incident wave

  • April 23 status incident: "MCP applications on Claude.ai unavailable" 00:41–02:09 UTC
  • v2.1.119 (April 23): changelog includes "Fixed plugin MCP servers stuck 'connecting' on session start when they duplicate a claude.ai connector that is unauthenticated" - directly touches the dedup logic between local and cloud connectors
  • v2.1.120 (April 24): force-rolled back by Anthropic within ~24 hours

Requested diagnostics from Anthropic

Note: The diagnostic below was generated by AI (Claude Opus 4.7 in Research Mode) in an attempt to be helpful. Please take it as such.

To narrow whether this is a gate, scope, or --mcp-config synthesis regression:

  • Verify the tengu_claudeai_mcp_connectors GrowthBook gate value for affected accounts in interactive Web sessions vs routine sessions on the same account
  • Verify the user:mcp_servers scope claim on the bearer token minted for interactive Web sessions vs routine sessions
  • Inspect the --mcp-config synthesis for interactive Web session VM spawns post-April 23 - specifically whether the connector list returned from /v1/mcp_servers is being silently filtered to GitHub-only before being passed to the VM

Suggested labels: area:claude-code-web, area:mcp, platform:web - please add if appropriate.

What Should Happen?

Interactive Claude Code Web sessions should inherit the user's account-level claude.ai MCP connectors at session start, mirroring the routines pipeline. Until ~April 23, 2026 this worked correctly.

Specifically: a fresh ad-hoc session on claude.ai/code (or the Code tab in Claude Desktop) should expose all connectors that show as "connected" at claude.ai/customize/connectors, not only the repo-scoped mcp__github__* server.

Error Messages/Logs

N/A

Steps to Reproduce

  1. Confirm on claude.ai/customize/connectors that connectors (e.g. Atlassian Rovo, Hugging Face) are connected and authenticated.
  2. Open claude.ai/code (or the Code tab in Claude Desktop on Windows). Start a fresh interactive session against any GitHub repo.
  3. Ask the model to list available MCP servers, or to search for tools matching connector keywords (atlassian, huggingface, rovo, etc.), or to directly invoke a connector tool such as: "Use the Atlassian Rovo MCP to find Jira issues assigned to me."
  4. Observe: only mcp__github__* is listed. ToolSearch returns no hits beyond GitHub. Direct invocations fail with 'no <connector> MCP connector available in this session'.
  5. From the same UI, create or run a Routine that uses the same connectors.
  6. Observe: connectors resolve correctly inside the Routine session.

Things tried, no effect on interactive sessions:

  • Disconnect + reconnect of Atlassian Rovo and Hugging Face at claude.ai/customize/connectors
  • Remove + reinstall of the same connectors
  • Multiple fresh sessions, across both Claude Desktop and Claude Web
  • Multiple explicit ToolSearch prompts across many keywords
  • Closing and reopening Claude Desktop

Environment:

  • Claude Code Web (claude.ai/code, research preview) AND Claude Desktop on Windows 11 "Code" tab - same symptom on both surfaces.
  • Account: Pro/Max tier.
  • Connectors verified connected at claude.ai/customize/connectors: Atlassian Rovo, Hugging Face, Google Drive, others.
  • Onset: ~April 23–24, 2026.
  • Repo used in repro: a private repo.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

~Apr 22, 2026 (Claude Code Web / Desktop - no CLI version exposed)

Claude Code Version

N/A - Claude Code Web and Claude Desktop "Code" tab; no claude --version exposed to me on these surfaces. Claude Desktop app version: Claude 1.4758.0 (fb266c)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

The TLDR:

  • connectors show as connected at claude.ai/customize/connectors
  • Claude Code Routine sessions see them and use them correctly
  • Claude Chat "+" UI recognizes them, allows me to select them, session can discover and use them
  • ad-hoc interactive sessions on Claude Code Web and Claude Desktop's "Code" tab see only the repo-scoped GitHub MCP, even after repeated discovery requests (not simply a deferred issue)

View original on GitHub ↗

14 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/51138
  2. https://github.com/anthropics/claude-code/issues/44361
  3. https://github.com/anthropics/claude-code/issues/41044

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Steffen-vdv · 4 months ago

I'd prefer this isn't auto-closed yet. About the 3 matches:

  • #51138 is the closest one, probably same underlying bug. Same "only GitHub loads" symptom, same ToolSearch returning "No matching deferred tools found". The framing there is "inherited sessions work, new sessions don't" which is similar to what I'm describing but narrower. My report adds value through Windows confirmation (#51138 is macOS only), the broader asymmetry that Claude Chat and Claude Code Routines work fine on the same account, timeline correlation to the April 23 status incident and the v2.1.119 dedup change. Investigating them together would be more useful than closing one against the other
  • #41044 doesn't really match. That one is from about a month ago on Claude Code v2.1.87, lives on the CLI side (claude mcp list), is scoped to a single specific connector (RUBE/Composio) and bundles in a Remote Control complaint. Different surface, different timeframe, different connector.
  • #44361 doesn't match either. That's from after the April 6 Claude.ai outage where Slack specifically failed to reconnect while everything else recovered. Inverse symptom (one connector down versus all but GitHub down) and three weeks earlier.

Happy for this to live as related-to #51138. Just want eyes on the diagnostic angle before it gets auto-closed.

wanho-kim · 4 months ago

Confirming the same symptom on Claude Code Web, macOS (the issue currently only labels Windows — adding a platform data point).

About two weeks ago I connected Figma via claude.ai/customize/connectors and it worked correctly in new Code Web sessions, with mcp__figma__* tools available. Since last Thursday (~April 23), every fresh session on claude.ai/code reports that the Figma MCP is not connected and refuses to proceed; mcp__github__* is the only MCP wired in at session start, even though Figma still shows as connected at claude.ai/customize/connectors.

danweis07 · 4 months ago

+1, repro confirmed on April 27, 2026 (Day 4 of the regression).

Surface: Claude Code on the Web, interactive session, fresh sandbox

claude.ai connector state at session start:
| Connector | Status on claude.ai Settings → Connectors | Available in session? |
|---|---|---|
| GitHub | Connected | ✅ Yes (mcp__github__*) |
| Supabase | Connected | ❌ No |
| Sentry | Connected | ❌ No |
| Vercel | Connected | ❌ No |

This extends the missing-connector list in the original report — Supabase and Vercel can be added as additional confirmed-missing connectors. Sentry was already mentioned and reproduces here.

Tool availability check: ToolSearch for supabase, sentry, vercel all return zero deferred tools. Only mcp__github__* is exposed.

Workaround status: None working. .mcp.json is gitignored in our repo (deliberate — to keep tokens out of git history), so the documented "commit .mcp.json" pattern isn't viable for us without taking on a meaningful secret-leak risk. We'd previously relied on the claude.ai connector bridge precisely to avoid that.

Business impact: blocking parallel cloud sessions for Supabase-backed work; forcing local-only execution on a tight deadline.

andrewbrittain · 4 months ago

Confirming the same symptom on Claude Code Web, macOS

riya-amemiya · 4 months ago

+1 me too

mattbroffman · 4 months ago

+1 Mac

yalamber · 4 months ago

+1

alliefeast · 4 months ago

+1
Confirming this is reproducible on a separate Pro/Max account, same environment (Claude Code Web at claude.ai/code, Windows). Notion is one of the affected connectors for me.

Empirical finding that may help triage — in a live affected session on 2026-04-24, I ran:

cat /tmp/mcp-config-*.json | grep -i notion

No matches. The session's MCP config file exists at /tmp/mcp-config-cse_.json (note the cse_ prefix, not session UUID), but it contains no Notion entry despite the Notion connector being added at claude.ai/customize/connectors and ENABLE_CLAUDEAI_MCP_SERVERS being unset (default enabled).

That seems to localize the bug to the MCP config wiring step at session boot — the auto-loader is silently writing an incomplete config rather than failing visibly during OAuth or tool-call resolution.

Setup details that match the original report:

  • Connector added at claude.ai/customize/connectors and shown as connected there
  • ENABLE_CLAUDEAI_MCP_SERVERS unset
  • Symptom present in interactive cloud sessions; haven't tested routines
rudi193-cmd · 4 months ago

Reproduction data from a production multi-agent system (April 28–29, 2026)

Confirming the regression with more specific failure conditions that may help triage.

Environment: Claude Code CLI (interactive session), Linux, 3-agent fleet (Hanuman, Heimdallr, Loki), ~7-hour session.

Connectors configured: claude.ai Grove (OAuth), claude.ai Gmail, claude.ai Google Drive, claude.ai Google Calendar

Observed: At session init, mcp__claude_ai_Grove__* tools appear in the deferred tool list (suggesting the connector is present), but the connector is never actually wired. Calls against mcp__claude_ai_Grove__* fail silently. Checking /tmp/mcp-config-cse_*.json confirmed the Grove entry is absent from the session config entirely — consistent with alliefeast's finding above.

The dangerous part: The connector appears available in the tool list but has no working send path. The agent believes it has Grove capability; it doesn't. This causes silent capability loss that misroutes work without any error surfacing. It's not a clean fail — it's a phantom tool.

Workaround that held: A separate local HTTP grove server (127.0.0.1:8765, defined in ~/.mcp.json as "type": "http") stayed fully operational throughout. The cloud OAuth route is the only broken path.

igorkofman collaborator · 4 months ago

Hey folks - thanks for the report. We've made a change last night that should resolve it. Please give it a try and let us know. There should also be a new "Connectors" menu in the + on claude.ai/code that will let you control which MCPs are enabled.

Steffen-vdv · 4 months ago

@igorkofman Whew! I can indeed confirm my issue is resolved in the exact way you described. Great stuff!

igorkofman collaborator · 4 months ago

Thanks for confirming and reporting! Closing the issue.

github-actions[bot] · 3 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.