[BUG] Repeated OAuth 401 "revoked" storms in Desktop app — regression 2.1.209 → 2.1.215

What's Wrong?

Starting with the Desktop app update to 2.1.215 on 2026-07-19, my sessions began seeing frequent 401 Invalid authentication credentials / OAuth access token has been revoked errors, auto-retried up to 10x with exponential backoff (visible in the UI as "Request failed · retrying (N/10)"). This is client-logged internally as system records with subtype: "api_error", source: "request_retry".

This is not occasional background noise — it's a sustained, heavily elevated rate concentrated in long-lived and/or concurrently-open sessions, and it is precisely dated to the 2.1.215 release:

Before/after, from local session logs (all sessions, all projects):

| Version | 401 errors | 502 errors | 529 errors | Window |
|---|---|---|---|---|
| 2.1.209 | 0 | 0 | 0 | Jul 14–19 (pre-update) |
| 2.1.215 | 295 | 59 | 8 | Jul 19–20 (~30h post-update) |

Historically (Feb–Jul 2026), 401 events in these logs were rare — at most 1-2/day, many days zero. The jump to 295 in ~30 hours on 2.1.215 is a 10-100x rate increase with no other variable changing.

Concentration pattern: across that ~30h window, all 362 error events trace to exactly 4 sessions (all source: code, i.e. Claude Code sessions in the Desktop app, not claude.ai chat). The two worst-affected were both long-lived sessions left open across many hours with other concurrent sessions also active:

• One session: 174 error events over ~14h, up to 8 consecutive failed retry attempts in a single burst before recovering
• Another: 150 error events over ~14h, up to 6 consecutive failed attempts

Within a burst, recovery is usually fast (successful requests resume within seconds of a 401), which means the retry path isn't just resending the identical request — it's presumably refreshing credentials before resending, and that refresh itself is what's intermittently failing (sometimes several times in a row) before succeeding.

I have not been able to get a clean screenshot of the retry banner itself (it's transient and I wasn't at the machine for the worst episodes), but I have the full source log data behind this report and can provide the raw api_error JSON records on request.

What Should Happen?

OAuth token refresh should succeed reliably without producing sustained bursts of 401s, especially not tied to a specific client version. If a 401 genuinely means the token needs a full re-grant, the client should say so rather than silently retrying up to 10 times.

Error Messages/Logs

Representative raw log entries (from local session JSONL, type: "system", subtype: "api_error"):

{
  "type": "system",
  "subtype": "api_error",
  "level": "error",
  "error": {
    "message": "401 {\"type\":\"error\",\"error\":{\"type\":\"authentication_error\",\"message\":\"OAuth access token has been revoked.\"},\"request_id\":null}",
    "status": 401,
    "formatted": "401 OAuth access token has been revoked.",
    "connection": null,
    "isNetworkDown": false,
    "rateLimits": null
  },
  "retryInMs": 559.2177040047475,
  "retryAttempt": 1,
  "maxRetries": 10,
  "source": "request_retry",
  "version": "2.1.215",
  "entrypoint": "claude-desktop"
}

{
  "type": "system",
  "subtype": "api_error",
  "level": "error",
  "error": {
    "message": "401 {\"type\":\"error\",\"error\":{\"type\":\"authentication_error\",\"message\":\"Invalid authentication credentials\"},\"request_id\":\"req_011CdDXEoeyxWjwGMQTWXHRq\"}",
    "status": 401,
    "requestId": "req_011CdDXEoeyxWjwGMQTWXHRq",
    "formatted": "401 Invalid authentication credentials",
    "connection": null,
    "isNetworkDown": false,
    "rateLimits": null
  },
  "retryInMs": 563.7647658401951,
  "retryAttempt": 1,
  "maxRetries": 10,
  "source": "request_retry",
  "version": "2.1.215",
  "entrypoint": "claude-desktop"
}

Steps to Reproduce

I don't have a minimal deterministic repro — this is a burst pattern, not a reliable trigger. What I can offer is the operating conditions under which it reliably occurs for me:

1. Update Desktop app to 2.1.215 (from 2.1.209 or earlier).
2. Run multiple Claude Code sessions concurrently in the Desktop app, in different project directories, over a period of several hours (I routinely run many parallel sessions and have done so since ~March 2026 without this symptom — the concurrency itself is not new, only the failure rate is).
3. Leave at least one session open/idle across a long stretch (multiple hours, including overnight).
4. Observe repeated "Request failed · retrying (N/10)" banners, tracing to 401 Invalid authentication credentials / OAuth access token has been revoked in the session logs, clustered in the long-lived and/or concurrently-active sessions.

I do not have a single-session, short-lived repro — I was not able to reproduce this with only one session open for a short period.

Claude Model

Sonnet (default) — dominantly claude-sonnet-5 (4,105 main-session + 1,056 subagent turns in the affected window), a small proportion claude-haiku-4-5 via subagents (29 turns, ~0.5% of traffic), zero Opus, zero Fable. Note: the api_error records themselves carry no model field — the 401 fires at the auth layer before model selection, so this can't be pinned to a specific model's requests, but given Haiku's traffic share it's not a plausible driver either way.

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.209

Claude Code Version

2.1.215 (Desktop app)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other (Desktop app GUI — not a terminal-integrated session)

Additional Information

Not explained by acknowledged status-page incidents: status.claude.com listed four resolved incidents on 2026-07-20 (Opus 4.5, Opus 4.8, Haiku 4.5, and a Fable 5 usage-credits bug) but none match my actual traffic. My usage in the affected window is ~99.4% claude-sonnet-5, and there is no Sonnet 5 incident logged for either 2026-07-19 or 2026-07-20. The one incident that superficially overlaps by model — Haiku 4.5, 13:20–15:41 UTC — doesn't overlap in time either: my only Haiku 4.5 traffic in this entire window is a single ~2-minute subagent burst at 12:20:58–12:23:08 UTC, nearly an hour before that incident started. So this isn't fallout from a publicized incident; it's a separate, unacknowledged issue.

Related but distinct existing issues (I searched before filing — flagging these proactively so this isn't auto-closed as a wrong-mechanism duplicate):

• #76561 — concurrent-instance credential-store cascade (symlink-shared .credentials.json across a 4-seat WSL2 fleet). Same general failure shape (one instance's refresh rotates the token and invalidates others), but a deliberately shared-credential-file setup, not a single-user Desktop app on macOS, and predates this version.
• #78020 — macOS Keychain vs .credentials.json split-brain causing token-family revocation. Same platform (macOS) and plausible mechanism, but also predates 2.1.215 and is unconfirmed (only comment is unrelated spam).
• #61912 — older (May) 401-loop issue, but its comment thread already identified several distinct root causes (Cloudflare 5xx-during-refresh corruption, silent-refresh-without-full-regrant, even a full disk). None of those signatures match this report: I have no 5xx-timing correlation, no evidence of a long-silent-refresh, and no disk space issue — and critically, this report has a clean version-gated before/after that theirs doesn't.
• #79299 — unrelated symptom (SessionStart hook stdout), but independently confirms 2.1.209 → 2.1.215 as a regression-carrying Desktop app release, which is corroborating context for treating this as version-tied rather than incidental.
• #78448 — reports routine-fire bearer tokens (a different token type) starting to fail quickly right around 2026-07-16, a few days before this. Possibly indicates a broader backend token-infrastructure change in the same window; noting it as context, not claiming the same mechanism.

Happy to provide the full raw log export (JSON, all 362 api_error records with timestamps/session IDs/attempt counts) if useful for debugging — didn't want to dump everything inline.