Context Fork: 10 Questions Answered

1. Mechanics

How does it work?

• context: fork in frontmatter triggers forked execution
• Skill runs in isolated sub-agent with fresh context
• Only the final result returns to parent

What triggers it?

• Presence of context: fork in skill frontmatter
• Applies to both skills and slash commands (per changelog)

Implementation model (guess):

• Spawns new Claude session/context
• Injects skill instructions as system prompt
• Runs to completion
• Returns final text output to parent
• Intermediate tool calls NOT visible to parent

2. Model/Agent

What model runs forked skills?

• SAME MODEL as parent (Opus 4.5 confirmed)
• No automatic downgrade to cheaper model
• Model identity visible in fork's system prompt

Configurable?

• Not observed - fork inherits parent model
• agent field (feature #3) may allow this - untested
• No model: frontmatter option observed

Implications:

• Forking for parallelism still costs same tokens
• No cost savings from fork alone
• Use case is context isolation, not cost reduction

3. Context

Fresh or inherited?

• Fresh conversation context (no prior messages)
• BUT: has system prompt with project info (git status, date, etc.)
• Has skill instructions prepended

What carries over:

• System-level context (project path, git info, date)
• Working directory
• Environment variables
• Tool permissions

What doesn't carry over:

• Conversation history
• Previously read files
• Prior assistant responses
• User preferences established in conversation

4. Tool Access

Default tools:

• Appears to have all tools by default
• allowed-tools can restrict

Tested tools in fork:

• Read: works
• Bash: works
• Glob: works
• Grep: works (via analyze-changelog)

MCP servers:

• Untested

Tool permission prompts:

• May differ - fork might auto-allow based on parent settings
• Needs more testing

5. Failure Modes

Error in forked skill:

• Fork returns error message as result
• Parent context unaffected
• Clean failure boundary

Fork timeout:

• Untested - unknown timeout behavior

Cancellation:

• Changelog mentions: "Fixed forked slash commands showing 'AbortError' instead of 'Interrupted'"
• Implies cancellation is supported

Partial results:

• Cancellation may return partial or no result

6. Performance

Latency:

• Observable delay for fork spawn
• Longer than inline skill (new context setup)
• Not measured precisely

Token cost:

• Full token cost (same model)
• PLUS skill instructions in fork context
• PLUS system prompt in fork

Parallelism:

• Unknown if multiple forks run truly parallel
• Changelog mentions: "Improved token count display in spinner to include tokens from background agents"
• Suggests some parallel execution support

7. Feature Interactions

With hot-reload:

• Works - forked skills also hot-reload

With allowed-tools:

• Works - tested with allowed-tools: Read,Bash,Glob

With agent field:

• Untested (feature #3)

With hooks:

• 2.1.0 added hooks support for skill frontmatter
• Untested in fork context

8. Edge Cases Tested

Scenario	Result
Multi-tool workflow in fork	Works (analyze-changelog)
Error handling (read nonexistent file)	Fork handles gracefully
Model identity check	Same model (Opus 4.5)
Conversation history access	None (fresh context)
System context access	Yes (git status, date)
Bad YAML with context: fork	Lenient - may not apply fork

9. Security

Trust boundary:

• Fork runs with same permissions as parent
• allowed-tools provides restriction capability
• Fork can't access parent conversation history (privacy benefit)

Isolation benefits:

• Skill can't pollute parent context
• Can't accumulate knowledge across invocations
• Each fork is stateless

Risks:

• Fork still has file system access
• Can execute bash with same permissions
• allowed-tools is skill-author controlled

10. Debugging

How to see what's happening:

• Only final result visible to parent
• No intermediate tool call visibility
• Add explicit logging in skill instructions

Transcript visibility:

• Fork execution NOT in main transcript
• Only the summary return is logged

Debugging strategy:

• Add "print your plan before executing" to skill
• Add step-by-step output requirements
• Use non-forked version first, add fork when stable

---

Key Insight

context: fork is about isolation, not performance or cost:

• Same model = same token cost
• Fresh context = no conversation pollution
• Summarized return = cleaner main thread
• Stateless = predictable behavior

Best for: research tasks, batch processing, untrusted/experimental skills, context window management.

NOT for: cost reduction, true parallelism (unverified), interactive workflows.

Use Cases: Context Fork for Skills/Commands

Feature: context: fork in frontmatter runs skill in isolated sub-agent context

---

Core Value Proposition

Forking creates a clean execution boundary. The skill runs with:

• Fresh context (no conversation baggage)
• Isolated tool execution (won't pollute main thread)
• Summarized return (only results come back, not intermediate steps)

Think of it as: subprocess for AI workflows.

---

Use Cases

1. Research Tasks That Would Pollute Context

Scenario: You need to search through 50 files to answer a question, but don't want all that noise in your main conversation.

Without fork: Every file read, every grep result, every intermediate thought bloats your context window. Later queries suffer.

With fork: Skill does the research in isolation, returns only the synthesis.

---
context: fork
allowed-tools: Read,Grep,Glob
---
# Deep Research Skill
Search exhaustively, but return only the answer.

Main thread stays clean. Context window preserved for actual work.

---

2. Expensive Analysis You Might Retry

Scenario: Running a complex analysis (security audit, perf review, architecture assessment) that you might need to run again with different parameters.

Without fork: First analysis fills context. Second run has less room. Third run might hit limits.

With fork: Each run is isolated. Context doesn't accumulate. Retry freely.

---

3. Parallel Independent Tasks

Scenario: You need three different analyses done - they don't depend on each other.

> /security-audit       # fork 1
> /perf-analysis        # fork 2
> /dependency-check     # fork 3

Each runs independently, returns results, main thread synthesizes.

Note: True parallelism depends on how Claude Code schedules forked skills. But isolation is guaranteed.

---

4. Skills That Might Fail or Loop

Scenario: You're testing a new skill that might go off the rails.

Without fork: Bad skill pollutes your session. Might need to restart.

With fork: Skill fails in isolation. Main session unaffected. Check results, fix skill, retry.

This makes skill development safer.

---

5. Long-Running Tasks You Want Summarized

Scenario: A task involves many steps but you only care about the outcome.

Example: "Analyze all test files and tell me which ones are flaky"

Without fork: You see every file read, every grep, every intermediate conclusion. Pages of output.

With fork: Skill returns: "Found 3 flaky tests: test_auth.py:45, test_api.py:112, test_db.py:89"

Signal, not noise.

---

6. Sensitive Operations With Audit Trail

Scenario: You want a skill to do something with clear boundaries and a clean return.

Forked skills have a natural audit boundary:

• Input: the skill invocation
• Output: the returned result
• Everything in between: contained in the fork

Good for: compliance-sensitive operations, reproducible workflows, explainable AI.

---

7. Plugin Isolation

Scenario: You're using a third-party skill/plugin and don't fully trust it.

context: fork means the skill can't:

• Read your full conversation history
• Accumulate knowledge across invocations
• Affect your main context in unpredictable ways

It gets a task, does the task, returns results. Sandboxed execution.

---

8. Batch Processing

Scenario: Process a list of items with the same skill.

---
context: fork
---
# Process Single Item
Given an item, do analysis, return structured result.

Call it N times. Each invocation is isolated. Results aggregate cleanly.

---

9. "Fire and Forget" Workflows

Scenario: You want to kick off a task but not babysit it.

Forked skills run to completion and return. You don't see intermediate permission prompts (depending on allowed-tools).

Good for: CI-style checks, pre-commit validations, automated audits.

---

10. Context Window Management

Scenario: You're in a long session approaching context limits.

Regular skill invocations add to context. Forked skills don't - only the summary returns.

Strategic use of forked skills can extend effective session length.

---

Comparison: Fork vs No Fork

Aspect	Regular Skill	Forked Skill
Context	Shares main thread	Fresh/isolated
Output	All steps visible	Summary only
Tool use	Visible in main	Contained
Retry cost	Accumulates context	Constant
Debugging	Easier (see steps)	Harder (need logging)
Performance	Synchronous	Same (not truly parallel yet)

---

When NOT to Fork

1. Interactive skills - If the skill needs to ask questions or get feedback mid-execution, forking breaks that.

2. Skills that need conversation context - Fork starts fresh, can't see what you discussed before.

3. Debugging new skills - Easier to see what's happening without fork. Add fork once it works.

4. Short, simple skills - Fork overhead not worth it for trivial tasks.

5. Skills that should affect main context - If the skill's purpose is to establish context for follow-up work, don't fork.

---

Technical Notes

• Forked skills return a single result message
• Tool access controlled by allowed-tools frontmatter
• Errors in fork don't crash main session
• Model/temperature settings may differ in fork (verify)
• Cancellation behavior: interrupting fork returns partial or no result