[Bug] Safeguard [cyber] false positive on local diagnostics pins the whole session to Opus 4.8 (repro for #87837)

Follow-up to #87837, which was closed for lack of reproduction steps. I went back through the session logs (~/.claude/projects/**/*.jsonl) from the day it was filed and found the exact mechanism, so here is the full report.

What happens

The model switch is not random. It is the CLI's safeguard refusal fallback: Fable 5's classifier flags a request as [cyber], the CLI retries the request on Opus 4.8, and because the fallback has scope: "session", every subsequent turn in that session also runs on Opus 4.8. The configured model is never retried.

The classifier is firing on plain local troubleshooting — reading a LaunchAgent plist, running --help on a local binary, checking why a localhost MCP server refuses connections. Since 2026-08-03 I have 15 of these fallback events across my sessions (v2.1.220 → v2.1.247). All 15 are category cyber, all Fable 5 → Opus, and none were security work.

Exact instance behind #87837

Session cc4bb9ec-4c88-4ee4-9949-e8c8adc44f19, v2.1.235, macOS, Apple Terminal, settings.json model claude-fable-5[1m]. Feedback ID from the original report: 4513aca6-09b9-47b0-be78-2f8afaea6c5f.

1. 05:31:42Z — ran /mcp. Output: Failed to reconnect to whatsapp: ConnectionRefused at http://127.0.0.1:2178.
2. 05:32:09Z — asked: "why connection failed check and if its an issue pls raise it as an issue on the mcp on remote".
3. 05:32:51Z–05:32:59Z — Claude (Fable 5) ran file on the MCP binary, cat ~/Library/LaunchAgents/<the server's plist>, and <binary> --help. All normal.
4. 05:33:03Z — the next API call was refused. The CLI retried on Opus 4.8 and logged:

{"type":"system","subtype":"model_refusal_fallback","level":"warning","trigger":"refusal","direction":"retry","scope":"session","originalModel":"claude-fable-5","fallbackModel":"claude-opus-4-8","requestId":"req_011CeBZVXeRrsqJnFZUjUBFm","apiRefusalCategory":"cyber","apiRefusalExplanation":null,"timestamp":"2026-08-19T05:33:14.489Z","version":"2.1.235"}

Displayed text: "Fable 5's safeguards flagged this message. … Switched to Opus 4.8. … Details: [cyber]"

1. Every assistant message for the rest of the session (~100 more) is claude-opus-4-8. I filed #87837 from that session at 05:34:11Z.

A second instance the same day, session 72a1942f-8c15-4e82-a4b4-b3a0729d0c7e (req_011CeBn1dDXPZB6LLqrdPh56, 08:17:38Z), was triggered by a plain-English message about how to word replies — no code, no commands, no tool calls in that turn — and again pinned the remaining session (2.5 hours of work, ~350k cached context) to Opus 4.8.

Steps to reproduce

1. Set "model": "claude-fable-5[1m]" in ~/.claude/settings.json.
2. Configure any stdio/HTTP MCP server, then stop it so it refuses connections.
3. Start claude, run /mcp (it reports the connection failure).
4. Ask: "why connection failed check".
5. Let Claude read the server's LaunchAgent plist / run the binary's --help.
6. Watch for the model_refusal_fallback warning. From then on /status and the statusline show Opus 4.8 and every reply is Opus 4.8 until the session is closed.

It does not fire every time (the classifier is probabilistic), but with local process/plist/launchd diagnostics it fires often — 15 times in about four weeks for me.

Expected

• A refusal on one request should fall back for that turn, then retry the configured model on the next turn — not pin the whole session. If pinning stays, the notice should say how to get back (/model), because as #87837 shows, the switch reads as "Claude Code is randomly changing models".
• Reading a plist, running --help, or diagnosing a ConnectionRefused on 127.0.0.1 should not be classified as cyber. The docs say the fallback for a cyber flag is fixed at Opus 4.8 regardless of fallbackModel, so every false positive here is a two-generation downgrade (Fable 5 → Opus 4.8) for the rest of the session, which makes classifier precision on local-diagnostics content matter more than for other categories.

Correction to what I first wrote here: an opt-out already exists — switchModelsOnFlag: false (/config → "Switch models when a message is flagged") pauses instead of switching. So this report is not asking for that; it is about the false positives and the session-scope pinning.

Environment

• Platform: darwin (macOS 25.5.0), Terminal: Apple_Terminal
• Versions observed: 2.1.220, 2.1.221, 2.1.227, 2.1.232, 2.1.233, 2.1.235, 2.1.245, 2.1.247 (current 2.1.252)
• Model setting: claude-fable-5[1m], effortLevel: high
• Request IDs: req_011CeBZVXeRrsqJnFZUjUBFm, req_011CeBn1dDXPZB6LLqrdPh56