How to Prevent Source Map Files from Leaking Your TypeScript/JavaScript Source Code

Apr 1, 2026

The Problem

On March 31, 2026, Anthropic accidentally exposed Claude Code’s entire source code through a single .map file. Anyone could download a 57MB cli.js.map file and reconstruct 1,906 TypeScript/TSX source files containing:

System prompts and agent instructions
Tool implementations and internal APIs
Architecture decisions and business logic
512,000+ lines of code

No hacking required. The file was publicly accessible. I checked the structure of source map files and realized this could happen to any project using TypeScript or JavaScript with sourcemaps.

What Happened?

Source map files (.map) are generated during the build process. They map minified/compiled JavaScript back to original source code for debugging. Here’s what they contain:

{
  "version": 3,
  "sources": [
    "../src/cli.ts",
    "../src/agent.ts",
    "../src/tools.ts"
  ],
  "sourcesContent": [
    "import { Agent } from './agent';\n// Full original source code here...",
    "export class Agent {\n  // Complete TypeScript source...",
    "// Tool implementations..."
  ],
  "mappings": "AAAA..."
}

The sourcesContent array contains your complete original source code. If this file ends up in production, anyone can download it and read everything.

I created a simple test project to verify this:

dist/
  bundle.js        (minified, safe)
  bundle.js.map    (contains ALL source code)
src/
  index.ts         (original TypeScript)
  utils.ts         (original TypeScript)

After building with default settings, the .map file contained all my TypeScript source in sourcesContent. I downloaded it and reconstructed the entire project.

How Source Maps Leak Code

The leak happens in three common scenarios:

Scenario 1: Copying development config to production

module.exports = {
  mode: 'production',
  devtool: 'source-map',  // Generates .map files with full source!
  // ... rest of config
};

Scenario 2: Forgetting environment-specific settings

export default defineConfig({
  build: {
    sourcemap: true,  // Always generates .map files!
  },
});

Scenario 3: Including .map files in npm packages

{
  "files": [
    "dist",
    "dist/**/*.map"  // .map files get published!
  ]
}

In all cases, the .map files end up in production or public packages. Anyone with access can extract the source code.

The Solution

I tested three approaches to prevent source map leaks:

Option 1: Disable Source Maps in Production

The simplest solution is to disable sourcemaps entirely for production builds:

export default defineConfig(({ mode }) => ({
  build: {
    sourcemap: mode === 'development',  // Only in dev
  },
}));

module.exports = (env) => ({
  mode: env.production ? 'production' : 'development',
  devtool: env.production ? false : 'source-map',
});

Pros: Zero risk of source leak Cons: No stack trace mapping in production errors

Option 2: Hidden Source Maps

Hidden sourcemaps generate the .map file but remove the URL comment from the bundle. The bundle doesn’t reference the map file:

export default defineConfig({
  build: {
    sourcemap: 'hidden',  // Generates .map but removes URL
  },
});

module.exports = {
  mode: 'production',
  devtool: 'hidden-nosources-source-map',  // No sources in bundle
};

The generated bundle ends like this:

// No sourceMappingURL comment!
// The bundle has no reference to the .map file

Pros: Stack traces work with uploaded sourcemaps (Sentry, Bugsnag) Cons: Must securely upload .map files to error tracking service

Option 3: No Sources Source Maps

Webpack can generate sourcemaps without source content. They map line numbers but don’t include code:

module.exports = {
  mode: 'production',
  devtool: 'nosources-source-map',  // Maps lines, no source content
};

The generated .map file has empty sourcesContent:

{
  "sources": ["../src/index.ts"],
  "sourcesContent": [],  // Empty! No source code exposed
  "mappings": "..."
}

Pros: Stack trace line numbers work Cons: No actual source code in traces; Webpack only (not Vite)

CI/CD Pipeline Checks

I added a check to my CI pipeline to catch .map files before deployment:

jobs:
  build:
    steps:
      - name: Check for source maps
        run: |
          if find dist -name "*.map" -type f | grep -q .; then
            echo "ERROR: Source map files found in dist/"
            find dist -name "*.map" -type f
            exit 1
          fi
          echo "No source maps found in build output"

For npm packages, I also verify the tarball:

# Build the package tarball
npm pack

# List contents
tar -tzf *.tgz | grep -E "\.map$"
# If any .map files appear, they'll be published

Package.json Exclusion

I explicitly exclude .map files from npm packages:

{
  "files": [
    "dist",
    "!dist/**/*.map"
  ],
  "publishConfig": {
    "access": "public"
  }
}

The !dist/**/*.map pattern ensures .map files never get published.

Why This Matters

The Claude Code incident revealed the real impact:

- Complete system prompts for all tools
- Internal agent orchestration logic
- API endpoints and request handling
- Error handling and retry strategies
- Token counting and cost calculation
- File operation implementations
- Git workflow automations
- MCP server configurations

An attacker with this information could:

Understand exact prompting strategies
Find potential vulnerabilities
Clone the product functionality
Reverse-engineer business logic

For any commercial project, this is a serious security risk.

Summary

In this post, I showed how source map files can leak your complete source code and how to prevent it. The key solutions are:

Disable sourcemaps in production (sourcemap: false) for maximum safety
Use hidden sourcemaps (sourcemap: 'hidden') if you need error tracking
Add CI/CD checks to catch .map files before deployment
Exclude .map files from npm packages in package.json

The key point is: never deploy .map files to production or include them in published packages. Your source code is too valuable to expose.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Webpack Devtool Documentation
👨‍💻 Vite Build Configuration
👨‍💻 Reddit Discussion: Claude Code Leaked Source

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!