[BUG] Claude in Chrome bridge permanently rejects valid tokens with "Invalid token or user mismatch" for Cowork — server-side stale state
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?
Claude in Chrome connector in Cowork permanently fails to connect via the WebSocket bridge. The bridge accepts the WebSocket handshake (status 101) but immediately rejects the application-level auth message with "Invalid token or user mismatch" (close code 1008).
This persists after clearing every possible client-side token/cache store, including Claude Desktop Electron auth, Chrome cookies, IndexedDB, Service Workers, extension LevelDB, and extension runtime storage via chrome.storage.local.clear(). The bridge UUID never changes, indicating stale server-side state that no client-side fix can resolve.
This appears related to #24593, #25151, and #26305, but those involve Claude Code CLI. This is purely Claude Desktop (Cowork) ↔ Chrome extension via the cloud bridge.
What Should Happen?
Claude Desktop should successfully connect to the Chrome extension via the WebSocket bridge at bridge.claudeusercontent.com and establish a working session, allowing Cowork to use Claude in Chrome for browser automation tasks.
Expected Behavior
Claude Desktop should connect to the bridge and establish a session with the Chrome extension.
Actual Behavior
From ~/Library/Logs/Claude/main.log:
[Claude in Chrome] ensureConnected called, connected=false, authenticated=false, wsState=undefined
[Claude in Chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/5e216c8a-9c47-48cd-83a8-4b694c83c64d
[Claude in Chrome] WebSocket connected, sending connect message
[Claude in Chrome] Bridge error: Invalid token or user mismatch
[Claude in Chrome] Bridge connection closed (code: 1008, duration: 0ms)
[Claude in Chrome] No longer connecting, giving up
This repeats indefinitely on every retry attempt.
Meanwhile, chrome-native-host.log shows:
Chrome native host starting (version 0.1.0)
Socket created successfully at: /tmp/claude-mcp-browser-bridge-nicha/3714.sock
Socket server listening for connections
The native host infrastructure works perfectly. The Control Chrome (Desktop MCP) connector also works perfectly — full handshake, all 10 tools registered. Only the Claude in Chrome cloud bridge fails.
Error Messages/Logs
[Claude in Chrome] ensureConnected called, connected=false, authenticated=false, wsState=undefined
[Claude in Chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/5e216c8a-9c47-48cd-83a8-4b694c83c64d
[Claude in Chrome] WebSocket connected, sending connect message
[Claude in Chrome] Bridge error: Invalid token or user mismatch
[Claude in Chrome] Bridge connection closed (code: 1008, duration: 0ms)
[Claude in Chrome] No longer connecting, giving upSteps to Reproduce
Environment
OS: macOS (Apple Silicon), Sequoia
Claude Desktop: v1.1.3770
Claude in Chrome extension: v1.0.53
Chrome native host: v0.1.0
Plan: Max (single account, no Team/Enterprise)
Auth method: Email magic link (consistent across all sign-in points)
Claude Code CLI: Not installed
Steps to Reproduce
Open Chrome with Claude in Chrome extension installed and signed in
Open Claude Desktop → Settings → Connectors → Claude in Chrome enabled
Open Cowork → enable Claude in Chrome in connector dropdown
Claude Desktop attempts to connect to bridge → immediately rejected
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude Desktop: v1.1.3770
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
Key Identifiers
Bridge UUID: 5e216c8a-9c47-48cd-83a8-4b694c83c64d (never changes despite full client wipes)
Organization ID: 890e15de-808d-4809-a44b-2216f5c8a5a4
Extension bridgeDeviceId: 08971388-c855-40cf-9776-dc4f5e08992a (regenerated fresh after wipe, still rejected)
Network Evidence
Chrome DevTools Network tab (filtered to WebSocket) shows 59 connection attempts to wss://bridge.claudeusercontent.com/chrome/5e216c8a-9c47-48cd-83a8-4b694c83c64d, all returning status 101 (WebSocket upgrade succeeds) but 0 kB transferred (rejected at application layer before any data exchange).
Client-Side Troubleshooting Exhausted
All of the following were attempted, none resolved the issue:
Standard restart cycle (quit Chrome → quit Desktop → reopen Chrome → reopen Desktop)
Sign out / sign in of Chrome extension
Cleared Chrome cookies for claude.ai and anthropic.com
Cleared Claude Desktop Electron auth cache (Local Storage/, Session Storage/, Cookies, Cookies-journal under ~/Library/Application Support/Claude/)
Deleted Chrome extension LevelDB (~/Library/Application Support/Google/Chrome/Default/Local Extension Settings/fcoeoabgfenejglbffodgkkbkcdhcgfn/)
Deleted Chrome IndexedDB and Service Worker data for claude.ai
Cleared Desktop OAuth token cache (confirmed fresh token obtained on reconnect)
Cleared bridge sockets (rm -rf /tmp/claude-mcp-browser-bridge-$USER/)
Fully uninstalled and reinstalled Chrome extension from Chrome Web Store
Toggled Claude in Chrome connector OFF/ON in Desktop Settings multiple times
Cleared extension runtime storage via DevTools console (chrome.storage.local.clear() + chrome.runtime.reload())
Verified: single Chrome profile, single account, consistent email magic link auth method everywhere, no Claude Code CLI installed
Root Cause Analysis
The bridge UUID 5e216c8a-9c47-48cd-83a8-4b694c83c64d is not stored locally — it appears to be derived or assigned server-side. After every client-side wipe, Desktop obtains a fresh OAuth token, the extension gets a fresh bridgeDeviceId, but the bridge server continues to reject with the same error on the same UUID.
This strongly suggests the bridge server has cached identity state (possibly from a previous session or auth context) that doesn't match freshly issued tokens, and no client-side action can clear it.
Request
Please investigate and reset the bridge state for this account on bridge.claudeusercontent.com.
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate — all three referenced issues were closed without any resolution:
#25618 (Feb 13, Windows 11): Closed as "invalid"
#25736 (Feb 14, macOS): Closed as "duplicate"
#26138 (Feb 16, macOS): Closed as "invalid"
None resulted in a fix. The bug spans multiple OS platforms (Windows + macOS), multiple auth methods (Apple Subscription, email magic link), multiple Desktop versions (v1.1.2998 through v1.1.3770), and multiple extension versions (v1.0.47 through v1.0.53). #25618 also references even older issues (#20298, #20887, #22052), suggesting this dates back.
My case adds new evidence:
The "invalid" label directs reporters away from this repo, but there is no public Claude Desktop bug tracker. Closing as duplicate of unfixed, closed issues creates a dead end where a confirmed, reproducible, cross-platform server-side bug receives zero engineering attention.
The fix is on bridge.claudeusercontent.com — the bridge server rejects valid OAuth tokens with stale state that no client-side action can clear.
✅ RESOLVED — Disconnect/Reconnect Cycle Fixes Bridge Auth
After extensive debugging (12+ client-side steps, full local storage wipe, version updates), the fix turned out to be a 3-step disconnect/reconnect cycle performed in this exact order:
The Fix
Phase 1 — Disconnect:
chrome://extensions/→ Claude extension → DisconnectPhase 2 — Restart:
Phase 3 — Reconnect (this order matters):
Key: Reconnection order matters — Desktop first, then extension, then let Cowork initiate the actual bridge handshake.
What Doesn't Work (Don't Do These)
local-agent-mode-sessions/,vm_bundles/,Local Storage/— destroys Cowork session history and does NOT fix the bridge (UUID is server-assigned, not locally stored)Key Finding
The bridge UUID (
5e216c8a-...in my case) is server-assigned. Even after wiping every local trace of it, the server returns the identical UUID on reconnection. The disconnect/reconnect cycle appears to force a fresh token handshake server-side without requiring engineering intervention.Environment
Hope this helps others hitting this.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.