[BUG]
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?
Web-based authentication fails to establish a session for an active Max
subscriber, routing to https://claude.ai/onboarding ("Let's create your
account") with the email displayed as verified. No error is surfaced.
Native app authentication for the same email works correctly. A fresh
email sign-in performed today in the Claude iPadOS app resolved into the
existing Max account with full history intact, confirming the account
record is present and resolvable by the backend.
The fault is therefore isolated to the web authentication callback, not
to the account record.
Related: #36797, #57164, #60022, #75638.
What Should Happen?
Claude should login on my Macbook Pro desktop Claude app version. ### Working — native app, universal link callback
- Claude app, iPadOS — fresh email sign-in, succeeded
- Claude app, iOS — authenticated, full Max access
Error Messages/Logs
### Failing — all web callbacks
- Safari, macOS, normal window
- Safari, macOS, private window
- Safari, iOS, private tab
- Chrome, macOS
- Chrome, macOS, via claude.com rather than claude.ai
- Claude Desktop, macOS (delegates to browser)Steps to Reproduce
Steps to reproduce
- Sign out of Claude on all web surfaces
- Request an email magic link from claude.ai or claude.com in any browser
- Open the link, or enter the verification code in the originating session
- Observe redirect to claude.ai/onboarding with email verified, rather
than the account dashboard
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Version 1.24012.9 (03c61d)
Claude Code Version
N/A
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
What's wrong
Web-based authentication fails to establish a session for an active Max
subscriber, routing to https://claude.ai/onboarding ("Let's create your
account") with the email displayed as verified. No error is surfaced.
Native app authentication for the same email works correctly. A fresh
email sign-in performed today in the Claude iPadOS app resolved into the
existing Max account with full history intact, confirming the account
record is present and resolvable by the backend.
The fault is therefore isolated to the web authentication callback, not
to the account record.
Related: #36797, #57164, #60022, #75638.
Working — native app, universal link callback
- Claude app, iPadOS — fresh email sign-in, succeeded
- Claude app, iOS — authenticated, full Max access
Failing — all web callbacks
- Safari, macOS, normal window
- Safari, macOS, private window
- Safari, iOS, private tab
- Chrome, macOS
- Chrome, macOS, via claude.com rather than claude.ai
- Claude Desktop, macOS (delegates to browser)
Steps to reproduce
- Sign out of Claude on all web surfaces
- Request an email magic link from claude.ai or claude.com in any browser
- Open the link, or enter the verification code in the originating session
- Observe redirect to claude.ai/onboarding with email verified, rather
than the account dashboard
Additional diagnostic
Navigating directly to claude.ai/chats from the onboarding page redirects
to the login screen rather than loading the account. No valid session
cookie is being set by the web magic-link callback. The failure is in
session establishment, not only in post-authentication routing.
Expected behavior
A verified email that resolves to a billed existing account via the
native app path should resolve identically via the web path. The web auth
callback should never silently fall through to new-user onboarding for an
email with an active subscription; it should surface an explicit error and
route to support rather than permitting creation of a duplicate account.
Ruled out
- Cleared ~/Library/Application Support/Claude and
~/Library/HTTPStorages/com.anthropic.claudefordesktop, restarted machine
- Private sessions across multiple devices and networks, sharing no cache,
cookies, or extensions
- Two browsers, two rendering engines, both domains
- Fresh magic link on every attempt
- No Sign in with Apple / privaterelay address involved
- No email alias mismatch; identical address string on working sessions
- Individual Max plan; no SSO or organizational seat
- Billing current and in good standing
Not done, deliberately
Have not clicked "Create account," to avoid spawning a duplicate account
under a different auth provider as documented in #51002.
Note
Filed here per the precedent in the referenced issues, where backend auth
failures required engineering escalation because front-line support could
not resolve them. Account and billing verification available privately
through official support channels.