Claude Desktop: Chrome Extension MCP bridge disconnects repeatedly, prompts for re-authentication

Description

Claude Desktop's "Claude in Chrome" MCP bridge repeatedly disconnects and forces user-visible re-authentication prompts. The Chrome extension WebSocket connection to bridge.claudeusercontent.com drops every 3-48 minutes, and because OAuth tokens are actively cleared from cache after each use, reconnection requires a fresh OAuth exchange that shows a browser sign-in prompt. This creates a disruptive cycle where Claude Desktop pauses mid-task and the user must manually re-authenticate.

Environment

• Claude Desktop version: 1.1.4328 (MSIX, Windows Store)
• Platform: Windows 11 Pro 10.0.26200
• Chrome version: 145.0.7632.117
• Chrome extension: Claude v1.0.56 (MV3)
• CPU: AMD Ryzen AI 7 PRO 350
• RAM: 32GB

Reproduction Steps

1. Open Claude Desktop with coworkWebSearchEnabled: true (default)
2. Start a conversation that uses the "Claude in Chrome" MCP (web search, browse, etc.)
3. Wait ~10-15 minutes after the initial connection
4. The Chrome extension disconnects from the bridge
5. Next tool call finds connected=false, authenticated=false
6. Claude Desktop opens a browser redirect for OAuth exchange
7. User is prompted to verify they're signed into Claude in Chrome
8. Clicking "Open settings" shows nothing actionable (already signed in)
9. After manually completing the flow, it works briefly, then the cycle repeats

Log Evidence

Repeated disconnections (7 in a single session on 2026-03-02):

15:27:36 [info] [Claude in Chrome] Chrome extension disconnected from bridge
15:39:03 [info] [Claude in Chrome] Chrome extension disconnected from bridge
15:57:15 [info] [Claude in Chrome] Chrome extension disconnected from bridge
16:45:23 [info] [Claude in Chrome] Chrome extension disconnected from bridge
16:57:47 [info] [Claude in Chrome] Chrome extension disconnected from bridge
17:19:26 [info] [Claude in Chrome] Chrome extension disconnected from bridge
17:22:22 [info] [Claude in Chrome] Chrome extension disconnected from bridge

OAuth token cache cleared after each use:

15:18:05 [info] [oauth] obtained new token for orgId=..., caching
15:18:06 [info] [oauth] clearing token cache, had 2 cached tokens
  (... next connection attempt has no cached token ...)
15:36:06 [info] [oauth] clearing token cache, had 1 cached tokens

Reconnection requires fresh OAuth every time:

15:18:04 [info] [Claude in Chrome] ensureConnected called, connected=false, authenticated=false, wsState=undefined
15:18:04 [info] [Claude in Chrome] Not connecting, starting connection...
15:18:04 [info] [oauth] no cached token found for orgId=...
15:18:04 [info] [oauth] performing fresh oauth exchange for orgId=...

Tool call timeouts after disconnect:

16:45:18 [warn] [Claude in Chrome] Tool call error: javascript_tool after 215ms
16:55:00 [info] [Claude in Chrome] Error calling tool: Tool call timed out: javascript_tool
17:36:23 [warn] [Claude in Chrome] Tool call timeout: navigate after 120014ms

EBUSY error on every startup (non-blocking but recurring):

[error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile '...\chrome-native-host.exe'

Root Cause Analysis

Two issues compound:

1. Chrome MV3 service worker suspension: The extension uses a service worker (manifest_version: 3) that Chrome suspends after periods of inactivity. This kills the WebSocket connection to bridge.claudeusercontent.com. The disconnection intervals (3-48 min) are consistent with Chrome's variable service worker lifecycle.

1. Aggressive OAuth token cache clearing: After each tool call or conversation turn, Claude Desktop clears the OAuth token cache (clearing token cache, had N cached tokens). This means every reconnection after a bridge disconnect must perform a user-visible OAuth exchange instead of silently using a cached token.

Expected Behavior

• Bridge disconnections should be handled silently with automatic reconnection
• OAuth tokens should persist long enough to allow silent re-authentication
• The user should never see a sign-in prompt unless their session has actually expired
• The EBUSY error on native host binary copy should be handled gracefully

Workarounds Attempted (none fully effective)

• Enabled Chrome background mode (background_mode.enabled = true)
• Added extension-service-worker-keepalive Chrome experiment flag
• Manually refreshed the native host binary (killed process, copied file)
• Verified single Chrome profile, no cookie-clearing extensions, no conflicting settings
• Restarted both Chrome and Claude Desktop — disconnections resumed within minutes