Claude Code 2.1.212 Tames Background Sessions

Claude Code 2.1.212 is an official @anthropic changelog release for Claude Code, Anthropic's coding agent, published on July 17, 2026. It deals with a very practical problem: long-running agent work, runaway loops, and tool failures can make a coding session hard to trust. The takeaway is simple: this version tames background work, adds budgets around search and subagents, and fixes several places where permissions or processes behaved too loosely. If you are learning how to use claude for code review, the useful part is not a new review button; it is a safer session model for asking Claude Code to inspect a pull request while you keep working.

Claude Code 2.1.212 is a workflow-hardening release: it changes how sessions split, how long tool calls behave, and how the CLI stops work when something goes wrong. That sounds small until you have watched an agent disappear into recursive search, spawn helpers forever, or leave a shell command running after the session ended.

Let /fork become a real background session

The headline change is that /fork now copies your current conversation into a new background session. That new session gets its own row in claude agents, while your current session stays available.

Before this release, the behavior that lived behind /fork was closer to an in-session subagent. In 2.1.212, that older behavior has been renamed to /subtask, which is a nicer split: use /fork when the branch of work deserves its own lifecycle, and use /subtask when you want a smaller helper inside the same session.

A real example: you are reviewing a billing PR. You can keep the main session focused on the diff, then /fork a second pass that checks migration risk or data-access assumptions. The trap is treating /fork like a throwaway note. It is now a real background session, so name the job clearly and ask for a review receipt you can inspect later.

The release also changes /resume in the agent view. Typing /resume now opens a picker of past sessions, including sessions deleted from the list, and resumes the one you pick as a background session. That is useful when the context was good but the visible session list was cleaned up too aggressively.

Put runaway work on a budget

Claude Code 2.1.212 adds two default caps that matter when a prompt is too broad. WebSearch tool calls now have a session-wide default limit of 200, tunable with CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION. Subagent spawns also have a per-session default cap of 200, tunable with CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION.

MCP is the integration layer Claude Code uses to call external systems such as repositories, documents, issue trackers, databases, and internal tools. In this release, MCP tool calls that run longer than 2 minutes move to the background automatically, so the session stays usable. The threshold can be configured, or the behavior disabled, with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS.

For a review-heavy repo, I would start lower than the defaults while you test the shape of the work:

export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=40
export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=12
export CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=120000

Those numbers are not magic. They are a small-repo safety rail. The trap is setting caps so low that legitimate research or dependency tracing gets cut off before Claude Code can produce evidence. Also note the changelog detail: /clear resets the subagent budget, so a fresh session boundary can also reset how much delegation is available.

Read the fixes as review clues

The bug fixes in this release are the part I would read twice. Plan mode no longer auto-runs file-modifying Bash commands such as touch or rm without a permission prompt or SDK canUseTool callback. That is exactly the kind of edge you care about during a claude code security review: planning should not quietly become mutation.

The worktree fix is similarly concrete. Claude Code fixed worktree creation following a repository-committed symlink at .claude/worktrees, which could create files outside the repository. In plain terms, a path that looked local could point somewhere else. If your repo uses worktrees and committed symlinks, this was not theoretical plumbing.

Hooks also got a sharper boundary. A continue:false hook halt is no longer dropped when the tool fails or completes mid-stream, and hook infrastructure errors are no longer misreported as user rejections. That matters because hooks are often where a repo enforces a no-write boundary, a test gate, or a review handoff receipt.

There are process fixes too. SIGTERM during a running Bash tool in print or SDK mode now aborts the turn, kills the process tree, and exits 143, instead of orphaning the command. On Windows, /background and claude --bg now prefer PowerShell 7 when Group Policy blocks PowerShell 5.1. For a nearby story about agent ergonomics and waiting states, see claude-meseeks Adds Meeseeks Waiting Alerts.

Try one repo-level code review pass

The best first experiment is a single Claude Code PR review where the agent may inspect, reason, and report, but not edit. This is the practical answer to how to use claude for code review with this release: let the new background-session behavior split the work, and make the output evidence-based enough that a human reviewer can accept or reject it quickly.

Start on a PR branch and ask Claude Code for a read-only pass:

Review this PR for risky behavior changes. Do not edit files. Return findings with file:line, evidence from the diff, risk level, and the smallest test or manual check that would prove the finding.

Then use /fork for one focused background pass:

/fork Run a claude code pr review focused only on auth, permissions, and data exposure. Do not edit files. Return only findings with evidence.

Use /subtask for a narrow local question, such as whether a helper function changed behavior across call sites. Keep the main session for the review narrative. If your repo has a concise CLAUDE.md, it can carry durable conventions like test commands and forbidden write paths, but do not hide the review request there. For the broader habit of keeping repo conventions small and inspectable, see the related training topic.

Copy this safe-review checklist for one repo

Use this checklist as a small experiment, not a ceremony. The point is to prove that Claude Code 2.1.212 can keep the session usable while producing review evidence you would actually paste into a PR.

A good claude code review should feel boring at the end. You should have a short list of claims, each tied to code, and no mystery about what the agent changed. In this particular experiment, the safest answer is that it changed nothing.

Common questions

• Does Claude Code 2.1.212 change how to use claude for code review?

  Yes, mainly by making review sessions easier to split and contain. /fork now creates a separate background session, while /subtask keeps smaller helper work in-session. The citable detail is that both WebSearch calls and subagent spawns now have default per-session limits of 200.

• What is the difference between /fork and /subtask now?

  /fork now copies the conversation into a new background session with its own row in claude agents. /subtask is the old in-session helper behavior under a clearer name. Use /fork for a parallel review track; use /subtask for a narrow question inside the current flow.

• Do the new caps stop every runaway agent loop?

  No, they are limits, not a proof of correctness. The defaults cap WebSearch calls at 200 per session and subagent spawns at 200 per session, with environment variables available for tuning. A vague prompt can still waste time before it hits the ceiling.

• Why does MCP auto-backgrounding matter?

  It keeps the main session usable when an integration call runs long. In 2.1.212, MCP tool calls longer than 2 minutes move to the background automatically, unless you configure or disable that behavior. The tradeoff is that background work still needs a clear receipt when it finishes.

• Should I trust plan mode more after this release?

  Trust it a little more, but still verify. The release fixes plan mode auto-running file-modifying Bash commands without a permission prompt or SDK callback. That is an important boundary fix, yet a careful review still asks Claude Code to state whether it read files, wrote files, or ran commands.

Best ways to use this research

• Best for: developers already using Claude Code in real repositories who want to understand why 2.1.212 matters beyond a list of fixes.
• Best first artifact: a one-PR evidence checklist that requires file:line, diff evidence, risk, and a test for every finding.
• Best comparison angle: compare /fork and /subtask by lifecycle, not vibes: background session versus in-session helper.
• Best safety habit: lower the search and subagent caps for a small repo experiment, then raise them only when the agent is failing for lack of budget.
• Best limitation to remember: background work is still work. It needs a name, a narrow prompt, and a reviewable receipt.

Further reading

• @anthropic — source
• Anthropic — Claude Code product page
• Claude Code — getting started

Next step

Run one read-only PR review with /fork, a small subagent cap, and an evidence checklist. If the output is easy to verify without replaying the chat, keep the pattern.

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.