[BUG] ANTHROPIC_MODEL locks the session model after 2.1.216 — /model cannot override

Status Open
Reported on v2.1.216
Maintainer reply None cached
Activity 0 comments · opened Jul 21, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug report — ANTHROPIC_MODEL locks the session model after 2.1.216

Summary

After Claude Code auto-updated from 2.1.215 to 2.1.216, every new session starts
on the model named by the ANTHROPIC_MODEL environment variable, ignoring the
"model" value in settings.json. /model then cannot switch away from it for the
rest of that session — the switch appears to be accepted, but the session stays on
the environment variable's model.

The identical configuration worked correctly on 2.1.215 (and older) for several weeks: sessions
honoured settings.json, and /model worked normally.

Environment

  • Claude Code: 2.1.216 (auto-updated from 2.1.215)
  • Update record: ~/.claude/.last-update-result.json

{"timestamp":"2026-07-21T13:38:04.672Z","path":"npm-global","outcome":"success","version_from":"2.1.215","version_to":"2.1.216"}

  • Platform: WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2), running in Docker
  • Install method: npm global
  • Entrypoint: CLI

Configuration at the time

~/.claude/settings.json:

{
  "model": "opus",
  "effortLevel": "high"
}

Environment (exported from ~/.bashrc):

ANTHROPIC_MODEL=claude-haiku-4-5-20251001

The variable was set deliberately, but for a different tool — a separate CLI
utility (graphify) that also reads ANTHROPIC_MODEL and only needs a small model.
It was never intended to apply to Claude Code, and under 2.1.215 (and earlier) it did not
noticeably do so.

No managed-settings.json exists at any of the standard policy paths.

Expected behaviour

Either of these would be fine:

  1. settings.json's "model" continues to take effect, as it did on 2.1.215; or
  2. the environment variable takes precedence at startup, **but /model can still

change the model within the session.**

Actual behaviour

  • New sessions open on claude-haiku-4-5-20251001 despite "model": "opus".
  • /model does not move the session off it. The selection appears to register, but

responses continue to come from the environment variable's model.

  • There is no message anywhere explaining that an environment variable is

overriding the setting, or that the model is pinned. That is the core of the
problem: the behaviour is silent and gives the user nothing to act on.

Timeline observed

All times UTC, 2026-07-21.

| Time | Event |
|------|-------|
| ~11:43 | Session A opened while still on 2.1.215. It opened on Haiku, but /model switched it to Opus successfully and it held for the entire session. |
| 13:38 | Auto-update 2.1.215 → 2.1.216. |
| after 13:38 | Sessions B and C opened on 2.1.216. Both locked to Haiku; /model would not move either. |
| — | Closing Claude Code and exiting/re-entering the Docker containers did not help — the updated binary persists on disk. |

Session A, started before the update, remained on Opus (after being switched) for its whole life. That
contrast is the clearest evidence that the change arrived with 2.1.216 rather than
with any configuration change: nothing in the user's configuration changed between
Session A and Session B.

Impact

A user on a paid plan was silently downgraded to a much smaller model, mid-project,
with no indication of why, and no working way to switch back. The work in progress
was regulatory documentation for a medical-device project, where the model
difference is material.

Because the variable was set for an unrelated tool, and because nothing surfaces the
override, there was no reasonable path from the symptom to the cause. It took a
filesystem-level investigation to find it.

Workaround

Remove the global export and scope the variable to the tool that actually needs it —
for example, wrapping that tool in a shell function that sets ANTHROPIC_MODEL only
for that command. After that, Claude Code honours settings.json again.

Suggested fixes, in order of usefulness

  1. Surface the override. If ANTHROPIC_MODEL is set and differs from the

configured model, say so at startup and in /model. A single line naming the
variable would have reduced this from a multi-hour investigation to a five-second
fix.

  1. Let /model win within a session. An explicit in-session choice by the user

should outrank an ambient environment variable. If it cannot, /model should
refuse visibly and explain why, rather than appearing to succeed.

  1. Document the precedence between ANTHROPIC_MODEL and settings.json.model,

and note it in the 2.1.216 release notes if the change was intentional.

Note

If the precedence change was deliberate, points 1 and 2 still stand: the failure is
silent, and a user cannot discover the cause from inside the product.

What Should Happen?

See the expected behaviour in the description of the problem that I got my remaining window of Opus to write (above).

Error Messages/Logs

None. It failed silently.

Steps to Reproduce

See the conditions noted in the description of the problem that I got my remaining window of Opus to write (above).

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.215

Claude Code Version

2.1.216

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_

View original on GitHub ↗