[BUG] Claude in Chrome: sign-in is lost on every full Chrome restart (consent screen every time) — breaks unattended automation

Same issue here on Windows 11 with extension v1.0.94. I dug into the extension's shipped code and have some findings that may help narrow it down.

What happens

• Tokens live in chrome.storage.session, so they are gone after a full Chrome restart; recovery depends on the silent re-auth (launchWebAuthFlow, interactive: false, prompt: "none").
• In the failing case, startupReauthState stays at {strikes: 1, until: <timestamp>} and never changes after until has passed, no matter how often the side panel is reopened.
• The side panel does send check_and_refresh_oauth to the service worker on every open (verified from the side panel console on a working session). But with logpoints at the entry of the token-check function (the await or() line inside mr) and at the if (cr) check, neither fires when the side panel is reopened in the failing state.
• So the function body is never re-entered: mr = () => dr || (dr = ...) keeps returning an in-flight promise from an earlier call that never settles. Every later retry just awaits that stuck promise for the lifetime of the service worker.

Why it looks random

Sometimes the first attempt succeeds, sometimes it fails cleanly and a retry 30 s later works, and sometimes it gets stuck as above and nothing helps until the service worker is replaced.

Workaround

Toggle the extension off and on in chrome://extensions. This gives a fresh service worker and clears session storage, and it signs in silently right away, with no consent screen or workspace picker. Changing any extension permission, such as "Allow in Incognito", has the same effect because it reloads the extension.

Ruled out

Other extensions (removed everything except Bitwarden, still reproduces), proxy extensions, and network latency to claude.ai.

Suggestion

Put an overall timeout on the startup re-auth path, so the memoized promise always settles. Also reset cr when the 15 s Promise.race timeout wins, not only in launchWebAuthFlow's own finally.

Thanks for the detailed analysis. I can confirm it on my side (Windows 11, Chrome 153, extension 1.0.94).

• After a full Chrome exit (menu -> Exit), the first time the extension stayed signed in, and the second time it was signed out. This matches the "looks random" behavior you described.
• In the signed-out state, toggling the extension off and on in chrome://extensions signed it back in silently, with no consent screen.

So the workaround works here too. I hope the fix for the startup re-auth timeout gets picked up.

Still reproduces on extension 1.0.97 (Chrome 154.0.8037.58, Windows 10 Pro 22H2), so none of the updates since 1.0.94 fixed it.

Checked in the shipped 1.0.97 bundle (read-only):

• accessToken / refreshToken / tokenExpiry are still routed to chrome.storage.session, so a full Chrome exit drops them.
• The silent re-auth timeouts were raised compared with the 1.0.91 figures quoted in #92335 (timeoutMsForNonInteractive: 15e3, outer race 2e4), but that did not help.
• The busy flag guarding launchWebAuthFlow is still reset only in that call's own .finally(), not when the outer 20 s race timeout wins.
• The memoized startup token-check promise is still cleared only in its own .finally(), with no overall timeout, so an await that never settles pins it for the lifetime of the service worker. This matches the analysis in the comment above.

State after the failure: accountUuid is present in chrome.storage.local, and lastAuthFailureReason is never written. claude.ai stays logged in in a normal tab. There are no Chrome policies, no clear-on-exit setting and no cookie exceptions.