Lessons from the Claude Code source leak: 5 npm settings to prevent bundling source maps

A source map incident that even Anthropic could blunder into

On April 7, 2026, InfoQ published an article titled "Anthropic Accidentally Exposes Claude Code Source via npm Source Map File." It revealed that version 2.1.88 of the Claude Code CLI, published by Anthropic to the npm registry, bundled TypeScript source map files (.js.map), which allowed the entire original TypeScript source code to be reconstructed by tracing them.

Claude Code is an AI coding agent used by developers worldwide, and its source code represents a vital source of competitive advantage for Anthropic. Having it unintentionally leaked carries significant repercussions.

Moreover, the root cause was neither an advanced zero-day exploit nor an insider threat; it was an inadvertent oversight in build configuration. In other words, this is an accident that could happen to any engineering team tomorrow. This article outlines five specific configuration checks to take away from the incident.

What is a source map in the first place?

The role of source maps

A source map is a file that maps minified and transpiled JavaScript back to the original TypeScript (or original JavaScript).

It is thanks to source maps that you can debug original TypeScript in browser DevTools instead of minified code. While they greatly enhance the developer experience, distributing them poses the hazard of exposing your original code completely.

What can be reconstructed from a source map?

A .js.map file typically embeds the full text of the original source code within its sourcesContent field. This means that obtaining just one .js.map allows you to reconstruct the corresponding TypeScript file in its entirety.

Incident chronology

What happened

According to reporting by InfoQ, the timeline of the incident unfolded as follows:

1. Anthropic published @anthropic/claude-code@2.1.88 to npm
2. The published package contained *.js.map files
3. Researchers unpacked the package and reconstructed the original TypeScript source from .js.map
4. Portions of the source code were posted on GitHub
5. Anthropic republished an immediate follow-up version excluding the source maps

Although remediated rapidly, the nature of npm is that once an artifact is published, it cannot be undone. Reconstructed versions were already in circulation.

Why was it missed?

This mishap occurred even within an organization possessing Anthropic's robust security culture. Likely contributing factors include:

• sourceMap: true was set as the default in the build configuration
• Map file exclusions were omitted in .npmignore
• They were not explicitly designated in the files field of package.json
• The CI pipeline lacked pre-publish diff checks
• Configurations were shared between release and development builds

In short, there is never just a single layer that needs checking.

Five-point checklist to prevent accidental source map bundling

1. Separate production builds in tsconfig.json

Separate your tsconfig for development and release, explicitly setting sourceMap and declarationMap to false for release.

// tsconfig.build.json（リリース用）
{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "sourceMap": false,
    "declarationMap": false,
    "inlineSourceMap": false,
    "inlineSources": false
  },
  "exclude": ["test", "**/*.test.ts"]
}

Explicitly specify this file in your build command.

npx tsc -p tsconfig.build.json

2. Use a whitelist approach with the files field in package.json

Rather than a blacklist approach with .npmignore, the ironclad rule is to use a whitelist approach via the files field in package.json.

{
  "name": "your-package",
  "files": [
    "dist/**/*.js",
    "dist/**/*.d.ts",
    "README.md",
    "LICENSE"
  ]
}

As long as *.js.map is not specified in the whitelist, it will not be bundled unless deliberately added.

3. Double-block with .npmignore

As an added safeguard, exclude map files in .npmignore as well.

# .npmignore
*.map
*.js.map
*.d.ts.map
src/
tsconfig*.json
*.test.ts

Creating a dual line of defense with both a whitelist and a blacklist ensures that defensive layers remain even if build tools change or configuration gaps occur.

4. Pre-publish dry run (npm pack)

Inspect the files actually included in the package immediately prior to release.

# ドライラン（実際には公開しない）
npm pack --dry-run

# tarball化して中身を確認
npm pack
tar -tzf your-package-1.0.0.tgz | grep -E '\.map$'
# 何も出力されなければOK

Incorporate this into your CI pipeline so that the build fails if any map files are detected.

# GitHub Actions例
- name: Check for source map files
  run: |
    npm pack --dry-run 2>&1 | grep -E '\.map$' && exit 1 || exit 0

5. Establish an automated npm publish pipeline

Manual npm publish executions are a hotbed for human error. Fully automate release workflows using GitHub Actions or similar tools, making the following steps mandatory:

1. Clean build using production tsconfig
2. Verify bundled files with npm pack --dry-run
3. Run test suites
4. Security scan (dependencies and secrets)
5. Tag creation → Automated publish

Incorporating AI reviews is also effective. By referencing practices like KAUCHE's automated merging with AI reviews and embedding AI from the security check phase, human error can be significantly curtailed.

Related security considerations

Connections to supply chain attacks

The security of npm distribution packages involves not only source code leaks, but also the risk of malicious code injection. Supply chain attacks targeting npm, PyPI, and RubyGems surged in 2026, as detailed in Supply Chain Attacks 2026.

Accidental distribution of secrets

Beyond source maps, files such as the following must also be strictly treated as items that must never be distributed:

Using a whitelist approach with package.json naturally excludes these as well.

Conclusion

Anthropic's Claude Code source map leak serves as an instructive case study demonstrating that regardless of how security-conscious an organization is, overlooking a single build configuration can result in a major incident.

There are five key pillars of defense:

1. Separate production builds in tsconfig.json and explicitly configure sourceMap: false
2. Whitelist via the files field in package.json
3. Double-block *.map using .npmignore
4. Pre-publish dry run using npm pack --dry-run
5. Fully automated pipelines via GitHub Actions or equivalent

Each of these configurations can be implemented in minutes to a few hours, but it is layering all of them together that halts incidents. We recommend treating Anthropic's mishap as a valuable lesson and auditing your own repositories' configurations today.

For broader security reflections on AI coding, please also consult the Web Security Fundamentals Guide.

---

References

• Anthropic Accidentally Exposes Claude Code Source via npm Source Map File — InfoQ
• npm Documentation — files field
• TypeScript Compiler Options — sourceMap