If you learned /fork before mid-July 2026, the command you type from muscle memory now does something different. Same name, same keystrokes, a different result — and nothing in the interface tells you that on its own.
Claude Code v2.1.212, released July 17, 2026, restructured /fork. It didn’t rename it, deprecate it, or gate it behind a flag. It changed what happens when you run it, and moved the old behavior to a new command, /subtask. The weekly release digest for that period describes it in one line: “/fork now copies your conversation into a new background session with its own row in claude agents while you keep working; the in-session forked subagent it used to launch is now /subtask.”
This guide covers the behavior shipped in v2.1.212 and confirmed in Claude Code’s official command reference and sub-agents documentation as of this writing. Check your version with
claude --version; the split only applies on v2.1.212 or later, and only when agent view is turned on.
What Changed
Before v2.1.212, /fork did one thing: it spawned a subagent that inherited your entire conversation — full message history, system prompt, tools, model — and ran a side task with that context, in a panel below your prompt, without leaving your session. When it finished, its result landed back in your main conversation as a message. Handy for “draft unit tests for what we just built” while you kept coding in the foreground.
As of v2.1.212, /fork does something structurally different. Per the official docs:
“Run
/forkto copy the current conversation into a new background session while the original keeps running. The copy starts with everything in the conversation up to that point, plus the working directory, model, permission mode, effort level, and any directories or ‘don’t ask again’ permission grants you added during the session, and appears as its own row in agent view. From that moment the two sessions are independent: what the copy does never reaches the original conversation.”
That’s the trap. It’s not a smaller or bigger version of the old /fork — it’s a different category of thing. The old /fork was a delegate-and-report-back mechanism inside one conversation. The new /fork is a full clone that walks off and lives its own life in claude agents, and whatever it does stays there unless you go check on it yourself.
The old behavior wasn’t removed. It’s still there, under /subtask.
Old vs. New /fork, Compared Directly
/fork before v2.1.212 (now /subtask) | /fork from v2.1.212 | |
|---|---|---|
| What it creates | A subagent inheriting the full conversation | A new, independent background session |
| Where it runs | In a panel below your prompt, inside the current session | As its own row in claude agents |
| Result delivery | Comes back as a message in your main conversation | Never returns to the original conversation automatically |
| Isolation from original session | None — sees the same history, tools, model | Full, from the moment it’s created |
| Counts toward subagent spawn limit | Yes (default cap: 200 per session, CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION) | No — runs with its own separate budget |
| How you check on it | Wait for it to finish; message appears automatically | Select its row in claude agents and press Space, or claude attach <id> |
| Command today | /subtask [prompt] | /fork [prompt] |
Both commands still accept an optional prompt argument. With /fork [prompt], the new background session starts on that prompt immediately; run bare /fork and the copy waits in claude agents for its first instruction — the docs note the row will show “space to send it a prompt” until you do.
One more wrinkle worth knowing: if you’ve turned off agent view, /fork reverts to the pre-2.1.212 forked-subagent behavior, and /subtask isn’t available at all. The split only exists when agent view is on.
The New /subtask Command
/subtask [prompt] is exactly the command /fork used to be, under a new name. A subtask is a subagent that inherits your whole conversation instead of starting with a clean, isolated context the way a named subagent (like Explore or a custom agent) does. That’s the specific value it offers: you can hand it a side task without re-explaining what you’re doing, because it already saw everything that happened in the session up to that point.
/subtask draft unit tests for the parser changes so farIt runs in the background panel under your prompt while you keep working in the foreground. Its own tool calls — file reads, greps, whatever it does to complete the task — stay out of your main context window. Only the final result comes back, as a message. You can watch it while it runs: arrow keys move between the panel’s rows, Enter opens a running subtask’s transcript so you can send it follow-ups, x dismisses a finished one or stops a running one, Esc returns focus to your prompt.
Two details that matter if you’re tracking session limits:
- A
/subtaskcounts toward your per-session subagent spawn cap (200 by default). If Claude itself has already burned through that budget dispatching its own subagents, your own/subtaskstill goes through — the limit only blocks subagents Claude spawns automatically via the Agent tool, not ones you start by hand. - A
/forksession doesn’t count against that cap at all. It’s a fully separate background session with its own resource budget, not a subagent under the current one.
If you’re on a version between v2.1.161 and v2.1.211, none of this applies to you yet — the command is still /fork, and it behaves like today’s /subtask. Before v2.1.161, the same capability existed but required setting CLAUDE_CODE_FORK_SUBAGENT=1 (available from v2.1.117); anyone who set that variable months ago is the exact audience most likely to be surprised by this change now.
How Forked Sessions Show Up in claude agents
This is the other half of the distinction, and it’s what makes /fork genuinely useful for a different class of work than /subtask.
Run claude agents and every background session you’ve dispatched — via /background//bg, via claude --bg, or now via /fork — appears as its own row, with the same status columns and controls as any other entry. A session created with /fork is not visually or functionally distinguished from one you started any other way; it’s a first-class, independent Claude Code session that happens to have started with a copy of your prior conversation instead of a blank one.
Subagents started with /subtask do not get a row in claude agents. They’re scoped to the session that spawned them and only show up in that session’s own background-task panel (and in /tasks, which lists a session’s current background work). If you want a dashboard view of “everything running right now,” /fork sessions are on it and /subtask runs are not — they’re one level down, inside whichever conversation dispatched them.
This lines up with the difference /background also draws: /background (alias /bg) detaches your current session into the background and frees up the terminal — the session itself moves, nothing is copied. /fork copies the session and keeps the original running in the foreground. Both land as rows in claude agents; /subtask never does.
When to Use /fork vs. /subtask
Use /subtask when:
- The side task is quick, and you want the result folded back into the conversation you’re already having — “check if this regex handles unicode,” “summarize what changed in this diff,” “draft tests for what we just wrote”
- You don’t want to context-switch away from your main session to go look at results elsewhere
- The task genuinely benefits from the subagent already knowing everything you’ve discussed, without you re-explaining it
Use /fork when:
- You want to try two different approaches from the same starting point and compare outcomes later, without either one polluting the other’s context
- The task is long-running or exploratory enough that you don’t want it blocking your ability to keep working in the original session
- You want the work trackable and resumable independently — closeable, attachable, checkable from
claude agents— rather than tied to the lifetime of your current terminal session - You’re near your per-session subagent spawn limit and want to sidestep it entirely
The practical rule: if you’d be satisfied with the answer showing up as a message in this chat, reach for /subtask. If you want a session you can walk away from and come back to on your own schedule, reach for /fork.
This split isn’t isolated. It’s part of a pattern across several July 2026 releases: v2.1.198 made subagents run in the background by default so the main conversation stays usable while they work; v2.1.212 (the release covered here) also made long-running MCP tool calls move to the background automatically after two minutes; and v2.1.218 changed /code-review itself to run as a background subagent. Claude Code is steadily separating “in-conversation, ephemeral” work from “background, independently trackable” work, and the /fork//subtask split is the clearest instance of that line being drawn through a single command.
FAQ
Q: I use /fork in scripts or muscle-memory habits from before July 2026 — will they silently break?
Not silently in the sense of erroring, but the outcome changes. A /fork some-task that used to return a result into your conversation will now start an independent background session that never reports back automatically. If your workflow depended on the old behavior, switch it to /subtask.
Q: Does /fork require an argument?
No. /fork [prompt] — pass a prompt and the new background session starts working on it immediately; run it bare and the copy waits in claude agents for its first instruction, which you send by selecting its row and pressing Space, or via claude attach <id>.
Q: What’s the difference between /fork and /branch?
/fork copies the conversation into a new background session while your original session keeps running in the foreground. /branch switches you into the copy — your original conversation stops being the one you’re driving. Use /branch when you want to explore a fork yourself; use /fork when you want it running independently while you keep working where you are.
Q: Does a /subtask show up anywhere I can monitor it, like claude agents?
No. /subtask runs are scoped to the session that started them — you monitor them in that session’s background-task panel (arrow keys, Enter, x, Esc) or via /tasks. Only /fork-created sessions get a row in claude agents.
Q: What happens if I have agent view turned off?
/fork reverts to the pre-2.1.212 forked-subagent behavior — the same thing /subtask does — and /subtask itself isn’t available as a command. The /fork//subtask split only exists with agent view on.
Q: Does /subtask count against any limit I should know about?
Yes. It counts toward the per-session subagent spawn cap, 200 by default (CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION), shared with subagents Claude spawns on its own. A /fork session runs independently and doesn’t draw from that budget at all.