Executive summary
On March 31, 2026, Anthropic accidentally published a release of its Claude Code tool (version 2.1.88) that exposed a large internal TypeScript codebase, roughly ~512,000 lines across ~1,900 files, primarily via a shipped JavaScript source map (cli.js.map). Public reporting and community reconstruction show the artifact was sufficient to recreate readable source code at scale.
Anthropic stated the exposure was a release packaging issue caused by human error, not a security breach, and that no sensitive customer data or credentials were involved or exposed. The incident quickly propagated: mirrors spread on GitHub, and Anthropic pursued takedowns, one takedown notice was processed across an 8.1K-repository network for a prominent mirror and its forks.
Why it matters: while the leak did not include model weights (per reporting), it exposed a meaningful portion of the “agent harness”, the orchestration layer, tool definitions, feature flags, remote-session plumbing, and internal prompts/instructions that turn a foundation model into a productized coding agent. This increases (1) competitive/IP risk (feature roadmap + implementation details), (2) security risk (attackers can study tool flows, context handling, and guardrail logic), and (3) reputational and governance risk given the company’s safety positioning.
Bottom line for executives and technical leaders: treat this as a high-severity IP + product security incident even if it is not a customer-data breach; assume adversaries will mine the code for weaknesses; prioritize build/release hardening, artifact scanning, credential rotation where uncertainty exists, rapid patching, and clear stakeholder communications.
Timeline and scope of the incident
Key events and actors
The timeline below reflects what can be corroborated from publicly available sources; items not confirmed directly by Anthropic are labeled “unspecified.”
- March 31, 2026 (date confirmed; exact publish time unspecified): Claude Code v2.1.88 is briefly published to the public npm ecosystem and includes a large source map (
cli.js.map) that enables reconstruction of internal TypeScript sources. - March 31, 2026: Researcher Chaofan Shou is widely credited as the first to flag the leak publicly.
- March 31, 2026: Community members rapidly reconstruct and mirror the code on GitHub; multiple outlets report a mirror reaching tens of thousands of forks (counts vary by observation time and repository).
- March 31, 2026: Anthropic confirms the issue (via media statements), emphasizing no sensitive customer data or credentials and describing it as a packaging issue caused by human error.
- March 31, 2026: A takedown notice is processed across an 8.1K-repository network tied to a major mirror and its forks.
- April 1, 2026: Claude Code documentation shows a subsequent version 2.1.89 dated April 1, 2026; notably, the docs’ version list includes 2.1.89 and 2.1.87 but does not list 2.1.88, consistent with reporting that 2.1.88 was withdrawn.
Timeline diagram
2026-03-31 Claude Code v2.1.88 published (exacttime unspecified)
2026-03-31 Source map(cli.js.map) enablesreconstruction of~1,900 TS files(~512k LOC)
2026-03-31 Leak flaggedpublicly; mirrorsproliferate onGitHub (fork countsrapidly change)
2026-03-31 Anthropic confirmspackaging error; saysno customerdata/credentialsexposed
2026-03-31 DMCA/takedownactions initiate; onenotice processed across 8.1K repos
2026-04-01 Version 2.1.89 appears in ClaudeCode changelog;2.1.88 absent
Claude Code leak (publicly reported sequence)
Show code
Scope of material exposed
Public reporting and community extraction indicate the leaked material included:
- A large portion of Claude Code’s internal TypeScript/TSX application code, with file counts around ~1,900 and line counts around ~512,000.
- Tool orchestration logic (how the agent invokes Bash, file reads/writes/edits, search, etc.).
- Feature flags / unreleased capabilities (examples reported include “Buddy,” “KAIROS,” “Dream,” and “Proactive” style concepts; details vary by source and are not fully enumerated in Anthropic’s public statements).
- Remote-session plumbing and proxying components (derived from directory structure and filenames present in reconstructed sources).
What was publicly reported as not exposed:
- Customer data and credentials, per Anthropic’s statements to multiple outlets.
- Model weights, per reporting (even where the harness/instructions were described as sensitive).
What the leaked code reveals about Claude Code
This section distinguishes (A) what is directly inferable from reconstructed source trees, (B) what is stated in Anthropic’s official documentation, and (C) what is reported/interpreted by third parties.
Release artifacts and how source maps enable reconstruction
A source map is a JSON format that maps transformed/minified code back to original sources for debugging; it can include enough information to reconstruct original code. BleepingComputer specifically notes that when source maps include sourcesContent, they can embed the full source files, enabling complete reconstruction of the source tree.
Community extraction repos (example: Exhen) document a workflow that uses the published cli.js.map to write out source files, describing an extracted tree of 1,906 files and noting the runtime bundle is a self-contained Node executable with a large .map file.
Some reporting also indicates the debugging artifact referenced a ZIP archive hosted in object storage (described as Anthropic’s Cloudflare R2). Source-map exposure and “public bucket/object” exposure are not mutually exclusive; the exact packaging/storage chain is unspecified by Anthropic beyond “packaging issue.”
Reconstructed codebase structure: major components
A directory listing from an extracted repository shows a broad product surface consistent with a mature “agentic IDE-in-terminal” toolchain, including UI (TSX), orchestration, plugins, and tool execution. Notable top-level modules include:
- Agent orchestration / query engine: Files like
QueryEngine.ts,Task.ts, andTool.ts, plus directories such asquery/andtasks/, suggest a layered orchestration mechanism and token-budgeting/config sections (e.g.,tokenBudget.ts). - Tool framework: The
tools/directory enumerates many capabilities:BashTool, file read/edit/write tools, grep/glob, LSP integration, web fetch/search, MCP tools, task/team management tools, and scheduling. - Remote sessions: A
remote/directory includes filenames such asRemoteSessionManager.tsandSessionsWebSocket.ts, implying WebSocket-based session transport and a “remote permission bridge.” - Proxying / relay: An
upstreamproxy/directory containsrelay.tsandupstreamproxy.ts, consistent with explicit upstream routing and intermediary control points. - Plugins and hooks: The tree includes
plugins/(with abundled/subdirectory) andhooks/, matching the documented extensibility surface (hooks are described in official docs as user-defined commands/endpoints/prompts executed at lifecycle events). - “Buddy” companion/pet UI: A
buddy/directory includesCompanionSprite.tsxand related sprite/prompt files, aligning with reporting about a Tamagotchi-like companion feature.
Models, data flows, and infrastructure context
Even without model weights, the harness matters because it governs how models are prompted, what tools they can access, and how risks like prompt injection are handled.
From Anthropic’s official Claude Code documentation:
- Claude Code is built around a permission-based architecture (read-only by default, explicit approvals for edits/commands), with additional protections like sandboxing and write-scope restriction.
- Sandboxing and permissions are described as complementary layers: permissions gate tool use, while sandboxing provides OS-level filesystem/network restrictions for Bash subprocesses.
- The docs explicitly warn that Read/Edit deny rules do not constrain Bash subprocesses (e.g., denying Read on
./.envdoes not stopcat .envvia Bash), recommending sandboxing for OS-level enforcement. - For cloud execution (Claude Code on the web), Anthropic states repos are cloned into an isolated VM, GitHub auth is handled via a secure proxy, and outbound traffic goes through a security proxy for logging/abuse prevention.
Third-party reporting further indicates the leak included “harness” instructions, commercially sensitive techniques for guiding Claude models as coding agents, without exposing model weights.
How the leak likely occurred
Anthropic has called the incident a release packaging issue caused by human error, not a breach. That public statement, combined with the presence of a shipped source map, strongly supports “accidental exposure” as the primary proximate cause.
Still, it is useful, especially for executives governing enterprise risk, to distinguish proximate cause (what was shipped) from enabling conditions (why internal materials were reconstructable and widely accessible).
Hypotheses, evidence, and likelihood
| Hypothesis | What it would mean | Evidence in public sources | Likelihood |
|---|---|---|---|
| Accidental release artifact inclusion | Build/release pipeline mistakenly bundled a debug artifact (source map) into a public distribution | Multiple outlets describe Claude Code v2.1.88 as shipping a large cli.js.map source map; Anthropic describes “packaging issue” and “human error.” | High |
| Misconfiguration of storage/object access | Internal debugging sources (or referenced archives) were accessible without auth once the URL/path became known | Reporting describes references to object storage (Cloudflare R2) used for debugging sources. Cloudflare docs show that enabling a “public development URL” (r2.dev) exposes bucket contents publicly (intended for non-production). | Medium–High (as an enabling factor) |
| Third-party compromise of build system or npm account | An attacker published the bad artifact or swapped contents | Anthropic publicly frames this as non-breach; no public indicators of attacker control are cited in major reporting; details remain unspecified. | Low (based on current disclosures) |
| Insider leak | Authorized individual intentionally exfiltrated or published | No public evidence; Anthropic describes human error, not malicious action; attribution details are unspecified. | Low |
| “Accidental” but compounded by weak release guardrails | Preventive controls existed but didn’t protect the artifact boundary (e.g., insufficient packaging allowlists, missing artifact scanning) | A published package.json from an extracted repo shows a prepare script intended to prevent direct unauthorized publishing, suggesting some guardrails existed but were not sufficient to stop the inclusion of debug artifacts. | High (as a systemic contributor) |
What is still unspecified
Public sources do not specify:
- The exact internal build step or configuration that caused
cli.js.mapto be included (e.g.,.npmignorevs bundler flags vs publishing workflow). Unspecified. - Whether any referenced object storage location was intentionally public (for debugging convenience) or mistakenly exposed. Unspecified.
- Whether additional artifacts beyond
cli.js.mapwere temporarily public (beyond what reconstructors captured). Unspecified.
Risk assessment and implications
This section separates direct risks (stemming from leaked code) from adjacent risks (events that become more likely in the wake of widespread mirroring and “clone building”).
Primary security and business risks
IP and product strategy exposure (high impact, high likelihood).
Axios characterized the leak as exposing Claude Code’s full architecture, unreleased features, and internal model performance data, handing competitors a roadmap and implementation reference. Even if competitors cannot replicate model quality without comparable models, the harness and “how-to” of agent orchestration is itself strategic.
Reduced attacker cost to weaponize prompt injection and context attacks (high impact, medium–high likelihood).
AI-security commentary highlighted that code visibility lets attackers’ study how context is managed and compacted and craft payloads that survive long sessions. Meanwhile, Anthropic’s own docs emphasize that agentic systems face prompt injection threats and rely on permission gates and sandbox boundaries. The combination means a leak can turn “black-box probing” into “white-box targeting,” accelerating exploit development.
Vulnerability discovery in a tool that can edit files and run commands (high impact, medium likelihood).
Claude Code’s design includes powerful local capabilities (file edits, command execution) gated by permissions and sandboxing. Source visibility may accelerate discovery of logic bugs (permission bypass edge cases, sandbox escape conditions, remote-session authorization bugs), shortening time-to-exploit even if those bugs existed previously.
Supply-chain and ecosystem risks (medium–high impact, medium likelihood).
Two dynamics matter:
- Claude Code itself exposes a broad “tool surface”, Bash, WebFetch/S, MCP integrations, plugin/hook systems, which can expand the attack surface if extension mechanisms are abused or misconfigured.
- The “clone rush” and widespread mirroring create opportunity for attacker deception (typosquatting packages, malicious forks, poisoned installers). Public reporting around the leak already emphasized rapid replication and rewriting attempts.
A related, contemporaneous example of why supply-chain vigilance matters: StepSecurity reported that the popular JavaScript HTTP client axios experienced a supply-chain compromise via a hijacked maintainer account and malicious dependency injection. While this is not asserted as part of the Claude Code leak, it illustrates the current threat environment and why incident responders should assume attackers will exploit developer urgency and dependency chains.
Customer trust, governance, and disclosure pressure (medium–high impact, high likelihood).
Even with “no customer data,” a high-profile IP leak can drive customer concern about operational maturity and internal controls, especially for safety-branded AI vendors. If the company is or becomes a public registrant, U.S. SEC rules require disclosure of material cybersecurity incidents within four business days after determining materiality, with disclosure describing nature/scope/timing and material impact. (Whether this particular incident is “material” is a legal/financial determination; public sources do not state a materiality conclusion.)
Risk matrix heatmap
Legend: likelihood (rows) × impact (columns). Each cell lists risk IDs; color blocks approximate severity.
Risk IDs
- R1 IP / feature-roadmap loss
- R2 Targeted exploitation of agent harness (permission/sandbox logic bugs)
- R3 Improved prompt-injection/context-poisoning attacks due to white-box insight
- R4 Supply-chain deception (malicious forks/installers/plugins/typosquats)
- R5 Reputational + enterprise trust erosion
- R6 Regulatory/disclosure pressure (materiality-dependent)
| Likelihood ↓ / Impact → | Low | Moderate | High | Critical |
|---|---|---|---|---|
| Almost certain | 🟨 | 🟥 R5 | 🟥 | 🟥 |
| Likely | 🟨 | 🟥 | 🟥 R1 | 🟥 |
| Possible | 🟩 | 🟨 R6 | 🟥 R3 | 🟥 R2 |
| Unlikely | 🟩 | 🟨 | 🟨 R4 | 🟥 |
| Rare | 🟩 | 🟩 | 🟨 | 🟨 |
Grounding for these placements:
- R1 and R5 are strongly supported by the scale of leaked source/harness and rapid mirroring/takedown dynamics.
- R2/R3 follow from documented tool power + security model (permissions/sandbox) and third-party security commentary on exploitability of orchestration logic.
- R6 depends on materiality assessment in a securities context; SEC guidance clarifies timing and scope of required disclosures when material.
Recommendations and playbooks
The goal here is actionable prioritization for both executives and technical responders. Effort estimates assume a mid-to-large engineering org; adjust for your scale.
Executive actions
| Recommendation | Priority | Effort | Expected impact |
|---|---|---|---|
| Treat as an IP + product security incident, not “just PR”: establish a single incident owner, define severity, and run a formal post-incident process aligned to established incident-response guidance | High | Low–Medium (hours–2 days) | High |
| Publish a clear, consistent public statement (what happened, what didn’t happen, what’s being done) and align internal talking points for Sales/CS | High | Low (same day) | High |
| Engage counsel to evaluate: trade secret exposure, takedown strategy, disclosure triggers in customer contracts, and, if applicable, securities materiality and timing | High | Medium | High |
| Use takedowns selectively: combine high-value removals (major mirrors, installers) with pragmatic acceptance that code is likely irretrievable once widely mirrored; avoid actions that amplify attention without reducing risk | High | Medium | Medium–High |
| Run customer-facing risk review: confirm “no customer data/credentials” with evidence; prepare targeted comms for regulated customers | High | Medium | High |
| Insurance and risk financing review: notify cyber/IP carriers (if required), preserve evidence, and confirm coverage for incident response + legal actions | Medium | Medium | Medium |
| Commission a third-party rapid assessment (build pipeline, artifact controls, storage access patterns) to restore trust with enterprise customers | Medium | Medium–High | High |
| Update board-level reporting metrics: release gating maturity, secrets exposure posture, and supply-chain controls | Medium | Medium | Medium |
Why these are aligned with primary sources: Anthropic’s own statements emphasize the incident is packaging/human error (helps shape comms) while takedown activity and widespread mirroring show containment limits. SEC guidance indicates disclosure obligations are tied to materiality determinations and require describing nature/scope/timing/impact when material.
Technical actions
| Recommendation | Priority | Effort | Expected impact |
|---|---|---|---|
Fix the release boundary: enforce artifact allowlists (publish only known-good files), block source maps/debug artifacts in production distributions, and require npm publish --dry-run style manifest diff checks in CI | High | Medium | High |
Add automated artifact scanning: detect large .map/debug files; run secret scanning; require approval gates on anomalous artifacts | High | Medium | High |
| Treat storage references as external exposure: ensure internal debugging artifacts are protected (private buckets/objects, access policies), and avoid “public development URL” configurations for internal code archives | High | Medium | High |
| Credential hardening: rotate any tokens that could plausibly be embedded or referenced; verify no credentials were present (don’t rely solely on assertion) | High | Medium | High |
| Exploitability sprint: assume attackers will audit the harness, prioritize security review of permission gating, sandbox edge modes, remote session auth, and plugin/hook execution paths | High | Medium–High | High |
| Add monitoring for “clone ecosystem abuse”: watch for malicious forks, trojan installers, and typosquats exploiting user confusion; publish signed install paths and verification guidance | Medium | Medium | Medium–High |
| Strengthen “agent safety” controls informed by public code: expand red-teaming of prompt injection and long-session persistence; ensure OS-level sandboxing is the default for high-risk actions | Medium | Medium–High | High |
| Watermarking/canaries for leak detection: embed non-secret canaries in build artifacts and internal docs to detect future unauthorized publication; consider model-output watermarking where relevant (noting limits and attacker adaptation) | Medium | Medium | Medium |
| Post-incident “lessons learned” with measurable controls: publish internal scorecards (artifact hygiene, access controls, CI provenance) and track regression | Medium | Medium | Medium |
Checklist for an executive briefing
- Confirm facts: what version, what artifact, what was exposed, what was not (customer data/credentials/model weights).
- Current containment: major mirrors removed? number of forks/copies? what remains?
- Customer impact statement: does any contract require notification even without customer data? (Often yes; unspecified publicly.)
- Legal posture: DMCA/takedowns, trade secret preservation, employee comms.
- Security posture: immediate release pipeline fixes, storage access lockdown, credential rotation scope.
- Business impact: competitor acceleration risk, roadmap sensitivity, reputational risk.
- Disclosure governance: if public/IPO-bound, consult counsel on materiality and SEC timing expectations.
Technical incident-response playbook
Structured to match modern incident-response guidance: integrate response into risk management and focus on detection, response, and recovery discipline.
Triage and scoping
- Identify affected releases and distribution channels (npm, installers, mirrors). (Exact npm timestamps are unspecified publicly.)
- Enumerate leaked artifacts: source maps, any referenced archives/URLs, and any internal endpoints exposed in code (treat as potentially sensitive until reviewed).
- Validate the “no credentials/customer data” claim via automated scans + manual review sampling.
Containment
- Withdraw the affected release(s) and replace with a clean version; ensure the official changelog/upgrade path points off deprecated channels where appropriate.
- Lock down any storage buckets/objects referenced by debug artifacts; confirm no public-access toggles (including public dev URLs) are enabled for internal code archives.
- Initiate takedowns for the highest-impact mirrors and “installer bundles,” recognizing full recall is unlikely after wide replication.
Eradication and hardening
- Patch release pipeline: allowlists, artifact scanning, reproducible build checks, and separation of debug vs production outputs.
- Rotate likely-at-risk secrets (and any secrets that could be inferred from code, such as internal endpoints with weak auth assumptions).
- Security review sprint on high-risk modules: tool gating, sandbox edge modes, remote session manager, plugin/hook execution.
Recovery and assurance
- Publish verification guidance: signed binaries, checksums, official install commands, migration away from deprecated installers where applicable.
- Increase monitoring for exploit attempts and malicious clones; treat “fork ecosystem” as hostile until proven otherwise.
Post-incident
- Run a blameless postmortem with measurable outcomes (artifact controls, access policy changes, audits) and track completion at exec/board level.
Source desk and reliability notes
Primary-source reliability comparison
| Source | Type | What it helps establish | Reliability | Notes / limitations |
|---|---|---|---|---|
| Anthropic statements quoted by The Verge / BleepingComputer / Bloomberg / Axios | Official statements reported by media | “Packaging issue,” “human error,” “no customer data/credentials,” “not a breach” framing | High | Still leaves technical root cause details unspecified. |
| GitHub DMCA repo (2026-03-31 notice) | Platform primary record | Takedown scope (8.1K repo network), infringing repo names | High | Does not prove all repos were removed permanently; shows GitHub’s processing of a request. |
| Extracted code mirror (e.g., Exhen repo) | Community reconstruction | File tree structure, tooling names, extraction method, artifact sizes | Medium | Demonstrates what reconstructors produced; does not independently prove completeness or fidelity beyond extracted map contents. |
| The Register | Reputable media analysis | Storage mechanism references (e.g., object storage), spread dynamics | Medium–High | Some claims (e.g., exact storage reference chain) may be hard to verify without internal logs. |
| TechCrunch (2025 context) | Reputable media history | Prior reverse-engineering/takedown behavior | Medium–High | Contextual; not direct evidence about the 2026 incident mechanics. |
| NIST and SEC guidance | Authoritative standards/regulatory sources | Incident response governance; disclosure timing if material | High | General guidance; applicability depends on org status (public/private) and materiality determination. |
| Cloudflare R2 documentation | Vendor primary docs | How public bucket exposure can occur (e.g., r2.dev public dev URL) | High | Does not confirm Anthropic’s exact configuration; supports plausibility of misconfiguration. |
Sources
- The Verge reporting on the v2.1.88 leak, scale, feature discoveries, and Anthropic spokesperson statement.
- Axios reporting on architecture exposure, unreleased features, and spokesperson confirmation.
- BleepingComputer reporting on source map mechanics, statement confirmation, and DMCA activity.
- The Register reporting on source map exposure and storage reference claims.
- GitHub DMCA notice processed across an 8.1K repo network.
- Extracted reconstruction repository documentation and file tree evidence (Exhen).
- Anthropic Claude Code documentation: sandboxing, permissions, security foundation, and data usage / cloud execution details.
- SEC compliance guide on Item 1.05 Form 8‑K timing and disclosure content (material incidents).
- NIST SP 800‑61r3 IR profile abstract (incident response integrated into risk management).
- Cloudflare documentation on public bucket exposure via
r2.devpublic development URL. - MDN Web Docs glossary on source maps as reconstructable mappings.
- StepSecurity reporting on a contemporaneous supply-chain compromise example (axios) to contextualize ecosystem risk.
Categories: Cybersecurity Blog
Leave a Reply