[BUG] Account switch to separate Max 20x account shows Max email but Pro tier and hits exhausted-account limit

What's Wrong?

I have two separate Claude accounts:

• Account A: my existing personal Pro account.
• Account B: a different email/account with a newly purchased Max 20x subscription.

This was an account switch, not a Pro-to-Max upgrade on the same account. After connecting Account B to Claude Code, I used the official claude -p CLI from a terminal tool in the Codex desktop app on Windows. I was using Claude subscription OAuth, not an API key.

The command failed with HTTP 429 and a monthly spend-limit message. At that time:

• claude auth status displayed Account B's email and organization, but subscriptionType was pro.
• I checked both accounts' usage: Account A (Pro) had exhausted its limit; Account B (Max 20x) still had usage available.
• The locally stored OAuth subscription metadata was pro / default_claude_ai.

This is more than an incorrect plan label: the request was blocked while the displayed Max account still had available usage, and the other account's limit was exhausted. These observations strongly suggest that account identity and effective authentication/usage context became inconsistent after switching accounts.

I cannot independently establish which account owned the exact access token used by the failed request. Please investigate whether the previous Pro account's OAuth credentials or usage context were retained while status displayed the Max account's identity.

What Should Happen?

After switching to Account B, requests should authenticate against Account B and use its applicable limits. claude auth status should consistently report the identity, organization, and subscription associated with the effective credentials. A depleted limit on separate Account A should not block requests authenticated as Account B.

Error Messages/Logs

Observed on September 14, 2026 (Asia/Seoul). Identifiers below are anonymized consistently.

Before re-authentication, relevant claude auth status fields:

{
  "loggedIn": true,
  "authMethod": "claude.ai",
  "apiProvider": "firstParty",
  "email": "<account-B-Max-email>",
  "orgId": "<account-B-org-id>",
  "orgName": "<account-B-org-name>",
  "subscriptionType": "pro"
}

Relevant non-secret fields from the local OAuth credential metadata before re-authentication:

{
  "subscriptionType": "pro",
  "rateLimitTier": "default_claude_ai"
}

Sanitized fields from the failed CLI result:

{
  "is_error": true,
  "api_error_status": 429,
  "terminal_reason": "api_error",
  "duration_ms": 35713,
  "result": "You've hit your monthly spend limit · raise it at claude.ai/settings/usage?from=cc_cli_limit_message · your session limit resets 4:20pm (Asia/Seoul)"
}

I then explicitly authenticated again with Account B:

claude auth login --claudeai --email <account-B-Max-email>

Login succeeded. Afterwards, claude auth status showed the same Account B email, orgId, and orgName, but subscriptionType changed to max. The credential metadata changed to:

{
  "subscriptionType": "max",
  "rateLimitTier": "default_claude_max_20x"
}

Re-authentication corrected the observed metadata mismatch. I have not included a controlled post-login inference test here, so I am not claiming that this alone verifies resolution of the request failure.

Steps to Reproduce

This is the observed sequence, not yet a deterministic minimal reproduction:

1. Previously use Claude Code with Account A (Pro).
2. Purchase Max 20x on a separate Account B and switch Claude Code to Account B.
3. Invoke the official claude -p CLI from the Codex desktop app's terminal tool on Windows.
4. Encounter the HTTP 429 monthly spend-limit error.
5. Run claude auth status: Account B's email/org are displayed together with subscriptionType: pro.
6. Check usage for both accounts: Account A is exhausted; Account B has available usage.
7. Explicitly run claude auth login --claudeai --email <account-B-Max-email> again.
8. Observe unchanged Account B identity fields, but subscription metadata changes to max / default_claude_max_20x.

Claude Code Version

2.1.263 at the time of the incident. Reproduction on a newer release has not been established.

Platform

Claude subscription OAuth (authMethod: claude.ai, apiProvider: firstParty), not API-key authentication.

Operating System

Windows

Terminal/Shell

PowerShell 7.6.5. The failed claude -p invocation was launched through the Codex desktop app's terminal tool. The status outputs were also inspected in PowerShell. This describes the launch environment; I have not established that Codex caused the mismatch.

Is this a regression?

I don't know.

Additional Information

Local checks around the incident found:

• ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, and CLAUDE_CODE_OAUTH_TOKEN were unset in the inspected process environment.
• No apiKeyHelper or authentication environment overrides were found in the inspected user/project/local Claude settings.
• CLAUDE_CONFIG_DIR was unset at Process, User, and Machine scopes.
• The local .claude/debug directory had no debug files available to attach.

No access tokens, refresh tokens, email addresses, organization IDs, or private task prompts are included in this report.

Related reports:

• #74217: displayed account differs from the account whose spend limit was exhausted. This is the closest symptom match, but that report involved macOS and Enterprise.
• #87447: Windows claude auth status identity differs from the reported effective authentication/billing account. That report involved Claude Desktop and multiple config roots; my case has no CLAUDE_CONFIG_DIR override.
• #43639: stale Pro subscription/tier metadata after upgrading. My case differs because it involves two separate accounts, not an upgrade of one account.

I searched existing reports and am filing this specific account-switch case with the before/after status and the two-account usage comparison. I have not confirmed a shared internal root cause with those reports.