Why Claude Code's Source Code Leaked — And It Wasn't Simple Human Error

TL;DR: Claude Code's source leak wasn't a developer slipping up during a release. It was a silent CI pipeline failure combined with an overly permissive cloud storage bucket — two independent mistakes that became catastrophic when they happened at the same time.

The root cause of this Claude Code source code leak is strikingly similar to the App Store web frontend leak from about five months ago, where the Svelte + TypeScript source was accidentally exposed.

For an engineering project of Claude Code's scale, a CI/CD pipeline is a given, with build configurations and scripts that are locked down and consistent. It's highly unlikely that an individual developer made a one-off mistake during this particular release.

So why wasn't the source map removed from the build artifacts?

Why Wasn't the Source Map Removed?

The answer lies in how production error monitoring works. If you're using a platform like Sentry to track runtime errors, you need source maps — there's no way around it. This means source maps are intentionally generated during the CI build, and the resulting artifacts will naturally include them.

The likely flow is this: after the source content is uploaded to a Cloudflare R2 bucket for Sentry to consume, a subsequent pipeline job should run a script to delete the source map files from the artifact directory. But this step probably failed silently, without blocking the rest of the pipeline. The artifacts, source maps included, were then published to the npm registry.

There are several mundane but realistic ways this silent failure could have happened:

• Wrong path in the rm command — the script targets a hardcoded path that no longer matches where the build actually outputs files
• Glob pattern didn't match — something like rm dist/*.map works fine locally but misses files in nested subdirectories; **/*.map requires globstar to be explicitly enabled in bash, and it's off by default
• CI environment path changed — a runner upgrade or a refactor of the build output directory silently shifted where artifacts land, causing the deletion script to operate on a path that no longer exists
• Shell behavior inconsistent across runners — the deletion step passes on one runner type but silently no-ops on another, depending on how the shell handles unmatched globs or missing paths

Any one of these is enough to cause the cleanup step to exit with code 0 while doing nothing — and without set -e in the script, the pipeline happily continues straight to npm publish.

Two Failures, One Catastrophe

Here's the thing though: even if the source maps were accidentally shipped to npm, it wouldn't necessarily be catastrophic — as long as the R2 bucket was properly locked down. Without the actual source file contents (sourcesContent), the .map file on npm is just a mapping table. You can't reconstruct readable source code from it alone.

That said, it's not entirely useless to a determined attacker. The .map file still exposes the full project directory structure and key symbol names, which makes it possible to reverse-engineer a meaningful portion of the codebase's logic — just with considerably more effort.

The real problem was that Anthropic's R2 bucket was completely public. Anyone who found the sourceMappingURL embedded in the published package could directly download the full source. Nothing was left to the imagination.

These were two independent failures that only became catastrophic in combination:

• Failure 1: The source map deletion step in the CI pipeline failed silently and didn't block the publish job
• Failure 2: The R2 bucket holding the source content was publicly accessible with no access control

Either one in isolation would have been harmless. Together, they exposed 512,000 lines of TypeScript to anyone paying attention.

Takeaway

This is also why Anthropic's official response — "this was a release packaging issue caused by human error" — feels like it's only telling half the story. The real question isn't who made a mistake. It's why the pipeline had no safeguard to catch it, and why a storage bucket containing proprietary source code was ever public-facing in the first place.

The faster you ship in the age of AI-accelerated development, the more engineering discipline actually matters.