Claude in Chrome: account mismatch on cold Chrome start from Cowork (no retry on bridge connect)

Summary

When Cowork triggers Chrome launch (Chrome not already running), the "Check your Claude in Chrome account" error dialog appears every time. Chrome extension works fine once manually dismissed and retried. The root cause is a race condition: Claude Desktop checks the WebSocket bridge for the extension before the extension has connected.

Environment

• macOS (Apple Silicon)
• Claude Desktop latest (as of 2026-03-20)
• Chrome extension v1.0.63 (ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Single Chrome profile (Default)
• Native messaging host correctly configured

Reproduction steps

1. Quit Chrome completely
2. Open a Cowork session in Claude Desktop
3. Request any action that requires Claude in Chrome tools
4. Error dialog appears: "Check your Claude in Chrome account"
5. Click Cancel, wait a few seconds, retry - works fine

Root cause analysis

The connection between Chrome extension and Claude Desktop uses two channels:

1. WebSocket bridge (wss://bridge.claudeusercontent.com/chrome/session-id) for account verification and session management
2. Unix socket (/tmp/claude-mcp-browser-bridge-user/PID.sock) for MCP tool calls, created by chrome-native-host

The race condition

When Cowork needs Chrome and Chrome is not running:

1. Claude Desktop is already connected to the WebSocket bridge
2. Claude Desktop launches Chrome
3. Chrome starts, extension service worker initializes, spawns chrome-native-host, creates Unix socket, extension connects to WebSocket bridge
4. But Claude Desktop checks the bridge BEFORE step 3 completes
5. Extension not yet on the bridge (or has stale/uninitialized auth state) -> "account mismatch"

Evidence from logs

chrome-native-host.log shows clean lifecycle: socket created, connections accepted, clean shutdown. No errors. The native messaging host itself works correctly.

main.log shows Claude Desktop repeatedly initializing "Claude in Chrome" as a connector. The bridge connection itself has retry logic for WebSocket drops (Bridge reconnecting in 2000ms attempt 1), but this retry pattern is NOT applied to the account verification step.

bridge-state.json persists stale session IDs between Chrome restarts. When Chrome relaunches, the old remoteSessionId is invalid but Claude Desktop may be checking against it.

What has been verified

• Native messaging host manifest correct (com.anthropic.claude_browser_extension.json)
• chrome-native-host binary exists and is executable (Mach-O universal)
• Extension has all required permissions including nativeMessaging
• Single Chrome profile, no multi-profile confusion
• Extension is from Chrome Web Store, not disabled
• Socket directory at /tmp/claude-mcp-browser-bridge-user/ creates and cleans up correctly

Proposed fix

Apply the same retry-with-backoff pattern that already exists for WebSocket connection drops to the account verification check:

1. When Chrome is not connected to the bridge, retry account check with exponential backoff (e.g., 1s, 2s, 4s) for up to ~15 seconds
2. Only show the error dialog if the extension still has not connected after the retry window
3. Optionally: clear stale bridge-state.json session IDs when Chrome disconnects, so reconnection always does a fresh handshake instead of comparing against stale state

Related issues

• #31971 Browser extension not connected despite correct setup
• #26305 Chrome Extension Connection Failure
• #24593 Browser extension persistently fails to connect from CLI