Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems

• Claude Code extends coding assistance from suggestions to autonomous multi-step planning, tool use, file modification, result evaluation, and iterative task completion.This shift creates architectural requirements involving safety, context management, extensibility, and delegation that completion-based tools do not face.Source: §1 · p. 1
• Because Anthropic provides user-facing but not detailed architectural documentation, the study uses source-code analysis to identify Claude Code’s design decisions and mechanisms.An internal survey found that about 27% of Claude Code-assisted tasks would not have been attempted without the tool.Source: §1 · pp. 1–2
• The analysis identifies five human values and thirteen design principles, then traces recurring design questions through Claude Code’s seven-component structure and five-layer subsystem architecture.The study examines reasoning location, iteration, safety, extensibility, context, delegation, and session persistence using source-level evidence.Source: §1 · p. 2
• Comparing Claude Code with OpenClaw (Steinberger and OpenClaw Contributors, 2026) and Hermes Agent shows how deployment contexts, product goals, safety requirements, and user assumptions produce different architectural answers.The comparison spans six design dimensions and seeks guidance for designing future agent systems across commercial and open-source settings.Source: §1 · p. 2
• Claude Code’s core runtime is a while-true loop with state management, while safety, extensibility, context management, delegation, and persistence subsystems contain most of the implementation.The running example, “Fix the failing test in auth.test.ts,” activates tool invocation, permissions, context selection, iterative repair, delegation, and session persistence.Source: §1 · p. 2

2.1 Five Values and Philosophies

• Claude Code’s five motivating values are human decision authority, safety/security/privacy, reliable execution, capability amplification, and contextual adaptability.The values distinguish human control from protective obligations, emphasize verification and dependable operation, expand human capability, and adapt to evolving user contexts.Source: §2.1 · pp. 3–4
• Human decision authority is implemented through observation, approval, interruption, auditing, and bounded autonomy, while safety addresses harm even when users are inattentive or mistaken.Users approve 93% of permission prompts, motivating defined boundaries such as sandboxing and auto-mode classifiers rather than relying only on repeated approvals.Source: §2.1 · p. 3

2.2 Design Principles

• Thirteen design principles make these values operational, distinguishing Claude Code from explicit state-graph orchestration, container isolation, and Git-centered safety through minimal scaffolding, layered enforcement, and composable extensibility.Claude Code combines values-based judgment with deny-first defaults and progressive context management rather than imposing explicit planning graphs.Source: §2.2 · pp. 4–5

2.3 From Values to Architecture

• The value-to-architecture mapping motivates deny-first evaluation, durable append-only state, context management, extensibility, recovery, and isolated subagent boundaries across the system.The architecture also omits explicit planning graphs, a unified extension mechanism, and restoration of all session-scoped trust state after resume.Source: §2.3 · p. 5

2.4 A Cross-Cutting Question: Long-term Developer Capability

• Long-term developer capability is treated as a cross-cutting concern because AI assistance may weaken understanding: developers in AI-assisted conditions scored 17% lower on comprehension tests (Shen and Tamkin, 2026).The paper does not treat this concern as a co-equal design value, instead applying it across the five values in Section 12.Source: §2.4 · p. 5

3.2 High-Level System Structure

• The seven-component architecture connects users and interfaces to the agent loop, permission system, tools, state and persistence, and execution environment through an iterative request–approval–execution–result flow.Interfaces include the interactive and headless CLIs, Agent SDK, and IDE/Desktop/Browser; sessions record transcripts and support resume, fork, and rewind.Source: §3 · p. 6, §3.2 · pp. 7–8

3.1 Design Questions and Running Example

