Claude Code Source Leak: Ban Risk, Current Models, and Account Logic Explained (2026)

Claude Code really had a source-code exposure in March 2026. Anthropic says it was a release-packaging mistake, not a breach, and that no customer data or credentials were exposed. The useful question now is not how many hidden strings people found in mirrors and screenshots. The useful question is what Anthropic's public docs still say about bans, current models, and account paths. As of April 1, 2026, those public docs still point users to policy-based suspensions, Sonnet 4.6 and Opus 4.6 at the top of the Claude Code stack, and a clean split between Claude subscriptions, Console accounts, and API-key billing.

“

Evidence note: this guide is based on Anthropic's official help-center, pricing, release-note, and policy pages checked on April 1, 2026, plus Axios' March 31 report, Fortune's March 26 report, and a direct inspection of the currently published @anthropic-ai/claude-code 2.1.89 npm tarball.

TL;DR

• Yes, the Claude Code source-code exposure was real. Axios quoted Anthropic saying an earlier release included internal source code because of a packaging mistake.
• Anthropic also told Axios that no sensitive customer data or credentials were exposed in that incident.
• Anthropic's public Safeguards Warnings and Appeals page says accounts may be banned for repeated Usage Policy violations, unsupported-location signups, or Terms violations. It does not document reading the leak as a standalone ban reason.
• The March 26 Fortune story and the March 31 Axios story are related only in timing. One was an unsecured-data-store exposure with unreleased materials; the later one was a Claude Code release-packaging mistake.
• The current public Claude Code model reality is Sonnet 4.6 and Opus 4.6 at the top end. Anthropic's current model-configuration page still lists some 4.5 models as configurable, but Opus 4 and 4.1 were removed from Claude and Claude Code on January 16, 2026.
• Claude and Console accounts can use the same email address and still operate independently. Inside Claude Code, ANTHROPIC_API_KEY takes priority over your subscription login for billing.

What actually leaked on March 31, and what did not

The first thing to fix is incident sprawl. Late March produced two separate Anthropic-adjacent stories, and the internet quickly blended them into one giant everything leaked narrative.

On March 26, Fortune reported that Anthropic appeared to have left internal materials in a publicly accessible data store. That report focused on unreleased-model details, internal event materials, and other not-yet-public assets. Anthropic acknowledged to Fortune that it was testing a stronger model with early-access customers, but that story was primarily about a broader internal-materials exposure.

On March 31, Axios reported a narrower but more developer-relevant incident: Anthropic told Axios that an earlier Claude Code release included internal source code. Anthropic's quoted statement matters because it narrows the claim in two directions at once. First, it confirms there really was internal-source exposure, so this was not just social-media exaggeration. Second, it says the issue was a release-packaging mistake rather than a breach, and that no sensitive customer data or credentials were exposed.

That distinction is what most panic threads miss. Internal source code was exposed is a serious statement. It is not the same thing as customer data leaked, model weights leaked, or live user keys leaked. If you flatten those into one phrase like Anthropic got hacked and everything spilled, you stop helping the reader and start repeating the least precise version of the story.

There is another practical detail most summaries skip: the currently published npm artifact is not automatically the same thing as the originally bad publish. I checked the current @anthropic-ai/claude-code 2.1.89 package directly on April 1, 2026. The tarball now ships as a single bundled cli.js, without a bundled .map file in the package listing and without a sourceMappingURL= footer in the current cli.js. That does not erase the earlier exposure. It does mean the best April 1 operator guidance is not the live npm package is still shipping an obvious full source map. The better guidance is a real exposure happened, but current users should distinguish the one-off bad publish from the package state they are pulling now.

The cleanest way to hold the incident in your head is this:

• Confirmed by Anthropic to Axios: internal Claude Code source was accidentally included in a release; no customer data or credentials were exposed.
• Confirmed by current package inspection: the currently served npm tarball no longer has the simplest obvious source map still attached shape.
• Still not a public product contract: any roadmap conclusions people drew from mirrors, hidden feature names, or internal flags.

If you stop here, you already have a better operational picture than most of the web. The leak is real. The scope of what Anthropic publicly confirmed is narrower than the headlines. And the current live package state matters more to a normal user than the most dramatic archived artifact somebody screenshotted yesterday.

Does Anthropic ban accounts over this? What the public policy actually says

This is where rumor and policy diverge most sharply.

Anthropic's public Safeguards Warnings and Appeals article says accounts may be banned for three broad reasons: repeated Usage Policy violations, account creation from an unsupported location, and Terms of Service violations. The same article also says Anthropic may issue warnings before bans in some cases, and it provides a public appeal path for accounts that were wrongly suspended or terminated.

