Home
AI
Blog

Claude Code Got Leaked: What Happened (and Why It Matters)

basanta sapkota

If you’ve ever shipped a JavaScript bundle and thought, “Meh, the .map file is harmless,” well… this week delivered a pretty brutal reality check.

Claude Code got leaked because a sourcemap slipped into a public npm release. People grabbed it and used it to rebuild the underlying source into something readable. Not “mystical hacking.” Just an oops file sitting in the open.

On March 31, 2026, multiple reports said Anthropic’s Claude Code CLI was accidentally published with a large sourcemap file named cli.js.map in Claude Code version 2.1.88. That map reportedly allowed reconstruction of roughly ~1,900 files and ~500k–512k lines of code. Anthropic also stated the release included “some internal source code” and that no sensitive customer data or credentials were exposed. They described it as a packaging issue caused by human error, not a breach. Same outcome for the code, very different meaning for the security story.

Key takeaways

  • Claude Code got leaked via a sourcemap shipped in an npm package, cli.js.map, reported around ~60MB. And sourcemaps can carry the original sources.
  • If a sourcemap includes sourcesContent, people can reconstruct readable source code even when the shipped JS is minified.
  • Anthropic says no customer data or credentials were exposed. Their line is release packaging mistake, not compromise.
  • Treat build artifacts like production data. Review what lands on npm, lock down .map files, and add CI checks so this doesn’t happen on a Friday night.
  • If you’re a user, assume behavioral details might become public. But don’t jump straight to “this means account takeover.”

What happened when Claude Code got leaked

Here’s the cleanest version of events based on reporting and community posts, without the extra noise.

  • March 31, 2026: Reddit threads reported Claude Code got leaked because a .map file was visible in the npm registry package.
  • News coverage, including BleepingComputer and Yahoo/Decrypt syndication, said Claude Code v2.1.88 briefly shipped with a large cli.js.map reported around ~60MB.
  • That same coverage said researchers/users could reconstruct large parts of the codebase, commonly cited as ~500k–512k lines across ~1,900 files.
  • Anthropic’s statement said the release included internal source code, no sensitive customer data or credentials, and it was a packaging issue.

Some articles mention “hidden flags” and internal features found in the code. Could be true. But treat it like secondary analysis, not official docs.

How sourcemaps cause leaks

A sourcemap is basically JSON that connects transformed code, bundled and minified, back to the original files. They’re fantastic when you’re debugging.And’re also a classic footgun.

The nasty surprise is an optional field called sourcesContent. When it’s there, the sourcemap can contain the full text of the original source files, not just filenames or paths. The Sentry security team calls out sourcesContent as “optional and potentially risky” because it can leak proprietary code and internal logic when it’s publicly exposed.

If you want the official references.

So when Claude Code got leaked, the story wasn’t “someone broke in.” It was more like leaving your spare key under the doormat, then acting surprised somebody tried it.

Why “not a breach” can still be a big deal

Even if no credentials were exposed, source leakage still bites. Hard.

  • Attack surface mapping gets way easier. Internal endpoints, feature flags, permission logic, assumptions people made at 2 a.m., it’s all right there.
  • Abuse acceleration is real. Attackers don’t have to reverse engineer. They can just read.
  • Trust and compliance pain follows quickly. Customers ask the obvious question: how did this make it into the release artifact?
  • IP exposure is still exposure. Workflows and implementation details can be copied.

And yeah, developers will rummage through it for architecture ideas. Hacker News chatter was already in the “I want to see the workflows/testing pipeline” lane. Very dev-brained. Also exactly why teams don’t publish this stuff casually.

If you publish npm packages: preventing “Claude Code got leaked” style accidents

In my experience, the fix is almost never one magic config switch. It’s layers.So’s boring. It works.

1) Check what you’re about to ship, before you ship it

Run npm pack and inspect the tarball the same way npm will see it:

npm pack --json
tar -tf *.tgz | sed -n '1,200p'
tar -tf *.And | grep -E '\.map$' || true

If you spot cli.js.map or any .Still file in a public CLI/tooling package, stop. Take a breath. Ask yourself if you really want it public.

2) Use files allowlists and/or .npmignore

npm lets you control what gets published using the files array in package.json, and you can exclude things with .npmignore. The official docs explain how packaging works and how files interacts with ignore files:
https://docs.npmjs.com/cli/v10/configuring-npm/package-json

A simple approach looks like:

{
  "files": [
    "dist/",
    "bin/",
    "README.md",
    "LICENSE"
  ]
}

And then in .npmignore:

**/*.map
src/
test/

3) Configure sourcemaps on purpose

Webpack has multiple devtool modes, including ones that generate maps without embedding source content, like nosources-*. That can keep some debugging value while shrinking the blast radius if a map leaks.

Example, and yeah, you should test it in your stack:

// webpack.config.js
export default {
  // For production: consider no source content in the map
  devtool: 'hidden-nosources-source-map'
};

One quick reality check though. “Hidden” doesn’t save you if you still publish the .map file to a public registry.

4) Add a CI tripwire

I’m a fan of dumb safeguards. The kind you’ll thank later.

Fail the build if .map files show up in what you’re about to publish:

# in CI, after build
if find dist -name "*.map" -maxdepth 5 | grep -q .; then
  echo "Refusing to publish: sourcemaps detected in dist/"
  exit 1
fi

Not glamorous. Very effective. Cheap insurance.

If you’re a user: what to do after “Claude Code got leaked”

If you installed Claude Code around the reported version/timeframe, here’s what i’d do.

  1. Update immediately to a fixed version, once available.
  2. Review your environment for local customization that depends on internal behavior, because internals often change fast after an incident like this.
  3. Don’t mirror or redistribute leaked code. Even if it’s “out there,” it’s still someone else’s copyrighted work.

Also, don’t panic-rotate everything just because code leaked. Anthropic explicitly said no customer data or credentials were exposed in this incident. Stay alert for follow-up changes, especially around authentication flows and permissions.

Claude Code got leaked, but the real lesson is bigger than Claude

The headline is spicy, sure. Claude Code got leaked. People will click. People will gawk.

But the deeper lesson is the one software teams keep relearning the hard way: release pipelines leak whatever we forget to treat as sensitive. Sourcemaps, debug logs, test fixtures, internal flags. “Just files.” Until they aren’t.

If you maintain npm packages, tighten your allowlists, add CI checks, and get serious about sourcemaps today.Yet you’re a user, update and move on, then keep an eye on vendor postmortems.Now you want to keep reading in this space, pair this with our internal post on agent tooling: Top 10 agentic coding tools in 2026. And if you’ve ever had a near-miss with .map files… honestly, i’d love to hear the story. What saved you? Or what didn’t?

Sources

Post a Comment