• Claude Code uses one queryLoop() across interactive, headless, SDK, and IDE surfaces, varying only rendering and interaction rather than maintaining mode-specific execution engines.This design favors a uniform execution path, whereas alternative systems may optimize separate code paths for particular surfaces.Source: §3.1 · p. 6
• Claude Code treats the context window as its binding resource, using five sequential compaction layers plus lazy instructions, deferred schemas, summary-only subagent returns, and per-result budgets.The context window is 200K for older models and 1M for the Claude 4.6 series; compaction proceeds from cheaper targeted reductions to semantic auto-compaction.Source: §3.1 · pp. 6–7, §3.6 · p. 10
• The architecture’s running example follows “Fix the failing test in auth.test.ts” from interface submission through the query loop, permission gate, tools, context window, delegation, and session persistence.The example is threaded through Sections 3 to 9 to connect the architecture’s major subsystems.Source: §3.1 · p. 7

3.3 Layered Subsystem Decomposition

• The layered decomposition assigns interfaces and rendering to the surface layer, queryLoop() and compaction to the core, controls and tools to safety/action, persistence and memory to state, and commands or external services to backends.The safety/action layer also supports plugins, skills, MCP tools, shell sandboxing, and subagent spawning; subagents use isolated contexts and return summaries.Source: Figure 3 · p. 8, §3.3 · pp. 8–9

3.4 QueryEngine: A Clarification

• Claude Code’s shared query() loop, rather than QueryEngine, is the common execution path across interfaces, while the harness validates and dispatches the model’s structured tool requests.The model does not directly access filesystems, shells, or networks; enforcement remains in separate harness code. The codebase is estimated at 1.6% AI decision logic and 98.4% operational infrastructure.Source: §3.1 · p. 6, §3 · p. 6, §3.4 · p. 9

3.5 Permission and Safety Layers

• Safety is defense in depth: deny-first rules, mode constraints, classifier checks, hooks, tool pre-filtering, sandboxing, and resume behavior each provide independent blocking or restriction points.Deny rules override ask and allow rules, and unrecognized actions escalate to the user rather than being silently permitted.Source: §3.1 · p. 6, §3.5 · pp. 9–10

4.1 The Query Pipeline

• Each turn resolves settings, maintains whole-object mutable state, assembles post-compaction context, calls the model, dispatches tools through permissions, collects results, and stops on text-only output.The loop is implemented as a ReAct-style while-loop that favors simplicity and latency over backtracking or search completeness.Source: §4.1 · pp. 10–11

4.2 Tool Dispatch and Streaming Execution

• StreamingToolExecutor starts tools before model streaming finishes, runs read-only operations concurrently while serializing state changes, and preserves model-request order in emitted results.A sibling abort controller stops other subprocesses when a Bash tool fails, while progress signals wake result consumers as output arrives.Source: §4.2 · p. 11

4.3 Pre-Model Context Shapers

• Five sequential shapers progressively manage context through result budgeting, history snipping, microcompaction, read-time collapse, and model-generated auto-compaction when pressure remains high.Collapse projects a compacted view without mutating full history, while auto-compact runs only after the preceding four shapers fail to relieve pressure.Source: §4.3 · pp. 11–12

4.4 Recovery Mechanisms

• Recovery handles output-token exhaustion, near-capacity context, prompt-too-long errors, streaming failures, and primary-model failure through bounded retries, compaction, fallback strategies, or an alternate model.Output-token recovery allows up to three attempts per turn, while reactive compaction fires at most once per turn.Source: §4.4 · p. 12

4.5 Stop Conditions

• The loop stops when the model emits no tools, maxTurns is reached, context overflows, a hook intervenes, or an explicit abort signal fires.These conditions define the boundary between continued tool orchestration and termination.Source: §4.5 · p. 12
• Execution begins with minimal autonomy: deny rules take precedence, unmatched risk-bearing actions request approval by default, and users can turn approvals into permanent rules.Declarative rules, global trust modes, and programmable hooks independently shape the permission policy.Source: §4.5 · p. 13

5 Tool Authorization and Control Boundaries

• Claude Code combines deny-first policy enforcement with optional OS-level sandboxing, applying layered controls and reversibility-weighted risk assessment.Source: §5 · p. 13

5.1 Permission Modes and Rule Evaluation

