claude-code - 💡(How to fix) Fix [BUG] Claude in Chrome v1.0.70: Infinite OAuth retry loop on persistent 403 causes side panel flicker and forced logout

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Title

[BUG] Claude in Chrome v1.0.70: Infinite OAuth retry loop on persistent 403 causes side panel flicker and forced logout

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet (related but distinct from #29628, #34176 which involve scope errors in different flows)
• This is a single bug report
• I am using the latest version of Claude in Chrome (v1.0.70)

Summary

The Claude in Chrome side panel flickers periodically (~every 10–20s) and eventually forces a redirect to login, wiping all conversation context. Network analysis (HAR) reveals an infinite retry loop: the extension obtains a fresh OAuth token, attempts to upgrade a WebSocket to bridge.claudeusercontent.com, receives a non-transient 403 error, and immediately retries — repeatedly, indefinitely.

The server explicitly marks the error as transient: false, yet the extension treats it as recoverable and re-attempts on every cycle.

Severity

🔴 High — Active sessions interrupted unpredictably; conversation history permanently lost; reproduces consistently for affected accounts; extension is unusable in this state.

Evidence (from HAR capture, 5-minute window)

In a 5-minute capture (17:43:24 → 17:48:25), 116 network requests were recorded with the following pattern repeating ~25 times:

``` loop: POST https://platform.claude.com/v1/oauth/token → 200 OK WS wss://bridge.claudeusercontent.com/chrome/<bridge_id> send: { "type": "connect", "client_type": "chrome-extension", "extension_version": "1.0.70", "os_platform": "Windows", "device_id": "<uuid>", "oauth_token": "sk-ant-oat01-..." } receive: { "type": "error", "error": "OAuth token forbidden (403) — missing scope or org access", "reason": "upstream_403", "upstream_status": 403, "transient": false } WS close GET /api/oauth/profile → 200 OK (immediately retry) ```

Key observations:

• All 25 WebSocket attempts received the identical 403 error
• Server explicitly sets "transient": false — indicating retry will not help
• A new OAuth token is minted every cycle — token rotates each retry, but every fresh token receives the same 403
• All HTTP requests return 200 — there are no failed REST calls; the failure is exclusively at the WebSocket layer
• The OAuth profile endpoint reports the user is authenticated successfully, yet the bridge rejects the same identity

Suspected Root Cause

Two overlapping issues:

1. Server-side authorization bug: The OAuth token issued to the user is missing the scope or org access required by bridge.claudeusercontent.com. This happens immediately after login — never works for this account. Possibly related to scope issues in #29628 and #34176.

2. Client-side retry-loop bug: The extension does not honor the server's transient: false flag and retries indefinitely. There appears to be no exponential backoff or retry cap. This turns a single auth misconfiguration into a continuous flicker/logout loop that destroys user state.

The client behavior is independently a bug — even when the underlying auth issue is fixed, the extension should not retry non-transient errors aggressively, and should not destroy user-visible state on each retry.

Steps to Reproduce

1. Install Claude in Chrome v1.0.70 (ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)
2. Log in with affected account [details available privately if needed]
3. Open the side panel, start a conversation
4. Within ~10–20 seconds: side panel flickers
5. After several flicker cycles: forced redirect to login
6. Conversation context is lost
7. Re-login produces the same loop

Expected Behavior

• WebSocket bridge accepts the OAuth token issued to a logged-in user (server-side fix), OR clearly surfaces the actionable error to the user (e.g., "Your account does not have access to Claude in Chrome — contact your admin")
• On transient: false errors, the client stops retrying and shows an actionable error UI instead of looping
• Conversation state is preserved across transient WebSocket reconnects

Actual Behavior

• WebSocket bridge returns persistent 403 immediately on every connect
• Client retries indefinitely, treating non-transient error as transient
• Each retry cycle re-renders the side panel (visible flicker)
• After enough failures, user is logged out and conversation is wiped

Environment

• Extension version: 1.0.70
• Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn
• OS: Windows (per WebSocket payload os_platform: "Windows")
• Chrome version: [TODO — chrome://version]
• Account type: [TODO — Pro / Team / Enterprise / Free]
• Org membership: [TODO — relevant if "missing org access" applies]

Tangentially related observations (likely not root cause)

While investigating, the following were also noted but appear unrelated to the flicker/logout loop:

• CSP violations on options.html#options:8 for inline scripts and a third-party Segment/Amplitude CDN load (cdn.segment.com/.../amplitude-plugins/...). These are Manifest V3 compliance issues but the side panel and service worker continue functioning despite them.
• Service worker is healthy during the loop: Installation: ACTIVATED, Running: RUNNING, Version ID: 76 (per chrome://serviceworker-internals). The service worker console log is empty.
• Build artifact name service-worker.ts-gaAAsstG.js retains the .ts extension before the content hash — minor, but unusual for a production build.

Suggested Triage

1. Investigate why bridge service rejects OAuth tokens for this account with missing scope or org access — coordinate with auth team
2. Add client-side handling for transient: false errors: stop retrying, show actionable error UI
3. Add exponential backoff and retry cap to WebSocket reconnect logic regardless of error type
4. Decouple side panel UI state from WebSocket connection lifecycle so transient reconnects do not visibly re-render or clear conversations

Attachments (please request privately — contain credentials)

• HAR file with full WebSocket payloads (contains rotating OAuth tokens — do not share publicly)
• Service worker internals snapshot
• Screenshots of CSP errors

What Should Happen?

The Claude in Chrome side panel should maintain a stable session during normal use. Specifically:

1. The WebSocket bridge at bridge.claudeusercontent.com should accept the OAuth token issued to a successfully logged-in user. If the token genuinely lacks required scope or org access, the user should see a clear, actionable error message (e.g., "Your account does not have access to Claude in Chrome — please contact your admin") instead of being silently logged out.

2. When the server returns an error with "transient": false, the client should stop retrying and surface the error to the user, not loop indefinitely.

3. Conversation context in the side panel should persist across transient WebSocket reconnects. The UI should not be destroyed on every reconnect attempt.

4. Users should not be forcibly redirected to the login screen without explicit action (logout button, expired session after long idle, etc.).

Error Messages/Logs

Steps to Reproduce

1. Install Claude in Chrome v1.0.70 from the Chrome Web Store (Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)
2. Log in with an Anthropic account
3. Open the side panel and start a conversation
4. Open DevTools on the side panel → Network tab → enable "Preserve log"
5. Wait 10-20 seconds during normal use

Observed loop (repeats every ~10-20 seconds): a. POST https://platform.claude.com/v1/oauth/token → 200 OK (fresh token issued) b. WebSocket connect to wss://bridge.claudeusercontent.com/chrome/<id> Sends: { "type": "connect", "extension_version": "1.0.70", "oauth_token": "sk-ant-oat01-..." } Receives: { "type": "error", "error": "OAuth token forbidden (403) — missing scope or org access", "reason": "upstream_403", "upstream_status": 403, "transient": false } c. WebSocket closes d. GET /api/oauth/profile → 200 OK e. Side panel flickers (visible re-render) f. Loop restarts

After enough cycles: side panel forcibly redirects to login screen, all conversation context is permanently lost. Re-login reproduces the same loop.

In a 5-minute capture, this loop repeated 25 times with 116 total network requests. Every WebSocket attempt received the identical non-transient 403, but a NEW oauth token was minted each cycle (token rotates every retry, all tokens get the same 403).

Additional context:

• Service worker remains healthy throughout (status: ACTIVATED + RUNNING, console log empty per chrome://serviceworker-internals)
• All HTTP REST calls return 200; failure is exclusively at the WebSocket layer
• HAR file with full payloads available on request (contains rotating OAuth tokens, cannot be shared publicly)

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

N/A — this is a Claude in Chrome extension bug, not Claude Code CLI. Claude in Chrome extension version: 1.0.70 Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

No response