Connector shows "connected" in Settings but isn't available to sessions or scheduled routines (Gmail)

check Google’s authorized app list → clear caches → check for shadow connections via Zapier/Make/custom MCP → reconnect)

Anthropic’s connector UI has a layer below “connected” status: individual tool/search toggles that must be separately enabled per-connector inside a chat’s “Search and Tools” menu, distinct from the account-level Customize > Connectors page. A connector can show “Connected” in Settings while its actual search/tool toggle is off in a given session or workspace, which would explain why Google Drive (often auto-enabled) works while Gmail silently doesn’t surface as a tool.

At myaccount.google.com/connections, open the Claude entry and inspect exactly which permissions were granted, not just whether it’s connected.

• Compare against what the current Gmail connector documentation says it should request; a stale/partial grant from an older connector version reconnecting under a new scope set is a known failure mode.

There’s a reported bug pattern where /mcp (Claude Code’s own connector list) and the web-based Customize > Connectors list are backed by different internal states, and a Gmail connector added via one path doesn’t register in the other, requiring the disconnect to happen specifically from claude.ai’s Connectors settings (server-side), not from within Claude Code. Given you already tried a website-side disconnect/reconnect, this next check matters: Inside Claude Code, run /mcp explicitly (separate from general tool search) — this surfaces MCP-registered connectors distinctly from the general tool list and has been the actual fix in at least one similar bug report. -> Look for a duplicate/orphaned Gmail connector entry — a known issue exists where disconnecting one Gmail connector can leave a broken internal reference that prevents a newly connected one from being usable, even though the UI shows only one active connection.

———Try authenticating in a fully separate browser (or a clean private/incognito profile with no extensions) rather than clearing cache in the existing browser.

(If applicable): If this Google account is a Google Workspace (business/org) account rather than a personal Gmail, your org’s admin console can silently block Claude’s OAuth app for Gmail-specific APIs while allowing Drive, since these are controlled as separate API scopes under “Manage third-party app access”. This would produce exactly your symptom: connected in Claude’s UI, invisible in practice, Drive unaffected. -> Check admin.google.com > Security > API controls > Manage third-party app access and verify Claude is marked “Trusted” specifically for Gmail scopes, not just generally.

Update: went further than the initial repro. Reached a much more complete connector state via the connector directory's detail view (not the Settings page) — a full "Tool permissions" screen with 5 read-only tools and 11 write/delete tools individually listed and configured (read-only set to "Always allow", write/delete set to "Needs approval"), and the top-level button correctly showing "Disconnect" rather than "Connect".

