Preventing Source Code Exposure: Aider and Source Maps

Correction note (2026-10-13). The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target. ssg daemon has no --env flag; edit the project rule files or add a waiver with ssg exceptions add.

Describe the task

A production issue is hard to debug without a stack trace. Aider offers to help and enables source maps in your TypeScript config:

{
  "compilerOptions": {
    "sourceMap": true
  }
}

Source maps in production builds map your minified bundle back to the original TypeScript — they're invaluable for debugging but expose your full source code to anyone with browser DevTools. SSG's no-sourcemap rule blocks the write before tsconfig.json is saved.

# illustrative sample output
[BLOCK] write_file › tsconfig.json — rule: no-sourcemap-in-tsconfig
Reason: sourceMap: true detected in production config.

Give SSG context

SSG intercepts write calls via the SSG MCP Server integration for Aider sessions and validates file content before saving.

Required context

rule no-sourcemap-in-tsconfig {
  enabled true
  priority 85
  severity error
  DENY write
  IF path ENDS_WITH "tsconfig.json"
  AND content CONTAINS "\"sourceMap\": true"
  MESSAGE "sourceMap: true in production config exposes source code. Use tsconfig.dev.json instead."
}

Optional context

Also guard against inline sources being embedded in the bundle:

rule no-inline-sources {
  enabled true
  priority 85
  severity error
  DENY write
  IF path ENDS_WITH "tsconfig.json"
  AND content CONTAINS "\"inlineSources\": true"
  MESSAGE "inlineSources: true embeds full source in the bundle."
}

What SSG does

SSG reads the full proposed file content and checks for the presence of "sourceMap": true. If found, the write is blocked before the file system is touched. Aider receives the block and can propose a safer approach.

Ask the agent to use a dev-only tsconfig

sourceMap: true in the base tsconfig was blocked. Create a tsconfig.dev.json that extends
the base config and adds source maps only for local development builds. The production config
should remain clean.

The agent creates tsconfig.dev.json — SSG only blocks writes to tsconfig.json, not the dev variant.

Extend protection to webpack and vite configs

Source maps can also be enabled in bundler configs. Add rules for those files:

rule no-sourcemap-webpack {
  enabled true
  priority 80
  severity warning
  ASK write
  IF path ENDS_WITH "webpack.config.js"
  AND content CONTAINS "devtool"
  PROMPT "devtool (source map) setting detected in webpack config. Confirm this is dev-only."
  MESSAGE "devtool (source map) setting detected in webpack config. Confirm this is dev-only."
}

Audit all tsconfig changes

Set ASK mode on any tsconfig.json write to create a human review checkpoint for every compiler option change:

rule review-tsconfig {
  enabled true
  priority 75
  severity info
  ASK write
  IF path ENDS_WITH "tsconfig.json"
  PROMPT "tsconfig.json is being modified. Review compiler options before saving?"
  MESSAGE "tsconfig.json is being modified. Review compiler options before saving?"
}

How your path condition scopes the rule

ENDS_WITH "tsconfig.json" matches the base config and any path depth (e.g., packages/api/tsconfig.json). If you have intentional tsconfig.dev.json files that allow source maps, the rule won't block those by default.

Check the rule against your CI build system

Some CI configurations run builds with source maps enabled for internal staging environments. If your internal staging builds legitimately enable source maps, edit the rule in the project's .sigmashake/rules files, or record a waiver with ssg exceptions add <rule-id> --reason <reason-code> --justification <text>.