[BUG] Gmail MCP integration uses Google Drive OAuth client — cannot grant Gmail permissions
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?
Bug Description
The built-in Gmail MCP server (gmailmcp.googleapis.com) consistently routes
through the "Claude for Google Drive" OAuth client instead of a Gmail-specific
OAuth client. This means the authorization flow can never grant Gmail API scopes,
making the Gmail MCP permanently non-functional.
Steps to Reproduce
- Use Claude Code with the built-in Gmail MCP integration
- Call any Gmail tool (e.g.,
list_labels,create_draft) - Get "requires re-authorization" error
- Call
mcp__Gmail__authenticate— receive an auth URL - Open the auth URL in browser
- Google shows: "Claude for Google Drive wants additional access"
— only Drive file permission checkboxes are shown, NO Gmail permissions
- Any token granted has Drive scopes, not Gmail scopes
- All Gmail API calls fail with 403
Expected Behavior
The OAuth consent screen should show Gmail permissions
("Read, compose, send and permanently delete all your email")
and grant https://mail.google.com/ or https://www.googleapis.com/auth/gmail.modify scopes.
Actual Behavior
Google consent screen shows "Claude for Google Drive wants additional access"
with only Drive file scopes. Callback URL always returns:scope=email+drive.readonly+drive.file+userinfo.email+openid
No Gmail scopes are ever granted.
Root Cause (suspected)
The Gmail MCP server OAuth client ID (5a970912-02f9-4e78-b66c-965c0e1a74b0)
appears to be the same OAuth app registered for Google Drive, not a
Gmail-specific app. Google's OAuth system shows the app name and scopes
registered for that client_id, which is Drive-only.
Environment
- Claude Code (web/CLI)
- Platform: Linux
- Gmail MCP server:
https://gmailmcp.googleapis.com/mcp/v1 - MCP server ID:
54fd9acb-7cb9-5d39-8b90-b9d1c7111fb4
Impact
The Gmail MCP integration is completely non-functional for all users.
Any workflow relying on Gmail (sending reports, reading email, creating drafts)
cannot work until the correct OAuth client is used.
What Should Happen?
It should connect to my gmail to send email response.
Error Messages/Logs
Steps to Reproduce
Bug Description
The built-in Gmail MCP server (gmailmcp.googleapis.com) consistently routes
through the "Claude for Google Drive" OAuth client instead of a Gmail-specific
OAuth client. This means the authorization flow can never grant Gmail API scopes,
making the Gmail MCP permanently non-functional.
Steps to Reproduce
- Use Claude Code with the built-in Gmail MCP integration
- Call any Gmail tool (e.g.,
list_labels,create_draft) - Get "requires re-authorization" error
- Call
mcp__Gmail__authenticate— receive an auth URL - Open the auth URL in browser
- Google shows: "Claude for Google Drive wants additional access"
— only Drive file permission checkboxes are shown, NO Gmail permissions
- Any token granted has Drive scopes, not Gmail scopes
- All Gmail API calls fail with 403
Expected Behavior
The OAuth consent screen should show Gmail permissions
("Read, compose, send and permanently delete all your email")
and grant https://mail.google.com/ or https://www.googleapis.com/auth/gmail.modify scopes.
Actual Behavior
Google consent screen shows "Claude for Google Drive wants additional access"
with only Drive file scopes. Callback URL always returns:scope=email+drive.readonly+drive.file+userinfo.email+openid
No Gmail scopes are ever granted.
Root Cause (suspected)
The Gmail MCP server OAuth client ID (5a970912-02f9-4e78-b66c-965c0e1a74b0)
appears to be the same OAuth app registered for Google Drive, not a
Gmail-specific app. Google's OAuth system shows the app name and scopes
registered for that client_id, which is Drive-only.
Environment
- Claude Code (web/CLI)
- Platform: Linux
- Gmail MCP server:
https://gmailmcp.googleapis.com/mcp/v1 - MCP server ID:
54fd9acb-7cb9-5d39-8b90-b9d1c7111fb4
Impact
The Gmail MCP integration is completely non-functional for all users.
Any workflow relying on Gmail (sending reports, reading email, creating drafts)
cannot work until the correct OAuth client is used.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Sonnet 4.6 (model ID: claude-sonnet-4-6)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
7 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This looks like a clean OAuth-client mismatch rather than a generic auth failure. The user is trying to authorize Gmail MCP, but the flow is attached to the Drive-branded client and only presents Drive permissions. In that configuration, Gmail access can never successfully materialize no matter how many times the user retries.
That makes this more severe than a flaky re-auth loop because the workflow is structurally unwinnable:
From the operator perspective, the connector feels connected-but-impossible. The surface offers Gmail capability, but the underlying consent model cannot actually mint the required permission set.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Adding corroboration: this is still broken and was auto-closed by the stale bot, not actually resolved. Same symptom on a separate Google Workspace account, onset April 20, 2026, the same date as the original report. Gmail and Calendar both return "The caller does not have permission" on every call, while Google Drive on the same account works normally. On re-auth, the consent screen only ever offers Drive scopes ("Claude for Google Drive wants additional access") and the callback returns scope=email+drive.readonly+drive.file+userinfo.email+openid, never any Gmail or Calendar scope. That matches the Drive-OAuth-client root cause described above and is consistent with #61534. This is a reproducible, all-users regression and should not sit closed as not planned. Requesting it be reopened and the Gmail/Calendar MCP repointed to a correctly scoped OAuth client. I can share account-specific diagnostics (request_id, timestamps) privately with a maintainer.
Confirming this is still broken as of June 2026. Attempted to use Gmail MCP tools today and hit the exact same issue—all read and write operations fail with "insufficient authentication scopes".
The root cause is clear: the OAuth flow is routed through the Google Drive client, not a Gmail-specific client, so tokens never
include Gmail scopes (gmail.readonly, gmail.modify, etc.).
Would appreciate any update on whether this is in the roadmap to fix. This blocks all Gmail workflows in Claude Code.
Still broken as of July 2026. Gmail MCP entirely non-functional—all API calls fail with "insufficient authentication scopes" due to Drive OAuth misconfiguration. This blocks critical workflows (search, read, label, create drafts). Requesting priority fix or timeline for Gmail-specific OAuth client registration.
Confirming this is still broken as of August 2026.
claude mcp login gmailcompletes "successfully" and reports the server as authenticated, but no Gmail tools become available in the session, not even after a full restart of Claude Code and VS Code. Separately, tools that did load stayed scoped to Drive-style permissions, consistent with the Drive-OAuth-client root cause described above. This is blocking basic inbox-read workflows. Requesting this be reopened rather than left closed by the stale bot.