[BUG] Connector tools activate silently and with long, unsignalled delay — connecting Calendar appears to have connected Gmail instead

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Connector activation gives no in-session signal, and the delay between granting
consent and the tools appearing can span several conversation turns. Combined
with a consent screen named after a different product than the one that
activates, this is very hard to tell apart from an outright failure.

Observed sequence in a single Claude Code desktop session:

1. Completed a Google OAuth flow. The consent screen read **"Claude for Google

Calendar wants access to your Google Account"**, with a note that *"Claude for
Google Calendar already has some access — See the 5 services."*

1. Immediately after consent, 16 Gmail tools hot-loaded into the running

session. Zero Calendar tools. A read-only list_labels call confirmed the
Gmail connector was genuinely live.

1. Searched the session repeatedly for any calendar capability across several

turns — nothing. list_calendars, list_events, create_event and friends
did not exist.

1. Several turns later, with no further action on my part in the session, **9

Google Calendar tools** appeared under a second, separate MCP server ID.
list_calendars then returned real calendar data.

So it did eventually work. But between steps 2 and 4 the session was
indistinguishable from a broken connector, and I nearly filed a bug saying
Calendar tools never load.

What Should Happen?

1. Signal activation. When a connector's tools load into a running session,

say so. Equally, if a connector is authorized but its tools are still
provisioning, that pending state should be visible rather than silent.

1. Name the consent screen after the connector being authorized. If a single

Google Cloud project intentionally backs all Google connectors, titling the
screen "Claude for Google Calendar" while Gmail is what activates
misrepresents the grant. At minimum the screen should name the connector the
user actually initiated.

Steps to Reproduce

Timing-dependent, so reproduction may vary:

1. From a Claude Code desktop session, authorize a Google connector.
2. Note the product named on the consent screen versus the toolset that appears.
3. Observe that tools appear with no announcement, and that the delay before a

second connector's tools arrive can span multiple turns.

Error Messages/Logs

No errors at any point. Every call that was possible succeeded; the difficulty
was entirely that unavailable-yet and never-going-to-be-available look identical.

Environment

• Claude Code desktop app, Windows 11 Pro (10.0.26100)
• Model: Opus 5
• Observed: 2026-08-02

Note on Confidence

I cannot tell from the outside whether the Gmail-first ordering was a
mis-provisioned grant, two connectors authorized by one consent screen resolving
at different speeds, or an unrelated action of mine landing late. The
reproducible, user-visible part is the silence and the delay; the consent-screen
naming is a separate and smaller observation included because it compounded the
confusion.

Related Issues

• #72914 — connectors show "Connected" but tools never load in a CLI session.
• #68794 — Google Calendar returns "Not connected" after OAuth granted (closed as

stale). Possibly the same underlying provisioning delay, observed by someone
who did not wait long enough.

• #70033 — GitHub connector connected but tools not injected into the session.