TL;DR

• On March 31, 2026, a packaging error in Anthropic's npm release exposed a source map file pointing to a Cloudflare R2 bucket containing 1,900 TypeScript files and 512,000+ lines of Claude Code's internal source.

• The leak exposed Claude Code's full tool architecture: ~40 permission-gated tools including Bash execution, file read/write, WebFetch, MCP connections, and sub-agent spawning. Attackers now have a complete map of the attack surface.

• Anthropic confirmed this was human error, not a breach. The user data exposure is zero. The security exposure for organizations running Claude Code is a different question entirely.

• Security teams need to act on five fronts: inventory every Claude Code deployment, audit MCP connections, test the tool permission boundary under adversarial inputs, review the persistent memory directory for poisoned context, and apply runtime controls. Details below.

On March 31 2026, security researcher Chaofan Shou flagged on X that Anthropic's Claude Code npm package had shipped with a source map file referencing a publicly accessible Cloudflare R2 bucket. Inside: the near-complete TypeScript source for Claude Code, 1,900 files, 512,000+ lines, covering the query engine, tool architecture, sub-agent system, IDE bridge, and permission model. By the time Anthropic pulled the bucket, the repo mirroring the code had accumulated 84,000 GitHub stars.

Anthropic's statement was clear and accurate: this was a packaging error, not a security breach. No user data was compromised. No systems were accessed by an unauthorized party.

That framing is correct for Anthropic. It is incomplete for the security teams whose organizations run Claude Code in production.

The issue is not that Anthropic was hacked. The issue is that Claude Code is a privileged agent, and its internals are now public knowledge. Every path traversal defense, every tool permission boundary, every sub-agent spawning mechanism, every MCP integration point: it is all documented in a repo with 84,000 stars. Attackers who want to probe Claude Code deployments no longer have to guess at the architecture. They have the source.

If your organization runs Claude Code, here is what your security team should be doing right now.

What the leaked source actually contains

The leaked code is not marketing copy or documentation. It is the working implementation of a production AI agent with significant system access.

The tool architecture alone is worth understanding in detail. Claude Code registers approximately 40 discrete, permission-gated tools: Read, Write, Edit, Bash, Grep, Glob, WebFetch, Agent (sub-agent spawning), LSP integration, and MCP connections, among others. Each tool is gated, but the gating logic, the permission checks, and the edge cases are now fully documented. Researchers and attackers can read exactly how Anthropic implemented path traversal defenses (URL-encoded traversal, Unicode normalization attacks, backslash injection, and case-insensitive path manipulation are all explicitly handled), which means they know the specific variants that were considered and can probe for the ones that were not.

The sub-agent system is equally significant. Claude Code can spawn child agents, each running in its own context with a specific tool permission subset inherited from the parent. The spawning logic, context isolation, and permission inheritance model are all in the source. For an attacker attempting to escalate from a sandboxed sub-agent to a parent agent with broader tool access, this is a roadmap.

The IDE bridge uses JWT-authenticated channels for bidirectional communication between the CLI and IDE extensions. That authentication mechanism is now documented. The protected file list (.gitconfig, .bashrc, .zshrc, .mcp.json, .claude.json) is explicit in the source: these files are hardcoded as protected from automatic editing. Which means the protection boundary is now known, and testing what falls just outside it is straightforward.

One detail that most coverage has missed: the leaked source documents a persistent memory system. Claude Code maintains a file-based memory directory where it stores context about the user, their project, and their preferences across sessions. This is not just a convenience feature. It is an attack surface. Adversarial content that successfully writes into the memory directory persists into future sessions, meaning a single successful injection does not reset when the session ends. This is the agentic equivalent of a persistent cookie — except the cookie influences the model's behavior on every subsequent invocation.

None of this means Claude Code is broken. It means the attack surface is no longer opaque.

Four things your security team should do now

1. Find every Claude Code deployment in your organization

Claude Code is installed by individual developers, not provisioned through central IT. A developer who installed it six months ago may be the only person who knows it is running. You need a complete picture before you can assess exposure.

This means infrastructure-level discovery: scanning package manifests for claude-code or @anthropic-ai/claude-code, reviewing endpoint software inventories, checking developer machines for the claude binary, and auditing .claude.json and .mcp.json files across developer environments. Manual surveys consistently undercount: developers who use AI tools daily frequently do not think of them as "AI deployments" that need to be disclosed.

Repello's AI Asset Inventory discovers AI integrations at the infrastructure layer continuously, including AI coding assistants, API integrations, and MCP connections that self-reporting misses. If you do not have a current inventory of your AI coding tool deployments, that gap is where your exposure is.

2. Audit every MCP connection attached to Claude Code

Claude Code supports MCP (Model Context Protocol) connections that extend what the agent can do: file systems, databases, internal APIs, external services. The .mcp.json file on each developer machine specifies which MCP servers are connected. The leaked source makes the full MCP integration model transparent.

For each developer running Claude Code, you need to know which MCP servers are configured, what access those servers have, and whether they have been reviewed by anyone in security. A developer who connected an MCP server to an internal database six months ago, for a task that is now complete, may have left that connection active. That MCP server now has the tool architecture documentation it needs to be used as an injection vector.

