[BUG] Claude in Chrome 1.0.91: Sign-in screen after every browser-session end (reboot / profile switch) — silent re-auth never restores the session while claude.ai stays logged in

What's Wrong?

After anything that ends the browser session for a Chrome profile, the Claude in Chrome
side panel shows the Sign in screen — while claude.ai in a normal tab is still fully
logged in and unrelated sites keep their sessions.

The extension still knows the account (accountUuid and tokenOrg are intact on disk), so
this is not a sign-out. The in-memory tokens are gone and nothing restores them, even though
the bundle ships a silent re-auth path that appears designed to cover exactly this case.

What Should Happen?

On the first service-worker start after a browser session ends, the extension should silently
re-authenticate from the live claude.ai session and open already signed in, with no user
interaction.

Steps to Reproduce

1. Sign in to the Claude in Chrome extension. Confirm claude.ai is logged in in a normal tab.
2. Reboot the machine (or fully quit Chrome so the browser process actually terminates).
3. Start Chrome and open the Claude side panel.

Observed: side panel shows Sign in. claude.ai in a tab is still logged in, and other
sites (checked with an unrelated Google/YouTube login) keep their sessions.

Expected: the extension is signed in without interaction.

Additional observation — not instrumented

Switching from this Chrome profile to a second profile and back reproduces the same Sign-in
screen without a reboot. I have not instrumented chrome.storage.session across that
transition, so I am reporting it only as a reproducible user-visible observation, not as a
claim about the mechanism. The reboot path above is the one the evidence below covers.

Evidence

All of this is read-only inspection of the shipped 1.0.91 bundle and of the on-disk profile
data. I have not decompiled or modified anything.

1. Auth tokens are routed to chrome.storage.session (RAM-only), by design.
In assets/SavedPromptsService-*.js:

On = new Set(["accessToken","refreshToken","tokenExpiry",
              "startupReauthState","posture","pairingOrgMismatch"]);
function Cn(t){ return On.has(t) ? "session" : "local" }
function Dn(t){ return chrome.storage[Cn(t)] }   // every get/set goes through here

Every other key goes to chrome.storage.local.

2. Confirmed on disk. In Default/Local Extension Settings/fcoeoabgfenejglbffodgkkbkcdhcgfn/
the LevelDB contains accountUuid, tokenOrg, lastActiveOrgHint, oauthState,
codeVerifier — and zero occurrences of accessToken, refreshToken or tokenExpiry.
So there is nothing on disk that failed to decrypt; the tokens were never persisted.

3. refreshToken is session-scoped too, so the grant_type=refresh_token path against
https://platform.claude.com/v1/oauth/token cannot run after a session ends. Only a full
authorize round can recover.

4. The silent re-auth path exists but is not restoring the session here. Same bundle:

Ms = "cic_ext_silent_reauth";
async function Bs(){
  if (!ei(Ms, true))            return "disabled_by_gate";
  const acct = await Ln(Rn.ACCOUNT_UUID);
  if (!acct)                    return "no_stored_account";
  … prompt:"none", login_hint: acct, orgUUID: …
  await chrome.identity.launchWebAuthFlow({
        url: `${AUTHORIZE_URL}?${params}`,
        interactive: false,
        abortOnLoadForNonInteractive: false,
        timeoutMsForNonInteractive: 5000 })     // raced against an outer 15000 ms timeout
  … "login_required" → account_mismatch · "consent_required" · "interaction_required"
  … → "authorize_failed" | "code_exchange_failed" | "success"
}

preceded by a session probe:
fetch("https://claude.ai/api/bootstrap", {credentials:"include", cache:"no-store"})
with an 8000 ms abort.

5. Two failure branches are ruled out by the on-disk state:

• accountUuid is present, so Bs() cannot be returning no_stored_account.
• lastAuthFailureReason was never written to chrome.storage.local. That key is only

written on the account_mismatch / consent_required terminal path, so neither of those
ran.

• accountUuid and tokenOrg both survive, so the full sign-out routine (which removes

accountUuid among others) did not run either. The logout is passive, not an explicit
sign-out.

That leaves disabled_by_gate, authorize_failed, or the path never being reached.

Likely cause

*This is analysis of the shipped bundle, not verified against source — please treat it as a
starting point rather than a diagnosis.*

The RAM-only token storage is clearly intentional; the defect is that the silent re-auth that
covers it does not complete. Either Bs() is not reached on this path, or it returns
disabled_by_gate / authorize_failed.

One environment-sensitive detail worth checking: the two timeouts (8000 ms for the
api/bootstrap probe, 5000 ms for the non-interactive launchWebAuthFlow) are tight on a
slow link immediately after boot. This machine is on a metered mobile link, so that may be a
contributing factor here — but it would not explain the occurrences where the network is
already warm.

What I could not determine

Whether the silent re-auth runs at all, and what the cic_ext_silent_reauth gate value is for
this account. There is no user-visible signal either way. A log line naming the Bs() return
value, surfaced in the service-worker console, would make this diagnosable from the user side
and would likely turn several vague "extension keeps logging out" reports into precise ones.

Workaround

None found. Clicking Sign in completes without re-entering credentials, because the
claude.ai session is alive — but it is a manual step after every browser session.

Environment

| | |
|---|---|
| Extension | Claude in Chrome 1.0.91 (fcoeoabgfenejglbffodgkkbkcdhcgfn), installed from the Chrome Web Store |
| Browser | Chrome 152.0.7977.82, Flatpak com.google.Chrome |
| OS | Fedora Linux 44 |
| Session | Wayland (niri compositor), no GNOME/KDE shell |
| Notes | Chrome's "clear cookies on exit" is not set; no cleanup script runs at boot; claude.ai cookies and unrelated site cookies survive every reboot intact |

Preflight

• Searched existing issues before filing: "storage.session", chrome.storage.session token,

extension logged out reboot, and Chrome profile switch extension all return no matching
report. The closest hits are #57365 (forced logout from a 403 WebSocket retry loop
during a session), #82455 (the opposite — extension stays bound to a stale account), and
#82074 (grant remains authenticated after global logout). None of them cover token loss at
session start.

• Single bug report.
• Extension is on the current Web Store version (1.0.91).