[BUG] Google Drive and Calendar connectors missing from Claude Code sessions; work on claude.ai web

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

The Google Drive and Google Calendar connectors are enabled and working on claude.ai web, but contribute zero tools to any Claude Code session on the same account. They are not reported as failed, pending, or needing auth — they are simply never enumerated.

Confirmed by comparing both surfaces on the same account, in the same hour:

| Connector | claude.ai web | Claude Code |
|---|---|---|
| Gmail | 29 tools | 29 tools |
| Notion | 41 tools | 41 tools |
| Slack | 27 tools | 27 tools |
| Google Drive | 11 tools | **absent** |
| Google Calendar | 9 tools | **absent** |

Three of the five namespaces match exactly, tool-for-tool, so the same connector set is being served to both surfaces from the same account. Only Drive and Calendar are dropped, and only in Claude Code.

On web, both connectors invoke successfully against real data — a Drive file listing and a calendar event listing both returned correct results. The OAuth grants, scopes, endpoints, and account linkage are therefore all verified working end to end.

Compounding this: `claude mcp list` reports both connectors as "Connected", identically to the working Gmail one, and `claude mcp get` returns byte-identical output for all three. The CLI cannot distinguish the broken case from the working one, so there is no way to self-diagnose this from the tooling.

### What Should Happen?

The Google Drive and Google Calendar connectors should appear in the Claude Code session's tool manifest and be invocable, exactly as Gmail, Notion, and Slack are. A connector that is enabled, authorized, and functional on claude.ai web should be available in Claude Code on the same account.

Failing that, the omission should at least be observable. If these connectors are intentionally not supported in Claude Code, then:

- `claude mcp list` should not report them as "Connected", since that is indistinguishable from the working Gmail connector; and
- the session startup log should account for them, rather than reporting `failed:0 / needs_auth:0 / disabled:0` while silently enumerating nothing.

Either behavior would have made this diagnosable. As it stands the connector is reported healthy at every layer while contributing no tools.

### Error Messages/Logs

```shell
There is no error message. That is the core of the report — the failure is silent.

Session startup log (%LOCALAPPDATA%\Claude\logs\main.log):

init_mcp=connected:14/pending:0/failed:0/needs_auth:0/disabled:0/other:0

14 connected, and the session manifest contained exactly 14 MCP namespaces. Drive and
Calendar appear in none of the failed / pending / needs_auth / disabled buckets, and
there was no tool-budget truncation notice. They contribute no namespace, so they
produce no log line at all.

`claude mcp list` reports both as healthy, identically to the connector that works:

claude.ai Google Drive: https://drivemcp.googleapis.com/mcp/v1 - Connected
claude.ai Google Calendar: https://calendarmcp.googleapis.com/mcp/v1 - Connected
claude.ai Gmail: https://gmailmcp.googleapis.com/mcp/v1 - Connected

All three report Connected; only Gmail yields tools. `claude mcp get` returns
byte-identical output for all three.

Separately, adding these endpoints manually is not a viable workaround, and fails with
its own error:

$ claude mcp add --transport http --scope user google-drive https://drivemcp.googleapis.com/mcp/v1
google-drive: https://drivemcp.googleapis.com/mcp/v1 (HTTP)
- Failed to connect - Incompatible auth server: does not support dynamic client registration

Cause: all three Google MCP hosts name https://accounts.google.com/ as their
authorization server in /.well-known/oauth-protected-resource/mcp/v1, and Google
publishes no RFC 7591 registration endpoint (/.well-known/oauth-authorization-server
returns 404). Claude Code's generic HTTP-MCP OAuth flow requires dynamic client
registration. This would fail for Gmail too, so it is not specific to Drive/Calendar —
but it does mean there is no user-side workaround for the main bug.
```

### Steps to Reproduce

No code or project files are required — this reproduces on any account with the Google
connectors enabled, in an empty directory.

1. On claude.ai, enable the **Google Drive**, **Google Calendar**, and **Gmail**
connectors. Complete the Google OAuth consent for each.

2. Verify the grants are healthy at https://myaccount.google.com/connections — "Claude
for Google Drive" and "Claude for Google Calendar" should both be linked to claude.ai
and carry their full scopes (`drive.file` + `drive.readonly`; `auth/calendar` plus
readonly variants).

