Skip to main content
Mythos

What Fork Mode Is

Forked sub-agents are a Claude Code feature (introduced in v2.1) that clones the current session's full context into a child agent rather than spawning a fresh one. The fork inherits the parent's system prompt, tool definitions, and conversation history — then executes independently and returns only a summary.

The key differentiation from standard sub-agents: a standard sub-agent gets a compressed summary of the parent context (losing detail through flattening). A fork gets the entire uncompressed parent context, cache-included.

How It Works

Forks are triggered either via the /fork slash command in an interactive session, or by setting context: fork in a skill's or command's YAML frontmatter. When subagent_type is omitted from the Agent tool call, the fork path fires automatically. If the model specifies an explicit type (e.g., Explore or Plan), forking does not trigger.

Each fork child gets an injected XML tag that tells it: "You ARE the fork. Do NOT spawn sub-agents." This prevents recursive forking. A fork cannot spawn further forks.

The environment variable CLAUDE_CODE_FORK_SUBAGENT=1 enables fork mode for external builds and CI/CD pipelines.

Prompt Cache Economics

Because a fork's system prompt and tool definitions are identical to the parent, its first request reuses the parent's prompt cache. This makes forking significantly cheaper than spawning a fresh sub-agent when the same context is needed. In a parallel fan-out of five agents, children 2–5 share the parent's cached prefix — the total shared-context cost drops to roughly one additional child's worth of tokens.

Worktree Isolation

When spawning a fork through the Agent tool, passing isolation: "worktree" routes the fork's file edits to a separate git worktree instead of the active checkout. This enables parallel implementation branches without filesystem conflicts.

Fork vs. Standard Sub-Agent

Standard sub-agents run in their own context window with a custom system prompt and inherit only a compressed summary of the parent. They're the right tool when the task is genuinely isolated and doesn't need the full parent context.

Forked sub-agents copy the full parent context at cache-discounted rates. They're the right tool when the task depends on session-accumulated understanding — long sessions where context compression would flatten critical details.

Policy Islands Pattern

The policy islands pattern (from Claude Code 2.1) pairs forked context with pre-declared permissions. A command with context: fork and agent: <name> in its frontmatter spawns an isolated sub-agent that can only use the tools in that agent's allowed_tools list. The sub-agent runs without mid-workflow approval prompts and returns only a summary. The parent never sees intermediate tool calls.

This eliminates approval fatigue on repeatable workflows while maintaining a security boundary — permissions travel with the agent definition, not negotiated per step.

Key Use Cases

Parallel evaluation — spawn two or three forks simultaneously to evaluate design variations, API structures, or copy alternatives. Each fork works from the same full context; comparisons are meaningful because the foundation is identical.

Context-heavy implementation — when deep session context is load-bearing (e.g., 180K tokens in, referencing middleware decisions made 90K tokens ago), forking preserves that context for the implementer agent instead of letting compression flatten it.

Isolate noisy work — implementer and QA agents doing test loops, large diffs, and iterative debugging generate enormous output. Forking them keeps that noise out of the orchestrator's context, returning only a clean summary.

Side-channel exploration — fork a tangent question without derailing the main session thread. The fork resolves the question independently; the main session stays clean.

CI/CD pipelines — set CLAUDE_CODE_FORK_SUBAGENT=1 at the pipeline environment level. Every agent run in that pipeline picks it up. Parallel module agents across five modules share the parent cache prefix.

Limitations

  • Fork mode only works in interactive sessions. It is disabled in non-interactive mode, including the Agent SDK.
  • A fork cannot spawn further forks.
  • Incompatible with --print mode. Fork uses permissionMode: 'bubble', which surfaces prompts to a parent terminal.
  • fork only fires when subagent_type is omitted from the Agent tool call.

Configuration Reference

# Skill or command frontmatter
context: fork
agent: <agent-name>   # optional — assigns a named agent's allowed_tools
# Enable for external builds / CI
CLAUDE_CODE_FORK_SUBAGENT=1

Reflective Notes

Fork mode is the answer to the "compression tax" problem that plagues long agentic sessions — the progressive loss of nuanced context as sub-agents receive summarized rather than raw history. For MythOS workflows (where session context accumulated over a long run is often the most valuable thing in the window), this feature has direct architectural relevance. The policy islands pattern is also worth integrating into any Claude Code-based orchestration work — it's a clean primitive for zero-prompt governed automation.

Contexts

Created with 💜 by One Inc | Copyright 2026