Claude Code release notes: 2.1.166 fallback models and stricter permissions

Adam Olofsson HammareAdam Olofsson Hammare
Claude Code release notes: 2.1.166 fallback models and stricter permissions

Claude Code 2.1.166 is not the loudest Claude update, but it is easy to use at work: fewer dead stops when a model is overloaded, clearer denied tools, and less risk that another Claude session accidentally carries the wrong authority.

Claude Code is Anthropic's coding agent: Claude in the terminal, with permission to inspect codebases, edit files, and use tools when you allow it. For small Nordic teams, the signal is simple. Agent work gets more useful when both the backup path and the stop rules are easy to understand.

Claude Code release notes 2.1.166: fallback model when the primary model is unavailable

The most practical change is fallbackModel. Claude Code can now be configured with up to three fallback models, tried in order when the primary model is overloaded or unavailable. --fallback-model now applies to interactive sessions too, and Claude Code can retry a turn once on a fallback model if the API rejects an unexpected error that would normally not be retried. Authentication errors, rate limits, oversized requests, and transport errors still surface immediately.

A fallback model is a backup model used only when the primary path does not hold. That makes it useful for report drafts, code review, documentation, and other workflows where an interruption costs more than switching model, as long as the team can still see which model did the work.

Sources: Claude Code changelog plus GitHub release v2.1.166 and NPM package metadata

Stricter deny rules and safer messages between sessions

The same release also tightens the agent control plane. Deny rules now support globs in the tool-name position, where "*" can deny all tools. Allow rules reject non-MCP globs, and unknown tool names in deny rules warn at startup. An approval gate is a rule or checkpoint where a person or policy must approve access before the agent continues.

Cross-session messaging is harder to misuse too. Messages relayed through SendMessage from other Claude sessions no longer carry user authority. Receiving sessions refuse relayed permission requests, and auto mode blocks them.

That is the right kind of boring. If several agents work in parallel, a status note should be able to move between sessions without turning into a shortcut around your permissions. Pair it with scoped API keys, secrets in a secret manager, redaction before logging, and audit logs for important runs.

Sources: Claude Code changelog plus GitHub release v2.1.166 and Claude Code settings

Try this prompt this week

Human step: Choose one Claude Code workflow that is already used for real work. Check the current version with claude --version, review the model and tool rules, and decide where a fallback model is acceptable. Do not turn that setup decision into a loose chat prompt.

Source for version check and release context: Claude Code changelog

Read our Claude Code settings and tool rules for [workflow].
Point out where a fallback model would reduce stoppage without hiding accountability.
List which tools should be denied or require approval.
Suggest one small run log that records model choice, denied tools, and human decisions.
Do not edit files until I approve the plan.

Good output should include:

  • One primary model and no more than three fallback models, not a vague model pool.
  • Tools that are allowed, denied, or require approval.
  • One simple log line per agent run: model, tool, decision, result.
  • A short note on when a human should stop or review the run.

Where Hammer would start

For Hammer Automation, this is Tool Forge work: take a promising Claude routine and make it operational enough for more people than the person who built it. Not by slowing everything down, but by writing down fallback paths, permissions, and review points so the agent can do real work without becoming a black box.

If you already use Claude Code for code, documentation, or internal processes, the next step is not more prompts. It is a small run policy: which model starts, which fallback may take over, which tools are closed by default, and which decisions must leave a trace.

The Forge newsletter

Get new articles in your inbox

Pick the topics you care about. No noise, at most one email a week.

Get new articles in your inbox

We follow GDPR. Unsubscribe anytime.