[Bug] Background worker cannot read Keychain credentials after foreground→background handoff in 2.1.211

Bug Description
Bug Report: Sending a running session to the background kills it with "Not logged in · Please run /login" (regression in 2.1.211) Environment - Claude Code 2.1.211 (native install, auto-upgraded from 2.1.210 at 2026-07-16T01:17Z) - macOS (Darwin 25.1.0), OAuth subscription login; credentials stored in macOS Keychain - Backgrounding sessions worked fine on recent prior versions; this broke after the upgrade to 2.1.211 Summary On 2.1.211, sending an actively-running, fully-authenticated interactive session to the background killed the in-flight turn within seconds, with a synthetic assistant message "Not logged in · Please run /login". Every subsequent prompt to that session, a freshly resumed session, and even /doctor failed instantly with the same message — while the same user remained fully authenticated in a new foreground CLI the whole time. Recovery required running /login again. Timeline (UTC, 2026-07-16) - 01:17 — Auto-upgrade to 2.1.211; the background daemon self-restarts and immediately logs: [supervisor] ─── daemon start ─── version=2.1.211 origin=transient [supervisor] auth: no token found, will re-check keychain every 30s - The 30-second keychain re-check never succeeds, even though the Keychain item exists and foreground processes read it without issue. - 01:19 — An interactive session starts in the foreground and works normally: file reads, WebSearch, and WebFetch all succeed for the next ~12 minutes. - 01:31:15 — The user sends the session to the background mid-turn; the daemon spawns a worker host to take it over. - 01:31:22 — 7 seconds later, the in-flight turn dies. The transcript records a synthetic assistant message (model: "<synthetic>", all usage counters zero): "Not logged in · Please run /login". - 01:39–01:40 — Further user prompts to the same session each return the same synthetic message immediately, with no API call made. - 01:40 — Resuming the conversation in a new session ("Continue from where you left off.") fails instantly with the same message. /doctor also returns "Not logged in · Please run /login" instead of producing a diagnosis. - Running /login in a fresh foreground session restored service. However, ~/.claude/daemon-auth-status.json still reads {"status":"auth_required"} even after successful re-login. Analysis The foreground process and the daemon-spawned background worker do not share credentials. The foreground session was demonstrably authenticated — successful API calls up to seconds before the handoff — but the worker that received the session had no token: [REDACTED] 2.1.211 daemon logged no token found, will re-check keychain every 30s from startup and never recovered. This suggests the daemon/worker processes cannot read the Keychain item that the foreground CLI reads fine (possibly a Keychain ACL bound to the binary path, which changes on every auto-upgrade under ~/.local/share/claude/versions/<x>). Since backgrounding worked on recent prior versions and the failure appeared on the first attempt after the 2.1.211 upgrade, this presents as a regression in how the 2.1.211 daemon acquires credentials, or in how credentials are handed off during foreground→background migration. Expected behavior - A session backgrounded from an authenticated foreground process should carry its working credentials into the background worker — or the handoff should be refused up front with a clear error, rather than killing the in-flight turn. - /doctor should still run and report the daemon's auth state instead of failing with the same "Not logged in" error. - After a successful /login, the daemon should pick up the new credentials (its status file still says auth_required). Attachments available on request - Daemon log (~/.claude/daemon.log) covering the 2.1.211 startup through the incident - Session transcripts (.jsonl) of the killed session and the failed resume//doctor attempts

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.211
• Feedback ID: d40b8350-6a56-4bae-aeb7-92f40a8d2371

Errors

[]