/login shows "Login successful" but immediately reverts to "Not logged in"

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/5359
2. https://github.com/anthropics/claude-code/issues/40473
3. https://github.com/anthropics/claude-code/issues/17402

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is NOT a duplicate. The linked issues are about different problems. My issue is specifically: /login shows ‘Login successful’ but auth is never persisted — status bar immediately reverts to ‘Not logged in’.

Additional repro: macOS + Claude Max + \claude auth login\ (v2.1.92)

Same pattern as this issue: UI shows success, session is not actually authenticated.

claude auth logout
claude auth login
# Browser completes authorization; terminal prints: Login successful.
claude auth status --text
# Immediately returns: Not logged in. Run claude auth login to authenticate.
claude
# Header still shows "API Usage Billing"; prompts fail with Not logged in / run /login

• OS: macOS (Darwin 24.x)
• Plan: Claude Max
• Claude Code: 2.1.92 (npm global)
• OAuth link printed by CLI uses \redirect_uri=https://platform.claude.com/oauth/code/callback\ (PKCE), scopes include \user:sessions:claude_code\, \org:create_api_key\, etc.
• Note for repro: If the shell has \alias claude='claude --bare'\, remove it or use \command claude\ so \auth login\ and the interactive CLI are the same binary/mode; otherwise login and TUI can diverge.

Related: #44267 (OAuth completes in browser but CLI never finishes / persists session). 👍 following both for visibility.

Just hit this bug. Can confirm it's still on v2.1.142

I hit the same bug today:

[https://github.com/anthropics/claude-code/issues/59935](url)

macOS Sequoia 15.7.6 (24G707). Claude Code 2.1.143. iTerm and Terminal

I got the same thing, when running Claude in a docker container :/

Using a Dev Container I run into the same issue. I'm using a Docker volume to persist authentication and settings as proposed here:

https://code.claude.com/docs/en/devcontainer#persist-authentication-and-settings-across-rebuilds

Turned out the issue was that my user within Docker didn't have write access to the created volume. For me the solution was to create the mount point with correct permissions by adding this to the Dockerfile:

RUN mkdir -p $HOME/.claude

Notes: Needs to run as user. Needed to delete the volume and then rebuild the container to take effect.

Got the same issue with dev containers.

While permissions via ls -la looked fine to me, I had to add this to my devcontainer.json:

{
  "postCreateCommand": "sudo mkdir -p /home/vscode/.claude && sudo chown -R vscode:vscode /home/vscode/.claude && chmod 700 /home/vscode/.claude"
}

After that, there was no visible change to the permissions, but suddenly logins became persistent.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

I ran into the same error on a system where there was just no more available disk space - claude code printed "login successful" but since the required files couldn't be written it immediately reported "Not logged in. Run claude auth login to authenticate".

Seems like claude code should throw a visible error if it cannot write the required files to complete the login, this would catch above permission problems or my eventual disk space problem!

I was getting the exact same issue. Login Successful but no auth. Now I'm not a tech guy at all (4th time in terminal - please don't clown me) so maybe my system wasn't configured correctly. But in my case the root cause was a corrupted PATH in ~/.zshrc, not a Keychain persistence bug per se.

My .zshrc had a broken export PATH=... line where $HOME and $PATH had been written without the $ (literal "HOME" and "PATH" text instead of expansion), duplicated across several appended lines from re-running an install script. End result: PATH was missing /usr/bin, /bin, /usr/sbin, /sbin entirely — even basic commands like cat and rm returned "command not found."

My working theory: Claude Code shells out to macOS's security CLI (in /usr/bin) to write OAuth tokens to Keychain. With /usr/bin missing from PATH, the OAuth flow itself completed fine ("Login successful"), but the credential write to Keychain silently failed, producing the "Not logged in · Please run /login" loop on the next check.

Fix:

1. Check your PATH: echo $PATH — confirm /usr/bin and /bin are present.
2. Check ~/.zshrc (or .bash_profile/.profile) for a bad export PATH= line missing $ before HOME/PATH.
3. Replace it with: export PATH="$HOME/.local/bin:$PATH"
4. source ~/.zshrc, open a fresh terminal, run claude, then /login.

Worth checking your PATH even if claude itself runs fine — a partially broken PATH can still be enough to break the Keychain write while leaving the rest of the CLI functional.

• Generated with Claude Code

Hit the same issue just now, found this after Googling.

Max plan, Ghostty, MacOS

FYI: The instant local "fix" was, of course, /logout -> /login, but I figured this shouldn't even happen in the first place.

<img width="391" height="97" alt="Image" src="https://github.com/user-attachments/assets/a80a7bd7-476d-45a8-a6ab-dc8b3c214c6b" />

Max plan, Ghostty, MacOS

It seems that after successful login sometimes it lets one message go through and then completely fails again

❯ /login
  ⎿  Login successful
  ⎿  Not logged in · Please run /login

❯ /model fable
  ⎿  Unable to validate model: Could not resolve authentication method. Expected one of apiKey, authToken, credentials, config, or profile to be set. Or for one of the "X-Api-Key"     or "Authorization" headers to be explicitly omitted

✅ Solved

the working directory (from which the claude session had been launched) was gone, so recreating an empty dir allowed to just resume chatting