Fable 5 refusal fallback: silent degradation in desktop app, /model switch-back reverts next turn, /feedback blocked by CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

Environment

• Claude Code Desktop app, Windows 11 Pro
• Selected model: claude-fable-5
• CLI session: 714e497c-3537-4cec-84c1-85c24bfa7f6d

What happened

Two model_refusal_fallback events fired in one session. Both flagged routine proxy/network-ops content (mihomo/clash config maintenance, cron pipeline path fixes — ordinary sysadmin work, no dual-use intent):

| # | requestId | UTC timestamp |
|---|---|---|
| 1 | req_011CcvEZmPYGJXkjRmqsQVQH | 2026-07-11T12:02:10.016Z |
| 2 | req_011CcvFG7mWEPoGSX4FQVv4Z | 2026-07-11T12:10:51.336Z |

Transcript system record (level=warning): "Fable 5's safeguards flagged this message. … Switched to Opus 4.8. Send feedback with /feedback …"

Pain points

1. Silent degradation in the desktop app. The warning record exists in the transcript jsonl, but no banner was noticed in the desktop UI — the conversation continued seamlessly on Opus 4.8 and the user only discovered the switch afterwards by asking the agent to forensically scan the transcript model fields. The warning record's timestamp equals the first Opus-generated message of the same turn, so the message stream looks completely continuous.

1. /model switch-back doesn't stick. After event #1 the user explicitly ran /model claude-fable-5 (stdout confirmed "Set model to claude-fable-5"). The very next reply — a plain forensic question about when the degradation had happened — was flagged again and generated by Opus 4.8 (event #2). There is no persistent UI indicator that the effective model differs from the selected one.

1. The recommended feedback path can be unavailable. The banner says "Send feedback with /feedback", but /feedback is disabled when CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 is set. Users who disable nonessential traffic for privacy reasons then have no in-product way to report safeguard false positives (the user had to temporarily remove that env setting just to submit feedback). Consider exempting explicit user-initiated feedback from that switch, or having the banner/error point to an alternative channel.

Expected

• A persistent, visible indicator whenever the effective model differs from the user-selected model (not only a transient system line).
• Routine coding / network-operations content not to trip the safeguard, or at least a frictionless way to report false positives.

🤖 Generated with Claude Code