What Actually Shipped
The changelog entry for 2.1.232 (August 13, 2026) reads, in full: "Subagent forking is now on by default: a subagent_type: "fork" subagent inherits the full conversation and prompt cache, and non-teammate agent spawns in interactive sessions now run in the background by default." That is two behavior changes bundled into one release line, and both matter to a multi-agent pipeline for different reasons.
The first change is about what a fork subagent sees. Claude Code's own subagent documentation defines a fork as a subagent that "inherits the entire conversation so far instead of starting fresh," seeing "the same system prompt, tools, model, and message history as the main session." That has been the documented definition of a fork since the type existed as a spawn target. The 2.1.232 changelog line says this inheriting behavior — full conversation plus the parent's prompt cache — is now what happens by default when a fork spawns, rather than something that required extra configuration. The changelog does not spell out exactly what a fork did differently before this release, and no earlier changelog entry documents forks running in a more isolated mode, so treat the prior default as undocumented rather than assume it was fully isolated. Treat "by default" as the operative phrase: after 2.1.232, calling Agent with subagent_type: "fork" or running /subtask gets you conversation and cache inheritance without asking for it.
The second change is about execution mode, not context. "Non-teammate agent spawns in interactive sessions now run in the background by default" means an agent call that is not a named, configured teammate agent no longer blocks your interactive session while it works — it runs in the background and you keep typing. This is a scheduling change, and it is easy to conflate with the forking change because both entries shipped in the same release line. They are not the same thing: a subagent can run in the background and still start with a completely fresh context if it is not a fork.
Fork vs. Non-Fork: What Each One Actually Gets
Claude Code's subagent reference draws the fork/non-fork line in a comparison table, and the two rows that matter for cost and context are cache and history. A fork gets a "shared" prompt cache — it reuses the parent's cache — while a non-fork subagent gets a "separate cache" that starts cold. On conversation history, the same reference states it plainly: "A fork inherits everything the main session has at the moment it spawns. Any other subagent starts fresh from its definition."
| Aspect | Fork (subagent_type: "fork") |
Non-fork subagent |
|---|---|---|
| Conversation history | Full parent history at spawn time | None — fresh context |
| Prompt cache | Shared with the parent session | Separate, starts cold |
| System prompt | Same as the parent session | The subagent's own definition |
| Output style, auto memory | Inherited with the rest of the session state | Not loaded |
| Nesting | Cannot spawn further forks | Can spawn nested subagents up to depth 3 by default |
A non-fork subagent still isn't blank, which is the detail worth knowing before you assume "isolated" means "empty." It starts with its own system prompt plus environment details, the delegation message the parent wrote, every level of the CLAUDE.md hierarchy the main session loaded, a git status snapshot from the start of the parent session, and the full content of any skill named in its definition. What it does not get — output style, auto memory, prior conversation turns, and the files the parent already read — is exactly what a fork now gets automatically.
Nested subagent spawning up to depth 3 was already the default as of Claude Code 2.1.219 (July 24, 2026), up from a depth of 1. That change is unrelated to forking's context inheritance, but it compounds with it: a chain of nested calls that includes a fork now carries a shared cache and history further down the tree than a depth-1 setup would have.
Where Your Cost Assumptions Just Moved
A shared prompt cache is not automatically a savings. It is a different bill shape, and which direction it moves depends on what the fork actually does with the inherited context.
The likely win: a fork that reuses the parent's cached prefix — system prompt, tool definitions, CLAUDE.md, the conversation so far — avoids re-paying for tokens the parent session already cached. A non-fork subagent starting cold pays full input-token price for its own system prompt and any context it has to re-establish, every single spawn, with no cache credit from the parent's work.
The less obvious cost: a fork that inherits a long conversation inherits a long context window, not just a cache hit. A fork spawned late in a long session starts with everything already in that session's context, which counts toward the fork's own context budget and its own output-generation cost on every turn it takes, independent of caching. A pipeline that fans out several forks from the same point in a long-running session multiplies that inherited context by the number of forks, where the same fan-out using non-fork subagents each pay only for their own, much shorter, task-scoped context.
The background-execution half of the changelog entry adds a second, separate cost lever: because non-teammate spawns now default to background, a pipeline that used to serialize subagent calls one at a time — implicitly rate-limiting itself by making the user wait — can now issue several in parallel without anyone changing a line of orchestration code. Parallel background fan-out is not free just because it doesn't block the terminal; it is still concurrent token spend, and it now happens by default rather than by explicit request.
Where Context Can Now Leak Between Subagents
"Leakage" here doesn't mean a security bug — it means information crossing a boundary your pipeline's design assumed was closed. Two cases are worth checking in an existing setup.
Secrets or scratch content typed earlier in the session. If your main conversation ever had a credential, a customer name, or an internal path pass through it — even briefly, even for a step unrelated to the fork's task — a fork spawned afterward carries that history by default. A non-fork subagent would not have seen it unless the parent explicitly wrote it into the delegation prompt.
A fork's own tool calls stay contained on the way back out. The subagent documentation is explicit that "the fork's own tool calls still stay out of your conversation and only its final result comes back" — so the leakage risk here runs one direction, parent-to-fork, not fork-to-parent. A fork can see everything the parent has done so far; the parent still only sees the fork's final report, not its intermediate tool calls.
Neither of these is a new capability introduced by this release — a fork could always inherit conversation history when explicitly configured to. What changed is the trigger: code that calls subagent_type: "fork" without having reasoned about inheritance now gets it automatically, on every spawn, going forward.
If You Already Have a Custom subagent_type Config
Three checks are specific enough to run today against an existing multi-agent pipeline:
- Grep your agent definitions and Agent tool calls for
subagent_type: "fork". Any call site using it now inherits conversation and cache without an extra flag. If that call site was written when forks needed explicit configuration to inherit context, its author's mental model may be stale. - Check what runs before the fork spawns in the same session. If secrets, customer data, or unrelated scratch work routinely appear earlier in the conversation the fork is spawned from, that content is now in scope for the fork by default.
- Recheck any cost or latency assumption baked into orchestration logic. Code that throttled subagent fan-out because spawns used to block the interactive session, or that budgeted subagent cost assuming a cold, task-scoped context every time, is now running against a background-by-default, potentially cache-and-history-inheriting default.
The corresponding opt-out is architectural, not a flag: use a non-fork subagent_type — a named agent definition, or one of the built-ins such as general-purpose, Explore, or Plan — for any task that should start from a clean, task-scoped context. The subagent reference also documents an isolation: "worktree" field, available to both forks and non-fork subagents, that isolates a subagent's file-system writes into a separate git worktree; this controls file isolation specifically and is orthogonal to the conversation and cache inheritance this release changed.
What to Check This Week
- Confirm your Claude Code version. The default changed in 2.1.232; a pipeline pinned to an earlier build does not see this behavior yet.
- Audit every
subagent_type: "fork"call site for whether inheriting the full parent conversation and cache is what that call site actually wants. - Re-examine what precedes a fork spawn in the same session for secrets, customer data, or content that should not be visible to a delegated task.
- Re-price subagent fan-out against the possibility of a long inherited context per fork, not just the possible cache savings.
- Switch task-scoped work to a non-fork
subagent_typewherever a clean, isolated context is the actual requirement, rather than relying on a default that just changed direction.
None of this is a reason to avoid forks. A shared cache and shared history are exactly what makes a fork cheaper and more coherent than a cold subagent for a task that genuinely continues the same conversation — drafting a follow-up section, continuing an in-progress refactor, or handing off a task mid-session without re-explaining it. The change in 2.1.232 is that this behavior is now the default rather than something you had to configure, which is precisely why it is worth one deliberate pass over any pipeline that already names subagent_type: "fork".