claude-code 2.1.212 Splits Forks and Subtasks
claude-code v2.1.212 is a GitHub release for Claude Code that runs in your terminal, IDE, and GitHub workflows. Parallel agent work is powerful, but it can also make sessions hard to follow, expensive to search from, or stuck behind slow integrations. Simple: /fork now means keep this conversation moving in a background session, while /subtask is the narrower in-session delegate. A Claude Code agent team is a group of Claude agents running separate sessions against the same work, so the practical answer to how to enable agent teams in Claude Code is to use agent view and /fork, then set sane budgets before you hand it a repo.
Treat /fork as a new session, not a helper
The most visible change is semantic. In v2.1.212, /fork copies your current conversation into a new background session and gives it its own row in claude agents, while you keep working in the original session.
That matters because a fork is now closer to opening a second workbench than calling a quick assistant. You can send one path after a flaky test, another after a refactor idea, and keep the main thread clean enough to make decisions.
Don't use /fork when you wanted a small, bounded inspection. The old in-session subagent behavior moved to /subtask, so a prompt like use a subtask to inspect the auth middleware and report only the files involved now belongs there.
A nice slash-command workflow looks like this:
# In the main Claude Code session
/fork investigate why the API client retries twice in CI but once locally
# Still in the main session
/subtask inspect package scripts and test setup; do not edit files
The fork can keep running in the background. The subtask should come back as local evidence you can use immediately.
Put budgets around delegation before it loops
The release adds two explicit brakes. WebSearch tool calls now have a session-wide default limit of 200, tunable with CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION. Subagent spawns now have a per-session default cap of 200, tunable with CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION, and /clear resets that budget.
Those numbers are high enough that most normal Claude Code workflows will never notice them. They are there for the bad afternoon: a broad research prompt, a mistaken recursive instruction, or a Claude Code subagents pattern that keeps delegating instead of deciding.
Don't treat the defaults as a target. For a small repo experiment, lower them. You want the session to fail loudly before it spends an hour proving your prompt was too vague.
export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=20
export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=20
This is also where a small convention helps. On Team conventions, the durable rule is not use agents everywhere. It is name the boundary: when to fork, when to subtask, and when to stop.
Let slow MCP tools move out of the way
v2.1.212 also changes how slow MCP calls behave. MCP tool calls that run longer than two minutes now move to the background automatically, so the interactive session stays usable. The threshold is configurable with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS, and the release notes say it can be disabled with that same setting.
MCP is Claude Code’s integration layer for external systems such as issue trackers, document stores, databases, and private tools. The practical win is simple: a slow database read or internal search should not freeze the conversation you are using to think.
Don't assume background means safe. Background means the foreground is usable. You still need a permission boundary for tools that can mutate state, and you still need to review what the integration returned before building on it.
The release has two safety fixes worth noticing. Plan mode no longer auto-runs file-modifying Bash commands such as touch or rm without a permission prompt or SDK canUseTool callback. Worktree creation also no longer follows a repository-committed symlink at .claude/work, which closes a nasty edge around where worktrees get placed.
Try agent teams on one small repo
This is the practical section if your question is how to enable agent teams in Claude Code without turning your main repository into a science project. Pick a small repo with a real test command, one external integration at most, and a branch you can throw away.
Start by resetting auto-mode if you have customized it heavily:
claude auto-mode reset
# or, when you really mean it
claude auto-mode reset --yes
Then start a normal Claude Code session. Ask for a plan first, not edits. Use /fork for one parallel investigation, use /subtask for one focused inspection inside the current session, and keep both prompts boringly specific.
A good first experiment is a failing test with an unclear owner:
Main session: summarize the failing test and propose the smallest fix. Do not edit yet.
/fork trace the history of the failing assertion and report likely intent. Do not edit files.
/subtask inspect related fixtures and list only the files that influence this assertion.
Before you rely on the result, check three things. Did the fork create a separate background session in agent view? Did the subtask return evidence instead of edits? Did any MCP call or WebSearch path hit the budget you set?
For the narrower background-session angle, see Claude Code 2.1.212 Tames Background Sessions.
Copyable v2.1.212 test note
Paste this into the issue, PR description, or session handoff after your first test. It is small on purpose.
Claude Code v2.1.212 check
Repo:
Branch:
Test command:
Setup:
- [ ] Ran `claude auto-mode reset` or confirmed current auto-mode settings
- [ ] Set a low subagent cap for the test: `CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=20`
- [ ] Set a low WebSearch cap for the test: `CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=20`
- [ ] Left MCP auto-background at the default 2-minute behavior, or recorded the custom value
Session behavior:
- [ ] Used `/fork` for one background investigation
- [ ] Used `/subtask` for one in-session inspection
- [ ] Confirmed the fork appeared as its own background agent session
- [ ] Confirmed the subtask returned evidence, not surprise edits
Review:
- [ ] Checked permission prompts for file-modifying Bash commands
- [ ] Checked whether any MCP call moved to the background
- [ ] Compared the final edit against the main session plan
- [ ] Recorded any confusing command behavior for follow-up
The useful signal is not whether the agent was impressive. The useful signal is whether you can reconstruct which session produced which evidence.