claude-code 2.1.212 Splits Forks and Subtasks

claude-code v2.1.212 is a GitHub release for Claude Code, Anthropic’s coding agent that runs in your terminal, IDE, and GitHub workflows. It deals with a very specific problem: parallel agent work is powerful, but it can also make sessions hard to follow, expensive to search from, or stuck behind slow integrations. The takeaway is 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.

The trap is using /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.

The trap is treating 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 the related training topic, 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.

The trap is assuming 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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about claude agents?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of claude code subagents. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “claude-code 2.1.212 Splits Forks and Subtasks.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• claude-code — source
• Claude Code — getting started
• Claude Code — skills
• Claude Code docs: en hooks

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.