[BUG] macOS 26: /login completes ("Login successful") but token never written to Keychain — browser does not auto-open, device code flow used instead

Open 💬 4 comments Opened Jun 22, 2026 by rindo-610

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 26.4 (Apple Silicon), /login completes the OAuth flow and shows
"Login successful", but the authentication token is never persisted to the
macOS Keychain. As a result, even in the same session immediately after
"Login successful", any message returns "Not logged in · Please run /login".

Two additional symptoms are present:

  1. The browser does not auto-open during /login (even though open <url>

works fine from the same shell). Claude Code falls back to displaying the
URL manually and using the device code flow (manual code paste).

  1. claude doctor consistently reports "macOS Keychain is not writable",

even after deleting the existing Keychain entry and even after
pre-creating a "Claude Code-credentials" entry with the -A flag
(allow all applications).

What Should Happen?

After completing /login (either via browser redirect or device code flow),
the authentication token should be persisted to the macOS Keychain so that
subsequent sessions do not require re-authentication.

The browser should also auto-open during /login when a default browser is
configured and open <url> works from the shell.

Error Messages/Logs

claude doctor output:
  Installation warnings ⚠
  ├ macOS Keychain is not writable. Console login will fail to save
    your API key.
  └ Run: security unlock-keychain ~/Library/Keychains/login.keychain-db

/status output (immediately after "Login successful"):
  Auth token: none

After /login:
  security find-generic-password -a "$(whoami)" -s "Claude Code-credentials" -w
  → security: SecKeychainSearchCopyNext: The specified item could not be
    found in the keychain.

Steps to Reproduce

  1. Install Claude Code via native installer on macOS 26.4 (Apple Silicon):

curl -fsSL https://claude.ai/install.sh | bash

  1. Run: claude
  1. Run /login inside Claude Code
  1. Note: browser does NOT auto-open. URL is displayed in terminal.

Claude Code falls back to device code flow.

  1. Manually open URL in browser (Arc or Safari — tested both).

Browser shows "認証コード / Authentication Code" page with a manual code.

  1. Paste the code into Claude Code when prompted → "Login successful" appears
  1. Immediately run /status → Auth token: none
  1. Type any message → "Not logged in · Please run /login"
  1. Confirm Keychain was not written:

security find-generic-password -a "$(whoami)" -s "Claude Code-credentials" -w
→ item could not be found

Additional diagnostic steps performed:

  • security unlock-keychain ~/Library/Keychains/login.keychain-db → no effect
  • Deleted existing Keychain entry, re-ran /login → same result
  • Pre-created entry with -A flag (allow all apps):

security add-generic-password -a "$(whoami)" \
-s "Claude Code-credentials" -w '{"placeholder":"placeholder"}' -A
→ after /login, entry still shows placeholder (not updated by Claude Code)

  • security add-generic-password with a test service name → SUCCESS

(Keychain is writable from CLI)

  • xattr -l $(which claude) → no quarantine attribute
  • open "https://claude.ai" → browser opens correctly
  • sw_vers → ProductVersion: 26.4

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — last known working around 2026-05-09 based on a Keychain entry timestamp. Exact version not recorded.

Claude Code Version

2.1.185

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Workaround currently in use:
claude setup-token → export CLAUDE_CODE_OAUTH_TOKEN=<token>
This works but provides user:inference scope only (user:profile missing).

Reproduced in both Terminal.app (macOS) and VS Code integrated terminal.

Related issue: #48162 (similar "macOS Keychain is not writable" symptom
caused by missing -U flag on add-generic-password). However, this issue
differs in that the token is not written even when no Keychain entry exists,
and even when a pre-created entry with -A (allow all apps) is present:

# Pre-created entry to rule out ACL as the cause:
security delete-generic-password -a "$(whoami)" -s "Claude Code-credentials"
security add-generic-password -a "$(whoami)" -s "Claude Code-credentials" \
-w '{"placeholder":"placeholder"}' -A
# After /login → "Login successful", entry still shows placeholder.
# Claude Code did not update it.

Keychain writability confirmed from CLI (different service name works):
security add-generic-password -a "$(whoami)" -s "test-write" -w "testvalue"
→ SUCCESS

Browser auto-open:
open "https://claude.ai" works from shell, but claude binary does not
trigger browser open during /login. Falls back to device code flow
(manual code paste in terminal). This behavior is consistent across
Terminal.app and VS Code integrated terminal.

After pasting the device code and seeing "Login successful":

  • /status shows: Auth token: none
  • Sending any message returns: Not logged in · Please run /login
  • security find-generic-password → item could not be found

codesign output on binary:
codesign -v ~/.local/share/claude/versions/2.1.185 --deep
→ "the code is valid but does not seem to be an app"

No quarantine attribute on binary:
xattr -l $(which claude) → (no output)

Hypothesis: macOS 26 may be restricting Keychain write access and/or
URL-open capabilities for native binaries in ~/.local/share/ that are
not packaged as .app bundles. Both failures (browser not opening,
Keychain not writable) may share the same root cause related to macOS 26
security policy changes for non-app-bundle binaries.

View original on GitHub ↗

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