[BUG] claude auth login succeeds but OAuth token not readable in new sessions (macOS, native binary install)

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)
• Install method: native binary (~/.local/bin/claude)
• Claude Code version: 2.1.162
• Shell: zsh

Behavior:
After claude auth login completes successfully (browser OAuth flow finishes, "Login successful" shown), the token is not available in any subsequent new terminal session. Every new session shows:

✗ claude.ai OAuth token present
✗ claude.ai subscriber auth active
✗ OAuth token has user:profile scope
Remote Control requires a claude.ai subscription. Run claude auth login to sign in with your claude.ai account.

The token received from claude auth login itself is also not usable in new sessions. The only working workaround is running claude setup-token immediately after login, then exporting the resulting token via CLAUDE_CODE_OAUTH_TOKEN in .zshrc. Without this, every new session requires re-authentication.

Steps to reproduce:

1. Install claude via native binary installer
2. Run claude auth login and complete browser OAuth flow
3. Open a new terminal session
4. Run claude doctor — shows all OAuth checks failing
5. Run claude auth login again — required every session

What was verified:

• Keychain entry IS written after login: security find-generic-password -s "Claude Safe Storage" -a "Claude Key" -w returns the AES key successfully
• oauth:tokenCache IS present in ~/Library/Application Support/claude/config.json
• Keychain is unlocked with no-timeout policy
• No ACL restrictions on the keychain entry
• No macOS security prompt appears when claude accesses the keychain
• Only one keychain entry exists — no service/account name mismatch between write and read
• Shell can read the AES key fine via security CLI; the claude binary cannot in a new process

Conclusion:
The binary successfully writes the keychain entry and encrypts the token, but silently fails to read the keychain entry back in subsequent process invocations. The macOS Security framework itself works correctly (the entry is readable via security CLI with no restrictions). The issue is specific to how the native binary reads the keychain entry in new sessions.

Workaround:

Run once after claude auth login:

claude setup-token

Add the output token to ~/.zshrc:

export CLAUDE_CODE_OAUTH_TOKEN=<token from setup-token>

This bypasses keychain entirely and works reliably across sessions.

What Should Happen?

After completing claude auth login successfully, the OAuth token should be persisted to the macOS Keychain and automatically retrieved in every subsequent terminal session without any additional steps. Running claude doctor in a new terminal should show:

✓ claude.ai OAuth token present
✓ claude.ai subscriber auth active
✓ OAuth token has user:profile scope

No manual token management (setup-token, CLAUDE_CODE_OAUTH_TOKEN) should be required.

Error Messages/Logs

Steps to Reproduce

1. Install claude via native binary installer
2. Run claude auth login and complete browser OAuth flow
3. Open a new terminal session
4. Run claude doctor — shows all OAuth checks failing
5. Run claude auth login again — required every session

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.140

Claude Code Version

2.1.162

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Steps to reproduce:

1. Install claude via native binary installer
2. Run claude auth login and complete browser OAuth flow
3. Open a new terminal session
4. Run claude doctor — shows all OAuth checks failing
5. Run claude auth login again — required every session