[BUG] Cowork remote MCP connector — "Couldn't reach the MCP server" with auth state desync, reference ID returned for support lookup

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?

Summary

Cowork desktop (Windows 11) is returning a "Couldn't reach the MCP server" error popup for a remote MCP connector that was previously working. The error provides a support reference ID, suggesting server-side telemetry is captured. Anthropic FinAI support confirmed this represents a "known pattern" of auth state synchronization lag where the OAuth handshake succeeds but the connection state does not propagate. Filing here per FinAI's recommendation that product bug reports are the path for engineering visibility.

Error message (verbatim)

Couldn't reach the MCP server. You can check the server URL and verify the server is running. If this persists, share this reference with support: 'ofid_518b899fda4d1ccf'

Screenshot attached.

Reproduction context

• Cowork desktop, Windows 11, Max plan subscriber
• Fresh Cowork install completed 2026-06-01 after recovery from a separate wedged MSIX install (HRESULT 0x80073CF6, related to clicking "Reinstall the workspace" link — separate concern)
• Affected MCP server: a remote MCP server connected through Cowork's connector UI (server-side), not a custom claude_desktop_config.json entry
• Error appears intermittently during normal Cowork mode use
• Regular Chat mode is unaffected

FinAI-suggested workaround

Toggle the affected connector off in Cowork settings, wait 2-3 minutes, toggle it back on. The wait is to allow server-side auth state to clear before reconnection.

Why filing this here

I escalated this case via email support. FinAI confirmed it cannot assign cases to human agents, cannot look up the reference ID in internal systems, and pointed to product bug reports as the path for engineering review.

The reference ID ofid_518b899fda4d1ccf should be lookupable by engineering to identify the specific server-side failure state.

Business context

This affects a paying client engagement (Max-tier). The Cowork mode instability across two separate failure modes within 24 hours of a fresh install is materially affecting my ability to deliver client value. Cowork on Windows production stability for client engagements is a real concern that I would appreciate guidance on.

Related issues

• #27801 (VM service not running, persists after reboot)
• #36522 (VM service stops after Claude launches)
• #48001 (Cowork fails to start, VM service not running)

What I am asking for

1. Engineering lookup of reference ID ofid_518b899fda4d1ccf to identify the specific failure state.
2. Confirmation of whether the connector-toggle workaround is the recommended ongoing remediation, or whether a more permanent fix is expected.
3. Status of the auth state desync as a "known pattern" — is this on the roadmap to address, or is the workaround the long-term answer?

What Should Happen?

The Cowork remote MCP connector should maintain a stable connection. When server-side auth state desynchronization occurs, the connection should auto-recover without requiring user intervention or producing error popups during normal Cowork mode use.

Error Messages/Logs

Couldn't reach the MCP server. You can check the server URL and verify the server is running. If this persists, share this reference with support: 'ofid_518b899fda4d1ccf'

Steps to Reproduce

1. Install Cowork Desktop on Windows 11 (fresh install via MSIX from claude.com/download).
2. Sign in with paid plan account (Max tier in this case).
3. Connect a remote MCP server through Cowork's connector UI (the affected one in this case is a server-side Zapier MCP integration).
4. Use Cowork mode normally — sub-agent task with file access.
5. After some period of normal use, the "Couldn't reach the MCP server" popup appears intermittently with a unique reference ID per occurrence.
6. Regular Chat mode in the same desktop app is unaffected.
7. Per Anthropic FinAI support, the recommended workaround is to toggle the affected connector off in Cowork settings, wait 2-3 minutes, then toggle it back on.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Worked until 2026-06-01 fresh reinstall

Claude Code Version

N/A — This issue is for Claude Cowork Desktop (productivity mode), not Claude Code CLI. Filing here per Anthropic FinAI support recommendation that product bug reports are the engineering visibility channel.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This issue is specifically for Claude Cowork Desktop (the productivity layer in Claude Desktop), NOT Claude Code CLI. Several related Cowork-on-Windows bugs are tracked in this same repo: #27801 (VM service stop pattern), #36522 (VM service stops after Claude launches), #48001 (Cowork fails to start).

Screenshots of the error popup are attached below.

Existing Anthropic email support ticket: [INSERT YOUR TICKET ID IF YOU HAVE IT OR LEAVE THIS NOTE IF YOU DO NOT]. FinAI explicitly stated it cannot escalate cases to human engineers or perform internal reference ID lookups, and recommended product bug reports as the path for engineering visibility.

<img width="718" height="334" alt="Image" src="https://github.com/user-attachments/assets/d9e03768-1297-4db1-90ea-55891866e551" />
<img width="622" height="418" alt="Image" src="https://github.com/user-attachments/assets/d359087e-8ace-455a-9a8c-8454d874b733" />
<img width="1198" height="622" alt="Image" src="https://github.com/user-attachments/assets/ebf7fda1-82c4-44aa-b480-7e85d137c49d" />