[BUG] `/model` in one session silently changes the model of every future session: an unnoticed downgrade led to data loss and put a root-privileged system agent on a model the user never chose

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?

Claude Code version: 2.1.283 (Linux, Gentoo)

Summary

Running /model <name> inside a session does more than switch that session. It also saves the model as the
global default for every new session, in every project. From its name and from how CLI commands normally
behave, /model reads as "use this model here". Nothing makes clear that its effect is global and lasting.

I lowered the model in a few sessions of other projects to save usage. Hours later, a new session in an
unrelated project, one I only ever run on Opus, started on Sonnet. I did not notice. For about 14 hours and
7 sessions a different model worked on that project. In that time it:

• shipped a bug that deleted stored data,
• rebuilt a build directory without a required option,
• ran sudo on a system service.

I first put the drop in quality down to the model I believed I was talking to.

What happened (all times UTC, from the session transcripts)

1. 2026-09-29 11:27. In three running sessions of other projects (Project A, Project B, Project C) I ran /model claude-sonnet-5 to reduce usage. Each printed one line:

Set model to 'Sonnet 5' and saved as your default for new sessions. Changing several parallel sessions
in a row, I did not read this as "all future sessions everywhere".

1. 2026-09-29 18:51 to 2026-09-30 08:25. Seven new sessions in Project D, a project I only ever run on Opus, started on

claude-sonnet-5 (about 3,000 assistant messages). Before that, every session in this project had run on
Opus. I started them with plain claude, expecting the model I always use there. No startup notice said
the model differed from the one the project last ran with.

1. Work done in those sessions that later had to be found and repaired:

• Data loss: a store routine deleted already-sampled species records whenever a body was mapped

after sampling. It was fixed only after a review of all commits from that period, together with
about 8 other defects in the same commit range.

• The build directory was reconfigured from scratch without a required -D... option. This deleted a

helper binary and silently disabled a feature for a whole play session.

• Security: on 2026-09-30 06:21 the session ran sudo unbound-control flush_infra all to "fix" a DNS

failure blocking git push. I interrupted it. A system-level change like this was never in scope for that
project.

1. 2026-09-30 09:13. I found the cause and ran /model claude-opus-5-5. That message again said

"saved as your default for new sessions", which only then explained what had happened. Since then I start
every session with claude --model claude-opus-5-5 and have a project rule to refuse work on any other
model.

The same default reached my system administration agent, which has root

I run several Claude Code agents, each with its own degree of trust. One of them is a system agent. It holds
root through sudo and looks after this machine's security, configuration and upkeep, and it also
administers remote company servers. My whole setup, and the work of my company, depends on that agent
deciding well. For it I pick the model deliberately.

The transcripts show that this agent too ran on claude-sonnet-5, from 2026-09-29 23:43 to 2026-09-30
19:00 UTC: 9 consecutive sessions, still on Sonnet hours after I had put the default back to Opus. As root it:

• installed packages (sudo emerge ...),
• changed group membership (gpasswd),
• added a udev rule under /etc/udev/rules.d/ and replaced /etc/gamemode.ini,
• switched the system Wine (eselect),
• installed binaries as root,
• ran sudo commands on a remote company server for security audit with explicite request to be readonly, including a TRY reading /etc/shadow and password status of root.

Whether I asked for each of these does not change the point. They were privileged reads at production
systems, made under a model I had not chosen for that agent. I was not told, and I had no reason to check.
Had that agent misjudged a single change, I could have lost the ability to boot this machine and the local
systems my business runs on.

Why this is a safety problem, not only a UX one

• A lasting, global side effect sits behind a command that looks session-local. Almost every CLI tool treats a

switch or flag as affecting the current invocation; persisting defaults is done by an explicit config set /
settings command.

• The only signal is a single line at the moment of the change, in a different session. Nothing appears

where the consequence lands: at the start of later sessions in other projects.

• The model largely decides how an agent handles destructive and privileged actions. A silent model change is

therefore a silent change of the risk profile of every agent the user starts afterwards, including agents
allowed to write to disk, rebuild, commit and push.

• The user naturally blames the output on the model they think they are using, so the root cause stays hidden

and the harm goes on.

• The command is neither privilege escalation nor a permission change. Permission modes and hooks apply as

before. But the same word does very different things: claude --model X affects one invocation, while
/model X affects every future session of every agent. With agents of very different privilege on one
machine, that makes a cost-saving change in a low-risk project a silent change to the highest-privilege
agent.

What Should Happen?

Suggested fixes (any of these would have prevented it)

1. Make /model session-only by default. Persist it only on explicit request, e.g. /model --save-default,

or a separate /config-style command with a name like "set global default model".

1. At startup, when the model comes from a global default set in another project or session (or differs

from the model this project last used), show a clear notice. For example:
Model: Sonnet 5 (global default set 2026-09-29 in ~/projects/project-a).

1. Support a per-project model in .claude/settings.json that takes precedence over the global default.

If it exists already, point to it from the /model output.

1. In the /model confirmation, spell out the scope: "Saved as the default for ALL new sessions in ALL

projects."

Environment notes

• Model defaults can currently be found in ~/.claude/settings.json ("model": ...).
• Evidence: the session transcripts (~/.claude/projects/*/*.jsonl) show the /model commands and their

output, and the model field of every assistant message by session.

Error Messages/Logs

Steps to Reproduce

1. In project A, start claude (default model Opus).
2. Run /model claude-sonnet-5. Output: "Set model to 'Sonnet 5' and saved as your default for new sessions".
3. Exit. In an unrelated project B, start plain claude.
4. Session B runs on Sonnet, with no startup notice that the model came from a /model command issued in project A.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.283 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

In established tooling the option prefix is pure syntax, never a change of scope. On Linux the POSIX/GNU convention gives an option a short form with one dash and a long form with two (-v / --verbose, -h / --help). Both affect only the current invocation. Clang accepts -std=c++23 and --std=c++23 alike, and clang-cl treats /O2 and -O2 as the same option. Where a tool does make a lasting, global change, it says so explicitly: git config --global, systemctl enable, gsettings set.

Users carry this expectation over, so claude --model X and /model X read as the same option. Their scope, however, differs completely: one invocation versus every future session in every project, with no "global" anywhere in the name.