[BUG] Claude Code on macOS ignores valid ANTHROPIC_API_KEY environment variable

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?

Claude Code on macOS completely ignores a valid ANTHROPIC_API_KEY environment variable. The same API key works via curl and works in Claude Code on Linux. On macOS, Claude Code reports "Not logged in" or "Missing API key" regardless of auth method used (ANTHROPIC_API_KEY, /login, setup-token).

The only auth method that works on macOS is CLAUDE_CODE_OAUTH_TOKEN.

This appears to be macOS-specific keychain logic that runs before (and preempts) environment variable checks. On Linux, there is no keychain, so Claude Code falls through to $ANTHROPIC_API_KEY and works correctly.

What Should Happen?

Claude Code should read ANTHROPIC_API_KEY from the environment and authenticate, as it does on Linux.

Error Messages/Logs

Not logged in · Run /login
Not logged in · Please run /login

Steps to Reproduce

1. Set a valid API key: export ANTHROPIC_API_KEY="sk-ant-api03-..."

1. Confirm the key works:

curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-4-5-20250929","max_tokens":10,"messages":[{"role":"user","content":"hi"}]}'
# Returns valid response

1. Run claude

1. Status bar shows "Not logged in · Run /login"

1. Type any message → "Not logged in · Please run /login"

1. Run /login → "Login successful" → still "Not logged in"

1. Run setup-token → same result

1. Pass key directly on command line: ANTHROPIC_API_KEY="sk-ant-api03-..." claude → still "Not logged in"

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.29

Claude Code Version

2.1.39 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Confirmed working on Linux

The same ANTHROPIC_API_KEY works in Claude Code on a Linux machine. The bug is macOS-specific.

CLAUDE_CODE_OAUTH_TOKEN works on the same machine

Setting CLAUDE_CODE_OAUTH_TOKEN (from setup-token) authenticates successfully on the same macOS machine where ANTHROPIC_API_KEY fails. This confirms the binary can authenticate — it's specifically the API key path that's broken.

Keychain has no Claude Code entries

security dump-keychain | grep -i claude -A 5

Returns only "Claude Safe Storage" (from Claude Desktop), nothing for "Claude Code" or "Claude Code-credentials". The /login flow that reports "Login successful" never actually writes to the keychain.

Stale process from previous version compounds the issue

A lingering --chrome-native-host process from v2.1.38 blocked all auth methods, including CLAUDE_CODE_OAUTH_TOKEN. Killing it (pkill -f claude) was required before any auth worked. After killing it, OAuth worked but API key still did not.

Tested on multiple versions

• v2.1.39 (latest): API key ignored
• v2.1.29 (stable): API key ignored
• Both versions: OAuth token works

claude doctor reports no issues

Diagnostics:
└ Currently running: native (2.1.39)
└ Path: /Users/rix/.local/share/claude/versions/2.1.39
└ Config install method: native
└ Search: OK (bundled)

Updates:
└ Auto-updates: enabled
└ Auto-update channel: latest

No auth diagnostics are included in claude doctor output.

Probable Root Cause

macOS-specific keychain auth logic runs first, fails (silently), and returns a "not logged in" state without ever checking $ANTHROPIC_API_KEY as a fallback. On Linux, with no keychain, the code falls through to the environment variable check and works.

Related Issues

#5359 — same reporter, same machine, same bug (August 2025, v1.0.71). Closed without root cause identified.
#9403 — keychain service name mismatch investigation
#5515 — "Missing API key" on SSH sessions
#8280 — macOS authentication loop
#19456 — OAuth token refresh fails due to keychain permission errors