[macOS] Claude Desktop's embedded Claude Code rotates the CLI's OAuth refresh token but can only persist to `.credentials.json` — Keychain stays stale, terminal CLI gets `Login expired` daily

Related (does not duplicate): #78020 (store split-brain from /login vs daemon refresh), #80085 (concurrent instances racing on one Keychain item). Neither covers the Claude Desktop → embedded engine path below, which is a deterministic split-brain, not a race.

Environment

• macOS (Apple Silicon), login keychain unlocked, security show-keychain-info → no-timeout
• Claude Code CLI 2.1.270 (npm install), authenticated via /login (Claude Max subscription, no API key)
• Claude Desktop with its embedded Claude Code engine 2.1.270 (~/Library/Application Support/Claude/claude-code/2.1.270/claude, spawned through the disclaimer helper, entrypoint=claude-desktop, no TTY, env has CLAUDE_CODE_OAUTH_TOKEN + CLAUDE_CODE_SDK_HAS_HOST_AUTH_REFRESH + CLAUDE_CODE_SDK_HAS_OAUTH_REFRESH)
• Same user, same ~/.claude config dir for both. Windows machine with the same workflow (file store only) never shows the symptom.

Symptom

Terminal CLI prints Login expired · Please run /login roughly once per access-token lifetime (≈ daily; on 2026-09-14 22:47 and 2026-09-15 15:12 local), even though nothing in the terminal ever logged out. Headless claude -p runs launched from other tools fail with authentication_error in the same windows.

Evidence (one full cycle, local time, all from disk)

| time | fact | source |
|---|---|---|
| 09-14 22:48 | /login in the terminal → Keychain item Claude Code-credentials updated (new access/refresh pair) | Keychain mdat |
| 22:50 → 13:25 | A Claude Desktop engine session stays alive all night (process started the day before) | ps, session transcript |
| ~06:48 | Keychain access token reaches its 8 h expiry | expiresAt |
| 08:35:36 | That Desktop session ends a turn (stop_hook_summary) | transcript |
| 08:36:05 | ~/.claude/.credentials.json is created (birth time). Its mcpOAuth section is byte-identical to the Keychain's for 26 of 27 entries (so it was populated from a Keychain read), and its claudeAiOauth is a new pair (only accessToken/refreshToken/expiresAt/scopes, i.e. the shape of a refresh response). subscriptionType/rateLimitTier are absent. | stat -f %SB, per-entry sha256 comparison |
| 08:30–15:03 | No other Claude Code process on the machine except Desktop-spawned sessions (entrypoint=claude-desktop) | scan of all ~/.claude/projects/*/*.jsonl timestamps |
| 15:03 | A headless claude -p (no env token, reads Keychain) → authentication_error in 9 s → the Keychain refresh token is already dead | its transcript |
| 15:12 | Terminal CLI → Login expired; /login at 15:15 writes a fresh pair to Keychain. The file keeps its diverged pair. | transcript, Keychain mdat |
| 15:15 → | Keychain claudeAiOauth fp b9cfbce7/ddf6f730, file fp 8f2b5874/70e3e546 (sha256[:8] of access/refresh). Two live token families, one account. | comparison script |

claude auth status from a non-TTY shell still reports the Keychain record (subscriptionType: max), confirming readers are Keychain-first.

What the 2.1.270 binary does (read from the bundled JS)

The credential store is a keychain-with-file-fallback composite:

• read: Keychain first; falls back to the file only when security find-generic-password returns 44 (not found), 36 (locked / interaction not allowed), or times out.
• update(o): i = keychain.read(); c = keychain.update(o);
• if c.success: if (i === null) file.delete() (migration) — this is the only code path that deletes .credentials.json;
• else if not transient: file.update(o); if that succeeds: if (i !== null) keychain.delete() — i.e. it tries to remove the now-stale Keychain item to avoid split-brain.

Failure mechanism

Inside the Desktop-spawned engine, Keychain read succeeds (the file got the Keychain's mcpOAuth), but add-generic-password fails and the subsequent delete-generic-password also fails (the Keychain item survives: cdat unchanged since 2026-08-18). Most likely the disclaimer sandbox permits security reads but not writes/deletes. Result:

1. The engine consumed the shared refresh token (rotation → old refresh token revoked), persisted the successor only to .credentials.json.
2. The Keychain item — still primary for every other process — now holds a revoked refresh token.
3. The next process that needs a refresh (terminal CLI, headless claude -p) fails → Login expired / authentication_error.
4. /login writes Keychain, the file keeps the other family; the cycle repeats at the next expiry.

Why the engine used the shared store's token at all: its CLAUDE_CODE_OAUTH_TOKEN env value is identical across engines spawned 29 h apart (same fp), i.e. it is a stale access token, so the engine falls back to the store for a live one.

Expected

Either (a) the Desktop engine should not touch the shared store's refresh token when the host provides auth, or (b) when the fallback write is used, the failed keychain.delete() should be surfaced/retried, or (c) the reader should prefer whichever store holds the newer expiresAt. Any of these prevents the split-brain. Windows is immune because it has a single store.

Workaround that works (verified)

Give the terminal CLI its own long-lived subscription token: claude setup-token → export CLAUDE_CODE_OAUTH_TOKEN=… in a 600 file sourced from ~/.zshrc. claude auth status then reports authMethod: oauth_token, and the terminal no longer depends on the Keychain refresh chain the Desktop engine keeps rotating. (Closing Desktop sessions before using the CLI also avoids it, but is impractical.)

Diagnostics anyone can run

# both stores present?
ls -la ~/.claude/.credentials.json; security find-generic-password -s "Claude Code-credentials" | grep -E 'cdat|mdat'
# do they hold the same claudeAiOauth family? (prints sha256 prefixes only)
security find-generic-password -s "Claude Code-credentials" -w | python3 -c 'import json,sys,hashlib;o=json.load(sys.stdin)["claudeAiOauth"];print("keychain",hashlib.sha256(o["refreshToken"].encode()).hexdigest()[:8])'
python3 -c 'import json,hashlib,os;o=json.load(open(os.path.expanduser("~/.claude/.credentials.json")))["claudeAiOauth"];print("file",hashlib.sha256(o["refreshToken"].encode()).hexdigest()[:8])'

Different prefixes = split-brain.

---
_Diagnosed with Claude Code; evidence gathered from local transcripts, Keychain metadata and the 2.1.270 bundle. Happy to provide more detail._