• Seven permission modes span plan, default, acceptEdits, auto, dontAsk, bypassPermissions, and internal bubble escalation, while deny rules always override allows.The auto mode depends on TRANSCRIPT_CLASSIFIER, and bubble is reserved for subagent escalation.Source: §5.1 · pp. 13–14

5.2 The Authorization Pipeline

• The pipeline prefilters denied tools, applies hooks and rules, selects contextual approval paths, and turns denials into model-visible guidance for safer retries.In coordinator and background paths, automated checks can precede user interaction; interactive mode provides the terminal approval dialog.Source: §5.2 · p. 14

5.3 Auto-Mode Classifier and Hook Lifecycle

• When enabled, the transcript classifier returns allow, deny, or manual approval, while five permission-related hooks can modify decisions, inputs, outputs, context, and retry guidance.For MCP tools, post-hook output modification occurs before the result enters context.Source: §5.3 · p. 15

5.4 Shell Sandboxing

• Shell sandboxing isolates filesystem and network access independently from authorization, but shared performance constraints can weaken defense-in-depth, including generic prompts for commands exceeding 50 subcommands.Source: §5.4 · p. 15

6 Extensibility: MCP, Plugins, Skills, and Hooks

• Claude Code’s four mechanisms extend the agent loop at distinct injection points: MCP integrates external tools, plugins distribute bundles, skills inject instructions, and hooks intercept execution.Figure 5 identifies assemble(), model(), and execute() as controlling what the model sees, what it can reach, and how actions run.Source: §6 · p. 16, Figure 5 · p. 16

6.1 Four Extension Mechanisms

• MCP supplies multi-scope, multi-transport tools; plugins package ten component types; skills inject SKILL.md instructions; and hooks expose 27 lifecycle events with multiple command types.Skills support tool access, model overrides, isolated execution, and dynamic hooks, while hooks can modify inputs, transform results, control retries, and inject context.Source: §6.1 · pp. 16–17

6.2 Tool Pool Assembly

• The tool pool starts with up to 54 base tools, applies mode and availability filtering, removes denied tools, merges MCP tools, and deduplicates by name with built-ins taking precedence.In CLAUDE_CODE_SIMPLE mode, only Bash, Read, and Edit are available, with deferred tools optionally hidden until queried through ToolSearch.Source: §6.2 · p. 17

6.3 Why Four Mechanisms?

• The four mechanisms form a graduated context-cost stack: hooks use zero context by default, skills low, plugins medium, and MCP high, enabling broad cheap customization while reserving schema-heavy integrations for new tool surfaces.MCP adds callable tools and server-management overhead; skills shape reasoning through lightweight metadata; hooks control lifecycles; and plugins package the other mechanisms.Source: §6.3 · p. 18, Table 2 · p. 18

7.1 Context Window Assembly

• Claude Code assembles its context window from system and environment information, hierarchical CLAUDE.md files, path-scoped rules, auto memory, tool metadata, conversation history, tool results, and compact summaries.Relevant memory, MCP instruction changes, agent updates, and background notifications can be injected after initial assembly, so the context grows during a turn.Source: §7.1 · pp. 19–20, Figure 6 · p. 19

7.2 CLAUDE.md Hierarchy and Auto Memory

• Claude Code uses inspectable, editable Markdown memory rather than opaque retrieval or database-backed representations, selecting up to five relevant memory files through an LLM-based header scan without embeddings.This prioritizes auditability and version control while surfacing memory at file rather than entry granularity.Source: §7.2 · p. 20
• CLAUDE.md memory has four levels—managed, user, project, and local—with nearer files loaded later and nested directory rules loaded lazily as exploration reaches matching paths.CLAUDE.md is delivered as user context, making compliance probabilistic; deny-first permission rules provide deterministic enforcement.Source: §7.2 · p. 20

7.3 Compaction Pipeline

