[BUG] Cowork Gmail/Outlook MCP connectors lose auth state, require disconnect-reconnect cycles repeatedly

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?

The Gmail and Outlook MCP connectors in Cowork periodically lose authentication / connection state and require the user to manually disconnect and reconnect (re-running OAuth) to restore access. This happens without user action and without explanation.

Environment

• Affected connectors: Gmail MCP, Outlook MCP (Microsoft 365 mailbox)

What Should Happen?

Gmail and Outlook MCP connectors should maintain authentication state continuously without user intervention. Specifically:

(a) OAuth refresh tokens should be persisted correctly across Claude app restarts
(b) Token expiration should be handled silently with refresh, not surfaced as a connection error
(c) Transient network failures should retry with backoff, not fail-and-disconnect
(d) If a connector does need re-authentication, the system should surface a clear notification and offer one-click re-auth, rather than requiring the user to manually navigate Settings → disconnect → reconnect

User shouldn't have to re-authenticate Gmail/Outlook multiple times per week during normal use.

Error Messages/Logs

Errors observed during MCP calls when connector is in failed state:

Gmail: "auth/connection error" (connector shows in disconnected state in Settings)
Outlook: "infrastructure error (not enabled for REST API)" — recurring even though connector worked previously
Outlook: returns no results when account state is degraded — silently empty results rather than explicit error in some cases (silent failure is its own bug variant)

User cannot access deeper logs — MCP server-side logs not exposed to end users.

If Anthropic has access to MCP server logs filtered to user's account, the disconnect events would be in the OAuth refresh / token-validate handlers.

Steps to Reproduce

Gmail and Outlook MCP connectors should maintain authentication state continuously without user intervention. Specifically:

(a) OAuth refresh tokens should be persisted correctly across Claude app restarts
(b) Token expiration should be handled silently with refresh, not surfaced as a connection error
(c) Transient network failures should retry with backoff, not fail-and-disconnect
(d) If a connector does need re-authentication, the system should surface a clear notification and offer one-click re-auth, rather than requiring the user to manually navigate Settings → disconnect → reconnect

User shouldn't have to re-authenticate Gmail/Outlook multiple times per week during normal use.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Frequency

"Quite often" — happens repeatedly throughout normal use. User estimates multiple times per week.

Possible relationship to other bugs

This may share root cause with [Issue 1 — Cowork scheduler stalls](LINK). Both manifest as background services failing silently after uptime. If a parent process is leaking memory or losing handles, both could be downstream symptoms.

Impact

• Disrupts hourly-email-triage scheduled task (likely silently fails when connector is disconnected, contributing to perceived "scheduler stall")
• User has to interrupt active work to manually re-authorize
• Trust degradation: user can't rely on email auto-monitoring

Suggested investigation

• Are Gmail/Outlook OAuth refresh tokens persisted correctly across Claude app restarts?
• Is there a token-expiration handler that fails silently?
• Is one connector (Gmail vs Outlook) more prone than the other?
• Logs from MCP server processes during a disconnect event would help — can users access these?
• Does the MCP framework retry transient auth failures, or fail-and-disconnect on first error?

### Labels
`bug`, `cowork`, `mcp`, `gmail`, `outlook`, `oauth`