Claude Code (2026)¶

The Lesson: Your build pipeline publishes what you tell it to publish. If you don't explicitly exclude debug artifacts, they ship.

What Happened¶

On March 31, 2026, security researcher Chaofan Shou noticed something unusual in the npm package for Anthropic's Claude Code CLI tool: a 59.8 MB JavaScript source map file sitting right there in the published package.¹ Source maps exist to help debuggers translate minified production code back to the original source — they're standard tooling for development. They are emphatically not supposed to ship to production registries.

The source map in version 0.2.88 of @anthropic-ai/claude-code didn't just contain vague mappings. It pointed to a publicly accessible zip archive on Anthropic's own Cloudflare R2 storage bucket, which contained the complete original TypeScript source — 1,906 files, 512,000+ lines of code.²

Within hours, the codebase was mirrored across GitHub, analyzed in blog posts, and dissected by thousands of developers. Anthropic's DMCA takedown requests arrived, but the internet had already moved on. The repository mirrors had accumulated over 84,000 stars before GitHub pulled them down.³

The Mistake¶

Claude Code is built with Bun, a JavaScript runtime and bundler. Bun generates source maps by default. Unless you explicitly pass --sourcemap=none or configure it off, every build produces a .map file alongside your minified output.

The rest was a packaging oversight:

• No --sourcemap=none flag in the production build step
• No .npmignore entry for *.map files
• No files field in package.json restricting what gets published
• No CI check validating package contents before npm publish

Any one of these would have prevented the leak. None were in place.

This isn't exotic. It's the kind of configuration gap that exists in thousands of projects right now — the difference is that most of those projects aren't shipping proprietary source code for a billion-dollar AI company's flagship developer tool.

What Was Exposed¶

The leaked source revealed the full architecture of Claude Code:

• System prompts and persona logic — the instructions that shape how the AI behaves
• Permission schemas — how the tool decides what it can and can't do on your filesystem
• Tool execution logic — how it runs commands, edits files, and manages sessions
• Telemetry and feature flags — what data is collected and which features were being tested
• Unreleased features — including references to autonomous agent modes not yet publicly announced⁴

For Anthropic, this was a competitive intelligence disaster. For the broader ecosystem, it was an object lesson in what "publishing a package" actually means.

Why It Mattered¶

Build defaults are not deployment defaults. Bun's choice to generate source maps by default is reasonable for development. But defaults that make sense during development can be dangerous in production. Every tool in your build chain has defaults. Do you know what they are?

npm publishes everything unless told otherwise. Unlike Docker (where you explicitly COPY files into images) or Go (where binaries are self-contained), npm's default is to include everything in your project directory that isn't in .npmignore or .gitignore. If your build step produces extra files, they go into the package. This is documented behavior — and it bites people constantly.

Source maps are a known risk. This wasn't a novel attack vector. Security teams have flagged source map leaks for years. Browser DevTools will happily fetch external source maps and reconstruct original code. The npm ecosystem has published guides about excluding them. The knowledge existed. The process didn't enforce it.

There is no "unpublish" on the internet. Anthropic pulled the package version. GitHub took down mirrors. But the code was already forked, downloaded, archived, and cached by hundreds of mirrors and individual users. Once data is public, it's public permanently. Your response plan needs to assume this.

The Broader Pattern¶

Anthropic is not a small team. They have security engineers, release processes, and code review. If a 59.8 MB debug artifact can slip past their pipeline, it can slip past yours.

The fix is straightforward — but only if someone thinks to implement it:

• Audit your bundler's defaults — know what files your build tools produce
• Use a files allowlist in package.json instead of relying on .npmignore blacklists — it's safer to say "only include these" than "exclude everything except these"
• Run npm pack --dry-run before publishing to see exactly what will be in the package
• Add a CI check that fails if unexpected file types appear in the package
• Treat package publishing as a build pipeline security boundary, not just a deployment step

Timeline¶