macOS: Keychain item written without trusted-application list -> auth prompt on every credential read

Status Open

Reported on v2.1.207

Maintainer reply None cached

Activity 13 comments · opened Jul 15, 2026

Version: 2.1.207 (also on 2.1.206)
Platform: macOS (Apple Silicon), login.keychain-db
Install: single, no tmux, no SSH, single terminal session

Summary

Claude Code stores OAuth credentials in a keychain item Claude Code-credentials, and reads it back by shelling out to /usr/bin/security.

The item is created without any trusted-application entry (no -T equivalent). macOS therefore prompts for the keychain password on every read -- in practice every LLM call, i.e. every 3-4 minutes of active use.

"Always Allow" does not help: Claude Code rewrites/recreates the item, and the new item again has an empty trusted-application list, discarding the granted ACL.

This is NOT the multi-session refresh race (#24317, #48786), which surfaces as an unexpected /login. And it is not limited to third-party tools (#22144): here the CLI prompts on its own reads.

Evidence

1. claude spawns security, and is not authorized against the item it wrote.
Process ancestry captured while the dialog was on screen:

  PID   PPID  COMMAND
68091  56374  security
56374    793  claude
  793    757  -zsh
  757    656  login

2. The keychain ACL machinery is healthy on this machine.
A control item created with an explicit trusted app reads back silently, twice, no prompt:

security add-generic-password -s "acl-test" -a "$USER" -w "x" -T /usr/bin/security
security find-generic-password -s "acl-test" -w   # -> x, no dialog
security find-generic-password -s "acl-test" -w   # -> x, no dialog

This rules out a corrupted keychain or a broken SecurityAgent.

3. Rewriting the item WITH -T /usr/bin/security suppresses the per-read prompts.

TOKEN=$(security find-generic-password -s "Claude Code-credentials" -w)
security delete-generic-password -s "Claude Code-credentials"
security add-generic-password -s "Claude Code-credentials" -a "$USER" -w "$TOKEN" -T /usr/bin/security

Prompt frequency drops from ~1 every 3-4 min to ~1 every 1h45. The residual prompts correlate exactly with Claude Code rewriting the item (ACL lost on rewrite):

| Event | cdat | mdat | Prompt |
|---|---|---|---|
| Item rewritten manually with -T | 14:10 CEST | 14:10 | none for 1h45 |
| Claude Code rewrote the item | 14:10 | 15:55 | dialog at 15:55 |

4. ~/.claude/.credentials.json is not an effective fallback on macOS.
With a valid credentials file in place, the keychain item was deleted. Claude Code recreated it on its own (fresh cdat), again with no trusted-application list, and prompting resumed. The file is not consulted in preference to the keychain, contrary to what several community workarounds assume.

Impact

Any macOS user on the keychain path gets an OS password dialog every few minutes of active use. Not dismissible, not remembered, not fixable from the user side. Only mitigation is to periodically rewrite the item by hand with -T, which reduces but does not eliminate the prompts.

Suggested fixes (in order of preference)

Attach a trusted-application list on write (equivalent to security add-generic-password -T <path>), so the ACL is valid from creation and no user interaction is ever needed.
Update the item in place instead of delete-and-recreate, so a user-granted ACL survives a token refresh.
Honour ~/.claude/.credentials.json on macOS as on Linux, and do not silently recreate the keychain item.

View original on GitHub ↗

13 Comments

pgaultier · 2 months ago

any news ?

because it's really annoying

pgaultier · 2 months ago

Better in 2.1.217, but bug still exists

tiimonn · 2 months ago

Makes the cli un-usable...

joshghent · 1 month ago

Still exists for me on 2.1.233 on mac - extremely annoying as it never logs in

parker-g · 1 month ago

Bumping as I'm experiencing this in v2.1.246 on macos 26.5.2. agreed @tiimonn that claude code is effectively unusable in this state

parker-g · 1 month ago

workaround that worked for me:

remove the standalone/sidecar binary(ies) of claude code. for me those existed at ~/.local/share/claude

rm -r ~/.local/share/claude

remove the broken keychain item:

security delete-generic-password -s "Claude Code-credentials" -a "$USER"

install claude-code from brew (version there is 2.1.231)

brew install claude-code

use /login
prosper

Kaitiak · 1 month ago

Same issue, recurring roughly every 2-4 days on my machine.

Environment:

Mac mini (Apple Silicon, M4)
Claude Code v2.1.251
VS Code + official anthropic.claude-code extension (also had 3 unofficial Claude Code-related extensions installed at the time: andrepimenta.claude-code-chat, man-vu.claude-code-usage-dashboard, codeflow-studio.claude-code-extension)

Pattern observed:

security dump-keychain | grep -c "svce.*Claude Code-credentials" consistently shows 2 duplicate entries for the same service name.

The macOS "security wants to access key Claude Code-credentials" password prompt loops indefinitely -- clicking "Always Allow" (with password entered) does not stop it.

Confirmed the partition-list workaround from this issue:
security set-generic-password-partition-list -S apple-tool:,apple:,teamid:NKUJUXUJ3B -s "Claude Code-credentials" -a $USER
This ran without error but did not resolve the dialog loop, likely because it only updates one of the two duplicate entries.

Only way to fully resolve: manually delete both duplicate entries via security delete-generic-password -s "Claude Code-credentials" (run twice, once per duplicate), then claude -> /login from scratch.

This exact sequence (2 duplicates -> delete both -> re-login) has now happened twice for me, about 2 days apart (Aug 31 and Sep 2, 2026). The fix does not appear to be durable -- duplicates come back.

Suspect something in the credential-write path (possibly triggered by multiple concurrent Claude Code processes -- CLI + VS Code extension, or the unofficial extensions above also polling/writing credentials) is what's re-creating the duplicate entry each time, which then re-triggers the partition-list reset described in this issue.

Would appreciate a look -- this makes Claude Code effectively unusable every few days without manual keychain surgery.

the-zulu-viking · 1 month ago

had the same problem and used the help contact with anthropic and found a fix was to unlock it manually by running the following in terminal
security unlock-keychain ~/Library/Keychains/login.keychain-db

codethought · 22 days ago

had the same problem and used the help contact with anthropic and found a fix was to unlock it manually by running the following in terminal security unlock-keychain ~/Library/Keychains/login.keychain-db

Thank you - off all the suggestions this one seems to have been the most effective for me.

la-bas · 15 days ago

FYI for anyone landing here: teamid:NKUJUXUJ3B is not an Anthropic team ID. It's Nextcloud's (NKUJUXUJ3B.com.nextcloud.desktopclient; check with codesign -dv /Applications/Nextcloud.app).

I had exactly this symptom: undismissable "security wants to access Claude Code-credentials" dialogs, with the partition list set to teamid:NKUJUXUJ3B only. I logged the item across a reboot. The Nextcloud desktop client modifies Claude Code-credentials on every startup, 4 seconds after rewriting its own keychain items, before any Claude process is running. The item's account is your macOS username, and it looks like Nextcloud matches on account only.

So if you have Nextcloud desktop installed, it's the likely cause, and this isn't a duplicate of #77697.

the-zulu-viking · 14 days ago

Did you end up unistallling Nextcloud to get it to work?

parker-g · 14 days ago

@la-bas verifying i've got Nextcloud desktop installed. assuming this was what caused the issue for me, my fix above ^^ should work for other users experiencing this nextcloud/claude code interference bug

joshghent · 13 days ago

Interesting - I do have Nextcloud desktop installed but how I solved it was clearing the credentials (in comments above) and then making sure that I was using the homebrew version - the node installation caused problems.