[BUG] Background/Workflow subagents all 401 at OAuth token rollover while the parent session refreshes successfully (spawn-time token capture)

[BUG] Background/Workflow subagents all 401 at OAuth token rollover while the parent session refreshes successfully (spawn-time token capture)

Environment

• Claude Code v2.1.222 (also observed across prior 2.1.x versions), Windows 10 Enterprise 10.0.19045
• Auth: Claude subscription OAuth (~/.claude/.credentials.json), direct Anthropic API, no proxy
• Usage: multi-agent orchestration — background Agent-tool subagents and Workflow-tool agents

Summary

During long-running background work, when the subscription OAuth token rolls over, every background agent fails with 401 simultaneously while the parent session keeps working fine. The parent's credentials are healthy; the background children apparently capture the bearer token at spawn time and never pick up the refreshed one.

Concrete incident (2026-06-20, from session transcripts): a background Workflow run spawned 10 agents; all 10 died with API Error: 401 Invalid authentication credentials · Please run /login inside a 15-second window (per-agent transcript timestamps, all UTC):

01:36:49.514Z  01:36:53.285Z  01:36:55.218Z  01:36:55.313Z  01:36:57.541Z
01:36:59.583Z  01:37:01.521Z  01:37:01.529Z  01:37:02.033Z  01:37:04.218Z

Machine-wide blast radius: two unrelated interactive sessions took the same 401 in the same window (01:36:51Z, 01:37:00Z) — a credential-rollover event, not a workflow-local bug. The parent session logged its own 401s at 01:37:37Z/01:37:46Z, recovered, and kept working. The OAuth token's expiresAt was ~8 hours in the future the whole time. From 03:24Z onward, foreground subagents spawned from that same parent ran normally and returned full output. Only the background children were unrecoverable — consistent with the children capturing a stale token at spawn and never re-reading the refreshed credential. Each dead child left a zero-byte .output file and no notification; the run produced nothing.

Same signature recurred 2026-06-08 (03:54–03:56Z) and 2026-07-20 (04:08Z, Login expired · Please run /login). Invalid authentication / Please run /login appears in 26 transcripts on this machine, clustered on rollover events.

Honest dating: last confirmed occurrence is 2026-06-20. The changelog for 2.1.203–2.1.217 contains adjacent auth/daemon fixes (stale daemon session token making background sessions unresponsive, "HTTP 401" classifier errors after OAuth expiry, a login-expiry warning "so you can re-authenticate before background sessions are interrupted") — but no entry names the actual mechanism reported here: running background children holding a spawn-time token snapshot across a parent-side refresh. Filing so the mechanism is tracked; I run large background fleets regularly on 2.1.222 and will report back with a confirm-or-clear on current behavior. The workaround I have carried since June — drive long swarms with foreground Agent-tool calls only, and check expiresAt before any Workflow launch — costs real wall-clock and session blocking.

Why this is not a duplicate of the existing OAuth threads

(Naming the nearest neighbors explicitly so the duplicate-detector comparison is on the record:)

• #12447 (OAuth token expiration disrupts autonomous workflows): that is token expiry requiring manual re-login in headless/Docker contexts, with no refresh handling at all. Here the refresh succeeds — the parent continues working — and only the background children die on the stale token.
• #81937 (claude -p fails to refresh while interactive works): closest structural analogue — a non-interactive auth path failing to refresh while the interactive path in the same environment succeeds. This report is the in-process background-agent variant of that same asymmetry, on Windows, with fan-out blast radius (all N agents at once).
• #61912 (refresh during upstream 5xx corrupts credentials): that poisons subsequent sessions' credentials. Here nothing is corrupted — the parent is healthy before, during, and after; only running children are affected.
• #81281 (stale .credentials.json shadows valid env token): adjacent evidence that credential-source resolution is fragile, but a different path.

Related precedent that subagent auth/limit failures are handled differently from the main loop: #79522 (Bedrock 429 pre-flight kills subagents while mid-stream failures silently switch models), #78463 (SubagentStop never emitted for subagents terminated during an API-error burst), #78224 (background agents terminate rather than pause on recoverable failures).

Expected behavior

1. Background agent processes should read credentials per-request (or be signaled to re-read on refresh), not hold a spawn-time snapshot until death.
2. If a background agent hits 401 and the parent's credential store has a newer token, retry with the refreshed token before terminating.
3. If termination is unavoidable, emit a loud, aggregated surface to the parent ("N background agents failed on auth rollover — respawn?") instead of silent batch death.

Suggested labels

area:auth + area:agents + platform:windows

Reporter context

Long-time daily Claude Code subscriber on Windows; this is one of three transport-reliability failure classes I'm reporting/corroborating today (see also my comments on #46767, #33949, #66393, #78463, #82028). I previously filed #68741 for the dropped-tool-results class; it was bot-closed as a duplicate in 3 days without human engagement, so this report deliberately includes the dedup analysis above.