Individual Pro subscriber blocked from Claude Code: 'organization disabled' → 'Max or Pro required' (entitlement sync bug)

I've spent several days going back and forth with Anthropic's support chat (Fin) on this exact issue. A few relevant points from that conversation (reference: Conversation ID 215474875050386):

Fin initially attributed this to the Claude Mythos 5 / Fable 5 access suspension (announced June 13, 2026). This doesn't hold up — Anthropic's own statement on that suspension says access to all other models is unaffected, and I was never a Mythos/Fable user in the first place.
Fin explicitly confirmed: "I can't transfer you to a human or provide a ticket number" and separately confirmed no human agent had been assigned to the conversation.
I have a $9.56 remaining balance in usage credits from the $10 API credit offer mentioned in the timeline above, in case that's relevant to whatever changed on the backend.
I'm based in India, in case there's any regional/billing-routing angle worth checking.

Posting here since the support chat explicitly told me it had no further escalation path available, and this looks like a backend account/entitlement bug rather than something fixable client-side.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68212
2. https://github.com/anthropics/claude-code/issues/35877
3. https://github.com/anthropics/claude-code/issues/69786

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

I have the exact same issue. I'm a Claude Pro subscriber (individual, not Team/Enterprise). I was using Claude Code normally until today when I suddenly got "This organization has been disabled" and OAuth 403 error. I never joined any organization. No solution found so far. Hope Anthropic fixes this server-side bug soon.

Same failure here, reached through a completely different trigger — which I think narrows where the bug actually lives.

Environment: Windows, Claude Code CLI. Individual Pro subscriber, auto-generated personal org, never created or joined a team/enterprise org.

Different entry point: I never accepted the $10 API credit offer. My Pro subscription was purchased through the Android app via Google Play. Settings → Billing shows Pro active and paid, while the organization Claude Code authenticates against still resolves as Free. The Play Store purchase appears to have never propagated to the org at all — so in my case the entitlement was never written, rather than being overwritten later.

That matters because @vizzzi's trigger (accepting API credit) and mine (Google Play billing rail) have nothing in common except the outcome. That points at the org-entitlement sync layer itself rather than at either specific trigger.

Data point not in the original report: Claude Cowork is blocked identically. Same account, same error class, same time window. Cowork has no API-key fallback path, so this isn't containable to the CLI — the fault sits upstream of Claude Code, in the shared subscription OAuth / entitlement resolution both products call.

Independently reproduced from the original report:

• 403 oauth_org_not_allowed — "Your organization has disabled Claude subscription access for Claude Code · Use an Anthropic API key instead, or ask your admin to enable access"
• /logout + /login escalated the error instead of clearing it, exactly as in steps 6–7, moving to "Claude Max or Pro is required to connect to Claude Code." Worth flagging that support still recommends this cycle; it reliably makes the state worse.
• No ANTHROPIC_API_KEY set in the environment, no stray .env files (verified by recursive search)
• claude.ai in the browser works normally throughout, on the same account

Support path so far: several sessions with Fin, then a ticket confirmed into the human queue on 10 July. No human response in the ten days since. Continuously blocked for roughly three weeks on a paid subscription.

Happy to provide my org ID, account email, and support conversation ID privately to a maintainer.

Adding a related, privacy-sanitized billing/auth entitlement signal from a separate unresolved Claude billing case.

The exact surface here is different, but the common failure boundary looks important:

• billing/subscription state says the customer should have paid access;
• a Claude or Claude Code auth/organization/entitlement surface routes the same customer away from that paid access;
• generic support guidance or re-login/retry steps do not reconcile the underlying records;
• the problem needs a Billing Platform / entitlement / auth-state owner who can compare billing ledger, subscription status, organization mapping, credit state, and Claude Code auth state together.

In my separate case, manual prepaid / bulk usage-credit purchase paths failed or became stuck on Anthropic's side while other Anthropic billing paths continued to work. That split behavior has the same "one internal source says allowed/paid, another product path says blocked/unpaid or route-to-credits" shape.

Public, privacy-sanitized evidence hub:
https://coolak.github.io/anthropic-claude-billing-incident/

Reconciliation matrix:
https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html

I am not repeating private identifiers from this issue body. The ask is for Anthropic to route this class of reports to an owner who can reconcile billing, organization, entitlement, credit, and auth records together instead of treating each symptom as an isolated user-side login/card problem.

Same issue. This is twice now this has happened to me. all checks are verified. no echo on anthropic key. /status reports latest version and /mcp successfully ran. restarted VSCode and PC. My Chat works fine. Claude code does not. I am a paid 20x max member. So sick of this.

Affected as well, on macOS. Adding a data point that I haven't seen in the other reports: on the same account and the same machine, the Claude Desktop auth path works while the standalone CLI is blocked — at the same moment, minutes apart.

Account shape

• Individual Pro subscription, active and paid
• Not part of any Team or Enterprise org — the "organization" is the auto-created personal one, and my organizationRole is admin, so "ask your admin to enable access" has no one to ask and no toggle to flip
• No ANTHROPIC_API_KEY set (confirmed unset in the failing shell)

Environment

• Claude Code CLI 2.1.220 (also reproduces via the desktop-bundled 2.1.219 and VS Code extension 2.1.218)
• macOS 12.7.6 (21H1320)

Reproduction

claude -p "reply with exactly: OK" --output-format text

Output, exit code 1:

Your organization has disabled Claude subscription access for Claude Code · Use an Anthropic API key instead, or ask your admin to enable access

Reproduces in a scrubbed environment with the inherited CLAUDE_CODE_* variables unset, so it isn't contamination from a parent Claude Code process.

The part that looks diagnostic

The stored OAuth credential is not obviously the problem. At the time of failure the keychain item held:

• subscriptionType: "pro"
• scopes including user:sessions:claude_code
• an expiresAt still several hours in the future

So the token carries the Claude Code session scope and a valid Pro subscription type, and is still rejected with an org-policy error. Meanwhile the Claude Desktop app — same account UUID, same machine — authenticates and runs Claude Code fine, using its host-auth refresh path rather than the keychain OAuth token.

That suggests the entitlement check that the standalone CLI hits and the one the desktop host path hits are not resolving the same way for the same account. If that's right, the bug is in the CLI's entitlement lookup rather than in the account's actual entitlements — which would also explain why re-authenticating doesn't help and, per the reports above, sometimes makes it worse.

Not attempting /logout + /login, since #72027's reporter found that escalated the failure into OAuth errors. Happy to run any diagnostic that would help isolate the difference between the two auth paths.