[BUG] Login authenticates but has_finished_claudeai_onboarding=false walls existing paid Max account behind new-account onboarding (web/desktop/setup-token) — 10th public report of this signature, first with the mechanism captured on the wire

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?

An active, paid Max 20x subscription (active since 2026-01-26) cannot be signed into on any browser, desktop, or CLI surface. Every sign-in path completes email verification successfully — authentication and account resolution succeed server-side — and the post-auth routing layer then discards the successful login and lands on "Let's create your account", the new-account signup screen, as though no account exists for that email. There is no actionable error: no error banner, no "account not found," no surfaced HTTP error — the flow reports success and then misdirects the user toward the one action most likely to harm the account (see #51002).

This failure signature — successful sign-in routed to new-account onboarding — has been publicly reported at least nine times before (dated reports March–May 2026, still unfixed as of August 2026); this is the tenth report, and the first with the mechanism captured on the wire. The prior reports vary in surface and error presentation, and their backend causes are not publicly established; what they share is the user-visible signature:

| Prior report | Date | Same signature | Outcome |
|---|---|---|---|
| #36797 | Mar 2026 | auth redirect loops to onboarding, active sub | open in name only — labeled invalid, unassigned, dormant since Mar 20 |
| #39788 | Mar 2026 | OAuth → account creation instead of auth | closed, no staff response |
| #51002 | Apr 2026 | connector flow created a duplicate account on the same email, locking out the paid subscriber | closed, no staff response |
| #57164 | May 2026 | Google OAuth → onboarding; phone + CLI still authenticated | closed, no staff response |
| #58566 | May 2026 | web + Mac + Windows desktop locked out; iOS, Console, CLI token still worked | closed duplicate/stale, no staff response |
| #60022 | 2026 | magic-link → onboarding, self-identified 5th report | closed "invalid," no staff response |
| #19160 | 2026 | Claude Code OAuth → /onboarding pricing page | closed not planned — despite carrying Anthropic's own has repro label |
| #45886 / #30854 | Mar 2026 | entitlement variant: "account does not have access" | closed not-planned/duplicate |

(The table lists nine prior issues; one row bundles the two entitlement-variant reports.) Across all nine: no human-authored public staff comment appears on any of them — the sole staff action on record confirmed reproduction (#19160's has repro label) and closed the issue not planned anyway — and no fix or workaround has ever been publicly documented. In #45886 the user reproduced the failure on a brand-new laptop, ruling out client state. In #51002, clicking "Create account" produced a duplicate identity and made things worse — I have not clicked it.

Current state of my account, by surface:

| Surface | Status | Evidence class |
|---|---|---|
| claude.ai / claude.com (Google SSO and email code) | signup screen | reproduced repeatedly |
| Claude Desktop (macOS) | signup screen | reproduced repeatedly |
| claude setup-token / CLI re-auth (same OAuth flow) | signup screen | reproduced repeatedly |
| Claude Code, this machine | claude auth status → {"loggedIn": false, "authMethod": "none"} | verbatim CLI output |
| Claude Code on a remote Linux server (separate pre-existing OAuth token) | worked until 2026-08-02; its refresh token hit hard expiry 03:22 UTC and Claude Code wrote back a cleared credential the same day (verified from the server's .credentials.json: both token fields empty, account/org/tier metadata intact). Cannot re-authenticate because re-auth IS the broken flow | credential file, verified |
| iOS app | still signed in and working — the only remaining access | verified today |
| console.anthropic.com (same email) | signs in normally | verified |

Timeline (evidence-anchored):

• 2026-01-26 — Max subscription active since this date (subscription record).
• 2026-06-13 — logout/login events with no onboarding redirect (browser history): sign-in still worked.
• 2026-07-07 22:17:49 UTC — account in active use on claude.ai web (browser history). 22:18:01 — logout. 22:18:12 — the very next Google-SSO login lands on /onboarding. A magic-link attempt at 22:19:14 (URL fragment encodes this account's email — available privately) lands on /onboarding at 22:19:17. The account was broken no later than the first post-logout login; whether the state was already inconsistent before the logout or the logout's session-destruction processing itself flipped it is answerable from the flag's write history against the 22:18:01 timestamp (see engineer check 2). Onset is bracketed between 2026-06-13 (last verified working login) and 2026-07-07 22:18 UTC (first documented failure, captured minute by minute). Failed-login clusters repeat Jul 20, Jul 27, Aug 1, Aug 2.
• 2026-07-10 22:34 UTC — last locally-documented healthy CLI OAuth session for this account's org (39894dd3…) in Claude Code telemetry, is_claude_ai_auth: true, CC 2.1.206 — a pre-breakage token still working.
• 2026-07-20 10:46 UTC — Claude Desktop still operating on this org via a persisted session predating the breakage (desktop main log). Sessions created before the failure survive (iOS still does today); every new login fails. This cleanly separates session validation (works) from post-authentication login routing (broken).
• 2026-08-02 03:22:26 UTC — the last surviving CLI refresh token hits its hard expiry on a remote Linux server (verified from that server's credential file: accountUuid 765bf686…, organizationUuid 39894dd3…, claude_max, default_claude_max_20x, both token fields now empty).
• 2026-08-02 07:33:03 UTC — the last successful request on the account's final surviving desktop/CLI credential: request ID req_011CddXtgF98KYt1rKoxjarW (the access token briefly outlived the refresh expiry). From this moment, iOS is the only access to a Max 20x subscription: every new login attempt on every other surface fails.
• Billing has continued throughout.

An open question for your auth team (explicitly not asserted as proven): this account's refresh tokens aged out to hard expiry on two machines (2026-07-29 18:27 UTC on the local machine's credential; 2026-08-02 03:22 UTC on the Linux server). A routine absolute maximum token lifetime would explain this, and I cannot rule that out client-side — I do not have the tokens' issued_at values. But if the refresh endpoint consults the same onboarding state that walls new logins, the wall would not just block the UI — it would end every surviving session at its next hard expiry, which is how CLI access died on both machines. Two observations would settle it: the issued_at→expiry deltas for those two tokens in your refresh logs (by client ID), and whether a healthy account's refresh expiry advances across sessions. On the second: my control account's CLI refresh-token expiry was observed advancing across sessions on 2026-08-03 (its credential store re-written the same morning with a later expiry), while the affected account's tokens aged to hard expiry on both machines — consistent with the question, not proof of the answer. If it is routine TTL asymmetry, I withdraw the point.

The failure is account-specific and server-side: a second Max 20x account (different email) signs in normally from the same machine, browser, session, and steps — VPN on and off. Cache clears, multiple browsers, full reinstall, and reboots change nothing. No hosts-file entries for Anthropic domains, no proxy.

Wire observation (2026-08-03, HAR available) — narrows the fault to post-authentication routing. I recorded the failing sign-in in Safari with full network capture. The result overturns the "identity doesn't resolve" hypothesis of all prior reports:

The login SUCCEEDS. POST /api/auth/verify_magic_link → 200 with success: true and my complete account object: uuid 765bf686…, both org memberships, capabilities: ["chat","claude_max"], billing_type: stripe_subscription. The returned uuid is a byte-for-byte match for the accountUuid in the surviving Linux credential file and in the subscription records — the account being walled IS the historically working, subscribed account. The authenticated session then successfully fetched 30 of my conversations (chat_conversations_v2 → 200) and a full feature grant (current_user_access: chat available, claude_code available). Nothing is orphaned; authentication and account resolution succeed. What fails is what happens next.

The account object also contains the defect:

has_started_claudeai_onboarding  = true
has_finished_claudeai_onboarding = false    ← on an account created 2024-04-25,
completed_verification_at        = 2024-04-25T00:44:59Z    verified, paid, in active use
visibility_status                = null     (not suspended)
api_disabled_reason              = null     (not disabled)
subscription_pause               = null     (not paused)

Every fresh sign-in is walled behind the new-account onboarding screen, and this flag pair is the only anomalous client-visible state in the account object — even direct navigation to /new in the authenticated session bounces to the wall (client-side route, not a server redirect: the HAR contains no /onboarding document fetch or 302; the SPA routes on state).

The client-side half of the mechanism is verified, not inferred. The route-guard predicate, read from the exact frontend bundle the failing session served (shared-0-NLgn1Ox9.js, preserved in the HAR):

({account: e, isClaudeDot: a}) =>
    a ? false === e.settings.has_finished_claudeai_onboarding
      : !e.full_name || !e.display_name

On claude.ai, "needs onboarding" is has_finished_claudeai_onboarding === false — a single flag, not a composite. (Pending legal-consent as an independent gate is weakened by the same capture: the account object's accepted_clickwrap_versions is populated.) What remains server-side and open is why the flag is false — and the shipped frontend itself suggests the answer's shape: an internal dev-tools action ("Onboarding restarted", bundle shared-14) writes {has_finished: false, has_started: false} and routes to /onboarding. A reset of that form, followed by the wall marking started=true on first landing, produces exactly this account's (started=true, finished=false) state — i.e., the state carries the signature of an onboarding reset (tooling, experiment, or migration side-effect), not of an account that never onboarded. Whether such a reset fired here is answerable only from your write history (check 2).

Healthy-account discriminator (captured 2026-08-03, second HAR available). I hold a second Max 20x account. Same plan, same rate-limit tier, same browser, same login flow, captured the same day:

| Account | has_started_claudeai_onboarding | has_finished_claudeai_onboarding | Login outcome |
|---|---|---|---|
| Affected | true | false | walled at "Let's create your account" |
| Control (2nd Max 20x) | true | true | signs in normally |

One bit differs between the two account objects' onboarding state, it is the exact bit the verified route-guard branches on, and the login outcomes differ accordingly.

A dated-versions observation (labeled hypothesis, not asserted): the affected account's accepted_clickwrap_versions contains all three document types (aup, privacy, consumer-terms) — so this is not an account that never accepted terms — but at older version UUIDs than the control's. If a consumer-terms version rollout triggers a server-side onboarding reset to force re-acceptance, that would explain the reset-shaped flag state, the wall rendering a terms checkbox, the March-onward trickle of public reports (progressive rollout), and the legacy-account skew. Check 2 below includes the correlation to run.

The blast pattern fits: sessions created before the breakage (iOS, desktop, CLI tokens) never re-run the post-auth gate and kept working; every new login on every surface hits the wall; Console signs in normally, which suggests its sign-in path does not evaluate this flag (inference, not verified).

Key request IDs from the captured (successful-but-walled) login, 2026-08-03 ~16:28 UTC: req_011Cdg8Wf3gYBpi4hLiWdzQk (verify_magic_link, returns the account), req_011Cdg8WkMfb41MQtsRdo7hE (current_user_access), and from the Google-SSO attempt minutes earlier: req_011Cdg8Ty2afEmT6gHAHW71u (verify_google, also 200).

The candidate repair: reconcile this account's onboarding state through the owning service — the flag, legal-document acceptance state, and org/entitlement invariants together — validated in staging before any production write, then retest fresh login and token refresh on every surface. Whether correcting the flag alone is sufficient, or it is one symptom of a deeper state inconsistency, is exactly what the checks below determine; what is certain is that no client-side action can resolve this. I have not clicked "Create account" / the terms checkbox — bundle analysis shows it submits PUT /api/account/accept_legal_docs plus get_or_create_chat_organization, which would probably resume the existing account, but issue #51002 documents a duplicate-account outcome from this screen and I am not gambling a two-year account on "probably."

What Should Happen?

After email verification succeeds, the existing paid account should load. Instead the flow silently falls through to new-account creation.

What I need from Anthropic, in this issue:

1. A human. No prior report of this signature has a human-authored public staff response. My four support follow-ups (conversation IDs below) have had no human response. Please escalate to whoever owns the claude.ai account/onboarding service.
2. Repair this account's onboarding state through the owning service (see "candidate repair" above) — validated in staging, then retested on fresh web, desktop, and setup-token logins.
3. The class-level diagnostic (check 3 below): if the class is non-empty, backfilling it makes this entire issue category disappear.
4. The diagnostic legwork is done — see the wire observation above. A sanitized HAR of the full captured login (cookies, auth headers, and one-time codes stripped; all API bodies intact) is ready to send through any private channel.

Billing has continued throughout; remediation of the account and billing is proceeding through support channels in parallel — this issue asks only for the engineering fix and the escalation path.

For the engineer who picks this up — five checks, phrased goal-first because I cannot know your schema (wherever onboarding state actually lives — table, event log, or derived view). No reproduction is needed; the account is in the failed state right now, and the first check is a single record read:

1. Read this account's effective onboarding state (765bf686…): confirm has_finished_claudeai_onboarding = false alongside completed_verification_at = 2024-04-25 and an active claude_max subscription, and confirm whether the value is stored or derived. That contradiction is the bug. Also read the write history of the has_started/has_finished pair — started=true on an account that never clicked through the current flow is itself unexplained and may be the actual clue (a partial onboarding write?).
2. Audit the flag's history against two timestamps: the 2026-06-13 → 2026-07-07 22:18 UTC onset bracket, and the 22:18:01 logout specifically (did session-destruction processing write account state?). Look specifically for a reset-shaped write — (has_finished=false, has_started=false) in one operation, the same shape your own frontend's "Onboarding restarted" dev action produces — from any tooling, experiment, or migration in that window. Correlate with whatever shipped enforcement then — code deploy, config change, feature-flag or percentage rollout — and specifically with any consumer-terms/AUP version rollout: this account's accepted_clickwrap_versions are older than a healthy control account's, and a forced re-acceptance job that resets onboarding state would produce everything observed. A progressive rollout over a legacy cohort would also explain the March-onward trickle of public reports and the sharp per-account onset.
3. Run the class query in your actual schema: accounts with onboarding started-but-not-finished state, an active paid subscription, and created_at before the current onboarding flow existed. Every row is another instance — the nine prior reports suggest the class is not empty.
4. Check what get_or_create_chat_organization does when called from the onboarding wall by an account that already has a chat org. If any path creates rather than gets, that is the #51002 duplicate-account factory, and it is still armed.
5. Answer the refresh-token question (framed as an open question above): pull this account's refresh logs by client ID and the two expired tokens' issued_at→expiry deltas. If the expiries were routine absolute TTL, say so and the point is withdrawn; if the refresh endpoint consults onboarding state, the wall is also ending surviving sessions at their next expiry.

Error Messages/Logs

There is no actionable error message — that is the bug. The flow reports success and then routes to account creation, misdirecting the user toward the very action most likely to harm them (#51002):

Email verified as <redacted>

followed immediately by:

Let's create your account

Current CLI state on the machine that held this account (verbatim):

$ claude auth status
{
  "loggedIn": false,
  "authMethod": "none",
  "apiProvider": "firstParty"
}

When a session is attempted on the Linux server that held the account's last token (transcript entry, 2026-08-03, model: <synthetic> — generated client-side, no API call made):

Login expired · Please run /login

The prescribed remedy is the defect: /login runs the OAuth flow that lands on the signup screen. The error message points at a door that doesn't open.

A useful server-side anchor: the last successful request on the account's final surviving desktop/CLI credential, 2026-08-02 07:33:03 UTC —

req_011CddXtgF98KYt1rKoxjarW

Look up that request; every desktop/CLI/new-login attempt after that timestamp is the failure in progress (the surviving iOS session continues to make successful calls, which is part of the diagnostic pattern, not a contradiction of it).

There is no client-side debug log to attach, and that is itself diagnostic: the failing sign-in happens on claude.ai's OAuth/verification endpoints before any client state is written. Two request IDs provably tied to this account's organization (from Claude Code telemetry stamped with org 39894dd3…, session 46253df0-ea73-421b-b9b3-962a4658c00b, 2026-07-10 — i.e., from when the account still worked):

req_011CcuAzWkTQgZYGHj9siUrU
req_011CcuB1eVoyafssK5sXjFGB

These identify the account server-side. The request IDs of the failing sign-in attempts exist only on Anthropic's auth endpoints; I can capture a sanitized HAR of the failure from browser DevTools and provide it through any private channel.

Steps to Reproduce

1. Go to claude.ai (or claude.com, or open Claude Desktop) signed out.
2. Enter the affected email address.
3. Use either "Continue with Google" or the 6-digit email code — identical behavior.
4. Verification succeeds ("Email verified as …").
5. Observed: "Let's create your account" (new-account signup). Expected: the existing paid account loads.

Reproduces on every path: claude.com Google SSO, claude.com email code, claude.ai directly (both methods), Claude Desktop, and claude setup-token. Not affected by: cache/cookie clears, different browsers, reinstall, reboot, VPN on/off. Control: a different Max 20x account signs in normally from the same browser session.

I have not clicked "Create account" (see #51002 for why).

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Day-1 support ticket recovered: onset moves to Jul 6, trigger window identified
I located the full transcript of the earliest support conversation (215474970960965), opened via the logged-out "I can't login" flow within hours of the failure, containing a contemporaneous report with screenshots — written four weeks before any of the forensics above. It establishes four things (times below converted from US Central, CDT = UTC−5):

1. Onset was the night of Jul 5→6, not Jul 7. Last confirmed signed-in web state: 2026-07-06 04:02 UTC (the account's usage pane visible in a signed-in session). First screenshot of the signup wall: 05:10 UTC; still failing at 05:49 UTC. The Jul 7 22:18 UTC capture in the timeline above remains the first minute-by-minute documentation, but it documents an already-broken account — the Jul 7 browser session was a surviving pre-breakage session; its logout merely ended it. This supersedes the "bracketed 2026-06-13 → 2026-07-07" line above, and answers check 2's Jul-7 question: the state was broken before that logout.

1. The trigger window is ~68 minutes wide and contains specific, unusual activity (per the contemporaneous report): alternating logins on claude.ai in one browser between this account and a second Max account (email-code logins included), and at ~05:09 UTC — about one minute before the first failure screenshot — a Claude Code install was re-bound from this account to the second one via /logout + /login: a session-destruction event on the affected account immediately before the first failure evidence. Check 2's audit window is therefore 2026-07-06 04:00–05:10 UTC, with specific attention to account-switching and logout/session-destruction processing writing account state.

1. Your support bot diagnosed this as backend on day one, then declined escalation. Verbatim, from the transcript: "there may be a backend lookup issue that needs investigation"; "This points to a backend account mapping issue that standard troubleshooting can't resolve." Asked directly "Could you send the ticket to an Anthropic engineer?", it replied that reporting in the conversation "is all that's needed," that "there isn't a separate ticketing system with tracking numbers," there is "no way to track the status of a fix," and "reaching out multiple times about the same issue won't expedite a fix."

1. The first report is Anthropic-timestamped 2026-07-06 — same day as onset — and included the account email and full identifiers. Everything in this issue was in your support system, with a backend diagnosis from your own bot, four weeks before this filing.

-----------------------
Local machine: 2.1.220 (Claude Code), macOS 26.5.2
At last healthy session (2026-07-10, telemetry): 2.1.206
Claude Code is a victim, not the cause: claude setup-token runs the same broken OAuth flow, so the CLI cannot re-authenticate this account anywhere — including on a separate Linux server whose token hit hard expiry 2026-08-02 03:22 UTC.

-----------------------
Terminal Shell: VS Code and Terminal.app
-----------------------

Additional Information
Support history — no human dialogue. Multiple tickets over ~5 weeks, four written follow-ups, explicit escalation requests in each; no human-authored response received to any of them (verbatim transcripts of the automated replies available privately). One earlier ticket was auto-closed with ban boilerplate — a misdiagnosis; suspended accounts do not render a signup form, and the account record confirms visibility_status: null, api_disabled_reason: null. At one point I received a notice giving me one day to re-log in before losing app access — with re-login being exactly the broken flow. Conversation IDs, all without human-authored response: 215474970960965 (the earliest — opened 2026-07-06 via the logged-out "I can't login" flow, within hours of onset, with full identifiers; transcript recovered, see Addendum), 215475251588888, 215475322334218, 215475309512859.

Also relevant: I hold a working Max 20x on a second email and own a Team org on a third. If the affected identity was ever touched by an org add/remove/migration, that may be the trigger — several prior reports (#51002, #57164) involve multi-account or connector flows.

Available privately on request — the full untruncated values of the identifiers referenced above (account email, org UUID 39894dd3…, account UUID 765bf686…, API-platform org UUID 5ce80225…), plus billing receipts, signup-screen screenshot, support-ticket transcripts, and the sanitized HAR of the failing sign-in. Identifier prefixes are left in the public text deliberately, so backend tracing can start without waiting on the private channel.

Screenshot 2026-07-27 at 5.02.36 PM redacted.pdf

---

Appendix — Prior Reports: What Each User Tried, What Anthropic Did, and the Outcome

All nine issues individually verified 2026-08-03.

| Issue | What the user did | What Anthropic did | Outcome |
|---|---|---|---|
| #19160 (Max 5x, Windows) | Reported CLI OAuth → pricing page, with reproduction steps | Applied its own has repro label — then closed not planned | Locked out; no fix |
| #30854 (Max, macOS) | Repeated /login as the error itself instructed | Closed not planned, stale | Locked out; no fix |
| #36797 | Reported the redirect loop | Labeled invalid, never assigned; dormant since Mar 20 | Open in name only; no fix |
| #39788 (Max, £90/mo) | claude auth login --claudeai, documented redirect to account creation | Closed duplicate — of other unfixed issues | Locked out; no fix |
| #45886 (Max) | The most exhaustive self-help on record: re-logins, desktop re-auth, full uninstall, ~/.claude wipe, npm cache clear, billing verified, bought a brand-new laptop — identical failure on fresh hardware | Closed duplicate/stale | Proved it server-side at personal expense; no fix |
| #51002 (paid Max) | Followed the Drive-connector flow in good faith; clicked through the signup it presented | Closed not planned / invalid | Actively harmed: duplicate account created on his email, deepening the lockout |
| #57164 (Max, macOS) | Documented the surviving-sessions pattern (phone + CLI alive, browser dead) | Closed not planned, stale | Locked out; no fix |
| #58566 (Max, $106.60/mo) | Did everything Fin suggested (cache clears, reinstalls, logout cycles); explicitly requested human escalation; refused to click "Create account" | Fin never handed off; closed duplicate/stale | Locked out, still billed; no fix |
| #60022 (Max) | Documented the magic-link variant, cited the four prior reports, emailed support | 72+ hours of silence; Fin refused handoff; closed invalid ("not related to Claude Code") | Locked out; no fix |

The patterns:

1. No self-help path has ever worked — up to and including new hardware — because the defect is server-side account state. Nothing client-side could ever have worked.
2. Every support route dead-ended at the AI agent. No user reported reaching a human. Every closure state on record is mechanical: duplicate, stale, invalid, not-planned (staff interaction was limited to labels and closure state).
3. The one user who engaged with the signup screen was made worse off (#51002).
4. has repro + not planned on #19160: triage confirmed the bug reproduces, and closed it anyway.
5. The invalid closures ("not related to Claude Code") are half-right and fully damning: the root cause lives in the claude.ai account service, for which no public tracker exists — so users report it in the only place available and get bounced. It remains a Claude Code bug regardless: claude setup-token is broken by it.

account.is_verified: true
account.completed_verification_at: present (May 30, 2025)
account.settings.has_started_claudeai_onboarding: true
account.settings.has_finished_claudeai_onboarding: false
consumer organization capabilities: [chat]
consumer organization billing_type: none
claude_max capability: absent