[BUG] Claude in Chrome v1.0.70: Infinite OAuth retry loop on persistent 403 causes side panel flicker and forced logout
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?
Title
[BUG] Claude in Chrome v1.0.70: Infinite OAuth retry loop on
persistent 403 causes side panel flicker and forced logout
Preflight Checklist
- [x] 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)
- [x] This is a single bug report
- [x] 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:
- 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.
- 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
- Install Claude in Chrome v1.0.70 (ID:
fcoeoabgfenejglbffodgkkbkcdhcgfn) - Log in with affected account [details available privately if needed]
- Open the side panel, start a conversation
- Within ~10–20 seconds: side panel flickers
- After several flicker cycles: forced redirect to login
- Conversation context is lost
- 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: falseerrors, 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:8for 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.jsretains
the .ts extension before the content hash — minor, but unusual
for a production build.
Suggested Triage
- Investigate why bridge service rejects OAuth tokens for this account
with missing scope or org access — coordinate with auth team
- Add client-side handling for
transient: falseerrors: stop
retrying, show actionable error UI
- Add exponential backoff and retry cap to WebSocket reconnect logic
regardless of error type
- 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:
- 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.
- When the server returns an error with "transient": false, the
client should stop retrying and surface the error to the user,
not loop indefinitely.
- Conversation context in the side panel should persist across
transient WebSocket reconnects. The UI should not be destroyed
on every reconnect attempt.
- 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
- Install Claude in Chrome v1.0.70 from the Chrome Web Store
(Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)
- Log in with an Anthropic account
- Open the side panel and start a conversation
- Open DevTools on the side panel → Network tab → enable "Preserve log"
- 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_
13 Comments
@anthropic-team This issue was auto-labeled
invalidbut I believethis is incorrect. This is a Claude in Chrome browser extension bug,
which is actively triaged in this repository. Reference issues with
area:browser-extensionlabel that were accepted here:The bug I reported involves the Claude in Chrome extension v1.0.70
running an infinite OAuth retry loop against
bridge.claudeusercontent.comthat returns persistent 403 with
"transient": false. This causesvisible side panel flicker and forced logout, destroying conversation
context.
Please remove the
invalidlabel and route to the browser-extensionteam. Could a maintainer add the
area:browser-extensionlabel?I have a HAR file with full reproducer (contains rotating OAuth tokens,
available privately on request). Happy to provide additional debugging
data.
Additional evidence — flicker also occurs on
options.htmlUpdate: I confirmed the flicker is not limited to the side panel.
The same flicker behavior occurs on:
chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/options.htmlThis significantly broadens the impact and narrows the root cause:
auth/WebSocket state, not just
sidepanel.htmlcause
auth/connection logic that runs across all extension pages
options.html#options:8may be more relevant than initially assessed — they originate
from the exact page that also flickers
This is a clear Claude in Chrome browser extension bug, not a
Claude Code CLI issue. Please reconsider the
invalidlabel.Hi Anthropic Support,
I'm a Claude Max subscriber experiencing a critical bug in the
Claude in Chrome extension that makes it unusable. I've already
filed a GitHub issue at [URL] but it was incorrectly auto-labeled
"invalid", so I'm escalating here.
Summary
The Claude in Chrome side panel and options page both flicker
continuously and force-redirect to login, wiping all conversation
context. Network analysis (HAR) shows an infinite OAuth retry loop:
{ "type": "error",
"error": "OAuth token forbidden (403) — missing scope or org access",
"reason": "upstream_403",
"upstream_status": 403,
"transient": false }
In a 5-minute capture, this happened 25 times.
Why this looks like a server-side issue
Account details
Impact
Claude in Chrome is completely unusable on my account. Every session
is destroyed within 1–2 minutes of starting.
What I need
my account
could fix immediately) or a deeper extension/server bug
I have a HAR file with full reproducer that I can share privately
(it contains rotating OAuth tokens, so I'm not posting it publicly).
Please let me know how to securely share it with your engineering team.
Reference GitHub issue: [your GitHub issue URL]
Thanks,
[Your name]
Update — additional evidence + relabel request
Adding new findings since this was auto-labeled
invalid:1. Confirmed server-side via multi-device test
Reproduces identically on 2 different Windows machines with:
This rules out: local cache, stale tokens, extension corruption,
profile state, cookies. The bug follows the account, not the
device — confirming server-side OAuth scope provisioning issue.
2. Affects all extension UI pages — not just side panel
chrome-extension://[id]/sidepanel.htmlflickerschrome-extension://[id]/options.htmlflickers (verified byattempting to view Claude in Chrome settings — page itself
flickers while open)
Rules out side-panel-specific React state corruption. Root cause
is shared auth/WebSocket logic.
3. Account context (filling in TODOs from original report)
out the org-domain hypothesis from #34990)
4. Settings verified correct
/api/oauth/profilereturns 200 (auth itself works)ACTIVATED + RUNNING, version stable,console empty)
5. Standard troubleshooting does NOT resolve
Full cycle attempted: sign out → clear all cookies (claude.ai,
claudeusercontent.com, anthropic.com) → uninstall extension →
wait 5 min → fresh install → fresh login. Same 403 immediately.
6. Related issues — same
bridge.claudeusercontent.com403This appears connected to a broader pattern of OAuth scope
issues with the bridge:
message, different flow — Pro plan)
user:sessions:claude_codescopeThe common thread:
bridge.claudeusercontent.comrejectingOAuth tokens with
missing scope or org accessdespite validauthentication. Possibly different surface symptoms of the same
underlying scope-provisioning bug.
Request for triage
Could a maintainer please:
invalidlabel — this IS a Claude in Chrome bugfiled in the established repo for browser extension issues
(precedent: #46514, #50157, #29628, #34176 all accepted with
area:browser-extension)area:browser-extension,area:auth,bug,platform:windowsSupport escalation status
escalate to engineering
215474228853141Available evidence (private)
tokens — cannot post publicly)
Happy to share via secure channel.
same issues
@anthropics <https://github.com/anthropics> — encountering the same error
message ("OAuth token
forbidden (403) — missing scope or org access" with transient: false from
bridge.claudeusercontent.com) but in a different flow:
Standalone Chrome extension on Max plan, not Cowork. The
side panel and options page both flicker every ~15s and force-redirect
to login, destroying conversation context.
Token rotates each retry — every fresh token gets the same 403.
Reproduces on 2 different Windows machines with fresh installs.
Tracked separately at #57365
<https://github.com/anthropics/claude-code/issues/57365> (my original
report) — please link
if same root cause. Full HAR analysis available there.
Adding here so triagers can see this 403 affects more than just
Cowork bridge connection.
ในวันที่ เสาร์ 9 พ.ค. 2026 เวลา 10:15 wasinngansathil1212-debug <
@.***> เขียนว่า:
same same
Can you improve one of them?
Nobody solved my problem.
ในวันที่ ส. 9 พ.ค. 2026 13:34 Por Jarlearnchaiyong <
@.***> เขียนว่า:
Update — VPN test reveals token rotation pattern
Adding new findings since this was auto-labeled
invalid:1. Confirmed server-side via multi-device test
Reproduces identically on 2 different Windows machines with:
This rules out: local cache, stale tokens, extension corruption, profile state, cookies. The bug follows the account, not the device.
2. Affects all extension UI pages — not just side panel
chrome-extension://[id]/sidepanel.htmlflickerschrome-extension://[id]/options.htmlflickers (verified)Rules out side-panel-specific React state corruption.
3. NEW: VPN test reveals token rotation issue
Tested with Cloudflare WARP (exit region: Singapore SIN):
Before VPN (Bangkok routing):
bridge.claudeusercontent.comimmediatelytransient: falseAfter VPN (Singapore routing):
POST /v1/messages 401 (Unauthorized)Critical insight: This pattern strongly matches #34785 ("Token refresh produces tokens with missing scopes"). The VPN doesn't fix the bug — it shifts WHEN it manifests:
This points to a token rotation pipeline bug that issues tokens with inconsistent scopes.
4. Account context (rules out org-domain hypothesis)
5. DNS resolution verified normal
nslookup bridge.claudeusercontent.com → 160.79.104.10 ✅
nslookup api.anthropic.com → 160.79.104.10 ✅ (same IP, Anycast)
Both resolve to Anthropic's IP block (
160.79.104.0/21). Anycast routing means same IP routes to different regional servers — explaining how VPN changes behavior.6. Settings verified correct
/api/oauth/profilereturns 200 (auth itself works)ACTIVATED + RUNNING)7. Standard troubleshooting does NOT resolve
Full cycle attempted: sign out → clear all cookies → uninstall extension → wait 5 min → fresh install → fresh login. Same 403.
8. Other users confirming same issue
Two other users have commented "same issues" / "same same" on this thread, indicating this is not isolated to my account.
9. Related issues — same
bridge.claudeusercontent.com403Hypothesis (refined)
Based on VPN test results, the most likely root cause is a token rotation pipeline bug where scope assignment is inconsistent across token issuance:
Request for triage
Could a maintainer please:
invalidlabel — this IS a Claude in Chrome bug (precedent: #46514, #50157, #29628, #34176)area:browser-extension,area:auth,bug,platform:windowsSupport escalation status
215474228853141Available evidence (private)
Happy to share via secure channel.
https://github.com/anthropics/claude-code/issues/57365
Update — Cowork is also affected (cross-product impact)
Tested Cowork mode in Claude Desktop App on Windows. Result confirms this bug has cross-product impact, not just Chrome extension UI:
Test
Asked Cowork:
Open google.com and search for "weather Bangkok"Result
Cowork attempted to invoke Claude in Chrome tools (response showed "Used Claude in Chrome (3 actions), loaded tools") but received:
Note: at the time of this test, the Chrome extension WAS installed, signed in, and visible in chrome://extensions — but it was in the broken state described in this issue (flickering, force-logout loop). Cowork couldn't establish connection because the extension's bridge connection is broken.
Implications
This confirms:
bridge.claudeusercontent.comfor browser tools (same dependency as Chrome extension itself)Comparison with #55611
#55611 reports: "Chrome extension works standalone, but Cowork can't connect to it."
In my case: BOTH are broken — extension flickers/force-logs out AND Cowork cannot establish browser connection.
Same root cause (
bridge.claudeusercontent.com403 / OAuth scope), different manifestations depending on extension's connection state.What still works on my account
What's broken
bridge.claudeusercontent.comThis significantly broadens the impact scope of this bug. Marking as cross-product issue would help engineering triage.
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.