Claude "Avoid Keychain prompts": account switch leaves ~/.claude/.credentials.json missing → "OAuth credentials not found" while Keychain token is valid

[mcp10]

TL;DR: With "Avoid Keychain prompts" enabled (debugDisableKeychainAccess = true), CodexBar reads Claude OAuth from the plaintext ~/.claude/.credentials.json instead of the Keychain. But after switching Claude accounts, Claude Code sometimes writes the new token only to the Keychain and not to ~/.claude/.credentials.json — the file goes missing entirely. CodexBar then shows "Claude OAuth credentials not found. Run claude to authenticate." even though a valid, non-expired token with the right scopes is sitting in the Keychain.

Every existing keychain/credentials issue I found is about the Keychain item being wrong or absent (#1844, #1823, #1161). This one is the opposite: the Keychain is fine; the file the avoid-keychain path depends on is the thing that disappears on account switch.

Environment

• CodexBar 0.40.0 (build 99)
• macOS 26.5.2 (25F84)
• Claude Code CLI 2.1.197, Claude Max, logged in and working
• Claude provider setting: Avoid Keychain prompts = ON (defaults read com.steipete.codexbar debugDisableKeychainAccess → 1)

Repro

1. Enable Avoid Keychain prompts for the Claude provider (so CodexBar reads source=credentialsFile). Confirm usage loads.
2. Switch Claude accounts in Claude Code (e.g. /login as a different account).
3. Observe the Claude tab shows "Claude OAuth credentials not found. Run claude to authenticate."

Smoking gun

At the point of failure:

$ ls -la ~/.claude/.credentials.json
ls: /Users/…/.claude/.credentials.json: No such file or directory     # file is GONE

$ security find-generic-password -s "Claude Code-credentials" -a "$USER" -w | python3 -c '...'
has accessToken: True
scopes: ['user:file_upload', 'user:inference', 'user:mcp_servers', 'user:profile', 'user:sessions:claude_code']
expiresAt: 1783487829153 -> expired? False                            # Keychain token is VALID

So the Keychain has a healthy claudeAiOauth token; the plaintext file simply does not exist. Because keychain access is disabled, CodexBar has nothing to read and fails closed with "credentials not found."

codexbar usage --provider claude -v after recreating the file confirms the same token reads fine:

allowKeychainPrompt=false … hasUserProfileScope=true isExpired=false … source=memoryCache … credentials loaded for usage

Manual recovery (workaround)

Regenerate the file from the Keychain, then Refresh (⌘R):

security find-generic-password -s "Claude Code-credentials" -a "$USER" -w > ~/.claude/.credentials.json && chmod 600 ~/.claude/.credentials.json

Suggested fix

When Avoid Keychain prompts is enabled and ~/.claude/.credentials.json is missing/unreadable, fall back to a non-interactive Keychain read (the Security.framework no-UI policy from #1877) before surfacing "credentials not found" — i.e. read-only, never prompting. That would make the avoid-keychain path resilient to Claude Code writing the token to only one of the two stores after an account switch, without reintroducing prompts.

(Reported via a debugging session; happy to grab additional logs.)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 7, 2026, 5:37 PM ET / 21:37 UTC.

Summary
Keep open: current main has a source-clear path where the visible Claude no-prompt setting maps to .never, but .never blocks Claude Keychain reads before the non-interactive repair fallback can use a valid Claude Code-credentials item.

Reproducibility: yes. from source: .never is set by the visible no-prompt toggle, the missing-file path tries no-prompt repair, and the repair is blocked before the no-UI Keychain read. I did not run live Keychain probes because repository policy forbids prompt-producing validation unless explicitly requested.

Root-cause cluster
Relationship: canonical
Canonical: #1975
Summary: This issue is the canonical report for the remaining missing-credentials-file plus valid-Claude-Keychain failure under the no-prompt Claude path; related items cover overlapping prompt, token ownership, and account-switching behavior but not this exact fallback gap.

Members:

• partial_overlap: Claude "Avoid Keychain prompts" can trigger Keychain prompts #1877 - That closed issue and merged PR Fix Claude keychain prompt toggle #1879 changed Avoid Keychain prompts to Security.framework .never, but did not settle whether .never should still allow no-UI fallback reads.
• partial_overlap: Claude constantly looses token for access #1823 - That open issue tracks broader Claude token-loss/delegated-refresh failures; this report has a narrower valid-Keychain, missing-file failure mode.
• adjacent_distinct: Fix Claude same-dir account-switch history mis-attribution (#1886) #1903 - The merged PR handled account-switch history attribution and notes stale .credentials.json after /login, but it intentionally did not change credential fallback selection.
• adjacent_distinct: Claude provider: Claude Code-credentials keychain item holds only mcpOAuth entries on Claude Code 2.1.x → ClaudeOAuthCredentialsError + hourly "delegated CLI refresh" opens the default browser #1844 - That closed issue covered MCP-only or invalid Claude Keychain contents, while this report says the Keychain contains valid Claude OAuth data.
• adjacent_distinct: [Bug]: CodexBar can desync Claude Code's OAuth refresh token, forcing daily re-login #1161 - That closed issue covered refresh-token ownership/desync risk, which constrains fixes here but is not the same missing-file fallback failure.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
Manual maintainer/security review should decide the .never Keychain boundary before any fix changes Claude OAuth credential access semantics.

Maintainer decision needed

• Question: Should Claude prompt mode .never allow non-interactive Security.framework reads of Claude Code-credentials when ~/.claude/.credentials.json is missing, while keeping Advanced Disable Keychain access as the hard block?
• Rationale: The docs and issue suggest .never means no UI, but current code treats it as no Claude Keychain access at all; changing that boundary touches OAuth credentials, Keychain policy, and user privacy expectations.
• Likely owner: steipete — This is an auth/keychain UX and privacy boundary decision in the same area as recent owner-led PR Fix Claude keychain prompt toggle #1879 and Claude account-switch follow-up work.
• Options:
  • Allow no-UI fallback under .never (recommended): Use KeychainNoUIQuery to read Claude Code credentials only when macOS can satisfy the request without UI, and add tests for missing file plus valid Keychain data.
  • Keep .never as no Keychain: Keep the current fail-closed behavior but update provider copy, docs, and diagnostics so users know they must re-enable Keychain access or restore the credentials file.
  • Fold into broader Claude auth triage: Route this into the existing broader Claude token-loss work if maintainers want one coordinated auth/storage policy decision instead of a narrow fallback change.

Security
Needs attention: This issue is security-sensitive because the likely fix changes the boundary for reading Claude OAuth credentials from Keychain without UI.

Review details

Best possible solution:

Treat the Claude provider Avoid Keychain prompts toggle as a no-interactive-UI policy, preserve Advanced Disable Keychain access as the true no-Keychain kill switch, and add a stubbed no-UI fallback from missing credentials file to Claude Code-credentials.

Do we have a high-confidence way to reproduce the issue?

Yes from source: .never is set by the visible no-prompt toggle, the missing-file path tries no-prompt repair, and the repair is blocked before the no-UI Keychain read. I did not run live Keychain probes because repository policy forbids prompt-producing validation unless explicitly requested.

Is this the best way to solve the issue?

Unclear until maintainer sign-off on the security boundary; the narrowest maintainable fix appears to allow KeychainNoUIQuery reads under .never while preserving Advanced Disable Keychain access as the hard off switch.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Live Keychain validation was intentionally not run because repository policy forbids checks that can display macOS Keychain prompts without explicit request.
• The reporter equates Avoid Keychain prompts with debugDisableKeychainAccess = true, while current main treats the provider no-prompt toggle and Advanced Disable Keychain access as separate controls; maintainer UX copy may need clarification.
• Any fix must preserve the global Keychain kill switch and avoid logging or asking users to post raw OAuth/Keychain payloads.

Codex review notes: model internal, reasoning high; reviewed against aa401f1d8b74.

Label changes

Label changes:

• add P2: This is a normal-priority Claude provider auth reliability bug with a specific workaround and limited blast radius to users relying on the no-prompt path.
• add impact:security: Triage and any fix touch OAuth tokens, Keychain access policy, and sensitive credential boundaries.
• add impact:auth-provider: The issue is directly about Claude OAuth credential routing between the credentials file, memory/cache, and Claude Code-credentials Keychain item.
• add impact:ux-friction: Affected users see a misleading credentials-not-found state and must use a technical recovery command or change settings to proceed.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority Claude provider auth reliability bug with a specific workaround and limited blast radius to users relying on the no-prompt path.
• impact:auth-provider: The issue is directly about Claude OAuth credential routing between the credentials file, memory/cache, and Claude Code-credentials Keychain item.
• impact:security: Triage and any fix touch OAuth tokens, Keychain access policy, and sensitive credential boundaries.
• impact:ux-friction: Affected users see a misleading credentials-not-found state and must use a technical recovery command or change settings to proceed.

Evidence reviewed

Security concerns:

• [medium] Preserve the hard Keychain access block — Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift:2148
  A fix should distinguish provider prompt mode from Advanced Disable Keychain access so .never can mean no UI without bypassing the user's explicit global Keychain kill switch.
  Confidence: 0.88
• [medium] Keep credential diagnostics redacted
  Follow-up should use stubbed tests or redacted logs and must not ask reporters to post raw OAuth tokens, cookie headers, Authorization values, or Keychain item payloads.
  Confidence: 0.82

What I checked:

• Repository policy read: AGENTS.md was read fully; its Claude/keychain guidance affected the review by keeping validation to source, docs, tests, GitHub context, and no live Keychain probes. (AGENTS.md:1, aa401f1d8b74)
• Vision fit and sign-off boundary: VISION.md aligns bounded bug fixes, but explicitly marks provider auth, storage, and privacy-affecting behavior as needing sign-off. (VISION.md:3, aa401f1d8b74)
• Maturity shortlist unavailable: The maturity helper could not find qa/maturity-scores.yaml in this checkout, so no stable maturity label is supported.
• Reporter evidence is specific: The live issue body reports CodexBar 0.40.0, Claude Code 2.1.197, missing ~/.claude/.credentials.json, and a valid non-expired Claude Code-credentials Keychain payload with claudeAiOauth.
• Docs define no-prompt as non-interactive: The Claude docs say Never prompt never attempts interactive Claude OAuth Keychain prompts and list Claude Code-credentials as a bootstrap/repair fallback, which supports the reporter's expected no-UI fallback shape. (docs/claude.md:49, aa401f1d8b74)
• Avoid Keychain prompts maps to .never: The settings binding makes the visible no-prompt toggle set claudeOAuthKeychainPromptMode = .never while keeping the Security.framework read strategy. (Sources/CodexBar/SettingsStore+Defaults.swift:428, aa401f1d8b74)

Likely related people:

• steipete: Auth/keychain decisions, PR Fix Claude keychain prompt toggle #1879, recent Claude account-switching follow-up, release tagging, and owner comments around related Claude credential issues all point to this person for final policy direction. (role: repository owner and recent area contributor; confidence: high; commits: b435e27b429f, a83a83fa4131, ab471783; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Sources/CodexBar/Providers/Claude/ClaudeProviderImplementation.swift, Sources/CodexBar/SettingsStore+Defaults.swift)
• ss251: PR Fix Claude same-dir account-switch history mis-attribution (#1886) #1903 specifically addressed Claude account-switch history after .credentials.json can remain stale while Keychain changes, making it directly adjacent to this report's trigger. (role: recent adjacent contributor; confidence: medium; commits: 9a0028442e35, e954ccc6ac14; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift, Tests/CodexBarTests/ClaudeOAuthHistoryCredentialRoutingTests.swift)
• Rajvardhan Patil: Commit 3488587 preserved Claude CLI token ownership and added CLI storage ownership tests, which constrains any fallback that reads Claude CLI-owned credentials. (role: introduced token-ownership policy; confidence: medium; commits: 34885878; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Tests/CodexBarTests/ClaudeOAuthCredentialsStoreCLIStorageOwnershipTests.swift)
• Zihao Qi: Recent Claude settings work disabled the prompt-free toggle when global Keychain access is disabled, which is relevant to the reporter's confusion between Avoid Keychain prompts and Advanced Disable Keychain access. (role: adjacent UI contributor; confidence: medium; commits: 9c54acd5; files: Sources/CodexBar/Providers/Claude/ClaudeProviderImplementation.swift, Tests/CodexBarTests/ProviderSettingsDescriptorTests.swift)
• ratulsarna: History search ties the original Claude Keychain prompt policy and delegated OAuth recovery work to this contributor, the same subsystem that should host any no-UI repair adjustment. (role: feature-history contributor; confidence: medium; commits: 0e7da356a37f; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthDelegatedRefreshCoordinator.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.