Claude Code Forked Subagents Now On by Default

Claude Code 2.1.302, released on 16 October 2026, made "forked subagents" the default in several places where they were not: scripted runs (claude -p), the Agent SDK, the desktop app and VS Code. They were already on in the terminal. A fork is a helper that starts with a full copy of your current conversation. If you use Claude Code in scripts or build pipelines, your jobs may behave a little differently after you update.

This article explains what a fork is, what changed, and what a team should check. It is based on Anthropic's Claude Code changelog, its subagents documentation and its environment variables reference.

What is a forked subagent in Claude Code?

A subagent is a helper that Claude starts to do one piece of work on the side. Its own steps stay out of your main conversation, and only the final result comes back. That keeps the main conversation short and focused.

Ordinary subagents start fresh. They know only the instructions Claude hands them. That is fine for a narrow job such as "search the code for every place that sends an email."

A fork is different. According to the docs, a fork "sees the same system prompt, tools, model, and message history as the main session." Think of it as photocopying the whole conversation and giving the copy to a colleague, instead of writing them a briefing note.

The docs say to use a fork when any other helper "would need too much background to be useful", or when you want to try several approaches in parallel from the same starting point.

What changed on 16 October 2026?

Fork mode was already on by default in interactive terminal sessions. The docs say that default needs Claude Code v2.1.232 or later. What was off by default was the non-interactive side: claude -p (the mode scripts and build pipelines use) and the Agent SDK, which is Anthropic's toolkit for building your own agents.

The 2.1.302 changelog entry says fork subagents are now on by default in claude -p, the Agent SDK, the desktop app and VS Code, "as they already are in the terminal". It also says that setting CLAUDE_CODE_FORK_SUBAGENT=0 turns them off. (That is an environment variable: a named setting you place around a program before it starts.)

The same release has two related changes. The desktop app and VS Code now always run the main conversation's subagents in the background, as the terminal does, instead of letting Claude choose. And a subagent's own helper calls in scripted runs, the SDK, the desktop app and VS Code now run in the foreground by default.

One caution. When I read it, the subagents documentation page still described fork mode as off by default in -p and the SDK. The changelog is the newer statement, so treat it as the current behaviour, and expect the docs to catch up.

How do forks differ from normal subagents?

The docs give a clear comparison:

• Starting knowledge: a fork gets the full conversation. A normal subagent gets only the prompt it is passed.
• Setup: a fork uses the same instructions, tools and model as the main session. A normal subagent uses its own definition file.
• Permission questions: a fork's questions appear in your terminal. A normal subagent running in the background sends its questions to the main session.
• Cache: a fork shares the main session's prompt cache. A normal subagent has its own.

The cache point matters for money. The prompt cache lets the service reuse text it has recently processed instead of starting over, at a lower price. Because a fork starts identical to its parent, its first request can reuse that cache. The docs conclude that a fork "costs less than a fresh subagent for tasks that need the same context."

Two more details. A fork cannot start further forks. And when Claude starts a fork, it can ask for the fork's file edits to be written to a separate working copy of the code (a git worktree) instead of your own checkout, which keeps parallel edits from colliding.

What does this mean for a team?

Side tasks get easier to hand off

With a fork, you can say "draft unit tests for the parser changes so far" without rewriting the background. The helper already knows what you were doing. Several forks can try different approaches from the same starting point, and you compare the results.

Automated runs may behave differently

If your pipeline runs claude -p, or you built something on the Agent SDK, Claude may now choose to spawn forks where it previously did not. The docs add that with fork mode on, Claude Code runs the subagents Claude starts in the background and removes Claude's option to ask for the foreground. For a nightly job, that probably does not matter. For a job whose output you compare exactly from run to run, run it once after updating and look.

Cost: cheaper per helper, but not free

A fork carries the whole conversation, so it starts with a lot of text. The cache reuse is what makes that cheaper than briefing a fresh helper on the same background. The sources do not say how much you will save or spend overall. That depends on how often Claude forks and how long the conversation already is. Check your usage after a few days instead of assuming.

Permissions still apply

A fork's permission questions appear in your terminal, as with other work in the session. If you want to keep fork mode on but stop Claude from spawning forks, the docs say to deny the fork subagent type with an Agent(fork) rule. A deny rule is simply a line in your settings that tells Claude Code never to do a named thing.

What should we check after updating?

1. Find out which version you run. The change is in 2.1.302 (16 October 2026) and later. The desktop app and VS Code are covered too.
2. Run one automated job and read the result. Look for anything that changed in order or timing.
3. Watch usage for a few days. Compare against your usual pattern, especially if you share a plan across people.
4. Decide your policy. Leave forks on, turn them off everywhere with CLAUDE_CODE_FORK_SUBAGENT=0, or deny just the fork type.
5. Tell your team. In the terminal, background helpers show in a panel below the prompt. The docs say you can open a fork's transcript with Enter and send it follow-up messages, or stop it with x.

How does Atlas handle this?

Partly. Atlas is a team of AI engineers built on Claude Code, and each engineer is its own Claude Code session with its own working folder, so engineers never edit the same files under each other. That is Atlas's own way of splitting work in parallel. Nothing in Atlas's description says it manages Claude's forked subagents, shows them, or controls them; they are a Claude Code feature that happens inside a session. The team's usage still counts against your Claude plan, and Atlas has an optional daily budget that warns at 50% and 80% and pauses at 100%. To see the whole picture, start at the Atlas home page.

Conclusion

Forked subagents are a sensible idea: a helper that already knows what you are doing, at a lower cost than starting from nothing. The 16 October change extends them from the terminal to scripts, the SDK, the desktop app and VS Code. Update, run one job, watch usage, and choose your setting on purpose. The single switch, CLAUDE_CODE_FORK_SUBAGENT=0, is there if you want forks off.