Claude Code 源码泄露了,花了一天读完全部源码 (English)

Generated: 2026-06-20 17:44:40

---

Okay, I reviewed this piece as an editor. Fact-wise, no fatal errors jumped out—the Claude Code source code leak through the source map file, the file and line counts, and the descriptions of core module functionality all check out against public information. I can't verify every data point line by line, but since the author is a developer who actually dug into the code, details like "1729 lines" and "228KB" likely come from real stats, so they can stay.

As for "AI flavor," the original text is already pretty vivid. You don't see formulaic phrases like "it is worth noting" or "in conclusion." The parallel constructions are not excessive, but here and there the wording feels a bit too crafted. I've tweaked the rhythm slightly, without touching the jokes or the tone, to make the sentences flow easier.

Below is the revised version. Changes are marked with 【】in the original, but I've stripped those marks for the output:

---

Claude Code's source code is out in the open! I stayed up all night reading it, and these designs made me slap the table

Hey, guess what? Yesterday I was tearing my hair out over a bug caused by an agent—the kind where you fix it ten times and it still crashes, and you just want to smash your keyboard. Then I scrolled past a tweet and my eyes went wide: the npm package @anthropic-ai/claude-code version 2.1.88 still had a cli.js.map file in it, pointing straight to Anthropic's R2 storage bucket, and—no authentication!

I unzipped it: 1,903 files, 510,000 lines of TypeScript, all laid out.

My mouse froze. What did I do for the next eight hours? Forget about debugging that bug. I downloaded everything and started reading!

It felt like a museum left wide open at midnight with a flashlight conveniently placed in your hand. As a heavy Claude Code user who also builds agents myself—this was a martial arts manual delivered to my doorstep. Heart racing, I dove in.

But after reading it, my feelings are mixed. 【Some parts are so elegant I wanted to applaud, others are so messy I wanted to storm into the Anthropic office and refactor for them.】 This article isn't hype or hate—it's just about the hardcore designs that made me think, over and over, "Damn, that's clever."

---

Agentic Loop: One while(true) runs the whole system—believe it?

The most central file is src/query.ts, 1,729 lines total.

I've written agent loops before, but I never imagined a single while(true) could handle this much work. The entire state machine for conversation management is embedded in that loop—message preprocessing, streaming model responses, dispatching tool calls, handling user interruptions. All in one pot.

The structure looks simple, but each layer carries a surprising amount of weight. It even has a dual-mode tool execution built in: one strictly serial, one "parallel when possible." When running in parallel mode, there's a mechanism called cooldown to control concurrency, with one goal in mind—don't blow through the token quota.

1,729 lines in a single file. Can you believe that? Maintaining it must be a nightmare. But you also can't help but admire it—it holds together purely through function splitting inside the module. You can tell this code wasn't written in a day; features just piled up over time, crammed in bit by bit.

Who hasn't been in that kind of project? I laughed when I read it, because I, too, have stuffed thousands of lines into one file, promising myself "I'll split it next time."

---

Four Levels of Context Compression: This isn't just saving money, it's squeezing every last token

Under src/services/compact/, I found four layers of compression strategy. The names are blunt, but the more I read, the more my jaw dropped:

• MicroCompact — Fires immediately after every call, compresses only the oldest few turns. Extremely lightweight. Like washing the dishes right after a meal.
• Full Compact — Fires when you hit the warning line. Full compression. Comes with a PTL (Prompt Token Loss) emergency strategy, meaning: it's okay to lose a bit, but the system cannot crash.
• Session Memory Compact — Specifically compresses the 10 sections of session memory, each with a budget of 12K tokens. That precise?
• Auto Compact — Fires automatically in the background, predicting token consumption trends. Yes, predicting! Not waiting for a disaster to start firefighting.

But the part that really made me slap the table wasn't the four layers themselves—it's how they transition between states. MicroCompact only triggers Full when it can't keep up; if Full fires too often, Auto kicks in automatically. I dug into the Auto Compact code and found a three-level alert system inside—each level uses a different degree of compression aggressiveness. The source is three functions named budget, which estimate current usage, reserved amount, and peak usage. This design is at least two tiers better than my handwritten strategy.

【Oh, and one detail they designed with real care】: during compression, they preserve the position of cache_control markers. Why? Because if the prompt cache alignment changes, the first-token latency spikes immediately. That's something you only learn the hard way. I'm guessing they tested it countless times before adding this seemingly subtle but absolutely critical logic.

You see, real production-grade optimization is always hidden between the lines.

---

Forking Sub-Agents: The Brutal Beauty of Byte-Level Consistency

Have you ever seen a 228KB TypeScript file? Now I have. src/tools/AgentTool/AgentTool.tsx, 228KB—probably one of the largest single files I've ever looked at. Why is it so big? Because it contains six operation modes, each with its own implementation of the sub-agent lifecycle.

But the part that made me stop and read over and over was forkSubagent.ts.

What does this module do? It forks a process-level Agent while guaranteeing byte-level consistency. That means all context state of the parent Agent—system prompt, tool registration, session memory snapshot—must be completely copied to the child process. And it's not something you can do with a simple JSON.stringify.

At first I thought it used v8 serialization. Looking closer, no. They use message channel fragmentation plus Manifest indexing. It's a bit convoluted, but the core idea I understood: the parent only passes the minimal necessary state, and the child Agent pulls the full context from storage on its own.

What's the benefit? Forking is extremely fast, and the parent Agent doesn't need to pause and wait at all. The cost? The child Agent has a millisecond delay on startup. But after weighing the tradeoffs, they decided the delay is worth it.

When I read this, I slammed the table—this is what engineering decisions look like: not chasing perfection, but chasing the most reasonable tradeoff.

---

Permission Pipeline: 10 Decision Steps, 3 Rejections and It Shuts Up

src/utils/permissions/permissions.ts—reading this file made me laugh out loud. It implements a permission decision pipeline. I counted—ten steps in total:

1. Command classification
2. Dangerous pattern matching (dangerous prefixes)
3. Check user's history of rejections
4. Whitelist/blacklist
5. Sandbox compatibility
6. Final decision

…and a bunch more. I got tired just counting.

The most interesting part is denialTracking.ts: it records your rejection history. The rule is: after three consecutive rejections of the same type, it automatically rejects for you until you manually reset it. I tested it with my own project—three times came fast. It's a bit aggressive, but it definitely reduces a lot of popup annoyance. Think about it—if you've rejected the same kind of operation three times in a row, stop bugging me.

And here's something I found "so simple it's kind of adorable": dangerousPatterns.ts maintains a list of dangerous command prefixes, like rm -rf /. I checked—only a few dozen entries. Do you think this was AI-generated? No, I'm guessing the Anthropic security team compiled it by hand. The truly dangerous Linux commands are just that many. The approach is crude, but reliable.

Sometimes the dumbest method is the smartest method.

---