Constantly reoccuring keychain prompt for "Claude Code-credentials"

[dstier-git]

Summary

Many times a day, the same keychain prompt appears from macOS. They often appear even when I don;t actively click on CodexBar from the menu. It doesn't just show upon regular background refresh, too, since it occurs less frequently than my set 2/5 minute reset.

Clicking "Always Allow" prevents the prompt from occurring every time I open the app from the menu, but it does not prevent the prompt from occurring throughout each day at various points.

Similar issues

This issue is not the same symptom as #1823, which reports an error whereas my issue is a regular request from macOS. #1161 reports needing to relogin to Claude, but this issue only requires macOS password. #1844 addresses CodexBar opening the browser, which I have not experienced.

Environment

Claude usage source: Auto
Macbook Pro 2024, 24gb RAM, M4
CodexBar 0.42.1 (and for at least a week prior)
Claude Code version: numerous

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 13, 2026, 1:25 AM ET / 05:25 UTC.

Summary
This issue remains necessary: v0.42.1 reportedly triggers background authorization prompts despite the established only-on-user-action policy, and although current main retires a plausible interactive CLI reader, no fix commit or packaged current-main reproduction proves the symptom resolved. Likely related people are @steipete (medium confidence) and @artuskg (medium confidence) based on Claude credential and no-UI Keychain history.

Reproducibility: no. live current-main reproduction is established, but there is a credible source-level path: an affected build could execute /usr/bin/security ... -w during background credential discovery without interaction gating. Packaged-app attribution is still required for high-confidence reproduction.

Ways to help us reproduce this

• Include the exact command, prompt, or workflow that triggered it.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
Route this to the Claude credential owners for packaged current-main reproduction and security-boundary attribution; a repair should not be queued until the requesting executable and remaining prompt-capable path are confirmed.

Maintainer decision needed

• Question: What packaged current-main evidence is sufficient to confirm whether CodexBar or one of its helpers still triggers this background Keychain prompt?
• Rationale: Source shows a plausible retired path but does not prove which executable and call site produced the reporter’s v0.42.1 prompts or whether current main resolves them.
• Likely owner: steipete — They are the strongest available owner for packaged-app validation and the Claude credential boundary.
• Options:
  • Capture packaged attribution (recommended): Reproduce with a freshly packaged current-main app and collect a redacted screen recording plus unified-log attribution identifying the requesting executable and Claude credential reader.
  • Treat reader retirement as sufficient: Accept the current-main strategy fallback as the fix and close only after identifying its exact commit and proving release or main-only provenance.

Security
Needs attention: The issue plausibly exposes an unintended interactive credential-access path during background work and needs executable-level attribution before repair or closure.

Review details

Best possible solution:

Keep Security.framework as the sole production reader, guarantee that every scheduled Claude credential probe uses no-UI queries, add upgrade coverage for retired persisted reader settings, and expose a redacted diagnostic showing the reader, interaction context, and requesting executable without requiring Terminal investigation.

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

No live current-main reproduction is established, but there is a credible source-level path: an affected build could execute /usr/bin/security ... -w during background credential discovery without interaction gating. Packaged-app attribution is still required for high-confidence reproduction.

Is this the best way to solve the issue?

Yes in direction: production background reads should use the existing no-UI Security.framework path, not an interactive CLI reader. The final patch boundary should be chosen only after confirming whether current main still prompts and which executable requests access.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The current-main reader fallback may already fix the release-only behavior, but closing without a fix SHA or packaged verification could hide a remaining Security.framework, helper-signing, or periodic-call-site prompt.
• The screenshot identifies the requested Keychain item but not the requesting executable path, so another CodexBar helper or installed app copy remains possible.
• Changing credential reads without upgrade testing could make Claude OAuth silently unavailable for users whose only usable credentials remain in the Claude CLI Keychain item.

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

Label changes

Label justifications:

• P2: The recurring authorization dialog is a significant current-release bug with limited Claude-provider scope and no proven total outage.
• impact:auth-provider: The reported prompt targets the Claude OAuth credential source used by the provider.
• impact:security: Unexpected background requests cross the macOS Keychain authorization boundary and require caller attribution.
• impact:ux-friction: Repeated system password prompts interrupt normal background operation despite the provider remaining usable.