3. **Control — confirm the connectors work on web.** In a new claude.ai web chat, ask it
to list its available connector namespaces with a tool count for each, then to list 3
Drive files and this week's calendar events. All three Google connectors are present
(Drive 11 tools, Calendar 9 tools, Gmail 29 tools) and Drive and Calendar both return
real data.

4. Start a Claude Code session on the same account, in any directory.

5. Inspect the session's MCP tool namespaces and their tool counts.

**Observed:** Gmail (29), Notion (41), and Slack (27) are present with tool counts
identical to web. Google Drive and Google Calendar are absent entirely — zero
namespaces, not a reduced set.

The connectors are also not merely deferred-and-unlisted: a deferred tool search for
`google drive list files` / `google calendar list events` returns no matching tools.
(On web these same connectors are deferred, and web's tool search does find and load
them.)

6. Confirm the CLI disagrees:

claude mcp list

Both Drive and Calendar report `- Connected`, identically to the Gmail connector that
is actually working.

7. Check the session startup log at `%LOCALAPPDATA%\Claude\logs\main.log`:

init_mcp=connected:14/pending:0/failed:0/needs_auth:0/disabled:0/other:0

The count matches the number of namespaces actually delivered. Drive and Calendar are
in no failure bucket — they are simply never enumerated.

Reproduced across 5+ fresh sessions, and after disconnecting and reconnecting both
connectors several times.

### Claude Model

Opus

### Is this a regression?

No, this never worked

### Last Working Version

_No response_

### Claude Code Version

2.1.259

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

PowerShell

### Additional Information

Everything below was checked and ruled out before filing, in case it saves triage time.

**1. Not local configuration.** Nothing about these connectors is cached locally.
`~/.claude.json` → `mcpServers` contains only an unrelated stdio server;
`%APPDATA%\Claude\config.json` has no connector keys. The only local trace of Drive and
Calendar is their names in `claudeAiMcpEverConnected` (historical).

**2. Not the OAuth grants.** Verified at myaccount.google.com/connections. Both apps are
linked to claude.ai, granted within the same hour as Gmail, and hold exactly the scopes
their endpoints advertise in `/.well-known/oauth-protected-resource/mcp/v1`.

**3. Not tool-budget truncation.** No truncation notice, and the namespace count matches
`connected:14` exactly. Nothing is being dropped for space.

**4. Not deferred-but-unlisted.** A deferred tool search for Drive and Calendar keywords
returns no matching tools in the Claude Code session. They are never registered. On web,
the same connectors are deferred and web's tool search finds and loads them successfully.

**5. Not stale session state.** Reproduced across 5+ fresh sessions, and after
disconnecting and reconnecting both connectors from the claude.ai UI several times. The
connectors cannot be toggled per-session in the desktop UI.

**6. No user-side workaround exists.** Adding the endpoints manually via
`claude mcp add --transport http` fails with "Incompatible auth server: does not support
dynamic client registration" — see the logs field. This is architectural: Google exposes
no RFC 7591 registration endpoint, and it would fail for the Gmail endpoint too.

**Secondary issue worth splitting out:** `claude mcp list` reporting "Connected" for a
connector that contributes zero tools is actively misleading. It health-checks the
endpoint — which succeeds, because the OAuth grant is valid — while the session never
enumerates the server. Surfacing a connected-but-zero-tools state distinctly would have
turned several hours of diagnosis into about a minute.

**Possibly related:** #88853 (open) reports the same `connected: true` / `enabledInChat: false`
state for Google Calendar/Gmail/Drive, but intermittently and on claude.ai/code. This report
is the deterministic, permanent case on the Windows desktop app: the same two connectors are
absent in every session, while three others from the same connector set attach normally with
identical tool counts to web.

Also possibly the same family: #62479 (closed as not planned) — Google connectors registering
only `authenticate`/`complete_authentication` stubs while Slack and Exa work; and #76442
(closed as not planned) — all connectors loading zero tools into Windows Cowork sessions.

Across those three the pattern is consistent: Google connectors specifically, account-level
state reporting healthy, tools absent from the session. This report adds a controlled
same-account comparison across two surfaces.

No source files or tests are identified. First reproduce with the Google Drive, Google Calendar, and Gmail connectors, then compare `claude mcp list`, the session MCP tool manifest, and `%LOCALAPPDATA%\Claude\logs\main.log`; done means Drive and Calendar tools enumerate like the working connectors, or their omission is explicitly surfaced with an actionable status.

索引モデルが issue の本文から書いたものです。