The Claude Code Leak: What the Source Code Actually Reveals

I’ve spent the past few days going through the community analysis of the Claude Code source that was exposed in the March 31 sourcemap leak. I’m not going to point to the source itself, Anthropic’s DMCA takedown campaign has cleared most of the GitHub copies anyway, but enough public discussion happened before the repositories were removed that there’s a coherent picture of the architecture worth analyzing.

This is what I found interesting, written from a developer’s perspective who works with AI coding tools and cares about how they’re built.

The Agent Loop Is More Structured Than It Looks

From the outside, Claude Code feels like a responsive chat interface with tool use. The source reveals the internal loop is considerably more structured than that.

The core reasoning loop runs in cycles that each have a defined structure: build context, call the model, parse the response, decide whether to invoke tools, invoke them if so, observe results, and decide whether to continue or surface output. For an agent this is a fairly standard ReAct-style implementation, but the detail is in how each phase is implemented.

Context building goes well beyond “append the conversation history.” There’s a lot of logic around what to include in each API call, how to summarize or compress prior context to stay within token budgets, and how to prioritize recent tool outputs over older conversation turns. The result is that what the model actually sees on each call is a carefully curated representation of the conversation state rather than a raw log.

The tool invocation handling has explicit retry and error recovery logic. When a tool call fails, a file doesn’t exist, a shell command exits non-zero, there’s structured logic for deciding whether to retry, report the error, or reframe the problem. This gives the agent resilience that you don’t get from a naive “call tool, check result” implementation.

The Verification System

The most-discussed aspect of the leak in the developer community was the verification system, what several people called “DRM-like” in their analysis.

Claude Code checks authentication state and feature entitlements throughout the execution path, well beyond the initial startup. There’s a set of capabilities that are gated behind account tier, some agent behaviors, some context window sizes, some features. The verification logic is distributed through the codebase rather than centralized in one auth module.

This explains something I’d noticed in practice: Claude Code’s behavior is controlled by more than the system prompt or a simple on/off plan check. There are granular capability flags that get checked against the account state at runtime.

What this architecture means for security researchers is interesting: the capability gates aren’t purely server-side. There are client-side checks that enforce the same boundaries. Security through obscurity isn’t great, but it does mean the entitlement model is more sophisticated than “the server just limits your API calls.”

How the Skill System Works Internally

The slash-command skill system, where /skill-name invokes a skill from a SKILL.md file, is visible in the public interface, but the internals are where it gets more interesting.

Skill loading reads the SKILL.md file at invocation time and dynamically adds its content to the system prompt for that conversation turn. Skills aren’t compiled or pre-processed, they’re text injection at the prompt level. This is elegant in its simplicity: skills are just markdown files that modify the model’s behavior by giving it different instructions.

The skill resolution order, checking .claude/skills/ in the project directory before ~/.claude/skills/, is also in the source, and it matches the precedence documented in our guide to Claude Code configuration and context. This is how project-level skills override global ones, which was documented behavior, but seeing the resolution stack makes the override mechanics clearer.

There’s also a skill dependency mechanism, where skills can declare dependencies on other skills and the loader will resolve and include them automatically. This isn’t documented in the public API but explains why some skills seem to pull in capabilities that aren’t explicitly described in their SKILL.md file.

Context Management: What the Model Actually Sees

Context management is where I spent the most time in the community analysis, because it’s where the real craft is in building a capable coding agent.

The source shows a multi-tier context strategy. At the innermost tier is the current conversation, recent turns, the current task, recent tool outputs. Outside that is project context, the contents of CLAUDE.md files, recently read files, the output of context-building tools like directory listings. At the outer tier are longer-term memories and persistent context that gets summarized and compressed over time.

Each tier has a budget, and when budgets are under pressure, there’s a compression strategy for each tier. Recent tool outputs get summarized, while file contents that haven’t been referenced recently get dropped. The CLAUDE.md files get priority because they contain instructions that should persist, which is the practical argument for writing a good one in the first place, covered in our complete guide to Claude Code.

The model doesn’t know which tier any piece of context comes from, it just sees a coherent prompt. The agent’s job is to build that prompt such that the model has the information it needs for the current task without wasting context on irrelevant history.

What Other Tools Can Learn

I’ve been building with AI coding tools long enough to have opinions about where the design choices here are interesting versus where they’re standard.

The multi-tier context management with explicit budgets and compression is the most transferable pattern. A lot of simpler agent implementations just stuff everything into context until they hit the limit and then fail. The structured approach to context budgeting is why Claude Code can maintain coherence on long, multi-step tasks.

The distributed verification rather than centralized auth is a design choice that reflects the complexity of the feature model. Whether it’s the right choice depends on how you value development simplicity versus security architecture, centralized auth is easier to reason about, but the granular capability flags are more flexible.

The skill system’s text-injection approach is simple enough to implement in any agent. The dependency resolution between skills is a nice extension that I haven’t seen documented in other tools, though it’s not a novel concept.

---

The accidental leak gave a rare view into how a production AI coding tool is actually built. The architecture is more sophisticated than the public-facing interface suggests, not in a way that should concern users, but in the sense that there’s real engineering depth in the parts you don’t normally see. That’s worth knowing regardless of how the code became visible.