Re-checked both surfaces (a live session's own tool list, and the /schedule cloud-routine connector list) immediately after reaching this state — still zero change, only the other connector (Google Drive) shows up in either. This was checked with the most complete-looking connected state achievable through the UI, so this doesn't look like an incomplete-connection issue on the user's end — the connector genuinely is fully configured on the claude.ai side and still isn't propagating to either the live session tool surface or the routine connector list.

Second update, ruling out my own earlier theories with a clean, minimal test.

Ran a maximally-permissive diagnostic routine (no allowed_tools restriction at all — let the platform default apply, which auto-populated a set of local built-in tools only; no Gmail entries in it) with all three of the account's connected MCP connectors auto-attached (Drive, Gmail, and one labeled "Claude_Code_Remote"). The task was trivial: list Gmail labels, create exactly one test label, report what happened at each step.

Confirmed via the routine's own last_fired_at/ended_reason: "run_once_fired" that it genuinely executed. Checked the real result directly via the Gmail connector from a separate, working session: the test label was never created. Zero effect, same as the two more complex attempts before it.

This rules out both prior theories (wrong MCP tool-name prefix guessed in allowed_tools; an overly-restrictive permitted_tools array on the connector) since this run had neither of those constraints — no allowed_tools override, no permitted_tools set. Four real attempts now, three different configurations, consistent zero-effect result. I don't have visibility into the routine's actual execution transcript via the trigger API (get/list don't expose it), so I can't see what error, if any, the routine encountered — but the consistent, total lack of any observable effect across genuinely different configurations points to something failing at the connector-auth or connector-execution level within the cloud-routine environment specifically, not a configuration mistake on the calling side.

Third update — a sharper hypothesis, reasoned from a clue I hadn't weighted properly.

Gmail works correctly in a live, interactive Claude Code session (confirmed — successfully called its tools repeatedly over several hours tonight). It only fails when attached to a cloud routine specifically, across 4 attempts and 3 different tool/permission configurations. Meanwhile, a second connector (Google Drive) works correctly in both contexts, and has been connected for several days prior, versus Gmail which was only freshly authorized a few hours before these tests.

That asymmetry (works in live session / fails only in routine creation; long-established connector works everywhere / freshly-authorized connector fails in one specific context) looks like a propagation-lag issue rather than a permanent failure: whatever backend serves live-session tool availability appears to have picked up the new Gmail grant already, while whatever backend serves cloud-routine mcp_connections resolution has not yet, for this specific freshly-granted credential. This would explain why every configuration permutation on my end produced an identical zero-effect result — the problem may not be reachable by any client-side configuration at all.

Scheduling a retry of the same minimal diagnostic several hours from now to test this directly (does time-since-authorization alone resolve it, with zero config changes) rather than assuming it will.

Fourth update — tested my own propagation-lag hypothesis from the previous comment directly, and it doesn't hold at this timescale.

Re-ran the identical minimal diagnostic ~7.5 hours after the original attempts (same connector, same account, no reconfiguration on my end in between). Confirmed via last_fired_at/ended_reason: "run_once_fired" that it genuinely executed. Result: identical to every prior attempt — zero effect, no test label created, checked directly via the Gmail connector from a working live session immediately after.

So: 5 real attempts now, across ~7.5 hours of elapsed time and 3 different tool/permission configurations, all producing an identical zero-effect result. Time alone does not resolve it, which rules out simple propagation lag as the explanation. At this point I've exhausted what's testable from the client side without visibility into the routine's actual execution transcript (the trigger API doesn't expose it). This looks like a genuine, persistent platform-level issue specific to the Gmail connector's availability within cloud-routine execution — happy to provide any additional diagnostic info that would help track it down further.

Consolidated summary of everything above, for anyone triaging this — the full trail across 5 real attempts is spread across several comments, here's the condensed version.

Symptom: Gmail connector shows fully connected (checkmark in Settings, complete "Tool permissions" screen with individually-configured read/write tool policies, "Disconnect" button present — the most complete connected state the UI allows) and works correctly in a live, interactive Claude Code session. It does not work at all when attached to a cloud routine (via the /schedule/trigger-creation flow's mcp_connections), across every configuration tried.

What was tried, all producing an identical zero-effect result (no labels created, no observable action taken):

1. allowed_tools restricted to a guessed tool-name prefix (mcp__Gmail__*)
2. allowed_tools widened to include a second guessed prefix (mcp__claude_ai_Gmail__*) alongside the first
3. Explicit permitted_tools set on the mcp_connections entry with both guessed prefixes
4. A maximally-permissive minimal diagnostic: no allowed_tools override at all (platform default applied), all 3 of the account's connectors auto-attached, single trivial task ("create one Gmail label")
5. The identical minimal diagnostic re-run ~7.5 hours later, to rule out propagation lag — same zero-effect result

Key comparison point: a second connector (Google Drive) works correctly in both the live-session and cloud-routine contexts throughout, using the exact same attachment mechanism (mcp_connections with its own connector_uuid/name/url). This rules out a general connector-attachment problem and points specifically at Gmail.

What would help move this forward: any way to inspect the actual execution transcript/error output of a specific cloud routine run (the RemoteTrigger get/list API used throughout this investigation doesn't expose it) — that would show whether the routine's session ever actually attempted a Gmail tool call and what error (if any) it received, rather than inferring purely from the absence of any effect.

Reporting this now so it's tracked — not something we can resolve further from the client side.