| Date (UTC) | Item | What happened |
| 2026-03-30 | Claude Code 2.1.88 | Claude Code 2.1.88 was released on March 30, 2026. |
| 2026-03-30 05:57 | [email protected] | A clean [email protected] was published. |
| 2026-03-30 23:59 | [email protected] | Malicious [email protected] was published. |
| 2026-03-31 00:21 | [email protected] | Malicious [email protected] was published with the hidden dependency. |
| 2026-03-31 01:00 | [email protected] | Malicious [email protected] was published. |
Claude Code Leak: What You Need to Know
[Update] April 1, 2026: “Has Anthropic Confirmed the Cause of the Claude Code Exposure?”, “Claude Code Leak Sparks Typosquatting Attempts”
On March 31, 2026, community reports drew attention to a source map exposure involving Anthropic’s Claude Code CLI after users found that the npm package appeared to include a JavaScript source map file, cli.js.map, alongside the distributed build.
This is not the same as a confirmed breach of Anthropic’s servers, and there is no public evidence at this stage showing user data theft or backend compromise tied to this issue. Still, a published source map can materially reduce the effort needed to reconstruct readable source from bundled JavaScript, exposing internal implementation details, code structure, and configuration surfaces that were not meant to be easy to inspect.
At this time, there is no verified official statement or advisory confirming the event or its scope. This post explains what likely happened in the alleged Claude Code leak, why it matters operationally, and what defenders can do now.
What Was Reportedly Exposed in the Claude Code Leak?
The reported issue centers on the npm package @anthropic-ai/claude-code and specifically the inclusion of cli.js.map in the published package contents. Public package screenshots show version 2.1.88 and list cli.js.map alongside files such as cli.js, package.json, README.md, and sdk-tools.d.ts. The artifact itself appears to have been publicly accessible as part of the release package.

Initially published npm contents for @anthropic-ai/claude-code v2.1.88, including the bundled cli.js.map source map.
If a source map contains full sourcesContent, or even sufficiently detailed mappings, a third party can reconstruct a close approximation of the original source tree. Even when it does not include the full original code directly, it can still reveal file paths, module names, internal structure, and naming patterns that make reverse engineering faster and more accurate.
How Do Source Maps Turn Bundled JavaScript Into Readable Source Code?
Source maps are designed for debugging. They allow tools to translate optimized JavaScript back to the original source layout when developers need to investigate errors or behavior. When such a file is included in a public production package, anyone who downloads the package can potentially use the bundle and the map together to reconstruct a much more readable representation of the codebase.
That is why this kind of exposure matters operationally. Bundled JavaScript can often be reversed anyway, but source maps lower the cost and time required. They improve visibility into symbol names, file paths, module boundaries, and feature logic.
Publicly shared screenshots from this incident suggest that users were able to recover a large internal source tree.

