[BUG] Claude Code Web interactive sessions lost all claude.ai MCP connectors ~April 23, 2026 while routines retain them
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: onlymcp__github__*is wired up. ToolSearch sweeps across keywords likeatlassian,rovo,jira,confluence,huggingface,slack,linear,notion,sentry, and a broadmcpquery 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 withno 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_serversscope. 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_connectorsGrowthBook gate value for affected accounts in interactive Web sessions vs routine sessions on the same account - Verify the
user:mcp_serversscope claim on the bearer token minted for interactive Web sessions vs routine sessions - Inspect the
--mcp-configsynthesis for interactive Web session VM spawns post-April 23 - specifically whether the connector list returned from/v1/mcp_serversis 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
- Confirm on
claude.ai/customize/connectorsthat connectors (e.g. Atlassian Rovo, Hugging Face) are connected and authenticated. - Open
claude.ai/code(or the Code tab in Claude Desktop on Windows). Start a fresh interactive session against any GitHub repo. - 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." - Observe: only
mcp__github__*is listed. ToolSearch returns no hits beyond GitHub. Direct invocations fail with 'no <connector> MCP connector available in this session'. - From the same UI, create or run a Routine that uses the same connectors.
- 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)
14 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I'd prefer this isn't auto-closed yet. About the 3 matches:
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.Happy for this to live as related-to #51138. Just want eyes on the diagnostic angle before it gets auto-closed.
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/connectorsand it worked correctly in new Code Web sessions, withmcp__figma__*tools available. Since last Thursday (~April 23), every fresh session onclaude.ai/codereports 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 atclaude.ai/customize/connectors.+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:
ToolSearchforsupabase,sentry,vercelall return zero deferred tools. Onlymcp__github__*is exposed.Workaround status: None working.
.mcp.jsonis 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.
Confirming the same symptom on Claude Code Web, macOS
+1 me too
+1 Mac
+1
+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:
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 CalendarObserved: 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 againstmcp__claude_ai_Grove__*fail silently. Checking/tmp/mcp-config-cse_*.jsonconfirmed 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.jsonas"type": "http") stayed fully operational throughout. The cloud OAuth route is the only broken path.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.
@igorkofman Whew! I can indeed confirm my issue is resolved in the exact way you described. Great stuff!
Thanks for confirming and reporting! Closing the issue.
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.