/model selection silently overridden (Fable 5.1 → Opus 4.8), likely a security-classification false-positive on a benign Wine game-compat task

Summary

An explicit model selection made via /model was silently overridden mid-session. I selected Fable 5.1 (and saved it as my default), but the session continued to run as Opus 4.8. I did not choose Opus 4.8 at any point.

What I observed (verifiable)

• I ran /model and set the model to Fable 5.1 (twice — the second time it was saved as my default for new sessions).
• Despite that, the session's own status line reported "You are powered by the model named Opus 4.8."
• So my explicit /model choice was not honored; the effective model was something I never selected.

What I expected

/model is an explicit user choice. If the harness must route away from the selected model (for policy/classification reasons or otherwise), it should at minimum be visible and explained — not a silent override. Ideally the user's selection should be honored, or the user should be told why it can't be, with a way to opt back in.

Suspected cause (my hypothesis — not confirmed from inside the session)

The session was a long, benign task: getting a legally-owned game client (MapleStory TW) to run on Linux under Wine. The work involved things a naive security classifier could easily flag:

• Binary-patching Wine's own DLLs (kernelbase.dll, win32u.so) to fix Wine compatibility bugs
• Reading/analyzing anti-cheat components (BlackCipher / NEXON Game Security) from logs
• Disassembly and socket/WINEDEBUG tracing
• Vocabulary like "bypass" — used only to state that bypassing anti-cheat was explicitly refused

None of this is offensive security. The task never touched credential theft, malware, exploitation of third-party systems, or anti-cheat circumvention (that was explicitly declined). If a security classifier is what triggered the model change, this is a false positive on legitimate software-compatibility / reverse-engineering-for-interoperability work.

I want to be precise: I can confirm the override (selected Fable 5.1, ran as Opus 4.8). I cannot confirm from inside the session that a security classification caused it — that is my inference based on the task content.

Why this matters

Reverse-engineering and binary patching for interoperability / getting owned software to run is a mainstream, legitimate developer activity. Silently downgrading/overriding the user's chosen model on these tasks (a) breaks the explicit /model contract, and (b) penalizes benign work. At minimum the override should be transparent; ideally the classifier should not treat "make my game run on Linux via Wine" as a security threat.

Repro

1. Start a session and use /model to select a model (e.g. Fable 5.1).
2. Do a task involving Wine DLL binary-patching + anti-cheat log analysis + disassembly.
3. Observe the effective model reported by the session become/remain a different model (Opus 4.8) than the one selected.

Environment

• Claude Code, Linux (Ubuntu, kernel 6.8), interactive terminal session
• Model explicitly selected: Fable 5.1; effective model observed: Opus 4.8