[BUG] Gmail connector OAuth missing write/modify scopes for label operations

+1 on this. I built a full email-triage workflow in Cowork around the Gmail connector — pulling threads, drafting replies, filing to Notion, archiving. Dropped it into daily use. Then label_thread / unlabel_thread disappeared from the tool surface and the whole second half of the workflow (archive, star, label) went dead.
Reconnecting doesn't fix it. The tools aren't even registered in my session now.

+1 Bug encountered in the Claude Code scheduled agent (remote trigger) + interactive sessions

Tools missing from registered MCP tools: label_thread, unlabel_thread — not present in the deferred tools list at all, unlike create_label, list_labels, search_threads which are available.

Error when attempting label operations via cloud trigger: 403 Permission Denied

Attempted fixes (all ineffective):

Reconnected Gmail integration via claude.ai > Settings > Integrations — repeated 8+ times across multiple sessions

• Deleted and recreated scheduled remote trigger
• Switched from cloud trigger to local scheduled task — same result; the tools simply aren't registered regardless of execution context

Analysis: Reconnecting never helped because it re-grants the same OAuth scope each time. The issue isn't the connection — it's that gmail.modify is absent from the OAuth app registration, so label_thread/unlabel_thread can't be requested or executed regardless of how many times the user reconnects. The tools appear to be implemented server-side but are effectively dead without the scope.

+1, reproduced today in Claude Code (Opus 4.7). What's the solution here?

Adding a scope breakdown in case it's useful for triage:

Working (read + compose scopes):

• list_labels — ✅
• search_threads — ✅
• create_draft — ✅

Failing with Request had insufficient authentication scopes (needs gmail.modify / gmail.labels):

• create_label — ❌
• label_thread — ❌
• unlabel_thread — ❌

A couple of notes that refine the previous comment:

• In my interactive Claude Code session label_thread and unlabel_thread are registered and callable — they just fail

at runtime with the 403 scope error. So the tools are wired up; it's purely the OAuth scope set that's missing
gmail.modify.

• Full revoke at myaccount.google.com/permissions + uninstall + reinstall does not re-prompt for new scopes,

confirming the connector's OAuth client registration itself doesn't request them.

• Claude.ai Settings → Connectors → Gmail shows "Write/delete tools" as "Always allow", so the Claude-side permission

gate is fine.

Same issue on my end today, connector is now blocked and cannot be re-connected it seems..

Confirming this issue in Claude Cowork. When attempting to create or manage Gmail labels, I receive a blocking error indicating Google is disconnected/blocked — despite the connector showing as fully connected with permissions set to allow.

Checked the granted OAuth scopes at myaccount.google.com/connections and can confirm the connector is only authorized for:

• See your profile info
• Manage drafts and send emails
• View your email messages and settings (read/search only)

The gmail.modify or gmail.labels scope is not present, which means the connector can view labels but cannot create, modify, or delete them. This is not a user configuration issue — the OAuth consent flow simply never requests the necessary write scope, so there's no way to grant it.

This makes label-based workflows in Cowork non-functional. Would appreciate a fix that includes the appropriate modify/labels scope in the OAuth request. Happy to provide additional details if helpful.

+1, I do see the tool mcp__claude_ai_Gmail__label_thread; but when Claude attempts to call it, it is hit with Request had insufficient authentication scopes.

Reproducing this bug on the routines / remote-agents surface (claude.ai/code/routines) in addition to Cowork. Same exact failure mode — label_thread returns:

MCP server "Gmail" requires re-authorization (token expired)
Streamable HTTP error: Server returned 403 after trying upscoping

Reads (search_threads, get_thread, list_labels) succeed in the same routine session that fails writes, confirming this is the missing-scope issue described here, not token expiry. The routine surface is worse than Cowork because there's no interactive consent prompt available — even if the user wanted to click through an upscope request, there's no UI for them.

Filed separately as #58225 (now closing as duplicate of this). Suggesting label area:routines be added here so the routines team also sees it.

Full repro context from the routines side: #58225

Any updates on this folks. Seems like a simple enablement.