Claude Code 2.1.203 to 2.1.214: caps are an admission

Between 7 and 18 July, Anthropic shipped eleven versions of Claude Code, 2.1.203 through 2.1.214, with no changelog entry for 2.1.213. The list is long and mostly detail work. Two releases stand out, 2.1.212 on 17 July and 2.1.214 on 18 July, and they point the same way: hard caps against agents running in circles, and a row of permission checks that could be bypassed. My thesis: both are admissions. Runaway loops are a real operational problem, not a theoretical one. And the permission layer that many people base their approval practice on was demonstrably leaky.

Which caps are new?

Three of them, all in 2.1.212. First, a session-wide limit on WebSearch tool calls, default 200, tunable via CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION. The changelog states the reason literally: to stop runaway search loops. Second, a per-session cap on subagent spawns, also 200, overridable via CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION, with /clear resetting the budget. Again the entry names the reason: delegation loops that do not stop on their own. Third, MCP tool calls running longer than two minutes now move to the background automatically so the session stays usable. The threshold can be changed or disabled via CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS. One more change follows the same pattern: /fork now copies your conversation into its own background session with its own row in claude agents, and the in-session subagent the command used to launch is now /subtask. A command that did two different things now does one.

200 sounds generous, and for most sessions the limit will never bite. That is precisely the point. A limit that stays invisible in normal operation does not exist for normal operation. It exists because someone saw sessions spawn subagents in the hundreds without finishing. Fitting that 2.1.203 already carried the note that agents are now less likely to re-delegate their entire task to another subagent. First they taught the model, then they added a counter.

Why are the permission fixes the real story?

Because they show that the layer meant to ask when in doubt simply did not ask, in several places. 2.1.214 lists this without sugar-coating. A permission-check bypass affected commands run in Windows PowerShell 5.1 sessions. Bash permission checks now fail closed on file-descriptor redirect forms that bash parses differently than the permission analyzer. Very long commands were misjudged; anything over 10,000 characters now always prompts instead of running automatically. Zsh variable subscripts and modifiers inside [[ ]] comparisons were treated as inert text and now prompt for approval. Certain help and man commands were auto-approved even though they could run unsafe options, command substitutions, or backslash paths. Permission prompts on remote sessions could proceed before the local confirmation dialog had been answered. And an allow rule like Edit(src/**) auto-approved writes to nested src/ directories anywhere in the tree instead of only under the working directory.

The most uncomfortable entry is already in 2.1.212: plan mode auto-ran file-modifying Bash commands such as touch and rm without a permission prompt and without the SDK’s canUseTool callback. Plan mode is the mode you work in when you do not want the agent touching anything yet. Deletion commands slipping through there is exactly the case where the protective assumption and the actual behavior are furthest apart. Similar in 2.1.210: subagents with isolation: "worktree" could run git-mutating commands against the main repository checkout instead of their own isolated worktree.

I do not read this as an accusation. Finding these bugs and writing them down in public is more than most vendors do, and the list is also a sign that someone is looking for them systematically. The sober conclusion stands anyway: an allowlist that has to parse Bash commands is a parser pitted against a parser. Bash and Zsh are languages with decades of edge cases. Every one of those six entries is an edge case the analyzer read differently than the shell did. They will not be the last.

What does this mean day to day?

First, treat permission rules as convenience, not as a security boundary. If you want to limit the damage an agent can do, do it through the environment it runs in, so a container, its own worktree, restricted credentials, and not through a rule list that interprets command lines. Also review your own dir/** rules; their meaning changed in 2.1.214. Single-segment allow and hook patterns now match only under the working directory, and you write **/dir/** for any-depth matching. Deny and ask rules keep the old any-depth behavior.

Second, set the caps deliberately instead of inheriting 200. If one of your sessions realistically needs 20 subagents, then 200 is not a guardrail but a very late emergency brake. The variables are there; the right value is yours.

In early July the same vendor dialed its trust defaults back toward oversight. These eleven days continue that line one level down: no longer when the question gets asked, but whether the question was reliably asked at all. It is the same observation as in agentic engineering: agent capability grows faster than the machinery that keeps it verifiable. Reliability does not live in the model, and not in the rule list either. It lives in the architecture around them. Responsibility stays with the human who started the run.

Sources

• Claude Code: Changelog