Claude Code v2.1.166: Four changes that matter for multi-agent pipelines in production

A quick note on version numbers before we get into it: the four features this post covers all shipped in Claude Code v2.1.166, released 6 June 2026. The current latest release is v2.1.171, a minor subsequent patch. Everything described here is present and active in that version.

None of these four changes are flashy. There is no new model, no new UI. What there is, for teams running Claude Code as part of a multi-agent pipeline, is a meaningful reduction in four specific categories of production pain: model overload cascades, overly broad tool access policies, inter-agent privilege escalation, and unexpected token costs from thinking models. Each fix is narrow and targeted, which is exactly what you want from a patch-level release.

Fallback models: automated recovery when your primary is unavailable

The new fallbackModel setting lets you configure up to three backup models, tried in priority order, when the primary model is overloaded or unavailable. The --fallback-model flag now also works in interactive sessions, not just headless or SDK modes.

The retry logic is deliberate about what it will and will not swallow. If the API returns an unexpected non-retryable error, Claude Code retries once on the fallback. But auth failures, rate limits, request-size violations, and transport errors surface immediately. They are not silently redirected to a backup model. That distinction matters: you still want to know when your credentials are wrong or your context window is too large. You just do not want a transient overload on one model to stall an entire pipeline while a human decides what to do.

For orchestration setups where a subagent stall can cascade into a full pipeline failure, this is straightforward resilience infrastructure that was previously missing.

Glob-pattern deny rules: write tighter access policies without enumerating every tool

Claude Code’s permission system already supported allow and deny rules on tools, but writing a deny policy that covered everything required listing every tool name explicitly. That is fragile as toolsets evolve.

With this release, the tool-name position in deny rules accepts glob syntax. A single "*" in the deny position blocks all tools on an agent. You can then write specific allow rules for exactly the tools that agent needs.

The intentional asymmetry here is worth noting: globs work in deny rules, but allow rules reject non-MCP globs. You can lock down broadly, but you must be precise when granting access. That is a sensible default for a security-conscious permission model.

There is also a practical operational improvement: unknown tool names in deny rules now generate a warning at startup. If you have a stale rule referencing a tool that no longer exists, or a typo in a tool name, you find out when the agent starts rather than discovering the misconfiguration silently at runtime when the policy fails to apply.

SendMessage authority hardening: closing a privilege escalation path in agent teams

This is the most security-significant change in the release, and it addresses a specific structural weakness in how Claude Code’s agent teams architecture worked.

In agent teams, each teammate runs in its own session with its own context window and inbox, communicating via SendMessage and coordinating through a shared task queue. Messages are written to inbox files under ~/.claude/teams/default/inboxes/. The problem is that prior to v2.1.166, messages relayed between sessions via SendMessage could carry user-level authority. A compromised or prompt-injected subagent could relay a permission request that the receiving session treated as coming from the original user.

The fix establishes a clear trust-tier boundary. Messages arriving via a relayed SendMessage are now marked as coming from an agent, not a user. The receiving session will not honor permission requests embedded in those messages, and auto mode blocks them outright. Agents sit below users in Claude Code’s principal hierarchy (Anthropic, then operators, then users), and they can no longer escalate by routing through the messaging bus.

Claude Code’s threat model for auto mode explicitly calls out prompt injection and overeager behavior as risks in multi-agent topologies. This change directly addresses both. It also ships alongside a fix for SendMessage silently breaking when CLAUDE_CODE_TMPDIR or $TMPDIR pointed at a deep directory path, which is worth noting because a broken messaging bus and a hardened one are only useful when the bus is actually working.

Thinking-control fixes: disable extended reasoning when you do not need it

Some Claude models think by default. Extended thinking on a model like an Opus variant can consume significant tokens on reasoning steps that your use case does not require. Previously, MAX_THINKING_TOKENS=0, --thinking disabled, and the per-model UI toggle were all ignored on models that think by default when accessed via the Anthropic API. The flags existed but had no effect.

That is now fixed. All three controls correctly suppress thinking on default-thinking models via the Claude API.

Two things to be aware of. First, Fable 5 is a documented exception: the session thinking toggle, alwaysThinkingEnabled, and MAX_THINKING_TOKENS=0 all have no effect on it. It always reasons adaptively. If you are routing through Fable 5, thinking cannot be disabled. Second, this fix applies to the Anthropic API. Teams using Bedrock, Vertex, or Azure AI Foundry as their provider are unaffected.

For pipelines that use thinking-capable models for tasks that genuinely do not benefit from extended reasoning, this is a straightforward cost control fix that should have worked from the start.

The bigger picture

Taken together, these four changes address the operational realities that come up when Claude Code moves from a single-developer terminal tool into a production multi-agent system. Resilience against model availability, precise access policy management, secure inter-agent communication, and predictable token costs are all table-stakes concerns for that context.

None of these were dramatic architectural changes. They were gaps between what the tooling promised and what it delivered in practice. v2.1.166 closes four of them.

The full changelog is on GitHub if you want to review everything in the release.