• Claude Code applies five increasingly aggressive compaction layers—budget reduction, snip, microcompact, context collapse, and auto-compact—to degrade context lazily rather than truncate it in one step.This preserves information progressively but increases complexity and can make context behavior difficult for users to predict.Source: §7.3 · pp. 20–21
• Compaction preserves append-oriented transcript history while re-announcing live runtime state, including plans, skills, and asynchronous agents, after prior attachment messages are discarded.Boundary metadata supports read-time chain patching, and pre-compaction hooks can inject custom instructions.Source: §7.3 · p. 21

8.1 The Agent Tool and Delegation Criteria

• AgentTool dispatches built-in or custom subagents in isolated contexts, varying routing, isolation, and lifecycle while rebuilding permissions and tool sets.Custom definitions can specify tools, models, permissions, hooks, memory, skills, turn limits, and isolation; unlike SkillTool, AgentTool normally requires a self-contained prompt.Source: Figure 7 · p. 22, §8.1 · p. 22

8.2 Isolation Architecture

• Claude Code supports in-process, worktree, and internal-only remote isolation, while parent safety modes take precedence over subagent permission overrides.Worktrees separate repository state without container orchestration; prompt behavior depends on explicit settings, bubble mode, and synchronous or asynchronous execution.Source: §8.2 · pp. 22–23

8.3 Sidechain Transcripts

• Subagents store full histories in separate transcripts and return only final text and metadata, preserving auditability without inflating the parent context.Agent teams consume approximately 7× the tokens of a standard session in plan mode (Anthropic, 2025b), making summary-only return especially important.Source: §8.3 · p. 23
• Agent teams coordinate through per-teammate JSON inboxes protected by file locks, trading throughput for zero-dependency deployment and fully inspectable state.The harness avoids message brokers or distributed coordination services, so agent state can be debugged by reading plain-text files (Anthropic, 2025b).Source: §8.3 · p. 23

9.1 Transcript Model

• Session transcripts are project-scoped JSONL files, supplemented by global prompt history and separate subagent sidechains.Transcripts include messages, compaction markers, file-history and attribution snapshots, and content-replacement records; prompt history supports reverse-order navigation.Source: §9.1 · p. 24
• Claude Code writes conversations, tool results, and compaction boundaries to disk as events occur, using mostly append-only JSONL to favor auditability and simplicity over query power.Logged events remain human-readable, version-controllable, and inspectable without specialized tooling, whereas database-backed alternatives would enable richer queries but add deployment dependencies and reduce transparency.Source: §9.1 · p. 24, §9 · p. 24

9.2 Resume, Fork, and Not Restoring Permissions

• Resume replays the transcript and fork creates a new session, but neither restores session-scoped permissions, requiring users to grant them again.This treats sessions as isolated trust domains, preventing stale approvals from carrying into changed contexts while accepting additional user friction.Source: §9.2 · p. 24
• Compaction remains mostly append-only because boundary metadata preserves message-chain links, while file-history checkpoints support filesystem rewinds rather than generic session recovery.Resume rebuilds permission context from CLI arguments and disk settings, with unrecognized requests falling back to deny-first prompting.Source: §9 · p. 23, §9.2 · p. 25

10.1 Six Comparison Dimensions

• Claude Code is an ephemeral repository-bound CLI, OpenClaw a persistent multi-channel gateway, and Hermes a long-lived process whose role is determined by its entry point.This scope difference frames the systems’ other architectural choices, including whether a broker exists and where sessions persist.Source: §10.1 · pp. 25–26, §10 · p. 25

10.2 Hermes Agent: Capabilities Beyond the Comparison Table

• Hermes extends the comparison with searchable WAL-mode SQLite sessions, automatic restart resumption, cron and webhook execution, and a Kanban work queue for durable multi-agent coordination.These capabilities follow from Hermes’s persistent-process scope and do not map cleanly onto the six main comparison dimensions.Source: §10.2 · p. 29, §10.1 · p. 29

10.3 What the Contrast Reveals

