Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

[BUG] Cowork MCP connectors lose auth after context compaction — not just server restarts

Summary

Custom MCP connectors in Cowork mode lose their authenticated session state after context compaction (not just server restarts). Every MCP tool call returns "This connector requires authentication. The user needs to connect it before this tool can be used." The only recovery is toggling the connector OFF → wait → ON manually.

Environment

• Claude Desktop: latest (March 2026)
• OS: macOS
• MCP server: Custom self-hosted server using Streamable HTTP + OAuth 2.1 (Bearer token auth)
• MCP server URL: https://mmpm.co.nz/mcp

Steps to reproduce

1. Connect a custom MCP connector in Cowork (OAuth flow completes successfully)
2. Use MCP tools — they work correctly
3. Continue working until the conversation is long enough to trigger context compaction
4. After compaction, attempt any MCP tool call

Result: Every call fails with "This connector requires authentication."

Expected: MCP session should survive compaction. The connector is still toggled ON in the UI — the auth state was simply lost when the context was compacted.

Two distinct triggers for the same failure

Both lead to the same dead state: connector shows as connected in the UI, but every tool call returns the auth error.

Why compaction matters

Related issues (#27142, #30385, #24350) focus on server-side session invalidation. The compaction trigger is different and arguably worse because:

• The user did nothing wrong — no server restart, no network issue
• It happens silently mid-conversation during long working sessions
• The MCP server is still healthy and accepting connections
• The client simply lost its cached auth state when the context was rebuilt

For users with long-running Cowork sessions (multi-hour coding/research), compaction happens regularly. Every compaction breaks every MCP connector until manually toggled.

Impact

This makes custom MCP connectors unreliable for any Cowork session that runs long enough to compact. Users must constantly monitor for the failure and manually reconnect, which breaks flow and loses context about what the MCP tools were being used for.

Suggested fix

The MCP client should persist connector auth state (tokens, session IDs) outside the conversation context, so compaction doesn't destroy it. On post-compaction initialization, the client should re-establish MCP sessions using the persisted credentials without requiring user intervention.

Related issues

• [BUG] MCP Streamable HTTP client does not re-initialize after server-side session invalidation #27142 — MCP Streamable HTTP client does not re-initialize after server-side session invalidation
• [BUG] CoWork connectors (Gmail, Slack, Calendar) lose session state — work once after toggle, fail on next session #30385 — CoWork connectors lose session state between sessions
• MCP server connections drop silently and require manual /mcp reconnection #24350 — MCP server connections drop silently, require manual reconnection
• [BUG] OAuth Authentication Succeeds but MCP Reconnection Fails - Requires Restart #10250 — OAuth succeeds but MCP reconnection fails
• [Feature Request] Auto-reconnect SSE MCP servers after server-side restart #30224 — Feature request: auto-reconnect SSE MCP servers after restart

What Should Happen?

MCP auth state should survive compaction. OAuth tokens and session IDs should be persisted outside the conversation context (e.g. in the VM's filesystem or a session store), not in ephemeral memory that gets wiped on compaction.
Auto-reconnect after compaction. When the Cowork VM resumes post-compaction, the MCP client should detect that its session is stale and silently re-establish the connection using the persisted credentials — no user intervention required.
Auto-reconnect after server restart. Same behavior when the remote MCP server restarts. The client should retry with existing auth tokens instead of giving up permanently.
UI should reflect actual state. If the connector is broken, the UI should show it as disconnected — not leave it toggled ON while every call fails. Currently the user has no signal that anything is wrong until they try a tool call.
Graceful degradation. If re-auth genuinely fails (e.g. token expired, server revoked access), surface a clear notification to the user — don't silently fail with a generic "requires authentication" error buried in tool call responses.

Error Messages/Logs

Before compaction (tools working normally):
Tool calls to custom MCP connectors return expected results. No errors.
After compaction — every MCP tool call returns:
This connector requires authentication. The user needs to connect it before this tool can be used.
This is the only error surfaced. There is no stack trace, no retry attempt, and no additional diagnostic information provided to the user or in the conversation.
Key observations:

The error appears on every MCP tool call after compaction, not just the first one
The connector toggle in the Cowork UI still shows ON/connected — there is no visual indication that auth was lost
The remote MCP server is healthy and accepting connections from other clients during the failure window
Server-side logs on the MCP server show no incoming requests after compaction — the client never attempts to reconnect
The failure is immediate — there is no timeout or retry period, the error returns instantly
Recovery requires toggling the connector OFF, waiting a few seconds, then toggling it back ON — at which point tools work immediately, confirming the server was never the problem

No server-side errors:
The MCP server (/health, /ready) returns 200 throughout. The issue is entirely client-side — the Cowork VM's cached session state was lost during context compaction and never re-established.

Steps to Reproduce

Steps to Reproduce

Open Claude Desktop → Cowork mode
Connect a custom MCP connector (e.g., a self-hosted server with Bearer token auth)
Verify the connector works by making several successful tool calls
Continue the conversation until context compaction is triggered (typically after extended multi-tool workflows that fill the context window)
After compaction, attempt any MCP tool call against the same connector

Result: Every tool call immediately returns:
This connector requires authentication. The user needs to connect it before this tool can be used.
Expected: Tools continue to work after compaction, or the client transparently re-authenticates using the stored credentials.
Workaround: Toggle the connector OFF in the Cowork UI, wait a few seconds, toggle it back ON. Tools work immediately, confirming the remote server was healthy the entire time.
Note: This also occurs after MCP server restarts (separate trigger, same root cause — cached session ID becomes invalid and the client never re-establishes it). The compaction trigger is more disruptive because it happens silently mid-conversation with no user action and no way to predict or prevent it.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

1.1.6679

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response