[BUG] Cowork macOS: all claude.ai-hosted MCP connectors fail — desktop OAuth token requested without `user:mcp_servers` scope

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/62548
2. https://github.com/anthropics/claude-code/issues/32000
3. https://github.com/anthropics/claude-code/issues/48130

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

Thanks for the triage hits. Quick assessment:

• #62548 and #48130 are not duplicates — different symptoms, no user:mcp_servers log evidence, different connectors-affected pattern (see "Why this is not the same bug as adjacent open issues" in the original report).

• #32000 is genuinely the same underlying defect class — same [claudeai-mcp] Missing user:mcp_servers scope log line, same macOS platform, same headless-agent-embedded-in-Claude.app shape.

That said, I'd push back on closing this as a duplicate of #32000, because the two reports cover different surfaces with different scope sets and likely require fixes in different code paths:

| | #32000 (scheduled tasks) | #62556 (Cowork) |
|---|---|---|
| Surface | ccdScheduledTasksEnabled runner | Cowork session SDK |
| Requested scope set | user:inference only | user:inference user:file_upload user:profile |
| Missing scope | user:mcp_servers | user:mcp_servers |
| User impact | Niche (scheduled tasks) | Broad (every Cowork session) |

Fixing the scope list in the scheduled-tasks OAuth code path will not automatically fix the Cowork OAuth code path — they're separate sites that each need to include user:mcp_servers.

I'd suggest:

• Keep both open and link them; or
• Consolidate explicitly with engineering confirmation that one fix covers both surfaces.

Happy to defer to maintainer judgment, but flagging that #32000 has been open since March 8 with no Anthropic response, so silent consolidation risks both reports dying together. The Cowork surface is materially higher-impact for Max-tier users than scheduled tasks.

Confirmed still an issue in Claude 1.9255.0 (a22af1) 2026-05-26T04:57:41.000Z

Adding some history on this defect class for whoever picks this up, since the prior reports may not all surface via the duplicate-detection heuristic:

• #26259 (Feb 17) — closed NOT_PLANNED on 2026-05-02. Different surface (Desktop Extension MCPs not passed to Cowork VM) but related shape.
• #28695 (Feb 25) — "[BUG] Cowork mode never requests user:mcp_servers OAuth scope" — near-identical title to this report. Auto-closed as dup of #26259 and locked, so can't add to that thread.
• #32000 (Mar 8) — same Missing user:mcp_servers scope log line on the scheduled-tasks surface. Still open.
• #53489 (Apr 23) — Claude Code Web lost claude.ai MCP connectors. Closed.

So this report joins a chain of related observations across surfaces (Cowork sessions, scheduled tasks, Code Web) all keyed on the same user:mcp_servers scope check at the claudeai-mcp gateway. The cross-surface pattern suggests the OAuth scope list is set independently in each embedded-agent code path, which is why a fix on one surface may not transfer to the others — flagging in case that's useful context for the audit.

In the meantime, confirmed workaround for users hitting this: connector-needing tasks work in Claude Code CLI and claude.ai web chat on the same account; only Cowork is affected.

Confirmed still an issue in Claude 1.9255.2 (1dc8f7) 2026-05-27T01:57:20.000Z

Confirmed still not working in Claude 1.9659.2 (390d6c) 2026-05-28T21:50:01.000Z

Root cause narrowed to a single 34-byte plugin file

After incremental restore from backup, the trigger is one specific file in one specific third-party plugin: settings.json at the plugin root of Ibrahim-3d/nano-banana-claude-plugin, containing exactly:

{
  "agent": "gemini-image-gen"
}

Removing only this 34-byte file (keeping every other file in the plugin, including the agent definition at agents/gemini-image-gen.md) restores user:mcp_servers in the OAuth scope set and brings every claude.ai-hosted MCP connector back. Adding it back drops the scope again, reproducibly.

Bisect path (full reproducer)

1. Full local reset of ~/Library/Application Support/Claude/ → fresh sign-in → Gmail / web search work.
2. Restore plugins in groups (Anthropic marketplace, then personal, then third-party).
3. Among 14 plugins, narrow trigger to one: nano-banana. Other third-party plugins (codex, plugin-dev, conductor-orchestrator-supaconductor) are innocent.
4. Within nano-banana, narrow further:

• Fixed hooks/hooks.json schema violation → bug still present
• Fixed commands/genimage.md ↔ skills/genimage/ name collision → bug still present
• Removed settings.json → bug gone

So contrary to my initial hypothesis, the malformed hooks.json was not the OAuth trigger — it's a real schema bug but independent of this regression. The actual trigger is the plugin-root settings.json declaring a top-level agent field.

OAuth scope evidence in the latest launch

From ~/Library/Logs/Claude/main.log during a session with the unmodified plugin installed:

[oauth] looking up token for orgId=..., cacheKey=...:https://api.anthropic.com:user:inference user:file_upload user:profile

— scope set lacks user:mcp_servers, leading to the [claudeai-mcp] Missing user:mcp_servers scope failure that surfaces as "no Gmail connector," "no web search," etc.

After removing only settings.json:

[oauth] looking up token for orgId=..., cacheKey=...:https://api.anthropic.com:user:inference user:file_upload user:profile user:mcp_servers

(or a scope set that includes user:mcp_servers — same effect: connectors come back).

Plugin author fix

Submitted upstream:

• PR Ibrahim-3d/nano-banana-claude-plugin#3 — deletes settings.json (plus fixes the hooks.json schema and the command/skill collision while we're here, since they're also real bugs)
• Issue Ibrahim-3d/nano-banana-claude-plugin#4 — companion bug report describing all three findings

Once that lands and propagates to anyone with the plugin installed, this trigger is removed at the source for nano-banana users.

