Hello everyone, I'm PaperAgent, not an Agent!
Yesterday, Anthropic's Claude Code source code was effectively open-sourced, and presumably everyone has seen the news. It's already reached 76k stars.
After restoring 4,756 source files from cli.js.map, I spent several weeks immersed in this codebase, dissecting its system prompts, Agent scheduling chains, tool execution pipelines, permission models, Hook mechanisms, and Skill ecosystem like an archaeological excavation.
To be honest, before diving in, I anticipated it would be impressive. But after completing the analysis, my reaction went far beyond merely "impressive". What I see is a generational difference in design philosophy.
Many assume Claude Code's strength lies in the model itself, or in some "mysterious system prompt." But after examining the source code, you'll realize: neither is correct.
Its strength stems from a meticulously designed, production-engineered Agentic Harness.
This concept isn't something I invented. Anthropic's official documentation states it clearly:
Translation: The entire Claude Code system is the Harness wrapped around Claude.
It provides not just a chat interface, but a complete runtime framework for "turning models into executable Agents": how tools are called, how permissions are controlled, how context is managed, how subtasks are orchestrated, how hooks intercept operations. All of these are institutionalized and productized within this harness.
When many people replicate coding agents, they only extract a system prompt, a file editing tool, Bash, and a CLI shell. But after dissecting Claude Code's source code, I realized: these aren't what create the real gap.
In this article, I'll break down and explain in detail those "real gaps" I discovered in the source code.
https://x.com/ScarlettWeb3/status/2038940065523552263/photo/1
01 It's Not Just a Prompt, But an Operating Model
First, let's address the most easily misunderstood question: how mysterious is Claude Code's system prompt?
I initially assumed that opening prompts.ts would reveal some "divine oracle." But when I actually opened it, I found a Prompt Assembly Architecture.
getSystemPrompt() doesn't simply return static text. It does far more complex work:
First, it assembles static prefixes: identity positioning, system specifications, task philosophy, risky action norms, tool usage specifications.
Then it injects dynamic suffixes: session guidance, memory, MCP instructions, scratchpad, token budget, output style.
Furthermore, the source code explicitly contains SYSTEM_PROMPT_DYNAMIC_BOUNDARY, with comments stating: content before the boundary should be cacheable when possible, while content after the boundary is session-specific and shouldn't be modified arbitrarily, otherwise cache logic will be disrupted.
What does this mean?
It means Anthropic has engineered optimizations for token costs and cache hit rates even within the system prompt. They don't stuff "everything conceivable" into the prompt. Instead, they treat prompts as orchestrated runtime resources.
Static portions are suitable for caching, while dynamic portions are injected on demand. This approach is cost-controlled on a completely different dimension than "one-shot" prompts.
But this is just the tip of the iceberg.
https://x.com/jungeAGI/status/2039007004333932929
02 It Institutionalizes Good Behavior
Here is another detail that impressed me: the getSimpleDoingTasksSection() essentially represents Anthropic's institutionalized expression of AI engineer behavioral norms.
It explicitly constrains the model:
The significance of this section goes far beyond "detailed prompt writing." It reveals an essential truth: Claude Code doesn't leave "good habits" to the model's improvisation, but writes them into rules for enforced execution.
Many coding agents are unstable not because the model cannot write code, but because of behavioral divergence. The same requirement might work today, but tomorrow trigger a spurious over-refactoring, adding a bunch of comments, or incidentally modifying unrelated files.
Claude Code uses this institutionalized constraint to minimize behavioral variance.
Similarly institutionalized are risky action norms: destructive operations, hard-to-reverse operations, modifying shared states, and uploading third-party tools are all marked as "requires confirmation." The source code explicitly requires: investigate unfamiliar states before acting. Do not brutally delete merge conflicts or lockfiles.
This represents blast radius thinking, writing damage scope directly into the model's behavioral norms.
03 It Understands Context is a Scarce Resource
Another point that repeatedly impressed me during the source code analysis: Anthropic's degree of cherishing context far exceeds most people's imagination.
Numerous designs revolve around context optimization:
System prompt's dynamic and static boundary plus cache boundary.
Fork paths sharing parent thread's prompt cache.
Skills injected on demand, not stuffed into global prompts.
MCP instructions dynamically injected based on connection status.
Function result clearing and summarize tool results.
Compact, transcript, and resume mechanisms.
Among these, the fork path design is particularly exquisite.
When the model decides to fork a sub-agent, the source code follows a specifically optimized path: inheriting the parent thread's system prompt and tool definitions, maintaining API request prefix byte-identical to improve prompt cache hit rates.
The comments state it bluntly: forking is cheap because it shares prompt cache.
What level of optimization is this?
Ordinary people only think subtasks need to run, but Claude Code considers that subtasks need to run and should reuse the main thread's cache where possible, without burning tokens unnecessarily.
This is product-level system thinking, not demo-level implementation.
04 Agent Division of Labor: Not a Universal Worker, But Specialists
Many assume Claude Code's Agent is a "universal worker", meaning you give it a task and it disassembles, executes, and verifies on its own.
But after examining the built-in agents, I discovered: nothing could be further from the truth.
The source code defines at least these built-in Agents:
Explore Agent: Pure read-only mode, specifically for code exploration. Its system prompt explicitly prohibits creating files, modifying, deleting, or moving files, or using redirects to write files. Bash is restricted to read-only operations like ls, git status, git log, git diff, find, grep, cat, head, and tail.
Plan Agent: Pure planning, no editing. Its responsibility is to understand requirements, explore the codebase, and output step-by-step implementation plans, finally listing Critical Files for Implementation.
Verification Agent: This amazed me most. Its system prompt states at the outset: your job is try to break it. Not "confirm the implementation looks fine," but actively seek flaws. It mandatorily requires: run builds, run test suites, run linters and type-checks, perform specialized verification, run browser automation or curl for actual testing, output each check's command and observed results, and finally output VERDICT: PASS or FAIL or PARTIAL.
This design solves a long-standing problem in many systems: when one agent handles research, planning, implementation, and acceptance, none of these tasks remain stable.
Claude Code's solution is explicit division of labor. Explore only reads, Plan only plans, Verification only performs destructive validation, with general tasks handled by the General Purpose Agent.
This isn't merely "having three more agents", but specialization thinking in architecture.
05 Scheduling Chain: AgentTool to runAgent to query
After dissecting the Agent scheduling chain, my understanding of "Agentic Harness" deepened further.
The entire chain can be abstracted as:
AgentTool.call()'s responsibilities go far beyond "forwarding to sub-agents". It is essentially the agent orchestration controller, handling permission filtering, MCP dependencies, worktree isolation, foreground and async task registration, and numerous other concerns.
Meanwhile, runAgent() is a complete sub-agent runtime constructor: initializing agent-specific MCP, filtering context messages, handling read-only agent claudeMd slimming, constructing permission modes, executing SubagentStart hooks, preloading frontmatter skills, merging agent MCP tools, and finally calling query() to enter the main loop.
What impressed me most is the abundance of product-level details in the source code: recordSidechainTranscript, writeAgentMetadata, registerPerfettoAgent, cleanupAgentTracking, killShellTasksForAgent, cleaning cloned file states, and cleaning todos entries.
Anthropic doesn't merely make subagents "run", but incorporates transcript, telemetry, cleanup, and resume into formal lifecycles.
This is product-level runtime.
06 Skills, Plugins, Hooks, MCP: Not Just Installable, But Model-Aware
Many systems have plugins, tools, and external protocols, but the model itself doesn't know what extensions exist, when to use them, or how to use them.
Claude Code is different.
Through skills lists, agent lists, MCP instructions, session-specific guidance, and command integration, it lets the model know what its extension capabilities are.
Skills aren't documentation, but prompt-native workflow packages: markdown prompt bundles plus frontmatter metadata plus declarable allowed-tools, injected on demand into current context.
Plugins aren't merely external add-ons, but extension mechanisms combining prompts with metadata and runtime constraints.
Hooks are the runtime governance layer: PreToolUse can rewrite inputs, directly provide allow or ask or deny decisions, or even preventContinuation. PostToolUse can append messages and inject additional context.
MCP isn't merely a tool bridge, but can simultaneously inject tools plus instructions on how to use them. getMcpInstructionsSection() incorporates these instructions into the system prompt.
This means MCP's value far exceeds simple tool registries. It is simultaneously a behavior specification channel.
07 Tool Execution Chain: Not Direct Invocation, But Pipeline
The final impressive section is the tool execution chain in toolExecution.ts.
It isn't "model decides, then directly run function." The actual chain is approximately:
This is a standard runtime pipeline, not a direct function call.
PreToolUse hooks have particularly powerful interception capabilities: hooks can rewrite inputs called updatedInput, directly provide permissionBehavior such as allow or ask or deny, or even preventContinuation, blocking process continuation even without denial.
Meanwhile, the resolveHookPermissionDecision() logic ensures that hook allow doesn't automatically bypass settings rules. If user interaction is required but the hook doesn't provide updatedInput, it still follows the unified permission flow.
Hooks are powerful, but don't bypass the core security model.
Epilogue: The End State of Agentic Harness Design
After reviewing these 4,756 files, I've been contemplating one question: what is the end state of Agentic Harness design?
If I had to answer in one sentence: It is the system that unifies prompt architecture, tool runtime, permission model, agent orchestration, skill packaging, plugin system, hooks governance, MCP integration, context hygiene, and product engineering.
When many people replicate coding agents, they only extract a system prompt, a file editing tool, a bash tool, and a CLI shell.
But Claude Code's true moat is the Harness that institutionalizes, engineers, and productizes all of these.
Missing any single component degrades the experience. Getting them all right, deep, and scalable requires far more than "prompt writing" capability. It demands complete system architecture thinking.
Perhaps this is the end state of Agentic Harness design: not a smarter model, but a more complete system.