Account-scoped auth failure: Gmail and Calendar return "The caller does not have permission" since April 20; persists after #229 closed; ruled out plugin trigger in claude-code#62556

[OvercastJeff]

MCP server URL or name

Built-in Gmail and Google Calendar connectors (provided by Anthropic). One root cause, two connectors; filing together deliberately.

How are you connecting to this server?

From browsing the MCP server directory

Where does the issue occur?

During a conversation (after initial auth)

When did you last reproduce this?

2026-06-10 ~11:15 AM EDT (live calls to Gmail search_threads and Calendar list_events, both failed)

Browser and OS

Cowork (Claude desktop app) on macOS; also reproduced on claude.ai web (Chrome) and Claude Desktop chat. Not browser-specific.

Describe the issue

Summary

For one account, every Gmail and Google Calendar connector tool call has returned The caller does not have permission continuously since April 20, 2026 (7.5 weeks). Drive on the same Google account works normally. Other users on the same Google Workspace tenant (overcast.com) run Gmail and Calendar without issue. Most recently reproduced June 10, 2026, ~11:15 AM EDT (search_threads and list_events, identical error string on both).

Why this is a new issue and not a duplicate

• Built-in Gmail connector: search_threads returns "permission denied" despite consent screen granting gmail.readonly #229 was closed because the original reporter's account self-resolved, with no identified fix. My account presents the same symptom signature but never recovered. Three reopen requests on that thread (June 1, 3, 7) have had no response, so the closed thread appears unmonitored. Filing fresh so this gets triage as what it is: a live, reproducible failure.
• [BUG] Cowork macOS: all claude.ai-hosted MCP connectors fail — desktop OAuth token requested without user:mcp_servers scope claude-code#62556 (plugin settings.json drops user:mcp_servers from the OAuth scope set) is not my bug. Two differentials:
  1. In that issue, gateway connectors expose zero tools. On my account, Gmail and Calendar tools load and are callable, then fail at the permission check. Different failure layer.
  2. I have verified no installed plugin ships a settings.json with a top-level agent field, and the all-connectors-down pattern does not match mine (Drive works).
• [BUG] Cowork macOS: Gmail and Google Calendar MCP connectors return "The caller does not have permission" on every call for one account; other users on the same Workspace tenant unaffected claude-code#62548 and [BUG] Gmail MCP Sever returns permission error on all tools claude-code#61534 were auto-closed as duplicates by the bot without triage; both point back to Built-in Gmail connector: search_threads returns "permission denied" despite consent screen granting gmail.readonly #229.

Failure signature

Surface	Result
Gmail tools (e.g. search_threads), any call	"The caller does not have permission"
Calendar tools (e.g. list_events), any call	"The caller does not have permission"
Drive tools, same account, same session	Success
Same connectors, other users on the same Workspace tenant	Success

Reproducibility: 100% since April 20 across claude.ai web, Claude Desktop, and Cowork.

Client-side surface is exhausted

Full detail in anthropics/claude-code#62548. In short: connector uninstall/reinstall with full scope re-grant (both connectors), Google-side revoke at myaccount.google.com/permissions and re-auth, Workspace admin verification that the Anthropic OAuth app is unrestricted for the domain, cross-user and cross-connector controls. Nothing changes the outcome.

What I am asking for

This pattern (one account, two specific Google services, fixed error, immune to re-auth) points to corrupted server-side token or scope state for my account at the gateway. An engineer with token-state access should be able to diff my account against a working user on the same tenant.

Error details

Error message (exact, on every Gmail and Calendar tool call since April 20, 2026):

The caller does not have permission

Most recent reproduction: 2026-06-10 ~11:15 AM EDT, Gmail search_threads and Calendar list_events, both returned the identical string. No request_id is surfaced in the Cowork UI for these failures; I can provide request_ids and exact timestamps from earlier claude.ai web reproductions on request.

Expected behavior

Gmail and Calendar tool calls succeed with valid OAuth tokens and return normal data, as they do for other users on the same Workspace tenant, and as Drive already does on this same account in the same session.

Additional context

Related:

• Built-in Gmail connector: search_threads returns "permission denied" despite consent screen granting gmail.readonly #229 (closed; same signature; root-cause discussion and my reopen requests of June 1, 3, and 7)
• [BUG] Cowork macOS: Gmail and Google Calendar MCP connectors return "The caller does not have permission" on every call for one account; other users on the same Workspace tenant unaffected claude-code#62548 and [BUG] Gmail MCP Sever returns permission error on all tools claude-code#61534 (auto-closed as duplicates)
• [BUG] Cowork macOS: all claude.ai-hosted MCP connectors fail — desktop OAuth token requested without user:mcp_servers scope claude-code#62556 (different bug, same gateway scope check; ruled out above)

Support ticket 215474011486857 is 47+ days old with no substantive human reply, so please do not route this back to support@anthropic.com. I can provide my account email, request_ids, and exact timestamps through any secure channel a maintainer prefers.

[OvercastJeff]

Thanks, agreed it's server-side. One data point worth adding: this began as a spontaneous regression. Both connectors worked normally until April 20 with no re-auth, reconnect, or config change on my end, so any scope narrowing happened without a new consent event. Client-side surface is fully exhausted per the issue body; awaiting an Anthropic engineer with token-state access.

[OvercastJeff]

@localden flagging for triage. Two developments since I filed this five days ago strengthen the case that this is a server-side gateway problem, not a one-off bad record on my account.

1. Independent corroboration in this thread (above) of the failure signature: Drive (a sensitive scope) survives while Gmail and Calendar (restricted scopes) get dropped, and client-side re-auth cannot fix it because it re-attaches to the same corrupted token lineage.
2. In [BUG] Cowork macOS: all claude.ai-hosted MCP connectors fail — desktop OAuth token requested without user:mcp_servers scope claude-code#62556, a user reproduced the same Missing user:mcp_servers scope drop triggered by a first-party Anthropic Cowork plugin ("Product management" v1.2.0), and found that disabling it was not enough, it silently re-enabled and only a full uninstall restored the scope. That says the gateway scope path is fragile system-wide, which is consistent with my account being stuck in a bad scope state since April 20.
   The ask is unchanged and small: an engineer with token-state access diffs my account's gateway token/scope record against a working user on the same Workspace tenant (overcast.com) and clears the bad state. Estimated effort: minutes.

I can provide my account email, request_ids, and exact timestamps through any secure channel you prefer. Please do not route to support@anthropic.com; ticket 215474011486857 is now ~56 days old with no substantive human reply.

[OvercastJeff]

@localden flagging again for triage. This issue has been open 9 days with no maintainer response, and the diagnosis is now independently corroborated on this thread.

Status (unchanged): Gmail and Calendar return "The caller does not have permission" on every call since April 20 (8+ weeks). Drive on the same Google account works normally. Other users on the same overcast.com Workspace tenant are unaffected. The plugin trigger from claude-code#62556 is ruled out on my account (no installed plugin ships a settings.json with a top-level agent field).

Independent corroboration above (@Ben-Home) reaches the same conclusion from outside: restricted scopes (Gmail, Calendar) get dropped on the refresh-token chain while a sensitive scope (Drive) survives, and client-side re-auth cannot fix it because it re-attaches to the same corrupted token lineage.

The ask is small and entirely server-side: an engineer with gateway token-state access diffs my account against a working overcast.com user on the same tenant and clears the bad scope state. I can provide my account email, request_ids, and exact timestamps through any secure channel you prefer. Please do not route to support@anthropic.com (ticket 215474011486857 is now 56+ days old with no substantive human reply).

[OvercastJeff]

@localden flagging again for triage. Brief update, no new symptoms.

Two developments since my last comment:

1. Independent corroboration on this thread. @Ben-Home reached my exact signature from outside: restricted scopes (Gmail, Calendar) get dropped on the refresh-token chain while the sensitive Drive scope survives, and client-side re-auth cannot fix it because it re-attaches to the same corrupted token lineage.

2. Plugin trigger re-verified absent on my account. I re-checked my install against the nano-banana / settings.json root cause in claude-code#62556. I have one Cowork plugin installed (sales), there is no settings.json with a top-level agent field anywhere in my plugin tree, and the official "Product management" plugin that triggered the scope drop for @faisj is not installed. The all-connectors-down pattern also does not fit mine: Drive works. So the #62556 trigger is conclusively not my cause.