Claude Code source tree derived from the exposed cli.js.map, showing the scale of internal code visibility. (X)
Which Versions and Channels Are in Scope?
The clearest version currently tied to the reporting is Claude Code 2.1.88, which Anthropic’s changelog lists on March 30, 2026. Public discussion centers on the npm package as the distribution channel.
Based on the artifact screenshots now circulating, it is reasonable to treat this as a packaging issue affecting at least one npm-published Claude Code release in that time frame.
Does This Mean Anthropic Was Breached?
At this stage, there is no public evidence that this issue involved a breach of Anthropic’s internal systems, theft of user prompts, or compromise of customer data. The strongest current reading is that this was an artifact-level exposure through a published package, not proof of a server-side intrusion.
A source map exposure can still increase downstream risk by making internal logic easier to inspect, but it does not by itself prove that accounts were compromised, secrets were stolen, or production services were breached. Security teams should treat those as separate questions unless stronger evidence emerges.
Why Does a Claude Code Source Map Exposure Matter for Security Teams?
Even when no credentials are exposed, a reconstructed source can raise risk in practical ways:
- Faster vulnerability research against the CLI: Readable code makes it easier to identify insecure patterns, such as unsafe file handling, questionable update flows, weak validation around plugin-like behavior, or logging and caching paths that may expose tokens locally.
- Greater visibility into hidden configuration and debug surfaces: Community discussion speculated about internal feature flags, undocumented environment variables, and hidden commands. Those specific claims are unverified here, but the general risk is credible: source-level visibility often reveals toggles, endpoints, telemetry schemas, and behavioral switches that were not documented for end users.
- Higher social engineering and malware imitation risk: Developer tools attract copycats. If attackers can mirror Claude Code’s UX, config structure, logging messages, or install and update behavior more convincingly, they can build more effective trojans. This matters because there has already been separate reporting about infostealers being disguised as “Claude Code” downloads and other AI developer tools, even if that activity is not proven to be caused by this source map exposure.
Community Claims About Hidden or Unreleased Features
Users have shared summaries claiming the exposed material points to hidden or unreleased Claude Code features, including persistent assistants, internal orchestration logic, memory-related functions, feature flags, remote planning components, and novelty concepts such as a “Buddy” companion-style system.
Public reverse-engineering repositories and social posts discuss these ideas, and the shared screenshots suggest that users were able to inspect a broad internal code structure.
But those claims should be handled carefully. Reconstructed code, feature flags, internal strings, or dormant modules are not the same as an official roadmap, confirmed product plan, or publicly intended feature set. The safe framing is that users are speculating about hidden or unreleased functionality based on exposed artifacts, not that Anthropic has confirmed any of those features.
Is There Any Link to the Axios npm Supply Chain Attack?
There is no confirmation that the Claude Code source map exposure is connected to the Axios supply chain incident.
Some users pointed to Axios references in Claude Code-related artifacts, but that alone does not indicate a link. Axios is widely used, and based on the currently reported timeline, a connection also appears unlikely because Claude Code 2.1.88 was released before the malicious Axios versions were published.
Has Anthropic Confirmed the Cause of the Claude Code Exposure?
Anthropic has confirmed that internal Claude Code source files were unintentionally exposed because of a release packaging mistake caused by human error, not a security breach. The company also said no sensitive customer data or credentials were involved.
Claude Code Leak Sparks Typosquatting Attempts
The incident is already creating follow-on risk. Attackers have begun reserving internal-looking npm package names in what appears to be an attempt to target anyone trying to build or experiment with the leaked Claude Code source, setting up potential dependency confusion attacks.
The npm user pacifier136 published the package names audio-capture-napi, color-diff-napi, image-processor-napi, modifiers-napi, and url-handler-napi, all of which appear intended to typosquat internal Claude Code dependencies and support possible dependency confusion attacks.
Security researcher Clément Dumas warned on X that even empty placeholder packages can later be weaponized through malicious updates once developers begin installing them.
What Should Defenders and Users Do Right Now?
If your organization uses Claude Code CLI, treat this as a supply chain hygiene event and reduce uncertainty:
Pin and verify the exact CLI version you run
- Prefer version pinning over floating installs like “latest.”
- Capture the installed version and the package integrity metadata your environment uses (lockfiles, internal registries, artifact hashes).
Inspect your internal mirrors and endpoints for source maps
- If you mirror npm artifacts internally, check whether any Claude Code packages in your repository include *.map files.
- If present, assess whether the maps include embedded sourcesContent or only mappings.
Tighten controls on developer endpoints where the CLI runs
- Apply egress controls where feasible, especially for developer workstations that hold high-value tokens.
- Review local secret handling practices: prevent API keys from being logged, cached in world-readable locations, or exposed via shell history and environment dumps.
- Revalidate filesystem permission boundaries if the tool has access to sensitive repos or credential stores.
Increase vigilance for lookalike packages and installers
- Restrict installations to approved sources (internal registry, vetted artifacts).
- Watch for brand-impersonating packages, fake install scripts, or unsigned binaries distributed via forums and social channels.
What Should Tool Vendors Do to Prevent This Class of Leak?
This incident pattern is preventable with build and release guardrails:
- Strip source maps from production registry artifacts by default (bundler settings, .npmignore, publish allowlists).
- Add CI checks that run npm pack and fail the pipeline if any *.map files are present in the tarball.
- Scan built artifacts for accidental inclusion of:
- sourcesContent
- internal endpoints and debug toggles
- telemetry tokens and feature flag keys (even if considered “non-secret”)
For security teams evaluating third-party CLIs, these checks are also useful as a vendor risk question: ask whether the vendor’s release process enforces an artifact allowlist and whether it routinely audits published packages.