• The recurring questions about reasoning, safety, context, and extensibility remain stable across systems, but their answers vary with deployment context.The comparison spans Claude Code’s repository-bound harness, OpenClaw’s multi-channel assistant, and Hermes’s single-process multi-surface deployment.Source: §10 · p. 25, §10.3 · p. 29
• Claude Code emphasizes per-action safety and a central agent loop, OpenClaw emphasizes gateway-perimeter access control and control-plane orchestration, while Hermes combines multi-surface approvals with a peer runtime loop.These differences follow from distinct trust models and deployment topologies rather than arbitrary implementation choices.Source: §10.1 · p. 27, §10.3 · p. 29
• The systems are composable rather than exclusive: OpenClaw can host Claude Code through ACP, while Hermes can host platform adapters and tool servers and can itself be hosted by external IDEs.This supports a layered design space in which gateway-level systems and task-level harnesses compose at multiple positions.Source: §10.1 · p. 26, §10.3 · p. 29

11.1 Coding Agent Taxonomy

• Claude Code occupies the agentic CLI category, combining autonomous shell and file operations with interactive approval by default while sharing features with higher-autonomy systems.The taxonomy ranges from inline completion and IDE-coupled chat tools to CLI agents and fully autonomous sandboxed systems.Source: §11.1 · p. 30
• This paper examines Claude Code’s internal architecture from source code, characterizing one specific point in the broader design space of agent systems.Its analysis centers on the harness around the model and compares Claude Code with OpenClaw and Hermes Agent across deployment contexts.Source: §11.1 · p. 30, §11.2 · pp. 30, 32

11.2 Agent Architecture Patterns

• Claude Code instantiates a simple, composable agent architecture around a ReAct loop, tool use, planning, memory, context compaction, and subagent delegation rather than a heavy coordination framework.Related work frames agents through planning, memory, and tool use; Claude Code’s implementation adds layered context management, file-based memory, and a simpler plan-then-execute permission mode.Source: §11.2 · pp. 30–31
• Production coding agents differ in approval, isolation, and recovery, while Claude Code layers deny-first permissions, classifier-mediated approval, optional shell sandboxing, and session-scoped permission reset.This contrasts with container isolation in SWE-Agent and OpenHands and Git-based reversibility in Aider, showing that safety is an execution-boundary design problem as well as an approval model.Source: §11.2 · p. 31
• Claude Code’s MCP-centered extensibility reflects a broader tool supply chain whose capabilities require security controls spanning runtime use, identity, allowlists, versioning, auditing, and revocation.MCP-related work documents threats including tool poisoning, rug pulls, and cross-server shadowing, while agent-first tool design adds search, resolve, preview, execute, verify, and recover phases.Source: §11.2 · pp. 31–32

12.1 Design Philosophy

• Only 1.6% of the codebase is decision logic versus 98.4% operational infrastructure, supporting model autonomy within a deterministic harness rather than heavy decision scaffolding.The harness enables model judgment through permission gates, tool routing, context management, and recovery logic.Source: §12.1 · pp. 32–33
• Harness choice alone shifts Fable 5’s functional and security pass rates by ten points or more, while stronger models mainly reduce the need for decision scaffolding.Safety, security, privacy, human authority, contextual adaptation, and most reliable-execution infrastructure remain necessary as capability grows.Source: §12.1 · p. 33

12.3 Architectural Trade-offs

• Permission modes create a safety-autonomy gradient, but approximately 93% prompt approval and auto-approve rates rising from approximately 20% to over 40% expose approval fatigue.Sandboxing reduced permission prompts by an estimated 84%, shifting the response toward reducing human decisions rather than relying on deliberate confirmations.Source: §12.3 · p. 34
• Defense-in-depth can fail when layers share constraints: commands exceeding 50 subcommands receive a generic approval prompt instead of per-subcommand deny-rule checks.Pre-trust initialization also lets hooks, MCP connections, and settings resolution run before interactive trust and permission enforcement, adding a temporal security gap.Source: §12.3 · pp. 34–35