Status otherwise unchanged: Gmail and Calendar return "The caller does not have permission" on every call since April 20 (now 9+ weeks). Drive on the same account works. Other users on the overcast.com Workspace tenant are unaffected.

The ask remains small and entirely server-side: an engineer with gateway token-state access diffs my account against a working overcast.com user on the same tenant and clears the bad scope state. I can provide my account email, request_ids, and exact timestamps through any secure channel. Please do not route to support@anthropic.com; ticket 215474011486857 is now approaching 60 days old with no substantive human reply.

[localden]

Thank you for flagging this. Given the error message, this seems to be a configuration issue with the specific account rather than something that is sourced from Claude. I recommend you check with the administrator of your tenant to make sure that there are no restrictions in place that prevent the user from accessing the data through the connector.

[OvercastJeff]

@localden thanks for the reply, but I want to push back, because the "check with your tenant administrator" path is already exhausted and the evidence points away from a tenant configuration issue.

Three facts from the issue body that rule out a tenant or account-restriction cause:

1. Other users on the same overcast.com Workspace tenant run Gmail and Calendar normally. If a tenant-level restriction were in place, it would hit them too. It does not. The failure is isolated to my account.

2. Our Workspace admin already verified the Anthropic OAuth app is unrestricted and unblocked for the domain, with the required scopes granted. There is no admin-side restriction to remove.

3. Drive works on this same account in the same session, using the same OAuth path. A blanket account or tenant permission problem would not let Drive through while blocking Gmail and Calendar. This is scope-specific, not account-wide.

This is also a different failure layer from the plugin trigger in claude-code#62556: there, gateway connectors expose zero tools. On my account the Gmail and Calendar tools load and are callable, then fail at the permission check. I have confirmed no installed plugin ships a settings.json with a top-level agent field, so that trigger is ruled out here.

The remaining hypothesis is corrupted server-side token or scope state for my account at the gateway, present continuously since April 20. The ask is small: an engineer with token-state access diffs my account against a working overcast.com user on the same tenant and clears the bad state. I can provide my account email, request_ids, and exact timestamps through any secure channel. Could this be reopened and assigned an owner?

[OvercastJeff]

@localden reopening, because the "tenant configuration" explanation does not fit the evidence, and there is now a concrete server-side mechanism that does.

Why this is not tenant config: other users on the same overcast.com tenant run Gmail and Calendar normally, our Workspace admin already verified the Anthropic OAuth app is unrestricted with scopes granted, and Drive works on my account in the same session over the same OAuth path. A tenant or account restriction cannot pass Drive while blocking Gmail and Calendar.

The mechanism that does fit: anthropics/claude-code#51326 documents that the Gmail and Calendar MCP OAuth flow is routed through the "Claude for Google Drive" OAuth client, so issued tokens only ever carry Drive scopes (the callback returns scope=email+drive.readonly+drive.file+userinfo.email+openid, with no Gmail or Calendar scope). That is exactly my signature: Drive succeeds while Gmail and Calendar fail with "The caller does not have permission" on every call since April 20. Three separate reporters confirm #51326 is still broken; it was auto-closed by the stale bot, not fixed.

This also explains the account-scoped shape. My account appears to have been moved onto the Drive-client token lineage on April 20, while other tenant users remained on a correctly scoped path. Client-side re-auth cannot fix it because it re-attaches to the same Drive-only client.

The ask is concrete and server-side: repoint Gmail and Calendar to a correctly scoped OAuth client for my account, or clear and reissue my gateway token against it. I can provide my account email, request_ids, and exact timestamps through any secure channel. Please do not route to support@anthropic.com; ticket 215474011486857 is now 67+ days old with no substantive human reply.

[ivan-arkhipov]

We have the same issue, all of the steps provided by Anthropic support team failed to resolve the issue.

Why this is not tenant config: other users on the same overcast.com tenant run Gmail and Calendar normally, our Workspace admin already verified the Anthropic OAuth app is unrestricted with scopes granted, and Drive works on my account in the same session over the same OAuth path. A tenant or account restriction cannot pass Drive while blocking Gmail and Calendar.