[BUG] Safety-classifier fallback silently switches whole session to Opus 4.8; switchModelsOnFlag:false is ignored

What's Wrong?

While doing routine, authorized IT fleet administration (managing our own office PCs: remote screenshots, lock-screen setup, background monitoring scripts, RADIUS config), Fable 5.1's safety classifier repeatedly flags assistant turns as [cyber]. On each flag Claude Code writes a model_refusal_fallback entry ("Switched to Opus 4.8") and the WHOLE session silently continues on claude-opus-4-8 — in one session 255 consecutive messages (~2 hours), in the previous session it fired 3 times (857 messages on Opus 4.8 vs 803 on Fable).

On the switch, prior thinking blocks are dropped with reason: model_mismatch (13 blocks / 11 turns in one case), so the session visibly loses context. To the user this presents as "Claude got dumb and forgets" with no indication anywhere in the UI that the model changed.

Three distinct problems:

1. False positives: standard sysadmin work on machines we own/manage is flagged as [cyber] repeatedly; the only per-flag recourse is /feedback.
2. "switchModelsOnFlag": false does not prevent the switch (it was already set in settings.json before the incident). The binary appears to have a silentAttempt / refusalFallbackSilentArm* path that bypasses the opt-out and the confirmation dialog entirely.
3. The downgrade is silent and sticky — no banner, and the session stays on Opus 4.8 until the user manually runs /model.

What Should Happen?

• switchModelsOnFlag: false should be honored — no model switch without the user's consent.
• Any fallback switch must be visibly announced in the UI and should be per-turn, not session-sticky.
• A model switch should not silently drop prior thinking blocks and destroy context.
• Legitimate IT-administration work on self-managed machines should not be classified as [cyber].

Error Messages/Logs

system entry: model_refusal_fallback — "Switched to Opus 4.8" (flag category: cyber)
subsequent assistant messages: "model":"claude-opus-4-8"
dropped thinking blocks: reason: model_mismatch

Steps to Reproduce

1. Set "switchModelsOnFlag": false in settings.json and start a session on claude-fable-5-1.
2. Do legitimate fleet-admin work in the conversation (e.g. discuss/implement remote screenshot capture and a background monitoring watcher for office PCs you manage).
3. Eventually an assistant turn gets flagged [cyber] → transcript shows a model_refusal_fallback entry.
4. Observe: no visible notice, every subsequent message runs on claude-opus-4-8, prior thinking blocks dropped with model_mismatch, and the session never returns to Fable until /model is run manually.

Workaround found

env.CLAUDE_CODE_DISABLE_REFUSAL_FALLBACK=1 in settings.json disables the whole fallback feature (flagged requests then refuse on Fable and the user re-prompts, instead of a silent multi-hour downgrade). This env var is undocumented.

Environment

• Claude Model: claude-fable-5-1
• Claude Code Version: 2.1.285 (Claude Code)
• Regression: unsure — first verified on 2.1.285 (also present in a session two days prior on the same version)
• Platform: Claude subscription (Max)
• OS: Linux (Ubuntu, kernel 6.17)
• Terminal: bash over ssh/tmux