Mehdi Akiki
Published on

Claude Code context: fork Explained: The Simplest Way to Isolate Noisy Workflows

Authors
  • Mehdi Akiki avatar
    Name
    Mehdi Akiki
    Twitter

Reference

A lot of Claude Code workflows get worse for one simple reason: too much noisy output ends up in the main conversation.

You run a huge test suite, inspect logs, scrape docs, or analyze a large part of the repo — and suddenly your main thread is full of junk. That is exactly where context: fork helps.

When you add context: fork to a skill, the skill runs in an isolated subagent context instead of directly inside the current conversation. The skill content becomes the prompt for that subagent, and the subagent does not get your main conversation history.

What context: fork actually does

Without context: fork:

  • the skill runs inline
  • its work pollutes the main session
  • verbose output competes for attention and context

With context: fork:

  • a new isolated subagent is created
  • the skill body becomes that subagent's task
  • the subagent does the noisy work separately
  • your main conversation gets back the useful result or summary

The forked subagent runs in isolation and does not have access to your conversation history. That is the whole mechanism.

Why this matters in practice

This is not just a technical detail. It solves real workflow problems.

context: fork is strong when the task is noisy, exploratory, or high-volume:

  • reading lots of files
  • searching a large codebase
  • processing logs
  • running tests and summarizing failures
  • gathering research before planning
  • checking many files for patterns

The goal is to isolate operations that produce a lot of output so the verbose work stays in the subagent's context and only the relevant summary returns.

A simple example

---
name: deep-research
description: Research a topic thoroughly across the codebase
context: fork
agent: Explore
---

Research $ARGUMENTS thoroughly:

1. Find relevant files using Glob and Grep
2. Read and analyze the code
3. Summarize findings with specific file references

The key part is not just context: fork — it is that the skill contains a real, concrete task. The subagent needs something to do.

The biggest mistake people make

They use context: fork on a skill that contains only guidelines, not a task.

Anthropic warns about this directly: context: fork only makes sense for skills with explicit instructions. If the skill is just general guidance, the subagent gets guidelines but no actionable task and may return without meaningful output.

Bad:

---
name: api-conventions
context: fork
agent: Explore
---

Use our API conventions and error handling rules.

This is weak because there is no concrete assignment.

Better:

---
name: review-api-endpoint
context: fork
agent: Explore
---

Review the endpoint implementation in $ARGUMENTS.

1. Check whether it follows our API conventions
2. Identify error handling inconsistencies
3. Find response shape mismatches
4. Return a concise report with file references

Now the forked subagent has something to do.

When context: fork is the wrong choice

Do not use it just because it sounds advanced.

It is the wrong fit when:

  • the task depends heavily on ongoing conversational nuance
  • you need the subagent to see a lot of previous discussion
  • the work is tiny and not noisy
  • the skill is only reference material, not an actionable workflow

The forked skill does not have your main conversation history. That is a feature, but sometimes it is also a limitation.

A practical anti-pattern list

1. Forking vague skills

If the skill body is just guidance, the subagent has no concrete task. The instruction set without an assignment produces nothing useful.

2. Forking tiny work

If the task is one quick answer, inline is simpler. The isolation overhead is not worth it.

3. Expecting full conversation awareness

A forked skill does not inherit the whole conversation history. Do not build skills that depend on context the subagent cannot see.

4. Using the wrong agent type

Different agent types — Explore, Plan, general-purpose — have different tools and execution characteristics. Pick the one that matches the task instead of treating them as interchangeable. Explore is read-only and well-suited for research. Plan analyzes before proposing changes. General-purpose is the default.

The clean mental model

Use context: fork when you want to say:

"Go do this contained piece of work elsewhere and come back with the useful part."

That is why it is so good for research, scanning, log analysis, output-heavy diagnostics, and pre-planning investigation.

It is not magic. It is just isolation. And in Claude Code, isolation is often what keeps a workflow usable.

For the bigger picture on when to use subagents versus skills in general, see Claude Code Subagents for Developers: When a Skill Is Not Enough.