[BUG] Claude account /login OAuth loop — state parameter dropped after "sign in again to continue" redirect

Update: This is intermittent rather than fully broken — captured back-to-back attempts with no changes in between:

) /login
Login interrupted

) /login
Login successful

Still occurring on Claude Code v2.1.212. Also noticed the browser itself can get visibly stuck during the flow — sometimes just re-issuing /login unsticks it.

Workaround that got a clean success:

1. Killed the browser entirely, opened a fresh window
2. Logged into claude.ai directly first (not via the CLI flow)
3. Ran /login in Claude Code
4. Got the OAuth Authorize screen → clicked Authorize
5. Got bounced to "sign in again" → chose the email option
6. Clicked the link in the email → landed back on the Authorize screen again
7. Clicked Authorize a second time — this time it succeeded

Previously step 7 would loop back to requesting the email link again instead of completing. Having an already-authenticated claude.ai session in place before starting /login seems to reduce (but not eliminate) the loop — it still took one extra Authorize→email→Authorize cycle even in this successful run.

This points toward a race condition around session/cookie state during the "sign in again" re-auth step, rather than a hard failure. Worth noting for anyone else hitting this: pre-authenticating in the browser before running /login may help get through it.

Update: Confirmed the underlying bug is still present as of v2.1.212 and v2.1.214 — raw /login (no pre-steps) still fails first, exactly as originally reported on v2.1.208. Not fixed by any of the recent releases.

However, I've found a consistent workaround once the raw attempt fails:

1. Kill the browser, open a fresh window
2. Log into claude.ai directly first (not via the CLI flow)
3. Run /login in Claude Code
4. Click Authorize on the OAuth screen
5. If bounced to "sign in again," choose the email option
6. Click the link in the email → back on the Authorize screen
7. Click Authorize again — this succeeds

This workaround has been reliable across v2.1.212 and v2.1.214, tested each time only after confirming the raw /login still fails on its own. Posting in case it helps others stuck on this while the root cause remains open.

I had same issue with Safari set as default browser and Claude Code opening login link in Safari. Setting Chrome as default browser fixed the login issue - seems like temporary workaround for now.

Experiencing something similar in v2.1.216 and Firefox.

Firefox:
clicking the link from VS Studio Code to authorize enters the authentication-re-sign-in loop.

Bypassed by:
Opening a private firefox window, manual copy+pasting the link from VSsc, sign-in via e-mail, entering the verification code, pasting auth code into VSsc.

Same issue here.

For what it's worth, this was enough to get me to cancel my Max plan and try codex for the first time.

FWIW for anyone else having this problem, this failed repeatedly in safari for me and worked in Firefox. Could be a cookie issue, could be browser specific.

Firefox: clicking the link from VS Studio Code to authorize enters the authentication-re-sign-in loop. Bypassed by: Opening a private firefox window, manual copy+pasting the link from VSsc, sign-in via e-mail, entering the verification code, pasting auth code into VSsc.

This workaround worked. Thank you @NeoRe-222! Hopefully this can be patched sooner rather than later.

Same behavior on Firefox

I've got the same issue on Firefox for version v2.1.218, using private tab did not help. I'm stuck in endless "authorize" loop.
Edit: It worked today

Update: Raw /login (no pre-login workaround) succeeded cleanly today on v2.1.218 — Authorize screen appeared, clicked Authorize, done. No "sign in again to continue" detour, no email step.

This is the first time the raw flow has worked without hitting the loop or needing the browser-first workaround described above. Given the intermittent nature confirmed across 2.1.208–2.1.214, I can't yet say whether this reflects an actual fix in 2.1.218 or is just this particular attempt succeeding by chance — will report back if it recurs or continues working cleanly.

I'm having the same issue.
Fresh clean install, first-ever auth on this machine
Six attempts in 15 minutes which probably will lock my account on top of this problem
Tried Zen (firefox engine) and Safari; also pasted the URL manually rather than clicking, ruling out browser handoff
this is pretty dumb!

I'm having the same issue. Fresh clean install, first-ever auth on this machine Six attempts in 15 minutes which probably will lock my account on top of this problem Tried Zen (firefox engine) and Safari; also pasted the URL manually rather than clicking, ruling out browser handoff this is pretty dumb!

Following up on my earlier comment because I resolved it!

Environment: macOS 26.5.2, Apple Silicon, Claude Code 2.1.218, fresh clean install (first-ever auth on this machine). Adding macOS to the platform:linux / platform:intellij labels to emphasize this isn't platform-specific.

What failed: six or seven attempts across Zen (Firefox engine) and Safari, including pasting the auth URL manually rather than clicking, which rules out browser handoff. Every attempt looped at the same step. Eventually got "We were unable to verify you with this link," presumably rate-limiting after that many magic links in fifteen minutes.

What worked:

