[BUG] Platform incidents (Aug 4/5) force-logged-out multiple different Claude accounts simultaneously — refresh tokens invalidated, manual re-login required on every account

Summary

During the platform incidents on Aug 4 and Aug 5 (status.claude.com), **login sessions for multiple different Claude accounts on the same machine were force-invalidated (refresh tokens revoked), requiring manual re-login on every account**. Transient platform incidents should not permanently invalidate OAuth sessions — the client (or server) appears to be dropping/revoking credentials in response to transient errors.

Environment

• Claude Code 2.1.222, Linux (Ubuntu-based), x86_64
• One physical machine, 3 different Claude accounts used under separate OS users — each with its own isolated ~/.claude/.credentials.json (file-permission isolated, no shared credential store)
• Same LAN / egress IP for all accounts

Timeline (UTC)

1. Aug 4, ~20:48–21:59 — status.claude.com incident "Elevated errors across many models", which explicitly notes "some users experiencing issues when attempting to log into Anthropic services, including Claude.ai and Claude Code via oAuth". During/after this window, the primary account's Claude Code login session was invalidated. Re-login was required the next morning. No logout command was executed (verified across all session transcripts on the machine); ~/.claude/.credentials.json was intact but the stored token was no longer accepted.
2. Aug 5, ~08:00–09:00 — while the "Degraded performance for Claude Mythos 5, Claude Fable 5, and Claude Opus 5" incident (opened 07:05 UTC) was active, two additional, unrelated Claude accounts on the same machine were logged out simultaneously (both Claude Code and claude.ai web sessions).

Why this looks like a bug rather than expected behavior

• Simultaneous logout of different accounts rules out per-account causes (refresh-token rotation races, credential file corruption, user action).
• Separate OS users with isolated credential files rule out local cross-account interference.
• The only common factors are the Anthropic backend state during the incidents and the shared egress IP.
• If the backend was shedding/revoking sessions during the incident, that turns a transient availability issue into a durable auth outage for end users (every device logged out, manual re-login everywhere).

Expected behavior

• Transient 5xx/degradation incidents should never revoke refresh tokens or invalidate login sessions.
• If token validation fails transiently, Claude Code should retry/back off and keep the stored credentials, rather than ending up in a logged-out state that requires interactive /login.
• If sessions genuinely must be revoked server-side, surface a clear message ("sessions were reset due to an incident") instead of a silent logout.

Ask

1. Confirm whether sessions/refresh tokens were revoked server-side during the Aug 4 / Aug 5 incidents.
2. Harden the client: never delete/overwrite stored credentials in response to transient auth-endpoint errors; distinguish "revoked" from "temporarily unavailable".
3. Consider automatic session recovery after incident resolution.