12.4 Empirical Predictions and Early Signals

• Bounded context and subagent isolation predict duplication and convention violations, while adjacent evidence reports complexity +40.7% and a velocity spike of +281% in month one before baseline by month three.In Claude Code, cleaner inputs left task pass rate unchanged but reduced token use by 7 to 8% and file revisitations by 34%.Source: §12.4 · pp. 35–36

12.5 Limitations

• The analysis is limited by memoized context assembly and build-time feature flags, which can delay dynamic updates and produce functionally different application builds.The auto-mode classifier may be eliminated, while compaction and lazy-loaded rules only partially counter stale context and configuration variability.Source: §12.5 · p. 36

12.6 Emerging Directions

• Emerging directions include architectural decoupling, first-class experiential memory, lifecycle-managed context, observability for silent failures, governance, and proactive agents tied to user presence and token economics.KAIROS reports task completion gains of 12 to 18% in its motivating study, while user preference drops at high frequencies.Source: §12.6 · pp. 36–37

12.7 Recurring Design Choices

• Across subsystems, Claude Code repeatedly favors graduated layering, append-only auditability, and model judgment within a deterministic harness, trading simplicity and query power for resilience and traceability.These commitments appear in permission, context, extensibility, persistence, and delegation mechanisms, while bounded context can still produce poor global outcomes from good local decisions.Source: §12.7 · pp. 37–38

13 Future Directions

• The section identifies six open questions: observability, persistence, harness evolution, horizon scaling, governance, and long-term developer capability.These questions extend the paper’s five-value framework and its cross-cutting developer-capability concern.Source: §13 · p. 38

13.1 Silent Failure and the Observability-Evaluation Gap

• Observability remains a harness-layer question because silent failures may reflect missing tooling, evaluation interfaces, or model limits, with current work spanning failure modes, trace anomalies, passk, and benchmark gaps.Whether scaffolding belongs inside the harness or in a separate evaluation layer, and whether hooks can support it within the context-cost envelope, remains unresolved.Source: §13.1 · pp. 38–39

13.2 Persistence: Memory and Longitudinal Colleague Relationships

• Persistence asks whether durable state should bridge static instruction hierarchies and session transcripts while preserving transparency, permission safety, and useful human-agent working relationships.Candidate mechanisms include production memory stores, procedural traces, self-reflection, dynamic-memory benchmarks, and reference architectures from OpenClaw and Hermes Agent.Source: §13.2 · p. 39

13.3 Harness Boundary Evolution: Where, When, What, and with Whom the Agent Acts

• Harness evolution asks whether one architecture can span where, when, what, and with whom agents act, or whether specialized stacks are required.The extensions raise unresolved issues involving hosted-service governance, physical-action reversibility, cross-agent consistency, proactivity, and composition across axes.Source: §13.3 · pp. 39–40

13.4 Horizon Scaling: From Session to Scientific Program

• Long-horizon reliability must determine whether session-scoped context, persistence, and subagent mechanisms support multi-session scientific programs, or require cross-session memory and new coordination primitives.Quantitative Goal Persistence shows that reasonable local actions can still stop before enough verified work is complete (Cai et al., 2026); orchestration-as-code is one emerging alternative.Source: §13.4 · pp. 40–41

13.5 Governance and Oversight at Scale

• Governance asks which logging, transparency, oversight, and rule-articulation interfaces architectures should expose as regulation constrains authority, auditability, training-data sourcing, and environmental safety.The current deny-first pipeline is internally auditable through transcripts but not yet externally auditable in forms contemplated by the GPAI Code of Practice (European Commission, 2025a).Source: §13.5 · p. 41

13.6 Long-term Developer Capability

• Long-term developer capability becomes a first-class design question: systems must determine whether capability effects are measurable and how architecture could respond without assuming the harness is the correct locus.Relevant work spans productivity, comprehension, complexity, technical debt, cognition, security, and hiring; process-level control asks what users can inspect and change during unfolding work.Source: §13.6 · pp. 41–42

Conclusion

• Claude Code gives the model broad local autonomy while a deterministic harness organizes permissioning, tool routing, context compaction, extensibility, and session recovery around five stated values.These values are human decision authority, safety, reliable execution, capability amplification, and contextual adaptability.Source: §14 · p. 42
• OpenClaw and Hermes Agent answer recurring design questions differently: OpenClaw uses perimeter-level access control and gateway memory, while Hermes provides cross-surface approvals with pluggable memory and model backends.Claude Code instead emphasizes per-action safety classification and graduated context compression within a CLI harness.Source: §14 · p. 42
• ACP composes the three systems at multiple positions, with OpenClaw hosting Claude Code as an external harness and Hermes Agent spanning both host and guest roles.Source: §14 · p. 42
• Future agent systems should treat preserving long-term human capability as a first-class design problem because current architectures provide limited mechanisms for sustained human understanding, codebase coherence, and developer-pipeline continuity.The paper identifies this sustainability gap as more consequential than simply adding autonomy or treating it as a downstream evaluation metric.Source: §14 · p. 42

Evidence Base and Methodology

• The appendix records the study’s evidence sources, analytic procedure, and limits.Source: Evidence Base and Methodology · p. 50

Evidence Base and Evidence Tiers

• Claude Code claims use three evidence tiers, with code-verified claims from the extracted v2.1.88 TypeScript codebase treated as strongest and reconstructed claims stated cautiously.Tier A establishes product intent, Tier B traces specific files and functions, and Tier C covers comparisons or inferences from code patterns.Source: Evidence Base and Evidence Tiers · p. 50

Design-Space Analytic Procedure

• The analysis identifies recurring design questions across subsystems, traces five values through thirteen principles to architecture, and treats capability preservation and token economics as cross-cutting concerns.The five values are human decision authority, safety, security and privacy, reliable execution, capability amplification, and contextual adaptability.Source: Design-Space Analytic Procedure · p. 50

Limitations

• Findings are bounded by a static v2.1.88 snapshot, build-time feature variability, reverse-engineering limits, single-system scope, and dated comparison-system snapshots.Source code cannot establish design intent, enabled production flags, runtime prevalence, or unshipped behavior.Source: Limitations · p. 50

Package Structure and Directory-to-Responsibility Map

• The package is organized around src/ and maps major directories and files to runtime responsibilities, including tools, commands, execution, compaction, MCP, and permission infrastructure.The package contains approximately 42 tool subdirectories and 86 slash-command subdirectories; query.ts contains the main loop while query/ contains loop and context helpers.Source: Directory-to-Responsibility Map · pp. 50–51

Conditional Tool Availability

• Conditional tool construction varies by mode, build, environment, and feature flags, exposing as few as 3 tools in simple mode or up to 54 in a fully enabled internal build.The maximum comprises 19 unconditional and 35 conditional tools.Source: Conditional Tool Availability · p. 51

Cross-File Dependencies

• The import graph connects QueryEngine.ts, query.ts, tool execution, compaction, memory, and prompt assembly while explicitly extracting types and caching context to avoid circular imports.QueryEngine.ts delegates turn execution to query.ts, which imports tool execution and compaction services.Source: Cross-File Dependencies · p. 51

Community Reimplementations and Representative Projects

• Community reimplementations provide working CLI agents across Python, Rust, Bun TypeScript, and npm JavaScript using independent rewrites, reconstructed forks, or automated decompilation.Table 9 identifies five representative projects as of 2026.Source: Representative Projects · p. 52, Table 9 · p. 52, Community Reimplementations · p. 52

Companion Design-Space Resources

• Companion notes track emerging agent-system developments but are not evidence for Claude Code’s implementation, while Figure 9 presents reconstructed source-to-runtime mappings as Tier C analysis.The companion material includes source-structure entries such as main.tsx, replLauncher.tsx, and entrypoints/.Source: Companion Design-Space Resources · p. 52, Figure 9 · p. 53