Evidence reviewed

Security concerns:

• [medium] Attribute the background credential requester — Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials+SecurityCLIReader.swift:1051
  Determine whether the packaged app, bundled CLI, or another installed copy invokes the Keychain request; changing the wrong reader could leave the prompt or break credential availability.
  Confidence: 0.82

What I checked:

• Plausible prompting path: The experimental reader invokes /usr/bin/security find-generic-password -w; its own documentation says interaction context is diagnostic only and does not prevent execution for background callers. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials+SecurityCLIReader.swift:1051, c852c135e10c)
• Current-main mitigation: Current main converts any persisted experimental Security CLI strategy back to Security.framework and defaults new installations to Security.framework, but provenance establishing when this changed was unavailable. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthKeychainReadStrategy.swift:359, c852c135e10c)
• Established prompt policy: The stored default is onlyOnUserAction; current main applies background gates and no-UI Security.framework queries around Claude credential discovery. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthKeychainPromptMode.swift:434, c852c135e10c)
• Background call site: Credential-existence discovery calls the optional Security CLI reader before the later background prompt gate, which explains how that reader could bypass the normal no-UI path when enabled in an affected build. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift:3309, c852c135e10c)
• Historical recurrence: Repeated keychain prompts for 'Claude Code-credentials' despite clicking 'Always Allow' #108 reported the same repeated Claude Code-credentials dialog after selecting Always Allow on v0.16.1; the current report shows the symptom recurred on v0.42.1.
• Release state: The latest shipped release is v0.42.1 at 3e05988, while the inspected current main is c852c13; no specific post-release fix SHA could be established, so implemented-on-main closure is not justified. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthKeychainReadStrategy.swift:359, c852c135e10c)

Likely related people:

• steipete: The repository owner has broad responsibility across the Claude provider and release history, making them the strongest available routing candidate for the credential-boundary decision and packaged reproduction. (role: repository owner and recent area contributor; confidence: medium; commits: c852c135e10c; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthKeychainReadStrategy.swift)
• artuskg: Release history credits work enforcing no-UI Keychain reads more reliably, directly adjacent to the reported background-prompt behavior. (role: recent adjacent contributor; confidence: medium; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.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.

[Phat-Po]

Confirming this same symptom on 0.42.1 (build 103), macOS.

Root cause on my machine: defaults read com.steipete.codexbar claudeOAuthKeychainPromptMode was always instead of onlyOnUserAction. With refreshAllProvidersOnMenuOpen=1 and a 15-minute background refresh timer, this meant essentially every menu-bar click or background tick asked macOS for a fresh Keychain authorization for Claude Code-credentials — producing a click -> password prompt -> menu closes -> re-click -> prompt again loop.

Workaround that fixed it for me:

defaults write com.steipete.codexbar claudeOAuthKeychainPromptMode -string "onlyOnUserAction"

then quit and relaunch CodexBar. No more prompts on click or background refresh since.

Log evidence before the fix, if useful — repeated keychain reads with abnormal duration (seconds instead of near-instant) despite interactive=false/allowKeychainPrompt=false on the call, plus one status=-128 (errSecUserCanceled):

[DEBUG] com.steipete.codexbar.claude-usage: Claude keychain data read start interactive=false process=CodexBar service=Claude Code-credentials
[DEBUG] com.steipete.codexbar.claude-usage: Claude keychain data read result duration_ms=54232.62 interactive=false process=CodexBar service=Claude Code-credentials status=0
...
[DEBUG] com.steipete.codexbar.claude-usage: Claude keychain data read result duration_ms=3122.43 interactive=false process=CodexBar service=Claude Code-credentials status=-128

This lines up with the automated review comment above — sounds like the always/onlyOnUserAction preference isn't reliably enforced at every call site, so resetting it manually is only a workaround, not a real fix. Posting in case the repro/workaround helps narrow it down or helps other people hitting this loop.