Built-in Gmail connector: search_threads returns "permission denied" despite consent screen granting gmail.readonly

[tamotsuiwaki-droid]

MCP server URL or name

Built-in Gmail connector (provided by Anthropic in claude.ai)

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-04-24 (around 23:50 JST, Japan)

Browser and OS

Chrome on Windows 11 (also reproduced in Claude Desktop App)

Describe the issue

The built-in Gmail connector in claude.ai returns The caller does not have permission when search_threads is called, even though the Google OAuth consent screen correctly requests the gmail.readonly scope and I approved it. Other Gmail tools (list_labels, list_drafts) work correctly against the same connection.

This looks like a different bug class from #218. In #218, required scopes were missing from the authorize request sent to Google. In this case, the scopes ARE requested and granted at consent time — but the stored/effective token behaves as if gmail.readonly is absent.

Consent screen (verified)

The Google consent screen requested exactly two scope groups and I approved both via "Select all":

1. "View your email messages and settings" (= https://www.googleapis.com/auth/gmail.readonly)
2. "Manage drafts and send emails" (= https://www.googleapis.com/auth/gmail.compose)

Observed pattern

Tool	Result
list_labels	success
list_drafts	success
search_threads	permission denied

This pattern is consistent with a token that effectively carries gmail.labels (or gmail.metadata) and gmail.compose, but NOT gmail.readonly — even though gmail.readonly was in the consent request and was approved.

Steps already tried

• Disconnected and reconnected the Gmail connector: no change.
• Tested in both Claude Desktop App and claude.ai Web browser: same behavior in both environments.

Error details

Error message: The caller does not have permission

request_id: req_011CaNrsfTEW1MUZwTN1o714

(Same error string and error pattern was returned on every attempt, across both Desktop App and Web browser.)

Expected behavior

search_threads should return matching Gmail threads, since the consent screen granted gmail.readonly which is the required scope for reading and searching threads.

Additional context

Suspected root cause (speculative)

Somewhere between the OAuth callback and the MCP gateway's token use, the gmail.readonly scope claim appears to be dropped or not propagated. This is downstream from #218 (where the authorize URL itself was missing scopes) — in this case, the authorize URL appears correct.

Related issues

• [BUG] claude.ai custom connector fails to request server-declared scopes for Google Workspace People API — all tool calls return permission denied #218 — custom connector, Google People API, same error string, scope missing from authorize request
• offline_token not being added as a scope during oauth #42 — offline_token not added as scope during OAuth

Impact

Search-based Gmail operations are the core of any email assistant workflow (e.g. "find the last email from X", "look up this thread"). With search_threads unusable, the Gmail connector is practically limited to label listing and draft creation, which makes most real-world use cases non-functional.

[tamotsuiwaki-droid]

Update (about 10 hours after filing): the issue appears to be resolved on my side.

Re-tested search_threads with the same query (newer_than:7d) on the same account, and it now returns results correctly. list_labels and list_drafts continue to work as before.

I have not changed anything on my end since filing — no reconnect, no scope change, no client switch. So I'm not sure whether:

1. a backend fix was deployed (possibly related to [BUG] claude.ai custom connector fails to request server-declared scopes for Google Workspace People API — all tool calls return permission denied #218),
2. the token was refreshed and the new token carries the correct scopes, or
3. something else changed server-side.

Leaving this issue open in case the maintainers want to confirm the fix and close it themselves, or in case the symptom is intermittent and recurs.

[localden]

Closing this as it is reported to be working correctly at this time.

[OvercastJeff]

@localden this does not appear fully resolved. Same bug still occurring as of June 1, 2026, roughly six weeks continuous, on Claude Code and the Desktop app (macOS).

Same error string ("The caller does not have permission") and the same split as the original report: Drive tools on the same Google account succeed, while Gmail fails on every call. Two additions beyond the original report:

1. It is not Gmail-only. The Google Calendar connector fails identically, same error, while Drive works. The scope-drop looks broader than just gmail.readonly.
2. A full Google-side revoke and re-auth plus multiple reconnects do not fix it, so whatever backend change resolved this for the original reporter never reached my account, or it regressed.

Could this be reopened? Happy to provide request_ids and exact timestamps. Related, both auto-closed as duplicates with no owner: anthropics/claude-code#61534 and #62548.

[OvercastJeff]

@localden following up on my June 1 note. This is still broken as of June 3, now roughly six weeks of continuous failure on my account.

Status unchanged:

• Gmail and Google Calendar connectors both return "The caller does not have permission" on every tool call.
• Drive on the same Google account works normally, so this is scope-specific rather than a general OAuth failure on the account.
• A full Google-side revoke and re-auth plus multiple reconnects do not resolve it. Whatever backend change fixed this for the original reporter never reached my account, or it regressed.

Could this be reopened and assigned an owner? I can provide request_ids and exact timestamps for failing Gmail and Calendar calls. Related reports, both auto-closed as duplicates with no owner: anthropics/claude-code#61534 and #62548.

Happy to share account identifiers through any secure channel that does not route through support@anthropic.com (ticket 215474011486857 has been open 39+ days with no substantive human reply).

[OvercastJeff]

@localden reopening request. This is still failing as of June 7, 2026, now roughly seven weeks of continuous failure on my account (since April 20).

Status unchanged from my June 1 and June 3 notes:

• Gmail and Google Calendar connectors return "The caller does not have permission" on every tool call.
• Drive on the same Google account works normally, so this is scope/account-specific, not a general OAuth failure.
• Other users on the same Workspace tenant (overcast.com) run Gmail and Calendar without issue.
• A full Google-side revoke and re-auth plus multiple reconnects do not resolve it.

This pattern points to account-state corruption that needs server-side intervention. An engineer with token-state access should be able to diff my account against a working overcast.com user and find the bad record.

Could this be reopened and assigned an owner? I can provide request_ids, exact timestamps, and my account email through any secure channel that does not route through support@anthropic.com (ticket 215474011486857 is 43+ days old with no substantive human reply). Related reports, both closed as duplicates: claude-code#61534 and claude-code#62548.