Repello's MCP Gateway provides real-time monitoring and control of MCP connections, blocking malicious servers and enforcing security policies without requiring code changes from developers. The MCP security threat model applies directly here: a misconfigured or malicious MCP server can redirect agent execution to attacker-controlled infrastructure from inside the developer's environment.

3. Test the tool permission boundary under adversarial conditions

Knowing the tool architecture is documented publicly, security teams should run adversarial testing against their Claude Code deployments now, not after an incident. The specific questions to answer: Can the Bash tool be manipulated into executing commands outside its intended scope through adversarial prompt inputs? Can the file write tools be used to modify files outside the protected list through injection? Can a sub-agent be manipulated into requesting elevated tool permissions from a parent agent?

These are not theoretical questions. The leaked source gives anyone who wants to probe these boundaries a detailed starting point. Security teams should be testing their deployments before external actors do.

Repello's ARTEMIS runs this testing automatically across 15M+ attack patterns including the OWASP LLM Top 10, MITRE ATLAS, and NIST AI RMF categories. For organizations running Claude Code in development pipelines with access to production systems, this testing should be treated as urgent. The window between "source code is public" and "exploitation attempts against deployments" is short.

4. Apply runtime guardrails to Claude Code's output surface

Claude Code's outputs drive real system actions: files are written, commands are executed, APIs are called. If an adversarial input can manipulate those outputs, the downstream effect is not just a bad response, it is a file modification, a bash command, or an API call the developer did not intend.

Runtime guardrails at the output layer can catch behavioral anomalies before they reach execution: flagging outputs that attempt to write to protected paths, execute unexpected command patterns, or make API calls inconsistent with the current task context. Repello's ARGUS provides this layer with sub-100ms latency, calibrated from the adversarial testing results in Step 3.

5. Review the persistent memory directory for poisoned context

The leaked source documents Claude Code's file-based memory system: a directory where the agent stores context about you, your project, and your preferences that persists across sessions. For security teams, this introduces a class of risk that does not exist in stateless tools: an adversarial input that successfully writes into the memory directory does not reset when the session closes. It influences every subsequent Claude Code invocation until the memory is cleared.

Check whether the memory directory exists on developer machines, what is currently stored in it, and whether any of the stored context looks anomalous. Establish a process for periodically reviewing and flushing memory content on machines that interact with sensitive codebases or production-adjacent systems.

The broader lesson for AI coding assistants

Claude Code is one tool in a category that includes GitHub Copilot, Cursor, Continue, Codeium, and others. The lesson from this incident is not specific to Claude Code: every AI coding assistant is a privileged agent, and most organizations have not audited them as such.

Bash access, file system write access, git access, and increasingly MCP connections to internal systems are standard capabilities in this category. The attack surface exists regardless of whether the source is public. The Claude Code leak makes the point visually clear, but the exposure is not unique to Claude Code deployments.

For a structured audit process covering all AI coding assistant deployments, the Claude Code security checklist covers what to check, what the leak revealed about each control, and how to prioritize remediation.

Frequently asked questions

Was the Claude Code leak a security breach?

Anthropic confirmed it was not a security breach. A packaging error caused a source map file to reference a publicly accessible archive of the source code. No user data, credentials, or production systems were accessed by unauthorized parties. The security exposure is indirect: the leaked source gives attackers a detailed map of Claude Code's architecture and permission model, which can be used to probe deployments more effectively.

Does this affect organizations that use Claude Code in their development workflows?

Yes, in a specific and bounded way. The leak does not create new vulnerabilities by itself. It makes existing attack surface easier to probe by removing the obscurity that previously existed around Claude Code's tool architecture and permission model. Organizations running Claude Code with access to production systems, sensitive codebases, or internal MCP connections should treat this as a prompt to audit and test their deployments.

What data does Claude Code have access to that could be at risk?

By default, Claude Code has access to whatever files are in the working directory, can execute bash commands, can make web requests, and can connect to any MCP servers configured in .mcp.json. In a typical developer environment, this includes source code, environment variables, local credentials files, and any internal APIs or databases accessible through configured MCP connections. The scope of access varies significantly by how each developer has configured their environment.

Should organizations disable Claude Code while this is assessed?

Disabling Claude Code across engineering teams is a high-disruption response that is unlikely to be proportionate unless the organization has specific evidence of active exploitation. The more proportionate response is to run the four steps above: inventory deployments, audit MCP connections, test the permission boundary, and apply runtime controls. Disabling can be reserved for deployments with Tier 1 risk profiles (access to production systems or sensitive data) that cannot be quickly remediated.

How does the Claude Code leak compare to other AI supply chain incidents?

The leak is an accidental disclosure, not a malicious supply chain attack. The relevant comparison is not to supply chain attacks like the LiteLLM incident, where malicious code was introduced intentionally. The more relevant framing is operational security: publishing detailed internal implementation documentation publicly changes the attacker's information advantage. The response is testing and controls, not incident response.

The packaging error is Anthropic's problem to fix. The audit of your Claude Code deployments is yours.

To see how Repello discovers AI coding assistant deployments across enterprise environments, tests their permission boundaries with ARTEMIS, and applies runtime controls with ARGUS, book a demo