[BUG] macOS: Claude Code locks itself out of its own keychain credential → endless "security wants to access Claude Code-credentials" password prompts

Status Closed — duplicate
Reported on v2.1.211
Maintainer reply None cached
Activity 3 comments · opened Jul 27, 2026 · closed Aug 15, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Environment

  • macOS Darwin 25.5.0 (Apple Silicon)
  • Claude Desktop, bundled claude-code sidecar v2.1.217 (reproduced across 2.1.211 → 2.1.215 → 2.1.217, all updated same day)
  • Keychain item: service "Claude Code-credentials", account = login user, in login.keychain-db

Summary

Claude Code reads its OAuth token by shelling out to the /usr/bin/security CLI:
security find-generic-password -a <user> -w -s "Claude Code-credentials".
But when it writes/refreshes that credential, it sets the keychain item's ACL partition list to teamid:NKUJUXUJ3B only. That partition list authorizes neither the security CLI (apple-tool:) nor Claude Code's own signing team (Q6L2SF6YDW). Every read is therefore blocked by the partition-list gate, and macOS prompts for the login keychain password. Because the credential is rewritten on every launch/update, the partition list is repeatedly reset, so the prompt returns indefinitely — and comes in bursts whenever multiple claude subprocesses run (e.g. plugins that spawn claude -p).

Evidence (all verified on-device)

  1. Caller identity (live capture): the /usr/bin/security process's parent is the sidecar binary

~/Library/Application Support/Claude/claude-code/2.1.217/claude.app/Contents/MacOS/claude,
invoking security find-generic-password -a <user> -w -s "Claude Code-credentials".
(The process often shows PPID 1 because the parent exits and security reparents to launchd while the prompt is up.)

  1. The sidecar embeds the call: strings on that binary shows security find-generic-password -a " (10 find-generic-password references). The standalone CLI at ~/.local/share/claude/versions/<v> contains zero — the two builds differ.
  2. Sidecar code signature: Identifier com.anthropic.claude-code; Authority Developer ID Application: Anthropic PBC (Q6L2SF6YDW); TeamIdentifier Q6L2SF6YDW.
  3. Keychain item partition list: teamid:NKUJUXUJ3B only — neither apple-tool: nor Q6L2SF6YDW is present.
  4. Item ACL is otherwise permissive (applications: <any>, don't-require-password), so the block is specifically the partition list, not the ACL.

Why users can't dismiss it

The prompt is the "enter login keychain password" variant. Clicking Always Allow with the password field empty silently no-ops; and even when applied it edits the ACL, not the partition list, so the partition-list gate keeps blocking. There is no fix available through the Keychain Access UI (the partition list isn't shown there).

Impact

Persistent, effectively un-dismissable keychain password prompts that interrupt work. Amplified by any workflow spawning multiple claude subprocesses (memory/observer plugins, etc.), producing prompt storms. Users cannot resolve it via the Keychain Access UI, and "Always Allow" does not stick.

Suggested fixes (any one resolves it)

  • When writing the credential, set the partition list to include apple-tool: (and/or teamid:Q6L2SF6YDW) rather than teamid:NKUJUXUJ3B only.
  • Read the credential via the native Security framework API from the signed Claude Code binary (self-authorized) instead of shelling out to /usr/bin/security.
  • Stop resetting the partition list on every credential rewrite.
  • Reconcile the sidecar vs standalone-CLI builds so keychain-access behavior is consistent.

Likely root cause

The partition list references NKUJUXUJ3B, which is not the current signing team (Q6L2SF6YDW). That team-ID mismatch — combined with reading via the security CLI, which needs apple-tool: — is the core oversight.

What Should Happen?

Expected vs Actual

  • Expected: Claude Code reads its own credential without prompting.
  • Actual: Every security read is blocked by a partition list that excludes both apple-tool: and Claude Code's own team; prompts repeat and re-arm on every credential rewrite.

Error Messages/Logs

Steps to Reproduce

Reproduction

  1. macOS, Claude Desktop signed in.
  2. security dump-keychain -a ~/Library/Keychains/login.keychain-db | grep -A40 'Claude Code-credentials' | grep -A2 partition_id → shows teamid:NKUJUXUJ3B only.
  3. Trigger any claude subprocess, or update Claude Code → "security wants to access key Claude Code-credentials" password prompt.
  4. Temporary workaround that confirms the diagnosis:

security set-generic-password-partition-list -S apple-tool:,apple:,teamid:NKUJUXUJ3B -s "Claude Code-credentials" -a <user>
silences it — until the next credential rewrite resets the partition list.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.24012.9

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