Post-Incident Review of an AI Coding CLI Source Code Leak

Event Background: An Avoidable Leak

A widely used AI coding agent CLI tool, distributed via a public package manager under a closed-source license, suffered a major release accident. Instead of delivering compiled, obfuscated code, the release exposed over 512,000 lines of original source code. This is considered one of the largest source code leaks of an AI tool in this package management ecosystem.

Notably, this was not an isolated incident. Just five days prior, the same vendor accidentally exposed internal materials for a next-generation model and around 3,000 internal assets due to a CMS misconfiguration, discovered independently by security researchers and media. Furthermore, this exact CLI tool had suffered a similar source map leak during its initial release over a year ago, which was hastily patched. The recurrence of the identical mistake after a year indicates a systemic flaw in the release process rather than an individual engineer’s oversight.

Timeline Reconstruction: From Seed to Loss of Control in Two Hours

Phase 1: The Leak is Seeded (06:36 UTC)

A new version of the tool was published to the public package manager. This version included a ~59.8MB cli.js.map file, a debugging artifact (source map) that should have been excluded during the production build. It contained the complete original TypeScript source code, preserving variable names, comments, and internal module structures.

Worse, the file pointed to the vendor’s self-hosted object storage address. Any user who downloaded the npm package could follow this reference to directly download the complete, unobfuscated source code archive. The leak was not confined to the package itself but was amplified through external storage.

Phase 2: Public Disclosure and Loss of Control (08:23 UTC)

Less than two hours later, a security researcher exposed the leak on social media, including a direct download link. The post quickly garnered millions of views, and multiple code repositories mirrored the leaked source, triggering community line-by-line analysis.

The scale was staggering: 1,906 files and over 512,000 lines of TypeScript code. This was not a simple API wrapper but a complete, production-grade development platform, including:

• 40+ permission control tools: Covering core security logic like sandbox execution, file read/write boundaries, and network access policies;
• ~46,000 lines of query engine code: Responsible for context retrieval and code understanding;
• Multi-agent orchestration system: Task decomposition, sub-agent scheduling, and result aggregation mechanisms;
• IDE bridging and persistent memory mechanisms: Editor integration protocols and cross-session state management;
• 35 compile-time feature flags, 120+ unexposed environment variables, and 26 internal slash commands (e.g., experimental session migration, internal debugging directives).

Once public, this information not only meant a loss of intellectual property but could also be exploited by attackers to discover hidden APIs, bypass permission controls, or locate server-side vulnerabilities.

Phase 3: Derivative Event: Clean-Room Rewrite Based on Leaked Code

On the day the incident escalated, a developer, alerted by the news, spent a few hours re-implementing the core functionalities based on the publicly leaked code logic using a “clean-room rewrite” approach in another language, open-sourcing it. The repository gained tens of thousands of stars within hours, becoming one of the fastest-growing repositories on the platform.

This derivative event itself was controversial: rewriting based on leaked source code exists in a legal gray area regarding copyright and licensing—leakage does not equal authorization, and whether viewing source code before rewriting constitutes a derivative work varies by jurisdiction. However, it clearly signaled that once source code is public, factual loss of control begins, and no legal means can truly “un-ring the bell” of already disseminated code.

Technical Root Causes: Three Concurrent Failures

1. Bundler Default Behavior

The tool was built using a modern JavaScript bundler, which in newer versions generates source maps by default unless explicitly disabled. This mismatch between default behavior and production expectations is the common starting point for many leaks. For closed-source distribution scenarios, you must explicitly declare in the build configuration:

// Example build configuration
export default {
  sourcemap: false,        // Must be explicitly disabled for closed-source distribution
  // Or: generate separately for internal crash analysis, but never publish with the package
};

2. Missing Exclusion Rules in the Publish Manifest

Someone forgot to exclude *.map files in the publish ignore manifest (e.g., .npmignore or the files field). This exposes a flaw in manifest management: relying on “remembering to exclude” rather than a “default whitelist” guarantees eventual failure. A more robust approach is using a whitelist mode, only publishing explicitly listed artifacts:

{
  "files": ["dist/cli.js", "dist/*.d.ts", "README.md"]
}

3. Failed Access Control on External Storage

The object storage address pointed to by the source map was completely open to the public internet. The permission model of object storage (public read / private read + signed URLs) is a fundamental cloud capability. Buckets containing sensitive assets should be private by default and distributed on-demand via short-lived signed links. Placing debugging assets in a publicly readable bucket opened a second door for the leak.

Actionable Prevention Checklist

In light of such incidents, teams should enforce the following checks in their CI/CD pipelines:

1. Build Artifact Scanning: Forcefully inspect package contents in the release pipeline; fail if *.map, .env, test fixtures, or internal documents are found;
2. Size Anomaly Alerts: Automate warnings for sudden package size increases (e.g., jumping from 10MB to 60MB);
3. Sensitive String Scanning: Perform regex scans on artifacts for intranet addresses, bucket names, and unexposed environment variable names;
4. Private Storage by Default: Make object storage buckets private by default; explicit approval is required for public access;
5. Release Drills and Dual Review: Add manual review steps for initial and major version releases;
6. Incident Response Plan: Upon a leak, immediately unpublish the version, revoke storage permissions, and rotate potentially exposed keys, rather than waiting for public backlash to escalate.

Conclusion

The irony of this incident is that an AI coding tool marketed for being “secure and reliable” fell victim to the most basic engineering details. No matter how advanced the tech stack is, it cannot withstand “someone forgetting to exclude a file in the manifest.” For engineering teams, the real defense is not individual memory, but secure-by-default build configurations, whitelist-based publish manifests, and pipelines that can automatically intercept abnormal artifacts. Shifting security left is never just a slogan; it’s about turning “forgot” into “impossible to forget.”