Half a Million Lines, One Public Package: Lessons from the Anthropic Claude Leak
News reports describe how a source map file inside a public npm package may have exposed over half a million lines of Claude Code CLI source. Here is a plain-English look at what went wrong and what actually needs checking before you publish.
Half a Million Lines, One Public Package: Lessons from the Anthropic Claude Leak
Picture the message nobody wants on a Monday: something sensitive for Claude Code, Anthropic’s developer CLI, showed up where it should not have. Press coverage described on the order of 512,000 lines of proprietary source surfacing in connection with a public package, not because someone picked a lock, but because something ordinary in a build pipeline went out the door by mistake.
If you have ever cut a release under a deadline, that probably sounds familiar. Good people miss checks when the process does not catch the right thing at the right time.
A tiny file type, a big problem
Reports pointed to a source map (a .map file) bundled into a public npm package. In day-to-day work, source maps are helpful: they link the minified JavaScript users run back to the readable code your team wrote, which makes debugging sane. They belong in internal builds and staging. They do not belong in a package you expect strangers to download, because they can make it straightforward to reconstruct that readable source from what you thought was “just” compiled output.
The boring version of the story is often the true one: a bundler or release setting did not strip maps before publish, and the registry ended up hosting more than the team intended. Anyone pulling that package could end up with far more context than a public CLI normally implies—implementation details, work-in-progress behavior, internal wiring.
Public registries do not forget. Copies spread to mirrors and caches. If a file should never be public, the safest place to catch that is before publish—not only on someone’s laptop.
Scanning Git is not the same as checking what you ship
A lot of security tooling still lives where the code is written: the repo. It looks for patterns that resemble API keys and passwords. That still matters.
It does not replace looking at the tarball, image, or package your pipeline hands to npm or Docker Hub. This incident was less “someone committed a secret string” and more “the artifact we asked the world to install contained things we never meant to release.” If your last serious check is only against Git, you never answered the question of what actually left the building.
What we added at Puaro
We hear the same complaint in security reviews: tools that flood the channel with noise, or that pass the repo and miss the release. Our latest update adds what we call Build Artifact Reasoning: it looks at what your CI/CD is about to publish—npm packages, zip bundles, container layers—and flags when something in that bundle does not match what a safe public release should look like.
- It cares about meaning, not only text patterns, so a source map that effectively ships your source is treated differently from a normal asset.
- It can stop the publish step when the bundle would expose sensitive build output.
- Because it is focused on shipped artifacts, you get fewer “maybe” alerts and more signals tied to a real release decision.
What we would do next on a typical team
Use this as a prompt to walk your release path end to end: who can publish, what your bundler emits, whether maps and debug symbols are stripped for production, and whether anything runs against the built artifact before it goes public. Blaming one engineer rarely fixes that picture; tightening the path usually does.
If you want help catching that class of mistake before it ships, see what is new in Puaro Security at puaro.io.