claude-code - 💡(How to fix) Fix [Bug] Keychain race condition causes DELETE of canonical credentials entry on concurrent token refresh with stale tokens

Bug Description Subject: 2.1.118 keychain-race fix is incomplete — DELETE still observed on 2.1.133 Version: 2.1.133 (latest as of 08-05-2026) OS: macOS 25.4.0 (arm64), Max plan, OAuth (oat01-...) The 2.1.118 fix ("Fixed macOS keychain race where a concurrent MCP token refresh could overwrite a freshly-refreshed OAuth token") narrowed one race path. A second path still wipes the canonical Claude Code-credentials Keychain entry on 2.1.133. DETERMINISTIC REPRO (4 captures by automated polling watcher): Two CC 2.1.x sessions on the same Mac, same Anthropic account (cmux auto-resume). Session A actively in use; Session B idle with stale cached refresh token. ~10–28 min after A's auto-refresh, B's auto-refresh attempts to use its now- invalid refresh token. The 401 error path DELETES the canonical Keychain entry, knocking BOTH sessions logged-out and forcing /login. Cycles observed: 28, 28, 34, 11 min between DELETE events. One clean REFRESH (+1504 B, retained entry) seen between events 2 and 4. CPU snapshots at each DELETE moment confirmed only the two CC PIDs alive; no Claude.app, no chrome-native-host, no MCP build subprocesses, no claude-mem, no vibe-kanban. NOT THE CAUSE (ruled out by methodical removal): claude-mem worker daemon (chmod -x'd, settings disabled) vibe-kanban MCP zombies (54 zombies purged, MCP removed) claude -p build subprocesses (now inject parent OAuth token via security find-generic-password -s "Claude Code-credentials" -w to skip child-side refresh) Claude Desktop crashpad helper (killed, behaviour unchanged) Lone-session theory (initially considered; refuted — process snapshots prove a sibling was always alive) ARTIFACT CONSISTENT WITH STDIN-BUFFER-OVERFLOW HYPOTHESIS: Multiple stale Claude Code-credentials- Keychain entries from 21–29 Apr, account marked "unknown". If the rumoured "large OAuth metadata overflow on security -i stdin" fix is real, these orphans are its fingerprint. WORKAROUND: one CC session per Mac per Anthropic account. Hard rule. Cmux's auto-resume of multiple CC sessions is the trap that surfaces this. EVIDENCE AVAILABLE (happy to share on request): Two deletion-.log watcher captures with full process snapshots 18 KB written-up investigation handoff with full timeline keychain-watch.sh polling script (filesystem-event detection on ~/Library/Keychains/login.keychain-db) Suggestion: an integration test that spins up two CC processes against a mock OAuth server with refresh-token rotation enabled, runs them past multiple refresh cycles, and asserts the canonical Keychain entry is never DELETED on a 401 from a stale child token.

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.133
• Feedback ID: 5a768c76-9f79-4344-ba6a-992cf29374c3

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/jagan/.local/share/claude/versions/2.1.133 (expected in multi-process scenarios)\n    at _76 (/$bunfs/root/src/entrypoints/cli.js:2651:2257)\n    at yRH (/$bunfs/root/src/entrypoints/cli.js:2651:1337)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-08T16:04:33.299Z"},{"error":"Error: Failed to delete keychain entry: security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.\n    at Zuq (/$bunfs/root/src/entrypoints/cli.js:256:288713)\n    at async M39 (/$bunfs/root/src/entrypoints/cli.js:409:898)\n    at async Ba6 (/$bunfs/root/src/entrypoints/cli.js:409:796)\n    at async i$_ (/$bunfs/root/src/entrypoints/cli.js:2627:2259)\n    at async CRH (/$bunfs/root/src/entrypoints/cli.js:2653:5965)\n    at async <anonymous> (/$bunfs/root/src/entrypoints/cli.js:2678:3455)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-08T16:06:10.845Z"}]