Anthropic-side defense-in-depth

The plugin author's fix removes one trigger from the wild, but the underlying host bug remains: any third-party plugin shipping a settings.json with an unexpected/unsupported field will silently regress global Cowork OAuth scopes for the entire session. The host should fail closed in the plugin scope (load the plugin partially or reject it entirely) without contaminating the global MCP/OAuth handshake.

Concrete suggested investigation targets in the desktop app:

1. The plugin-load code path that parses settings.json at the plugin root — what does it do with an agent field? If it's an unsupported/undocumented field, why does its presence affect the OAuth scope decision rather than being ignored?
2. The OAuth scope-list construction code in the Cowork session bootstrap — it should unconditionally request user:mcp_servers whenever any claude.ai-hosted connectors are configured for the account, regardless of any plugin's settings or load state.
3. Possibly the same regression as the scheduled-tasks scope path in #32000 — both surfaces fall back to a scope set without user:mcp_servers under conditions that shouldn't matter.

Workaround for users who can't wait for the plugin fix

Quit Claude, then:

rm "$HOME/Library/Application Support/Claude/local-agent-mode-sessions/<user-uuid>/<org-uuid>/rpm/plugin_<nano-banana-ULID>/settings.json"

(Find the right ULID via grep -l nano-banana <user-uuid>/<org-uuid>/rpm/plugin_*/.claude-plugin/plugin.json.) Launch Claude. Connectors come back; nano-banana keeps working.

Or just uninstall nano-banana via the Cowork UI.

Hi @SmartCarrion,

First of all, thank you for the really thorough detective work here. It helped us find and fix the same problem on our side very quickly, so I wanted to give something back and confirm we are hit by this too.

Same symptom for us: all claude.ai connectors (Gmail, Google Calendar, Notion, Drive) returned 403 in Claude Code / Cowork on macOS, while the exact same connectors kept working perfectly in the Claude desktop chat.

Same evidence in our logs:

[claudeai-mcp] Missing user:mcp_servers scope (scopes=user:inference)

What is interesting is that our trigger was not nano-banana. For us it was a different plugin: the official "Product management" Cowork plugin (Marketplace "Anthropic & Partners", author Anthropic, version 1.2.0), which had been updated about 3 days before the connectors broke. So this seems to confirm your hypothesis that any plugin shipping a settings.json can silently drop the global OAuth scope, even a first-party one.

One extra thing worth flagging: disabling the plugin was not enough. After disabling it, it quietly re-enabled itself again later on its own. Only after fully uninstalling it (and restarting) did user:mcp_servers come back in the scope set, and all connectors started working again.

So for anyone landing here: check your recently updated Cowork plugins, and if you find the culprit, uninstall it completely instead of just disabling it.

Thanks again for the great write-up.

First of all, thank you for the really thorough detective work here. It helped us find and fix the same problem on our side very quickly, so I wanted to give something back and confirm we are hit by this too.

Thank you @faisj I spent a lot more time on it than I thought i would, and it broke a lot of trust I had in the value of Cowork! I'm really glad to see I helped someone, and it is very interesting to see the broader issue. Thanks for the details.

the per-connector Unauthorized is downstream: Slack/Linear exchange off the gateway token, which never got the scope to mint them.

@SmartCarrion thanks for the detailed scope-drop analysis. Adding a data point from a different variant in case it helps the audit.

My account (Cowork on macOS, Max plan, Google Workspace tenant overcast.com) has had the Gmail and Google Calendar connectors returning "The caller does not have permission" on every call since April 20, 2026. The difference from your report: Drive on the same account works normally, and other users on the same Workspace tenant run Gmail and Calendar without issue. So mine presents as partial, account-scoped breakage rather than all-connectors-down.

I checked my installed Cowork plugins and none ship a settings.json with a top-level agent field, so the plugin trigger you bisected does not appear to be my cause. But the shared symptom (Gmail and Calendar failing at the OAuth scope check while Drive survives) suggests the same user:mcp_servers gateway scope path may be involved, reached by a different route.

Root-cause discussion is in anthropics/claude-ai-mcp#229. My own report is anthropics/claude-code#62548 (closed as duplicate). Support ticket 215474011486857 has been open 40+ days with no substantive human reply.

Happy to provide request_ids and exact timestamps for failing Gmail and Calendar calls through any secure channel. Flagging in case a maintainer with token-state access can diff my account against a working user on the same tenant.

Adding an account-scoped variant of this defect, in case it helps bound the root cause.

My account (Cowork on macOS, Google Workspace tenant overcast.com) has had Gmail and Calendar returning "The caller does not have permission" on every call since April 20, with one difference from the all-connectors-down reports here: Drive on the same account works normally, and other users on the same tenant run Gmail and Calendar without issue. So mine presents as partial and account-scoped rather than global.

I ruled out the plugin trigger that @SmartCarrion bisected: no installed plugin on my account ships a settings.json with a top-level agent field, and the all-connectors-down pattern does not fit (Drive survives). So if this is the same underlying user:mcp_servers gateway scope path, it is being reached by a different route than the plugin settings.json one.

What seems consistent across the reports here: the failing layer is the gateway-issued token, and restricted scopes (Gmail, Calendar) get dropped while a sensitive scope (Drive) survives. The corroboration from @faisj that a first-party Anthropic plugin can also trigger the scope drop suggests the scope construction is fragile independent of any one plugin.

One ask for whoever picks up the gateway fix: alongside correcting the scope list construction, it would help to have a way to clear or re-mint stuck per-account gateway token state. Client-side re-auth does not fix my case because it re-attaches to the same token lineage. I am happy to provide my account email, request_ids, and exact timestamps as a test case for that path through any channel a maintainer prefers.