The message means your Claude Code client authenticated with a Claude subscription (Pro or Max), but an organization-level policy now blocks that path, so you have two fixes: switch Claude Code to an Anthropic API key with its own pay-as-you-go billing, or ask your workspace admin to re-enable subscription access for Claude Code. The first option gets you working in minutes but bills per token. The second preserves your flat subscription but depends on someone else's decision.
The error is a policy statement, not a bug. Claude Code supports two authentication routes: a consumer subscription login (OAuth) and a direct Anthropic API key. Organizations that manage Claude accounts, particularly through Claude for Work (formerly Team and Enterprise plans), can govern which routes members may use. When an admin disables subscription access for Claude Code, the OAuth route closes for managed members while the API-key route typically remains available, because API keys are billed and governed separately. This explainer covers the mechanism behind that split, when each fix applies, the cost and permission tradeoffs, and the edge cases that make the "obvious" fix wrong.
The authentication split inside Claude Code
Claude Code is a command-line agent that sends your prompts, file context, and tool results to Anthropic's models and executes the returned actions locally. Every request must carry credentials, and Anthropic supports two credential types with different governance.
Subscription credentials are tied to a person. A Pro or Max plan grants a usage allowance under fair-use limits, and Claude Code draws on that allowance when you log in through the browser OAuth flow. The organization that owns the account, if any, controls whether the subscription credential is accepted for programmatic tools like Claude Code.
API keys are tied to a workspace. Each key belongs to an Anthropic Console organization and bills to that organization's credit balance. Keys carry scopes, can be rotated or revoked centrally, and appear in audit logs. Many enterprises prefer them for exactly this reason: usage is metered, attributable, and revocable.
The disabled-access message fires at the intersection: you are authenticated as a member of an organization, and that organization's policy says subscription credentials may not be used for Claude Code. The client is working correctly. It is telling you the door you knocked on is locked by policy, and pointing at the other door.
One subtlety explains most confusion. The setting lives on the organization, not on your machine. Reinstalling Claude Code, clearing credentials, or logging out and back in will not change it. Neither will switching networks. The policy follows the account.
Why organizations disable subscription access in the first place
Admins rarely disable the subscription route to be obstructive. Three governance motives recur, and each maps to a real risk.
First, spend control. Subscription allowances are shared across chat, Claude Code, and other surfaces under fair-use rules. An agentic coding tool can consume far more model traffic per hour than interactive chat, and a heavy engineering team can exhaust a team-wide allowance in ways that are hard to attribute to individuals. An API key converts that shared, opaque consumption into per-key metering.
Second, visibility. API usage lands in Console billing and usage reports broken out by key and workspace. Subscription usage under a managed plan is visible too, but at coarser granularity. Security teams that need per-developer or per-project attribution often mandate keys.
Third, data governance. Some organizations configure API traffic to flow through their own gateways or proxies for logging and loss prevention. That architecture requires key-based authentication with a configurable base URL, which the subscription OAuth path does not offer in the same way.
The counterintuitive part: in many organizations the API-key route is not just tolerated but preferred, and the "disabled" message is really a redirect. You may be complying with policy by switching, not working around it. Check before assuming otherwise, because some admins disable subscription access and expect developers to use keys provisioned through a central process.
The two fixes, compared honestly
Both fixes restore access. They differ in billing model, latency to unblock, control, and what happens when limits hit.
| Dimension | Anthropic API key | Admin re-enables subscription access |
|---|---|---|
| Billing model | Pay-as-you-go per token, billed to the key's organization | Flat subscription fee under fair-use allowance |
| Time to unblock | Minutes, if you can create or receive a key | Depends on admin response and change process |
| Who controls usage | You or your platform team, via key scopes and budgets | The organization, via plan-level policy |
| Usage visibility | Per-key Console usage and billing reports | Plan-level reporting, coarser attribution |
| Hard limits | Credit balance and any configured spend limits | Subscription allowance under fair-use rules |
| Revocation | Key can be revoked centrally, instantly | Policy can be re-disabled at any time |
| Best fit | Individual developers, teams with Console access, audited environments | Members who cannot obtain keys, or orgs that prefer flat cost |
Two practical caveats sit under the table. An API key is a bearer credential: anyone who obtains it can spend against its organization until it is revoked. Store it in an environment variable or secret manager, never in a repository, and rotate it on any suspicion of exposure. And subscription access, even when re-enabled, can be re-disabled by the same policy engine, so treat it as revocable at any time.
If neither route is open to you, a third exists in principle: an organization may provision keys through a central platform team or gateway, and you request one the same way you request any other credential. That is still "use an API key," just with a procurement step attached.
Setting up an API key correctly
The mechanics are simple, and most failures come from skipping one of four steps.
Create or obtain a key. If you have Console access to your organization, create a key scoped to your work and, where supported, set a spend limit. If you do not, request a key through your normal access process and state that it is for Claude Code. Do not create a personal key under an unrelated organization to route around a disabled policy; that is the one version of this fix that can get you in real trouble.
Store it as an environment variable rather than typing it into commands that land in shell history. Claude Code reads the key from the environment, so the credential never appears in your prompt or in process arguments. Give the variable a name only you and your tooling know.
Set it in the shell profile or session for the account you actually run Claude Code under. A key exported in one terminal does not exist in another, and IDE-integrated terminals inherit a different environment than your login shell. This single mismatch accounts for a large share of "I set the key and it still fails" reports.
Verify and then remove the old credential path. Confirm Claude Code authenticates with the key, then log out of the subscription account if the client still prefers it. Two credentials present at once can produce confusing selection behavior. If your organization routes API traffic through a gateway, set the base URL at the same time; a key pointed at the default endpoint will fail in a proxied environment.
Red flags to stop and escalate on: A key pasted into a chat message, ticket, or commit, even "temporarily." A key created under a personal account to bypass a managed-organization policy. A shared key distributed to a whole team with no rotation plan. An unexpected billing spike after switching, before spend limits are set. Instructions to disable logging or proxies that your security team requires.
When the admin route is the right call, and when it is not
Asking your admin is the correct fix when you cannot obtain a key, when your organization explicitly funds Claude Code only through subscriptions, or when policy requires that agentic usage stay inside the managed plan for audit reasons. It is also right when the disablement was accidental, for example a policy rolled out broadly that unintentionally caught engineering.
Write the request so it can be approved without a meeting. State what you use Claude Code for, that the client is authenticated with your subscription, the exact message you receive, and the specific setting you are asking to change: subscription access for Claude Code for your account or group. Admins respond faster to a named setting than to "Claude Code is broken."
Know the limits of this route. An approval today does not bind tomorrow, and a group-level exception is better than a personal one because it survives personnel changes. If your admin declines, ask which route they prefer: a key you create, a key they provision, or a gateway. The decline is usually about the route, not about you using the tool.
Limits, costs, and what neither fix solves
Neither fix is free of constraints, and the constraints differ.
API billing is usage-based, and agentic coding is token-hungry: long file contents, repeated tool calls, and multi-step reasoning all consume tokens per request. Costs scale with how much context you feed the agent and how many steps tasks take, so heavy sessions cost more than light ones by design. Set a spend limit before your first long session, and check usage after a week to calibrate. The article cannot quote current per-token prices because they change; check Anthropic's pricing page for current figures.
The subscription route, when enabled, is bounded by fair-use allowances rather than a per-token invoice. That makes cost predictable but capacity less so: heavy agentic use can hit allowance limits that interrupt work mid-task.
Both routes share a dependency you cannot fix locally: availability of the model service itself. Rate limiting, regional availability, and model deprecations apply regardless of credential type. And neither route changes what Claude Code can do on your machine; permissions for file writes and command execution are a separate configuration layer.
The honest limitation of this entire explainer: policy names, setting locations, and client behavior change as Anthropic ships updates. The mechanism, a policy gate on the subscription route with a metered key route alongside it, is stable. The exact menus are not. When the message text differs from the one quoted here, treat it as the same class of problem and check the current Claude Code documentation for the authentication options your version supports.
If this error appeared alongside unexpected charges, credential prompts you did not initiate, or a key you did not create, treat it as a security event: revoke keys, rotate credentials, and involve your security team before changing any configuration.
This article is general educational information about authentication and billing configuration, not a security audit, contractual interpretation, or financial recommendation. It does not promise that either fix will restore access in your environment, and organizational policies override any suggestion here. For decisions about credentials, spend, or policy compliance, consult your organization's IT, security, or legal professionals; for suspected credential compromise, contact your security team immediately.