›_ Claude Code Issues
Claude Code Issues / #57522

[BUG] Claude in Chrome extension auth loop — re-authenticates every ~30s (PermissionManager-BqJmxUlR.js / mcpPermissions-X6RKG-4F.js)

Status Fixed / completed
Maintainer reply None cached
Activity 6 comments · opened May 9, 2026 · closed May 18, 2026

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 / Claude in Chrome

What's Wrong?

Claude in Chrome extension is stuck in a continuous auth/permission loop. Every ~30 seconds the extension re-authenticates and reconnects its websocket, generating constant background traffic from PermissionManager and mcpPermissions modules, even when the extension is idle and no tools are being invoked.

DevTools Network panel (with the extension's side panel open) shows a repeating pattern every ~30s:

  • GET /profile → 200 (fetch, ~0.6 kB) — initiated by PermissionManager-BqJmxUlR.js:3
  • GET /batch → 200 (fetch, ~0.2 kB) — initiated by PermissionManager-BqJmxUlR.js:3
  • GET /token → 200 (fetch, ~0.9 kB) — initiated by PermissionManager-BqJmxUlR.js:3
  • WebSocket reconnect to ff2f45b4-578a-47b0-ad80-4e79f67c1b95 → 101 — initiated by mcpPermissions-X6RKG-4F.js:1

Observed: 39 requests / 105 kB transferred / 245 kB resources within ~110 seconds of idle.

The loop reproduces:

  • Across browsers (Chrome, Edge)
  • Across networks (home WiFi, mobile hotspot)
  • Across machines (different physical computers)
  • In a fresh Chrome profile
  • After clearing all cookies for claude.ai and claudeusercontent.com
  • After reinstalling the extension
  • After signing out all devices and back in

Isolation testing confirms claude.ai web auth itself is healthy (no loop on web). The loop is specific to the extension's auth token issuance flow.

Steps to Reproduce

  1. Sign in to claude.ai on a Max plan account
  2. Install Claude in Chrome extension and connect
  3. Open the side panel
  4. Open DevTools → Network tab on the extension's panel
  5. Leave it idle and observe the repeating profile / batch / token / websocket pattern every ~30s

Environment

  • Plan: Max
  • Started: May 8, 2026
  • Browsers tested: Chrome (latest), Edge (latest)
  • OS: Windows
  • Extension files (hashed builds): PermissionManager-BqJmxUlR.js, mcpPermissions-X6RKG-4F.js
  • Web claude.ai: works normally, no loop
  • Cowork was used the night before the issue started — possibly relevant to extension token state

What I Investigated

The PermissionManager-*.js and mcpPermissions-*.js modules have a recurring history of permission-state bugs across builds:

  • #21772 — mcpPermissions-D8RnuVb0.js (extension fails to connect)
  • #30356 — PermissionManager-Dh53JkTm.js + mcpPermissions-D-cKe6e4.js (permissionMode read from bridge message instead of persistent storage; PermissionManager not instantiated when mode is "ask")
  • #50157 — mcpPermissions-D7Rkh1yL.js (navigation blocked despite allow setting)
  • #51273 — navigate tool blocked since v2.1.111

The build hashes I'm seeing (BqJmxUlR, X6RKG-4F) are newer than any of the above, suggesting this may be a regression in the latest extension/web build.

Given the symptom (token re-issuance every 30s with no user action) and the file involved (PermissionManager), the likely root cause is a token-lifetime / refresh-storage mismatch where the extension's auth state is treated as expired immediately after issuance — possibly related to the same persistent-storage bug pattern documented in #30356, but on the auth path instead of the permission path.

Expected Behavior

Extension auth token should persist for its full lifetime; PermissionManager should not re-issue credentials and reconnect the websocket on a 30-second interval while idle.

Actual Behavior

Continuous re-authentication and websocket reconnect every ~30 seconds, generating constant background traffic and (per support testing) blocking the paid Claude in Chrome use case.

Support Reference

A support ticket has been opened from account wasinngansathil1212@gmail.com with full troubleshooting history. Filing here additionally because the file-hash pattern points at a code-level regression rather than per-account state.

Thanks.

View original on GitHub ↗

6 Comments

github-actions[bot] · 3 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/57365
  2. https://github.com/anthropics/claude-code/issues/57373

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

wasinngansathil1212-debug · 3 months ago

any update?

wasinngansathil1212-debug · 3 months ago

Bug: Claude for Chrome extension stuck in ~30s auth token loop

Summary

The Claude for Chrome extension re-authenticates every ~30 seconds, making the extension unusable. The same account on claude.ai web works normally across multiple browsers — the issue is isolated to extension auth token issuance.

Environment

  • Extension: Claude for Chrome (latest)
  • Browsers tested: Chrome (stable), Microsoft Edge
  • OS: [fill in]
  • Plan: Max
  • Account: wasinngansathil1212@gmail.com
  • First observed: May 8, 2026
  • Still reproducing as of: May 13, 2026

Reproduction

  1. Install/enable Claude for Chrome extension
  2. Sign in
  3. Observe: every ~30s the session is invalidated and re-authenticated automatically, in a loop

Isolation confirmed

| Surface | Result |
|---|---|
| claude.ai web (Chrome) | Works normally |
| claude.ai web (Edge) | Works normally |
| Claude for Chrome extension (Chrome) | Loops every ~30s |
| Claude for Chrome extension (Edge) | Loops every ~30s |

Since web auth on the same account works fine across both browsers, but extension auth fails on both browsers, the issue is isolated to the extension auth token issuance pipeline, not session cookies, network, browser, or device.

Troubleshooting already completed

  • Signed out of all devices, signed back in
  • Cleared all cookies for claude.ai, anthropic.com, claudeusercontent.com
  • Uninstalled and reinstalled the Chrome extension
  • Tested in a fresh Chrome profile
  • Tested on home WiFi and mobile hotspot (different network entirely)
  • Disabled all other extensions
  • Verified system clock is correct

Relevant files seen in DevTools

  • PermissionManager-BqJmxUlR.js
  • mcpPermissions-X6RKG-4F.js

Support ticket

Conversation ID: 215474220348632 (open since May 8, 2026, no fix or ETA as of day 5).

Impact

Max-plan core feature fully blocked.

fobos-mk · 3 months ago

Hitting a related-but-distinct failure on the same extension build
(PermissionManager-BqJmxUlR.js, mcpPermissions-X6RKG-4F.js), worth
correlating because the file hashes match this report.

Symptom (different from OP): intermittent ~2-second "logout" in the
side panel — UI redirects to /login and bounces back. Not a 30s
re-auth loop; happens irregularly.

Trigger captured in side-panel DevTools Network:

  • GET https://api.anthropic.com/api/oauth/organizations/{orgId}/mcp/v2/bootstrap → 500 (also seen as net::ERR_ABORTED)
  • GET https://api.anthropic.com/api/oauth/organizations/{orgId}/spotlight → 500 (×2)
  • both initiated by PermissionManager-BqJmxUlR.js:3

Console error correlated in time:

  • WebSocket connection to wss://bridge.claudeusercontent.com/chrome/{deviceId} → net::ERR_NAME_NOT_RESOLVED and WebSocket opening handshake was canceled
  • DNS resolves fine from the OS (dig bridge.claudeusercontent.com → 160.79.104.10), so this is a transient Chrome-side or DNS-microblip issue, not local config.

Cookie / claude.ai web auth verified healthy at the same moment
(separate tab, no 401/403, no redirect).

Likely behavior in PermissionManager: the error handler treats a
500 from bootstrap as "not authenticated" and routes the side panel
to /login; once the retry succeeds the UI returns. Suggest
distinguishing 5xx from 401/403 in that code path — a transient backend
500 should retry-in-place, not bounce to login.

Env:

  • Plan: Max
  • OS: macOS 15.4 (Darwin 25.4.0)
  • Browser: Chrome (latest stable)
  • Date observed: 2026-05-13
fobos-mk · 3 months ago

Additional correlation from CLI side: Claude in Chrome MCP server in
Claude Code is "not connected" for the entire duration of this incident.
Local MCP log (mcp-logs-Claude-in-Chrome/*.jsonl) shows every call to
list_connected_browsers / switch_browser completes successfully in
~800ms — the Anthropic bridge is reachable, it just reports no paired
browser. So the side-panel bootstrap → 500 → /login failure also
prevents the extension from registering on the bridge for the CLI MCP
pairing. Same upstream cause, two surfaces.

github-actions[bot] · 1 month ago

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.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Authentication & login failures, IDE & terminal integration, Crashes, hangs & freezes

Browse all Claude Code issue topics →