That article is important precisely because of what it does and does not say. It gives you a published enforcement surface. It does not say opening a mirror, reading a report, or seeing leaked code discussed on GitHub is by itself a suspension trigger. So the most defensible public answer today is narrow: Anthropic has documented policy-based suspension reasons, but it has not publicly documented reading the leak as a standalone ban reason.

That does not mean every behavior around exposed materials is risk-free. Anthropic's Responsible Disclosure Policy asks good-faith researchers to avoid exfiltrating, downloading, or retaining data they encounter, to avoid disclosing vulnerability details publicly before coordination, and to avoid exploiting a vulnerability beyond what is minimally necessary to prove it exists. That policy is written for security research, not for normal Claude end users, but it does tell you something about how Anthropic frames acceptable behavior when exposed internal systems are involved.

Inference from those sources: Anthropic's public docs do not support the viral claim that merely reading about the leak or being aware of it gets an ordinary user banned. But if your behavior looks less like I saw a news story and more like I retained exposed internal assets, exploited a live weakness, or used leaked materials in ways that cross policy or terms lines, you are obviously closer to the kinds of conduct Anthropic's public policies are designed to govern.

That narrower framing is more useful than both extremes. You are definitely safe no matter what is overconfident. Anthropic is banning everyone who looked at the repo is unsupported. The public evidence supports a middle answer: policy and terms still matter, warnings and appeals exist, and Anthropic has not publicly documented a simple guilt-by-exposure ban rule.

If you are a normal Claude Code user, the practical takeaway is boring but correct:

• base your risk model on Anthropic's published usage and terms pages, not rumor screenshots
• do not treat exposed internal artifacts as a sanctioned operating surface
• if you were suspended and think it was an error, use the published appeal path instead of assuming social media knows more than the help center

What the current Claude Code model lineup actually is

The leak discussion also caused a lot of stale model talk to resurface. That matters because people start making purchase or migration decisions from whatever model names showed up in leak screenshots instead of checking the current supported-model page.

Anthropic's current Claude Code model configuration article lists these supported models:

• Sonnet 4.6: claude-sonnet-4-6
• Opus 4.6: claude-opus-4-6
• Opus 4.5: claude-opus-4-5-20251101
• Haiku 4.5: claude-haiku-4-5-20251001
• Sonnet 4.5: claude-sonnet-4-5-20250929

That list matters for two reasons. First, it shows that the current public top-end Claude Code reality is Sonnet 4.6 and Opus 4.6. Second, it shows that not every older 4.5 model vanished, so latest and still configurable are not the same thing.

Anthropic's release notes make the timeline clearer:

• January 16, 2026: Opus 4 and 4.1 were removed from Claude and Claude Code
• February 5, 2026: Claude Opus 4.6 launched
• February 17, 2026: Claude Sonnet 4.6 launched

So if a thread is still speaking as if Opus 4 or 4.1 is the current normal Claude Code flagship, it is outdated. If a thread treats leak-derived model names as if they replaced the public lineup overnight, it is also outdated.

There are two extra model details worth surfacing because they change real usage decisions.

The first is access. The same model-configuration page says Pro users can use Opus in Claude Code only after enabling and purchasing extra usage. That is a much more important fact for most readers than any roadmap speculation, because it directly affects whether Opus 4.6 is actually available to them under the contract they are already paying for. If you want the full plan breakdown, our Claude Code Pro vs Max guide goes deeper on shared limits and when Opus-heavy work is worth paying for.

The second is long context. Anthropic's Claude Code FAQ now says 1M context is included in Claude Code for Max, Team, and Enterprise users with Opus 4.6. That is another example of why current public docs matter more than leak chatter. The practical public decision is already hard enough: which supported model do you have access to, under which plan, with what billing behavior? You do not need a speculative future model name to make that decision correctly.

The shortest accurate model summary today is this:

• Use Sonnet 4.6 as the current public Claude Code default if you want the mainline current model.
• Use Opus 4.6 when you need Anthropic's current public top-end reasoning path and your plan or billing setup supports it.
• Treat 4.5 models as older still-supported options, not as the current frontier headline.
• Treat leak-discovered names as roadmap noise until Anthropic publishes them in current docs, release notes, or pricing.

How Claude account, Console account, and API-key auth actually work

This is the most practically important part of the article, because it is where many users accidentally confuse identity with billing.

Anthropic's help-center answer to Can I have a Claude account and a Console account? is short and extremely clear: yes, you can have both with the same email address, and they operate independently. That single sentence resolves a huge amount of confusion.

A Claude account is your consumer or work-product surface: Free, Pro, Max, Team, or Enterprise access to Claude. A Console account is the API side: the organization you use for API billing, keys, rate limits, and developer-oriented controls. The same human can sit behind both. That does not make them one billing system.

