Claude in Chrome: bridge relay persistently rejects valid OAuth token with 'Invalid token or user mismatch' (account-specific, 2 months unresolved)

Summary

The Claude in Chrome connector cannot establish a bridge connection to bridge.claudeusercontent.com. Every connection attempt is rejected by the server with WebSocket close code 1008 (policy violation) and the error Invalid token or user mismatch — returned immediately (0ms after the WS upgrade).

The OAuth token is valid and works for everything else in Claude Desktop (model inference, other MCP connectors, etc.). The rejection happens only on the bridge relay, and only for my account. A different account (my wife's, on her laptop) pairs successfully with the same Desktop build, so this is not a client bug — it's server-side state tied to my account/org.

Filing here because this has been open with support@anthropic.com for a month (original March 22, 2026, follow-ups March 28 and April 18, 2026) with no engineer engagement — all replies have been generic Fin AI templates.

Repro log (today, Desktop v1.3109.0)

[Claude in Chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/<account-uuid>
[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] Bridge reconnecting in 30000ms

Repeats indefinitely every 30 seconds. chrome-native-host.log is healthy (socket opens, Chrome connects via native messaging, clean EOF on app close) — the failure is strictly the cloud bridge leg.

Environment

• Claude Desktop: 1.3109.0 (started on 1.1.7714 when first reported, updated many times since)
• Chrome: 147.0.7727.56
• Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn
• macOS: 15.7.4 (Sequoia), Apple Silicon (M3 Max, 48 GB)
• Network: wired + Wi-Fi tested on multiple networks, VPN off, Tailscale off

What I'm asking

Please have someone with access to the bridge relay infrastructure inspect the server-side pairing state for the affected account. The likely cause is a stale pairing record from a previous account that was signed in on this machine ~2 months before the original report, which now conflicts with the current account's pairing attempts. A server-side reset of that state is almost certainly all that's needed.

Happy to provide the account UUID, organization ID, and support conversation IDs privately (email or Anthropic-internal channel). I don't want to post them on a public issue, but support@ has the full details — conversation IDs:

• 215473584418621 (original, March 22)
• 215473968610394 (follow-up, April 18)

What has been ruled out locally

Every step from the March 22 thread has been repeated, most of them multiple times:

• Reinstall Chrome extension
• Fresh OAuth authorization (Desktop and extension)
• Sign-out/sign-in cycle on both sides
• Chrome Local State cleanup (including the stale unsafely-treat-insecure-origin-as-secure flag from an earlier failed attempt)
• Extension LevelDB storage wipe + re-auth from scratch
• Full macOS reboot
• Different Wi-Fi networks

Account on the extension matches account on Desktop. Matching is confirmed in the logs: the extension is authenticated, Desktop's OAuth token is present and used successfully for other features, but the bridge rejects them as mismatched.

Why this is worth an engineer's 10 minutes

• Affects account since Feb 2026
• Two-month-old support thread with no action
• Fix should be server-side only (reset pairing state) — no client change needed
• Generalizes: any user who ever had a different Anthropic account signed in on the same Chrome install is probably in the same failure mode

Happy to DM account details to whoever picks this up. Thanks.

---

(This issue was drafted by Claude Opus 4.7 in Claude Desktop's Code tab, based on direct inspection of main.log, chrome-native-host.log, Chrome Local State, Desktop's OAuth store, and running process state.)