model_refusal_fallback (category: cyber) repeatedly fires on legitimate tmux-based multi-session orchestration; with switchModelsOnFlag: false the coordinator session is blocked

Environment

• Claude Code 2.1.222, Linux (Ubuntu 24.04, self-hosted dev VM)
• Model: claude-fable-5 (set via ANTHROPIC_MODEL by our tmux launcher), effort high
• switchModelsOnFlag: false in ~/.claude/settings.json

Setup (legitimate use case)

We run 10–15 parallel Claude Code sessions in tmux — one per repository of an
e-commerce platform (catalog, storefront, infra, shipping). One session acts as a
coordinator: it assigns work to the other windows via tmux send-keys, reads the
target window state via tmux capture-pane before each send (our own safety flow, so
it never overwrites a human's typed input), and otherwise consumes distilled state
files produced by an external non-LLM Python watcher. All sessions are our own, on our
own machine, working on our own repositories. Domain content is e-commerce (product
catalogs, storefront rendering, shipping) — no security tooling.

Problem

Since 2026-07-31 the coordinator session repeatedly receives
type: "system", subtype: "model_refusal_fallback" with
apiRefusalCategory: "cyber", level: "warning", trigger: "refusal", silently
switching claude-fable-5 → claude-opus-*.

Structured events measured from our transcripts (*.jsonl):

• 10 × model_refusal_fallback between 2026-07-31 and 2026-08-05

(first: 2026-07-31T10:12:11Z, claude-fable-5 → claude-opus-5); daily pattern
07-31 ×1, 08-01 ×2, 08-03 ×4, 08-05 ×2. All category: cyber.

• The most frequent tool calls immediately preceding these events are plain tmux

orchestration: Bash(tmux …) 155×, Bash(cd …) 94×, git, ls, grep — no
offensive-security content of any kind.

• A separate api_error 529 (Overloaded) fallback also occurs; that one is

understandable — mentioned only to note we distinguish the two causes.

With the default switchModelsOnFlag: true the switch is silent (we ran for a
whole morning on a different model than configured before noticing — we had to build
our own detection: a PreToolUse hook comparing message.model against the expected
model, plus an external systemd watcher). With switchModelsOnFlag: false every flag
becomes a hard stop, so the coordinator is now repeatedly blocked mid-work.

Why this matters

The classifier appears to pattern-match "AI reads and controls other terminal
sessions" as cyber tooling. But orchestrating one's own Claude Code sessions over
tmux is a common power-user pattern (several public orchestration projects exist), and
there is no offensive content involved. Both outcomes are bad: silent model
substitution undermines trust in model pinning; hard-stop makes the workflow unusable.

Related issues

• #67246 (open) — safety-classifier model switch fires on benign content, /model cannot override
• #61646 (open) — false-positive cyber-safeguard on legitimate systems-engineering work
• #66697, #63499 (closed) — same classifier class on defensive-security work

Ask

1. Tune the cyber classifier for terminal-automation of the user's own Claude Code

sessions (tmux send-keys/capture-pane of sibling Claude Code windows).

1. Provide a working appeal/override channel for false positives (the

cyber use case form referenced in community posts appears unavailable), or an
org-level allowlist.

1. Make the fallback observable: a visible, persistent notification and a

documented event, so users don't discover a silent model switch hours later.

Happy to provide sanitized event logs (timestamps + preceding tool names only) on request.