[BUG] Claude Code fails to authenticate on MacOS in certain environments.

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?

On macOS, Claude Code shells out to the security command for Keychain read/write operations (storing and retrieving OAuth credentials under the Claude Code-credentials service name) by invoking the bare command name security, resolved via the user's $PATH, rather than the absolute system path /usr/bin/security.

This has two consequences:

1. Reliability: In environments where $PATH has been modified (shell config, Homebrew shims, corporate MDM-managed shells, EDR/security tooling that wraps or intercepts common binary names), the resolved security may not be the Apple-signed system binary. This can produce silent failures, unexpected behavior, or interference from security tooling that pattern-matches on generic binary names rather than a known, fixed system path — surfacing to the end user as Failed to retrieve auth status after login with no actionable diagnostic.
2. Security: Resolving a security-sensitive credential-access binary via $PATH instead of an absolute path is a PATH-hijacking risk. Any writable directory earlier in $PATH than /usr/bin containing an executable named security would be invoked instead of the real system binary, with no warning. Absolute-pathing this is a standard hardening practice for any tool that shells out to a security-critical system binary.

What Should Happen?

Claude Code should invoke /usr/bin/security explicitly for every macOS Keychain read/write operation. On a healthy system this changes nothing user-visible — identical behavior to today. On a compromised or interfered-with $PATH, this removes the ambiguity entirely: the binary invoked is always the real one, and any failure can be attributed to that specific, known binary rather than an unknown PATH-resolved substitute.

Error Messages/Logs

Steps to Reproduce

Reproduction A — generic PATH-shadowing demo (doesn't require knowing the offending package):

1. Create a fake security binary earlier in $PATH than /usr/bin:

``bash
mkdir -p ~/fake-bin
cat > ~/fake-bin/security << 'EOF'
#!/bin/bash
echo "FAKE SECURITY BINARY INVOKED: $@" >&2
exit 1
EOF
chmod +x ~/fake-bin/security
export PATH="$HOME/fake-bin:$PATH"
``

1. Confirm the shell now resolves the fake binary:

``bash
which security
# -> /Users/<you>/fake-bin/security (should be /usr/bin/security)
``

1. Launch Claude Code (or the IDE extension) from this shell session and attempt /login.
2. Observed: Claude Code fails to retrieve/store credentials — surfaces as Failed to retrieve auth status after login or Auth token: none — because it invoked the fake binary in step 1 instead of the real Keychain tool.
3. Clean up:

``bash
unset PATH # or open a new shell
rm -rf ~/fake-bin
``

1. Fix verification: manually forced Claude Code's Keychain calls to resolve /usr/bin/security explicitly instead of the $PATH-resolved security (tested by placing /usr/bin first in $PATH for the session / invoking the absolute path directly in the credential helper). With /usr/bin/security used explicitly, /login and /status succeeded immediately and consistently — no EDR kill, no Failed to retrieve auth status after login, no further auth errors. Reverting to PATH-resolved security reproduced the failure again immediately. This isolates the root cause conclusively: the bug is the unqualified security invocation, not the EDR, not the entitlement flag, not the Keychain ACL.

Reproduction B — actual field case (EDR-interfered security):

1. On a managed macOS endpoint with EDR software installed (SentinelOne in this case), run:

``bash
security find-generic-password -a "$USER" -s "Claude Code-credentials" -w
echo "exit code: $?"
``

1. Observed: process is killed before returning (Killed: 9 / SIGKILL) rather than returning the credential or a normal permission error.
2. Attempt /login in Claude Code IDE extension.
3. Observed: Failed to retrieve auth status after login, reproducible on every login attempt on this endpoint.
4. Confirming it's a PATH resolution issue, not solely an EDR issue: which -a security on the affected endpoint to check for multiple resolvable security binaries in $PATH ahead of /usr/bin/security. (We could not identify which installed package placed the additional binary on $PATH — see note below.)
5. Fix verification: manually forced Claude Code's Keychain calls to resolve /usr/bin/security explicitly instead of the $PATH-resolved security (tested by placing /usr/bin first in $PATH for the session / invoking the absolute path directly in the credential helper). With /usr/bin/security used explicitly, /login and /status succeeded immediately and consistently — no EDR kill, no Failed to retrieve auth status after login, no further auth errors. Reverting to PATH-resolved security reproduced the failure again immediately. This isolates the root cause conclusively: the bug is the unqualified security invocation, not the EDR, not the entitlement flag, not the Keychain ACL.

Note on root cause of the shadow binary: In our case, something in the environment (suspected but unconfirmed: a Python package installed via pip that ships or symlinks a same-named security CLI) placed an executable named security on $PATH ahead of /usr/bin. We were not able to pin down the exact package. This doesn't change the fix — regardless of what shadows security, hardcoding /usr/bin/security closes the gap. Anyone hitting this can self-diagnose with:

which -a security

which lists every security binary resolvable on $PATH, in resolution order.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.235 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Proposed fix

Replace all invocations of security in the macOS Keychain integration with the absolute path /usr/bin/security. This is the fixed, standard location on all supported macOS versions (System Integrity Protection prevents this path from being altered or removed), so there's no portability tradeoff.

Example of the class of call that needs updating:

bash

Current (PATH-resolved, ambiguous)

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

Should be (absolute path, unambiguous)

/usr/bin/security find-generic-password -a "$USER" -s "Claude Code-credentials" -w

Why this matters beyond convenience

This surfaced during troubleshooting of Failed to retrieve auth status after login on a managed macOS fleet where EDR software was interfering with security invocations. Root-causing was harder than necessary because there was no way to confirm which security binary was actually being invoked. Absolute-pathing doesn't fix EDR/AV false positives on its own, but it removes an entire class of PATH-related ambiguity and closes a real (if narrow) hijacking vector — should be treated as a security hardening fix, not just a bug fix.

Related issues

• #51971 — same user-facing error text, different root cause (Pro/Console entitlement conflict)
• #81707 — same error family, root cause is Keychain ACL partition-list corruption on write

Neither of those is caused by the $PATH resolution issue described here, but all three currently surface the same generic auth failure to the user with no way to distinguish cause. Fixing this doesn't resolve #51971 or #81707, but removes one more variable from that failure mode and hardens the credential path.

Environment