[Bug] Version 2.1.220 spuriously drops auth mid-session with stale subscription state

Bug Description

# Bug: 2.1.220 intermittently drops auth mid-session — spurious "Not logged in · Please run /login" turn; restart clears it ## Summary On Claude Code 2.1.220, an active session intermittently terminates a turn and writes Not logged in · Please run /login as a synthetic assistant message, despite the session being fully authenticated on a Max (20x) plan with ample headroom (2% session, 24% weekly at time of report). Running /login appears to fix it, then it recurs minutes later. Restarting Claude Code and starting a new session restores normal operation — which matches the in-product notice under Plan usage limits ("If you see a prompt to set up usage credits for it, restart Claude Code"). The version correlation is total: 94 occurrences, 100% on 2.1.220, zero across 20,450 assistant turns spanning 16 prior versions (2.1.200–2.1.219). ## Impact Days of work lost to a misleading error. The message says "not logged in", so the user repeatedly re-authenticates (30 /login invocations across 3 days) against a fault that re-authentication cannot fix. Existing sessions become unresumable, and work in progress is interrupted mid-burst. ## Environment - Claude Code: 2.1.220 (native install, installMethod: "native", autoUpdates: false) - Platform: macOS (darwin 24.6.0) - Plan: Max (20x), usage credits enabled - Auth: OAuth via Keychain, single Claude Code-credentials item, login keychain no-timeout ## Evidence Measured from local transcripts (~/.claude/projects/**/*.jsonl), 300 most recent session files, 162k lines, 2026-07-24 → 2026-08-03. ### 1. Failure is confined to 2.1.220 Bucketing every assistant turn whose entire content is exactly Not logged in · Please run /login, by the version field on the transcript line: | Version | Auth failures | Successful assistant turns | Failure rate | |---|---|---|---| | 2.1.200 – 2.1.219 (16 versions) | 0 | 20,450 | 0.00% | | 2.1.220 | 94 | 48,609 | 0.19% | At a uniform rate, the older-version sample would have produced ~39 failures. It produced zero. ### 2. The failing turns are app-generated All 94 carry model: <synthetic> — Claude Code wrote them, not a model. ### 3. Not idle-related Gap between the preceding transcript event and the failure: median 0s, p75 0s, max 28s. 0 of 85 followed more than 5 minutes of idle. This fires mid-work. ### 4. Not concurrency-related Other sessions active within ±120s of a failure: mean 3.06. Control (successful assistant turns, same days, evenly sampled, n=400): mean 2.87. No meaningful difference — this is not a multi-process token-refresh race. ### 5. Not usage/credit exhaustion Max (20x) plan, 2% of session limit and 24% of weekly limit consumed at time of report, usage credits enabled. ### 6. Not model-specific Real model in use immediately before each failure: Opus 5 48.9%, unknown 21.3%, Opus 4.8 18.1%, Fable 5 11.7%. Spread across models, not tied to one. ### 7. Local config holds subscription state contradicting the actual account ~/.claude.json contains: `` hasAvailableSubscription: false cachedExtraUsageDisabledReason: "out_of_credits" ` while the account is on Max (20x) with 76% of the weekly limit remaining. This stale/incorrect cached state may be the same underlying fault, or a symptom of it. ### 8. Episodic clustering 27 failures on 2026-07-26, 28 on 2026-07-27, 39 on 2026-08-03, none on the five days between. Within a bad window, median gap between consecutive failures is 51s. Failures sprayed across **33 distinct sessions**, so it is not one wedged process. ## Reproduction Not deterministically reproducible. Observed on 2.1.220 during normal multi-session use, in bursts lasting 1–3 hours, several days apart. ## Expected vs actual - **Expected:** an authenticated session on a plan with available usage continues to serve requests; any auth-adjacent failure reports its real cause. - **Actual:** the turn is terminated with Not logged in · Please run /login, which misattributes the fault to credentials and sends the user into a re-login loop that cannot resolve it. ## Suggested fixes 1. Don't surface non-credential failures as "not logged in" — report the actual rejection (plan/limit/subscription-state) so the user isn't sent to /login. 2. Investigate what regressed in 2.1.220 relative to 2.1.219 in auth/subscription state handling. 3. Invalidate or refresh hasAvailableSubscription / cachedExtraUsageDisabledReason` when they contradict the live plan, rather than requiring a full restart.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.220
• Feedback ID: aa2c6e16-9719-4017-b603-f48fc407718f

Errors

[]