Keychain password prompt repeats every few hours despite 'Always Allow'

[lechatlisse]

Description

CodexBar repeatedly prompts for the macOS login keychain password every few hours, despite clicking "Always Allow" each time. The ACL setting does not persist.

Environment

• CodexBar version: 0.18.0-beta.2 (Build 50)
• macOS: 15.3 (Darwin 25.2.0)
• Architecture: Apple Silicon

Affected keychain entries

Both entries under service com.steipete.codexbar.cache:

• Account: oauth.claude
• Account: cookie.claude

Root cause analysis

The oauth.claude entry is being modified frequently (token refresh cycle). Based on the keychain dump, the entry appears to be deleted and recreated rather than updated in place. This wipes the ACL on every token refresh, causing macOS to prompt again on the next read.

Evidence:

• CodexBar is already listed in the Access Control tab for the entry
• "Always Allow" is selected each time but does not persist
• The app binary has not changed (signed Jan 21, codesign verification passes)
• The oauth.claude entry's mdat (modification date) changes frequently, suggesting regular token refresh writes

Expected behavior

Clicking "Always Allow" should permanently grant CodexBar access without further prompts.

Suggested fix

Use SecKeychainItemModifyAttributesAndData (or the Swift equivalent SecItemUpdate) to update the existing keychain entry in place, rather than deleting and recreating it. Updating in place preserves the user-configured ACL.

[inspirepan]

Same issue here. CodexBar 0.18.0-beta on macOS 15.3 (Apple Silicon). The keychain prompt reappears every few hours despite clicking 'Always Allow'. Would love to see this fixed with in-place keychain updates. 👍

[ratulsarna]

Thanks for the detailed report.

One correction: for the com.steipete.codexbar.cache items (oauth.claude / cookie.claude) CodexBar already updates in place using SecItemUpdate and only falls back to SecItemAdd if the item is missing. We don’t intentionally delete+recreate these on a normal refresh.

Also, mdat changing is expected for an in-place update, so it doesn’t by itself imply recreation. The fastest way to validate “recreated vs updated” is whether the item’s “Date Created” (cdat) changes over time (Keychain Access -> Get Info), or only “Date Modified”.

We do delete these cache items only in a few exceptional paths (e.g. cache decode invalid, or explicit OAuth cache invalidation on certain OAuth failures), not on a successful refresh cycle.

To narrow this down, could you share:

• A screenshot / exact text of the keychain dialog (to confirm it’s prompting for com.steipete.codexbar.cache vs Claude Code-credentials).
• In Keychain Access: does oauth.claude’s Date Created change after a token refresh, or only Date Modified?
• Do you have multiple oauth.claude entries under the same service, or multiple CodexBar installs running from different locations?

If the item is truly being recreated (or macOS is resetting ACL on update), we’ll need to adjust how we write these items, but the above will confirm which case we’re actually in.

[Nabeel-javed]

Can someone please fix this one

[darthShadow]

Can confirm on 0.18.0-beta.2 (macOS 15.3). ~/.claude/.credentials.json already exists and stays current — Claude CLI updates it on token refresh. The file-first approach in dc407fc should fully resolve this.

Are you sure it works for you and the file actually exists? In my setup there is no such file and indeed there are existing bugs for the same in the claude-code repo:

anthropics/claude-code#1414
anthropics/claude-code#10039

Quoting a dev reply from the former:

This is intended behavior (cleaning up plain text credentials when successfully storing them in macos keychain)

[ratulsarna]

Working on a way to surface this much more clearly and add an option to never show keychain prompts if users want that. First step in PR #360

[ratulsarna]

If someone is building from main branch and don't want to see prompts: Please switch to CLI (PTY) in "Usage Source" in the Claude provider settings. That source has been hardened recently and doesn't ask for permissions.

[Nabeel-javed]

I managed to fix this on my local build.

1. Created a self-signed code signing certificate (valid for 10 years):
   openssl req -x509 -newkey rsa:2048 -keyout /tmp/codexbar-dev.key
   -out /tmp/codexbar-dev.crt -days 3650 -nodes
   -subj "/CN=CodexBar Development"

openssl pkcs12 -export -out /tmp/codexbar-dev.p12
-inkey /tmp/codexbar-dev.key -in /tmp/codexbar-dev.crt
-passout pass: -legacy
security import /tmp/codexbar-dev.p12 -k ~/Library/Keychains/login.keychain-db -P "" -T /usr/bin/codesign

2. Trusted it for code signing:
   security add-trusted-cert -d -r trustRoot -p codeSign -k ~/Library/Keychains/login.keychain-db /tmp/codexbar-dev.crt

3. Set APP_IDENTITY so the build scripts use it:

export APP_IDENTITY='CodexBar Development'

4. Added com.apple.security.cs.disable-library-validation to the app entitlements in package_app.sh — this is needed for the app to load Sparkle.framework from /Applications since the self-signed cert has no Team ID.

After rebuilding with the stable certificate, "Always Allow" sticks across restarts and rebuilds. The Keychain prompt only appears once.

Note: the -legacy flag on the openssl pkcs12 command is needed for OpenSSL 3.x compatibility with macOS security import.

[ratulsarna]

Thanks for all the reports here.

Quick clarification on the prompt behavior: some prompts are expected when Claude OAuth credentials are expired/invalid/missing and a re-auth path is needed. We can reduce/shape when prompts happen, but we can’t bypass macOS Keychain security behavior.

To make this controllable, we’ve added a UI surface in PR #364:

• Preferences → Providers → Claude → Keychain prompt policy
• Options:
  • Never prompt
  • Only on user action (default)
  • Always allow prompts
• With Only on user action, opening the CodexBar menu is treated as user action.
• If Advanced → Disable Keychain access is enabled, this Claude policy remains visible but is disabled/inactive.
• Choosing Never prompt does not auto-switch your usage source; source selection stays user-controlled.

If you still see unexpected prompts, please share your exact settings (usage source + prompt policy + keychain global toggle) and repro steps.

[darthShadow]

@ratulsarna Thanks for the continuous improvements. Would it be possible for you to review this commit too and see if it can be used to remove the ACL prompt altogether?

richhickson/claudecodeusage@8f5310a

Running the command from the commit (/usr/bin/security find-generic-password -s "Claude Code-credentials" -w) indeed doesn't require a password prompt.

[ratulsarna]

@ratulsarna Thanks for the continuous improvements. Would it be possible for you to review this commit too and see if it can be used to remove the ACL prompt altogether?

richhickson/claudecodeusage@8f5310a

Running the command from the commit (/usr/bin/security find-generic-password -s "Claude Code-credentials" -w) indeed doesn't require a password prompt.

Thanks for the link and for testing. I can reproduce that /usr/bin/security find-generic-password -s "Claude Code-credentials" -w returns the creds without triggering the Keychain “Allow/Deny” prompt. And also went through the code.

I would not like to switch CodexBar to this unconditionally because it changes the consent model: the access decision is effectively “allow security”, not “allow CodexBar”, so it can bypass app-specific Keychain denial in a way that may surprise users. There are also edge cases around multiple matching keychain items, and we’d need strict timeouts/off-main execution for reliability.

I’m leaning toward adding it as an Advanced / Experimental option for Claude OAuth, implemented with a hard timeout, and falling back to the current path if it fails.