Anthropic's Using Claude Code with your Pro or Max plan article makes the consumer-plan side explicit. If you log into Claude Code with the same credentials you use for Claude, you can use the terminal tool with that subscription. The article also says Claude and Claude Code share the same usage pool under that subscription. That means your web/app usage and Claude Code usage are not isolated buckets.

The biggest gotcha comes from the environment-variable article. Anthropic says Claude Code prioritizes environment-variable API keys over authenticated subscriptions. If ANTHROPIC_API_KEY is set, Claude Code will bill through the API account associated with that key even if you are also logged in with a Claude subscription or a different Console account. That is one of the most useful operational facts in the whole Claude Code help center, because it explains a large class of Why am I being charged API rates? confusion.

Here is the clean mental model:

There are two more account-path details advanced users often need.

First, the Pro/Max help article says that if you are already logged into Claude Code via Claude Console pay-as-you-go, you can run /login to switch to your subscription plan. That is not a tiny UI trick. It is the official way to move between the two systems cleanly instead of guessing which identity is active.

Second, Anthropic's Claude Code FAQ explains some organization-level logic that rumor threads often reinvent badly. It says Console users can add people to a Console organization with a Claude Code User or Developer role, and that users then run /login and choose the intended Console account. The FAQ also says that if you see an error like Claude Max or Pro is required to connect to Claude Code while you believe you should have Team or Enterprise access, you may simply have selected the wrong login path during setup.

This is why internal account logic is the wrong mystery to obsess over. The public account logic is already enough to prevent most mistakes:

• one email can back separate Claude and Console accounts
• plan usage and API billing are different systems
• ANTHROPIC_API_KEY beats subscription auth for billing
• /status and /login are your friends

If what you actually need is stable API behavior for production workloads, treat that as an API problem, not as a Claude subscription loophole. Use a normal API contract, whether directly through Anthropic's Console or another supported provider path, instead of trying to bend a consumer subscription workflow into something it was not designed to be.

What leak-derived internals should not change your decisions yet

This is where it helps to separate interesting from actionable.

Yes, bundle inspection and leak coverage can reveal useful signals. Even the current bundled Claude Code package still surfaces strings that reflect real public flows, such as --console, --claudeai, /login, setup-token, and --enable-auto-mode. Some of those are already documented. Some are lightly exposed. Some sit closer to internal plumbing than polished public documentation.

But a real string in a bundle is not the same thing as a current user entitlement, a current pricing contract, or a current rollout promise. The best example is Auto mode. You can find mode-related strings in code or changelog notes, but whether Auto mode is actually available to you is still determined by Anthropic's public documentation about plan, model, admin enablement, and surface support. If you want the deeper permission-mode breakdown, our Claude Code Auto mode guide covers the current public contract in detail.

The same rule should govern how you read every leak-derived feature rumor:

• If Anthropic has documented it in current help-center, product, release-note, or pricing pages, you can act on it.
• If the only evidence is a leaked label, feature flag, or mirror screenshot, treat it as roadmap smoke, not as a contract.
• If the leaked detail conflicts with the current help center, the help center wins until Anthropic publishes a change.

That is not a timid stance. It is the only stance that keeps operators from buying the wrong plan, choosing the wrong login path, or telling their team a feature exists when it is still only a string in a leaked artifact.

What to do now

If you are a normal Claude Code user, the right next step is not to memorize leak trivia. It is to normalize your own setup:

1. Update Claude Code and stop assuming the live npm package still matches the originally bad publish.
2. Run /status and check whether you are on subscription auth or API-key auth.
3. If you meant to use plan usage, make sure ANTHROPIC_API_KEY is not silently overriding billing.
4. Choose current public models from Anthropic's supported-model list, not from social posts.

If you are worried about suspension risk, anchor yourself to Anthropic's published rules. The public docs support a policy-based view of enforcement, not a rumor-based one. If you believe your account was wrongly disabled, Anthropic publishes an appeal path for exactly that case.

If you are a team lead or admin, the biggest value of this incident is not that it revealed exciting hidden features. The value is that it exposed how much confusion your users already have about model availability, login paths, and billing precedence. Fix those first. Make sure people know whether they should be logging into Claude plans or Console orgs, and make sure they understand that API keys override subscription billing inside Claude Code.

And if you are a researcher or power user reading leak mirrors for technical interest, keep the category boundaries straight. There is a big difference between understanding a reported exposure, using Anthropic's published products correctly, and treating exposed internal artifacts as if they were a public development surface. The first is ordinary. The second is necessary. The third is where people start talking themselves into avoidable trouble.

The most useful conclusion is also the least dramatic one: the leak is real, but the current public Claude Code contract is still much simpler than the rumor stream. Anthropic's help center already tells you the current supported models, the official account split, the billing precedence, and the published suspension surface. Start there, and most of the panic evaporates.