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

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

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.

RAW_BUFFERClick to expand / collapse

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 / 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 [email protected] with full troubleshooting history. Filing here additionally because the file-hash pattern points at a code-level regression rather than per-account state.

Thanks.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING