claude-code-decompiled (research reports)
A documentation-only collection of 20 independent research reports on Claude Code v2.1.88 covering architecture, agent behavior, permission design, prompt assembly, MCP integration, and context management. Deliberately ships analysis rather than extracted code.
View source on GitHubKey takeaways
- 01
Report set spans permissions, prompt assembly, MCP, and context management
- 02
Documentation-only approach is the cleanest for attribution
- 03
Strong specifics on permission tiers around dangerous tools
Flows built on this research
MCP & Tooling
Design Tool Schemas for Agents
Write tool schemas that constrain model behavior: tight types, enums over strings, and parameters that make misuse hard.
4 steps · 60-90 minutes
Harness Engineering
Hook a Permission Layer onto Dangerous Tools
Intercept dangerous tool calls with a hook layer: pattern rules, approval gates, and blocks that the model cannot talk its way past.
4 steps · 60-90 minutes
Agent Architecture
Sub-Agent Delegation with Context Isolation
Delegate bounded work to sub-agents that run in fresh context and return only distilled results - the pattern behind scalable long tasks.
4 steps · 90-150 minutes
MCP & Tooling
Deferred Tool Loading
Stop paying context for tools the task never needs: load a core set eagerly and expand the toolset on demand.
4 steps · 90-120 minutes
Harness Engineering
Rate and Blast-Radius Limits for Destructive Tools
Cap how much damage any window of agent activity can do: rate limits, change budgets, checkpoints, and undo.
4 steps · 60-90 minutes
From the archive
Verbatim excerpts mined from our local archive of this repository — the prompts, schemas, and patterns worth stealing.
The system prompt is an array, and the boundary is infrastructure
return [ // --- Static content (cacheable) --- getSimpleIntroSection(outputStyleConfig), getSimpleSystemSection(), getActionsSection(), getUsingYourToolsSection(enabledTools), getSimpleToneAndStyleSection(), getOutputEfficiencySection(), // === BOUNDARY MARKER - DO NOT MOVE OR REMOVE === ...(shouldUseGlobalCacheScope() ? [SYSTEM_PROMPT_DYNAMIC_BOUNDARY] : []), ...resolvedDynamicSections, ].filter(s => s !== null) Before the boundary: cacheScope 'global' - shared across the entire Anthropic fleet, prefill cost amortized across millions of requests. After: per-session content.
getSystemPrompt() returns string[] not string - each segment becomes an API block with its own cache scope, and one literal marker decides what the whole fleet can share.
docs/en/09-system-prompt-engineering.md
Nine exit reasons, each one a production scar
The Terminal return value carries the reason the loop exited: 'completed', 'aborted_streaming', 'aborted_tools', 'max_turns', 'prompt_too_long', 'model_error', 'image_error', 'hook_stopped', or 'stop_hook_prevented'. Each of those exit paths was added because of a real bug in production. The outer query() is a thin wrapper: command lifecycle notifications only fire on successful completion - not on throws or .return() calls that abort the generator.
From the 1,729-line query.ts: an agent loop's maturity is measured by how many distinct ways it knows how to stop.
docs/en/06-agent-loop-deep-dive.md
MCP connections as a five-state discriminated union
export type MCPServerConnection = | ConnectedMCPServer | FailedMCPServer | NeedsAuthMCPServer | PendingMCPServer | DisabledMCPServer Connection results are memoized (lodash memoize, keyed on server name + serialized config) - repeated calls return the cached connection. When a connection drops, the cache entry is explicitly deleted in the onclose handler so the next call triggers a fresh connection.
Production MCP clients don't model 'connected or not' - they model five states so the UI, retry logic, and auth flows each know exactly what to do.
docs/en/10-mcp-integration.md