1. Open a private/incognito window in Chrome and log into Claude.ai
2. Run claude auth login from Terminal command line
3. Copy the auth URL that comes back and paste it manually
4. At the email step, choose "Enter verification code" rather than waiting for the link
5. Anthropic still emails a magic link, not a code — but that link resolves to a page displaying a long auth code
6. Paste that code into the terminal

Why I think this works: the OAuth callback is where state gets dropped. Manual code paste never touches the callback at all. The "Enter verification code" option is a bit of a misnomer since you still get a link, but the link lands you somewhere different than the normal flow does.

It recurred on the very next launch. Whan i fully launched Claude Code CLI, it wanted to link to my subscription and required Augth. It opened my default browser (default Zen, carrying migrated cookie state) and looped again immediately. Fix: killed the CLI, relaunched, and pasted the new auth URL into the still-open incognito window from the successful attempt. Went straight through. Worth keeping that window around if you need to re-auth.

One other data point supporting the intermittent/race-condition read: claude doctor reported Sign-in is missing the user:profile scope while stuck, which suggests a partial credential gets written rather than the flow failing cleanly. (Claude wrote this last line and I don't fully understand it FYI)

Same problem with v2.1.220. seems like a server side issue. None of the workarounds above worked for me.

I have a different workaround that Claude itself came up with - log out of claude.ai in the browser you use completely, sign back in(to clear the 'sign in recently' flag), then do the sign in from CLI or VSCode again - it should skip the 'need a recent login' bit that's failing and authenticate.

In version 2.1.220 I was having trouble with what appeared to be this bug. I'd follow the URL, I'd authorize, it would ask me to log in again, I'd do it, I'd press authorize, and it would ask me to log in again ad nauseam. I tried the suggestions the chatbot gave me - rm -rf'ing all my config data to no avail. But unsatisfyingly, what worked for me was to push that URL to my phone, try it there, and it gave me a code I could push back successfully. This was on Ubuntu i.e. Linux

I had the same issue on Firefox, using Ubuntu 22.04. Logging in via Chrome fixed it for me.

Confermo lo stesso comportamento. Setup: estensione VS Code (2.1.220) + CLI da terminale (Windows 11).

Sequenza:

1. Sessione CLI funzionante da tempo, mai fatto /logout esplicito (solo /exit tra le sessioni)
2. Improvvisamente sia l'estensione VS Code che il CLI richiedono nuovo login
3. Flusso: autorizzo app → "Accedi di nuovo per continuare" (recent authentication richiesta) → redirect a schermata di login completa → provo sia email (magic link) che Google OAuth → entrambi riportano al medesimo redirect di login, loop infinito
4. Il loop si presenta identico sia da VS Code extension che da CLI terminale, confermando che il problema è nel servizio OAuth condiviso, non nel client

Questo suggerisce che anche token precedentemente validi vengono invalidati lato server e il tentativo di refresh/nuovo login cade nello stesso punto di rottura (state parameter perso dopo il redirect "sign in again").

Reproducing this on macOS with a fresh install — adding a data point since the original report was Linux/IntelliJ.

Environment:

• Platform: macOS (Apple Silicon), zsh, iTerm2, Safari
• Claude Code version: 2.1.220 (native installer)
• Auth method: /login → option 1, "Claude account with subscription"

Loop behavior:
Authorize → "Sign in again to continue" → login page → account picker → back to Authorize page → repeats indefinitely. Also tried claude auth login directly — same loop, and the "Paste code here if prompted" field only ever returns "Invalid code" since no code is ever issued to paste.

Steps taken, none resolved it:

• Confirmed no stale ANTHROPIC_* env vars (env | grep ANTHROPIC empty)
• Started on 2.1.178, upgraded to 2.1.212 via Homebrew — loop persisted
• Logged out and back into claude.ai in-browser immediately before retrying (so the sign-in was under a minute old) — still diverted to "sign in again to continue"
• Full clean reinstall: brew uninstall --cask claude-code, removed ~/.claude, ~/.claude.json, deleted the macOS Keychain entry, reinstalled via curl -fsSL https://claude.ai/install.sh | bash → fresh v2.1.220, entirely new local state — loop identical

This strongly suggests the issue is fully server-side rather than tied to local install state, version, or credentials, matching what's already noted above about claude setup-token hitting the same failure.

same login problem in windows / claude code v2.1.220 (using max plan)
Suddenly VS Code requests new login so I did. (same for claude code terminal)
When I press Sign in by claude subscription in claude code -> redirect in browser -> and this bug comes out.
This is not browser problem becuz it also happens at Microsoft Edge, Chrome Secret mode and cookie delete doesn't work at all.

<img width="1895" height="876" alt="Image" src="https://github.com/user-attachments/assets/0bcc2d0c-1d50-45ad-8cd8-fa31b1de1972" />

I am having this issue on WSL2. Tried different browsers and still getting stuck in Authorize --> Sign in again loop.

The incognito method from @baratunde worked for me

This just happened to me as well. The Incognito method worked here as well, but this should get fixed. I'm stuck running an old version of Claude Code v2.1.108 due to developing simple apps and scripts on an older mac for professional reasons

Confermo lo stesso comportamento. Setup: estensione VS Code (2.1.220) + CLI da terminale (Windows 11). Sequenza: 1. Sessione CLI funzionante da tempo, mai fatto /logout esplicito (solo /exit tra le sessioni) 2. Improvvisamente sia l'estensione VS Code che il CLI richiedono nuovo login 3. Flusso: autorizzo app → "Accedi di nuovo per continuare" (recent authentication richiesta) → redirect a schermata di login completa → provo sia email (magic link) che Google OAuth → entrambi riportano al medesimo redirect di login, loop infinito 4. Il loop si presenta identico sia da VS Code extension che da CLI terminale, confermando che il problema è nel servizio OAuth condiviso, non nel client Questo suggerisce che anche token precedentemente validi vengono invalidati lato server e il tentativo di refresh/nuovo login cade nello stesso punto di rottura (state parameter perso dopo il redirect "sign in again").

Follow-up to my comment above: found a workaround that worked for me today (2026-08-05).

Setup: VS Code extension, auto-updated to v2.1.222 — auth broke after the update, same OAuth loop described in this issue (redirect after "sign in again to continue" never completes).

What worked:

Trigger the login flow again from the VS Code extension (it generates a new identity-verification link).
Open that link in a fresh private/incognito browser window — not your regular browser session. This seems to matter: doing it in a normal window with existing cookies/session state kept hitting the same loop for me.
Complete the flow in the private window → a confirmation email arrives.
Open the link from that email → it shows a code to enter in the browser.
Enter the code → the browser then generates a final authentication code.
Paste that final code back into VS Code's auth prompt.
That completed successfully and the extension has been working normally since. Posting in case a clean session (private window) is a useful workaround for others stuck in the loop while the underlying state parameter bug gets fixed server-side.

Same here. Claude Version 2.1.223. OS Ubuntu 26.04 LTS, Browser Firefox.
Workaround: Private Window in FF

I'm hitting this exact bug on Claude Code CLI v2.1.220 (macOS) as a Claude Max subscriber ($200/mo). /login and claude setup-token both loop back to "Sign in again to continue" after completing the magic-link sign-in, every time, no exceptions. SO INCREDIBLY FRUSTRATING.

This is fully blocking, not a minor annoyance. I have work in Claude Code I currently cannot touch because I can't authenticate at all.

I've been through Anthropic's support widget four times and emailed [support@anthropic.com](mailto:support@anthropic.com) twice over the last two days. Every response has come from their AI agent (Fin) WHO IS A COMPLETE AND UTTER AI IDIOT, which cannot escalate to a human and has no visibility into when this will be fixed. Flagging here since this is the only channel where an actual engineer might see it. Any update on a fix would help a lot.

Thanks for the detailed writeup — the URL capture at the failure point was especially useful.

I tested this on 2.1.233 on Linux, in both a no-browser terminal and with a browser handler available:

• /login → "Claude account with subscription" and claude setup-token both produce an authorize URL that always includes state and code_challenge_method=S256. I could not get the CLI to emit one without them.
• When a browser is available the flow uses a http://localhost:PORT/callback redirect; when no browser can be opened it falls back to the hosted paste-the-code page. That second case is why you saw a non-localhost redirect_uri — it's the expected fallback, not part of the failure.
• The initial hop preserves every parameter, matching your observation that the first URL looks correct.

So this looks like the sign-in web flow dropping the original parameters when it rebuilds the authorize request after the "sign in again to continue" email step — consistent with setup-token failing identically, since it shares that flow. We're routing it to the team that owns the account sign-in service; it isn't something a client update would fix.

One ask: could you confirm whether this still reproduces for you today? A change on that side would take effect without any new release, and it's been a little while since you filed.

🤖 Generated with Claude Code

We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.

Thanks for looking into this! To answer directly: the infinite loop itself hasn't reproduced since my update on July 23. I've since gone through several more versions, currently on v2.1.241, and haven't gotten stuck again.

A few more observations that might be useful:

• I still sometimes get routed through the "sign in again" / email step, but it now completes successfully instead of looping back to the authorize screen.
• Other times it authenticates directly with no email step at all — seems inconsistent which path I get.
• Whichever path it takes, the whole process takes noticeably long — close to a minute in some cases before authorization completes. I don't have a baseline for what's normal on other platforms/setups, but a minute feels slower than I'd expect for an OAuth flow.

So the core loop/failure looks resolved on my end, but there may be a lingering latency issue worth a look — even in the success case, /login seems to take longer than it probably should.

Happy to close this on my end regarding the loop itself, or defer to you if you'd like to keep it open to track the slowness separately.