[BUG] Cyber-safeguard feedback loop: discussing a previous false positive is itself the strongest trigger for new flags, locking the user out of the session

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Working context: local-only LLM engineering lab — C++ harnesses around llama.cpp, open-weight models on the user's own hardware. Nothing touches external systems. Hours of actual coding/debugging never trigger safeguard flags.

The bug: once one cyber false positive occurs, the in-session conversation needed to diagnose and report it — reading the model_refusal_* events from the session transcript, discussing why the flag fired, drafting a bug report — becomes the dominant trigger for further cyber flags. Flag frequency escalates with accumulated meta-discussion until the session hard-blocks (model_refusal_no_fallback) and must be abandoned. The work itself never flags; discussing the flags does.

Evidence (all events are type=system, subtype=model_refusal_* in local session transcripts; all apiRefusalCategory: cyber):

• 2026-08-05, 21:01–21:26 local: 4 refusal events in 25 minutes, all while discussing why the first flag fired. Two were full blocks: req_011CdkJk7dP4qmMqoAKjqgjW, req_011CdkJopz8UQ5u9hz5YiWPF. The chain at 21:26:12 shows Fable 5 refused → fallback Opus 5 also refused.
• 2026-08-06 09:45:07 UTC: the first message of a new day in the post-mortem session was a one-line joke with zero technical content. Flagged cyber. The current message cannot be the cause; only the accumulated context can.
• 2026-08-07, 13:12:50–13:16:12 local: resuming the same session produced 5 refusal events in 4 minutes, including full block req_011CdoSy2sCGYYrdetispUoU. Session unusable; the only remedy was abandoning the session and its context.

Control experiment: a fresh session — same user, same machine, same model (Fable 5) — ran the same transcript-forensics greps over the same refusal records: zero flags. The differentiator is the accumulated meta-discussion, not the tooling, the files, or the user.

Net effect: a false positive cannot be debugged or reported from inside the session where it happened — the attempt locks the user out. That is a feedback loop by construction, and it punishes exactly the workflow the refusal banner invites ("Send feedback").

What Should Happen?

The classifier should weight the current request rather than letting accumulated discussion-of-safeguards context dominate. Diagnosing or reporting a refusal — a workflow the refusal banner itself invites — should not raise the probability of further refusals to the point of session lock-out. A conversation ABOUT a false positive is not cyber-offensive content.

Error Messages/Logs

2026-08-07 13:14:31 | type=system subtype=model_refusal_no_fallback | originalModel=claude-fable-5 | requestId=req_011CdoSy2sCGYYrdetispUoU | apiRefusalCategory=cyber | apiRefusalExplanation="This request triggered restrictions on violative cyber content and was blocked under Anthropic's Usage Policy. ..."

Banner (fallback case): "Fable 5's safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate coding, cybersecurity, and biology tasks. Switched to Opus 5. Send feedback..."

Earlier full blocks (2026-08-05): req_011CdkJk7dP4qmMqoAKjqgjW, req_011CdkJopz8UQ5u9hz5YiWPF

Steps to Reproduce

1. In a long Claude Code session doing benign local engineering work, hit one cyber false positive (accumulated-context flagging per #74295 makes this likely in long sessions).
2. In the SAME session, investigate it: grep the transcript for model_refusal_* events, discuss why the flag fired, draft a bug report about it.
3. Observe flag frequency escalate — in our transcripts: 4 events/25 min on day 1, then 5 events/4 min when the session was resumed on day 3 — including model_refusal_no_fallback full blocks that end the session.
4. Open a fresh session and run the exact same transcript forensics: zero flags. This isolates the trigger to the accumulated meta-discussion about the safeguards, not the work.

Related issues (searched before filing): #74295 (context accumulation, general), #82319 (silent fallback / notification gap), #84408 (silent model switch). This report is distinct: it isolates WHICH accumulated content is the strongest trigger — the discussion of a previous false positive itself — and the resulting lock-out loop.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.224 (VSCode native extension, win32-x64)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Compounding UI defect observed at 2026-08-05 21:26:12: when Fable 5 refused and the fallback Opus 5 ALSO refused, the banner read "Opus 5's safeguards flagged this message" — naming the fallback model, not the model that originally refused. That misattribution sent us diagnosing the wrong model for a day. Mentioned here as context because it is what makes the feedback loop undebuggable; happy to split it into a separate report if preferred.

Also relevant: model_refusal_fallback carries scope: session, so after one flag the remainder of the day silently ran on Opus 5 (related: #82319, #84408). This masked the pattern — the flag-free period was Opus serving, not the trigger being absent.

All timestamps/request IDs come from the local session transcripts (~/.claude/projects/**/*.jsonl); we can provide fuller excerpts on request.