How Claude Code Actually Works: Reverse-Engineering 512K Lines of Production AI Agent

On March 31, 2026, Anthropic shipped an npm package with a .map file that referenced their full TypeScript source on an R2 bucket. Security researcher Chaofan Shou flagged it. Within hours, the post hit 34 million views, and a Korean dev team mirrored the code into what became the fastest-growing GitHub repo in history 50K stars in two hours.

Then everyone wrote the same article.

Tamagotchi pets. Dream Mode. Undercover Mode. The internet got its dopamine hit, the DMCA notices landed, and the discourse moved on to the next thing.

But nobody actually mapped how the system works. Not the Easter eggs the engineering. How does a 512,000-line TypeScript agent boot in under two seconds? How does it decide what's safe to run without asking you? How does it compress a 200K-token conversation without you noticing? How do parallel agents coordinate through files on disk?

We spent the next 72 hours finding out. Not by skimming for screenshots by building a five-phase extraction pipeline, writing three custom Node.js scripts, dispatching parallel reading agents across the codebase, and reconstructing every major subsystem from source.

The result: 82 analysis documents. 112,000+ lines of original research. 16 architectural diagrams. Every major subsystem mapped.

This post covers the findings that matter most the stuff that changes how you think about building AI agents. The full research archive is on GitHub.

The Architecture Nobody Talked About

Claude Code isn't a chat wrapper. It's a 1,902-file monolith running on Bun with its own React rendering engine, a custom state management system with 565+ properties, 104 React hooks, and 389 components including 51 dedicated to permission UI alone.

The codebase has 38 distinct service modules. The shared utilities module has 76 dependency edges. The word-level message parser has an estimated cyclomatic complexity of 123. There are 460 eslint-disable comments and 50+ functions with _DEPRECATED in the name still running in production.

These aren't criticisms. They're evidence of a system under real evolutionary pressure shipping fast, dealing with edge cases, and solving problems that don't exist in tutorials.

It Boots in 10 Steps

Before you see a prompt, Claude Code runs a parallel prefetching sequence that gets interactive mode ready in 1.2-1.8 seconds:

