[BUG] ANTHROPIC_MODEL locks the session model after 2.1.216 — /model cannot override
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:
settings.json's"model"continues to take effect, as it did on 2.1.215; or- the environment variable takes precedence at startup, **but
/modelcan still
change the model within the session.**
Actual behaviour
- New sessions open on
claude-haiku-4-5-20251001despite"model": "opus". /modeldoes 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
- Surface the override. If
ANTHROPIC_MODELis 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.
- Let
/modelwin 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.
- Document the precedence between
ANTHROPIC_MODELandsettings.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_