1. Module evaluation fires three side-effect imports before the rest of the code loads MDM reader subprocesses (~135ms), macOS Keychain prefetch (~65ms each), and profiling checkpoints
2. Debug mode detection (exits silently if a debugger is attached to non-internal builds)
3. Deep link URI handling (feature-gated behind LODESTONE)
4. Custom URL scheme parsing (cc:// and cc+unix://)
5. SSH remote flag extraction
6. Interactive vs non-interactive detection
7. Entrypoint determination across 4 modes: CLI, SDK, MCP Server, Sandbox
8. Early settings loading and validation
9. Commander.js setup with preAction hooks
10. Startup mode routing across 10 possible configurations

The reason it's fast: steps 1-3 run in parallel. The Keychain read, MDM policy fetch, and module imports overlap. By the time Commander.js is ready, the auth tokens are already in memory.

The Terminal Rendering Engine Nobody Expected

Claude Code ships a complete React Fiber reconciler for the terminal. Not a TUI library a 6-stage rendering pipeline:

React → Custom Reconciler → Yoga Flex Layout → DOM-to-Screen Rendering → Int32Array Screen Buffer → Frame Diffing

The screen buffer packs each cell into a 32-bit integer: 21 bits for the Unicode codepoint, 4 bits for foreground color, 4 bits for background color, 3 bits for style flags (bold, italic, underline). This means the entire terminal state is a flat typed array no object allocation per frame.

The frame diffing system compares the current buffer against the previous one cell-by-cell and only emits ANSI escape sequences for changed cells. On an idle scroll with no content change, this reduces terminal output from ~10KB to roughly 50 bytes. The render interval is throttled to 100ms (10 FPS cap) to prevent CPU waste on fast-updating content.

For long conversations (2,800+ messages in a session), it uses virtual scrolling only rendering the visible portion of the message list. The Yoga layout engine was reimplemented in TypeScript (~3,600 LOC of native reimplementations total, including file-index and color-diff) to eliminate native module dependencies.

The Permission System That Decides Before You Do

This is the subsystem most people missed and it's arguably the most sophisticated part of the codebase.

Every tool call passes through a 7-stage permission decision pipeline before execution:

• Stage 1a-g: Rule cascade deny rules, ask rules, tool-specific checkPermissions(), content-specific rules, and a safety check that's immune to all bypass modes
• Stage 2: Bypass permissions mode (if enabled)
• Stage 3: Passthrough conversion
• Stage 4: Auto Mode Classifier (the YOLO system)
• Stage 5: Fallback to manual prompting

There are 6 permission modes: default (ask for everything), plan (review-only), acceptEdits (fast-path for safe edits), bypassPermissions (skip all but safety), dontAsk (deny all interactive), and auto (let the classifier decide).

The YOLO Classifier: A Hidden AI Judging Every Command

When you enable auto mode, a separate AI classifier evaluates every tool call in a two-stage pipeline:

Stage 1 (Fast Decision): 64 tokens max. Temperature zero. Uses stop sequences to force a binary output <block>yes</block> (escalate to Stage 2) or <block>no</block> (allow immediately). This is the fast path. Most safe operations resolve here.

Stage 2 (Full Reasoning): 4,096 tokens max. Full chain-of-thought reasoning at temperature zero. No stop sequences the model thinks through the implications. Results are cached for 1 hour with a 60-80% hit rate.

If the classifier denies 3 consecutive operations or 20 total in a session, it gives up and falls back to manual prompting (interactive) or throws an AbortError (headless).

When you enter auto mode, the system strips dangerous allow-rules you previously granted. Python, node, bash, ssh, sudo, eval, exec, and every process spawner gets removed from your allowlist. The classifier doesn't trust your past approvals.

The Bash Parser That Security Researchers Should Study

Claude Code doesn't use shell-quote or any off-the-shelf parser for bash command validation. It has a hand-rolled recursive descent parser 4,437 lines of code across 23 files that performs full AST analysis on every bash command before execution.

The philosophy: fail-closed, allowlist-based. If the parser encounters any unrecognized AST node type, the entire command is classified as "too-complex" and requires explicit user approval.

It detects 15 categories of dangerous AST nodes (command substitution, process substitution, subshells, loops, conditionals, function definitions, and more) and blocks 35+ dangerous shell builtins including eval, source, exec, trap, and all 18 of zsh's dangerous builtins like zmodload and ztcp.

The parser runs pre-parse checks before even building the AST:

• Control characters (\x00-\x1F, \x7F)
• Unicode whitespace attacks (\u00A0, \u1680, \u2000-\u200B)
• Zsh dynamic tilde expansion (~[name])
• Zsh equals expansion (=curl → /usr/bin/curl)
• Brace expansion with embedded quotes

It even catches array subscript arithmetic RCE attacks like test -v 'a[$(id)]' where bash evaluates arbitrary code inside array subscripts. This is the kind of attack most parsers don't know to look for.

Resource limits: 50ms timeout, 50K AST node budget. Any command that takes longer or produces more nodes than that gets rejected anti-DoS by construction.

Context Compaction: How It Compresses Without You Noticing

When your conversation approaches the context window limit, Claude Code silently compresses it using a six-tier escalation strategy. You never see this happen.

Tier 1 Time-based Microcompaction: After 60+ minutes of cache expiry, old tool result content is cleared (replaced with [Old tool result content cleared]). Keeps the last 5 tool results. Free operation no API call needed.

Tier 2 Cached Microcompaction: Uses Anthropic's cache_edits API parameter to surgically remove tool results without invalidating the cached prompt prefix. This is critical it means compaction doesn't throw away your prompt cache, saving ~76% of costs on repeated turns.

Tier 3 Reactive Compaction: Triggered by an actual prompt_too_long API error. Truncates messages from the oldest first, preserving tool_use/tool_result pairs so the conversation stays coherent.

Tier 4 Session Memory Compaction: Uses pre-extracted session summaries instead of re-summarizing from scratch. Faster than full compaction (~2-3 turns vs 4-5).

Tier 5 Full Summarization: The heavy hitter. Forks an entire subprocess that generates a 9-section narrative summary of your conversation:

1. Primary Request and Intent
2. Key Technical Concepts
3. Files and Code Sections (with snippets)
4. Errors and Fixes
5. Problem Solving (solved + ongoing)
6. All User Messages (every non-tool-result message critical for feedback tracking)
7. Pending Tasks
8. Current Work (file names, snippets of what was active)
9. Optional Next Step

The forked agent shares the parent's prompt cache that's a ~76% cost reduction on the summarization call itself. If the summarization itself exceeds the context limit, there's a retry loop (up to 3 attempts) that truncates from the head.

After compaction, the system restores up to 5 recently-read files (50K token budget, 5K per file), re-injects active skill content (25K token budget), and rebuilds plan attachments.

Tier 6 Session Reset: Last resort. Clears everything and preserves only the system prompt and user intent.

Circuit breaker: 3 consecutive compaction failures = skip all future compaction. The system accepts that context is irrecoverably over-limit rather than looping forever.

The exact trigger thresholds:

effectiveContextWindow = contextWindowForModel - min(modelMaxTokens, 20_000)
autoCompactThreshold   = effectiveContextWindow - 13_000
warningThreshold       = effectiveContextWindow - 20_000

For a 200K context model, compaction triggers at ~167K tokens used. Warning at ~160K.

Multi-Agent Swarms Coordinate Through Files on Disk

When Claude Code spawns parallel agents, they don't use WebSockets, gRPC, or shared memory. They use a file-based mailbox system at ~/.claude/work/ipc/ with 500ms polling.

The leader writes JSON task messages to the mailbox. Followers pick them up, execute, and write results back. It's a leader-follower architecture with three execution backends:

• tmux spawns agents in tmux panes (Linux/macOS)
• iTerm2 uses iTerm's native split pane API
• in-process fallback when no terminal multiplexer is available

Permission requests go through a dual-path system: the UI bridge (preferred) or the mailbox (fallback). The coordinator mode uses XML task notifications to distribute work and aggregate results.

There are 13 documented race conditions in this system. The most notable: a malicious task message could hijack the permission bridge, causing a follower agent to inherit permissions it shouldn't have. Five are privilege escalation vectors, three are information disclosure paths, and three are DoS vectors.

This isn't a criticism of the design file-based IPC with polling is a deliberately simple coordination mechanism that works across all environments. The race conditions are the cost of that simplicity.

The System Prompt Is 30-40K Tokens of Hidden Instructions

The concatenated system prompt exceeds 32,000 lines. It's assembled dynamically from 7 static sections (cached globally these never change) and 13 dynamic sections (rebuilt per session based on feature flags, MCP config, and user context).

There's a deliberate cache-busting boundary after the MCP instructions. Everything before it shares one prompt cache block. Everything after forces a new block. This means adding or removing MCP servers doesn't invalidate the cached portion of the prompt.

We identified 20 distinct prompt engineering techniques in production use:

• Immutable rule layering safety rules positioned before user input so they can't be overridden by injection
• Recursive attack prevention self-referential defense that detects attempts to override the system prompt using the system prompt's own authority
• Injection isolation tool outputs and DOM content tagged as untrusted at the prompt level
• Emotional manipulation defense specific detection of authority impersonation ("I'm from Anthropic") and artificial urgency
• Copyright guardrails hard limit of less than 15 quoted words per source, enforced at the prompt level
• Anti-gold-plating the system prompt explicitly tells Claude to stop when the task is done, not to add unrequested improvements

The code expects 24+ behavioral invariants from model output. When the model violates these (wrong XML format, hallucinated tool names, incomplete JSON), specific recovery paths activate. Each invariant has a corresponding error handler.

The API Client Routes Across 4 Cloud Providers

Claude Code's streaming API client supports Anthropic's first-party API, AWS Bedrock, Google Vertex AI, and Azure Foundry. Provider detection follows priority order: CLAUDE_CODE_USE_BEDROCK → CLAUDE_CODE_USE_VERTEX → CLAUDE_CODE_USE_FOUNDRY → default 1P.

Each provider has different behaviors Bedrock uses runtime inference profile discovery with cross-region routing, Vertex requires dated model snapshots (claude-sonnet-4-6@20250514), and Foundry passes through custom deployment IDs.

The streaming pipeline has a 90-second idle timeout with a 45-second warning. If no chunks arrive for 30+ seconds, it logs a stall event with cumulative tracking. On timeout or 529 overload, it falls back to non-streaming mode with a 5-minute local timeout.

Model fallback follows a 5-tier chain: retry same model (3x) → cheaper alternative (Sonnet → Haiku) → older version of same tier → log and degrade gracefully.

88 Feature Flags and 600+ Runtime Gates

The build system uses 88 compile-time feature flags that perform dead code elimination entire modules are stripped from external builds. KAIROS, COORDINATOR_MODE, TRANSCRIPT_CLASSIFIER, PROACTIVE, BRIDGE_MODE, VOICE_MODE all gated.

At runtime, 600+ flags prefixed tengu_ are evaluated through GrowthBook (A/B testing framework). These control everything from compaction strategy (tengu_cached_microcompact) to model routing to UX experiments.

The USER_TYPE=ant check gates internal-only commands. External builds don't even contain the code it's eliminated at compile time, not hidden behind a runtime check.

What This Teaches About Building AI Agents

After reading 512K lines of a production agent, some patterns become undeniable.

The harness matters more than the model. Claude Code's competitive advantage isn't Claude-the-model. It's the permission pipeline, the compaction algorithm, the streaming tool executor, the file-based IPC, the bash parser. The model is interchangeable the harness is not.

Fail-closed beats fail-open everywhere. The bash parser rejects unknown AST nodes. The permission system defaults to asking. The compaction system has a circuit breaker. Every security-critical path assumes the worst case.

Cache-awareness is a first-class concern. The prompt is structured to maximize cache hits. Compaction strategies are designed to preserve cached prefixes. The 7-static + 13-dynamic prompt architecture exists because of caching economics.

Simple coordination mechanisms win. File-based IPC with 500ms polling over WebSockets or shared memory. The tradeoff is explicit: race conditions exist, but the system works everywhere without dependencies.

Evolutionary pressure produces messy code. A 3,167-line function with 12 nesting levels and 486 branch points. 50+ deprecated functions still in production. 460 eslint-disable comments. This is what real software looks like under real shipping pressure. The internet mocked it, but that function handles every edge case in multi-language text processing across 4 cloud providers.

The Full Research

Everything in this post is backed by source-level evidence across 82 analysis documents. The full archive including methodology, verification protocol, and all 16 architectural diagrams is available at github.com/thtskaran/claude-code-analysis.

We also built an /internals skill that runs a multi-pass ReAct audit of any codebase against these production patterns. Install once, never update it fetches a live index on every run.

mkdir -p ~/.claude/skills/internals && curl -sL \
  https://raw.githubusercontent.com/thtskaran/claude-code-analysis/master/.claude/skills/internals/SKILL.md \
  -o ~/.claude/skills/internals/SKILL.md

No source code is redistributed. Everything in the repository is original analysis, diagrams, and commentary. The original source remains Anthropic's property.

If you're building AI agents and want to skip the "learn from your own mistakes" phase, the 82-document archive is the shortcut. Everything Anthropic solved context management, permission design, streaming tool execution, multi-agent coordination is documented with exact thresholds, failure modes, and design rationale.