[BUG] Mid-response safety classifier repeatedly interrupting benign follow-up requests after one legitimately-declined topic #104134

Preflight Checklist

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

What's Wrong?

Summary

In a single long Claude Code session, after I (correctly, per Claude's own stated policy) declined to help build/review a specific network-filter-evasion feature, the session's automated mid-response safety classifier went on to repeatedly interrupt and discard in-progress responses to unrelated, benign follow-up requests — including:

• A plain request to add a static UI text label to a game's menu (showing a server IP address already displayed elsewhere in the same menu, for players' reference).
• A request to review a different, unrelated set of file changes in a sibling folder.
• Ordinary clarifying exchanges about what the assistant would or wouldn't help with going forward.

Each interruption produced the generic message:

"Your response above was stopped by a safety classifier — this is not a tool or API error. The rest of it was withheld, and tool calls in it that had not finished did not run."

In several cases the interrupted response had not generated any disputed content yet — it was cut off while running an ordinary file-read tool call, or while writing plain prose that did not touch the earlier topic at all.

Why this matters

• The assistant itself (correctly) distinguishes between "I won't do X" and "nothing adjacent to X can ever be discussed again." The classifier does not appear to make the same distinction once a conversation has touched a sensitive topic once, even many turns and unrelated requests later.
• This degrades trust in the product for legitimate, security-conscious users: once a conversation has included any discussion of network/firewall topics (including ones Claude declined), ordinary follow-up engineering work in the same codebase becomes unreliable, with silent loss of in-progress tool calls.
• It also wastes the user's time and tokens: responses are discarded after tool calls have already started (in one case, after a build command had already been kicked off), so the work has to be redone.
• The interruption message gives no actionable detail (which part triggered it, whether rephrasing differently would help), so users cannot route around it other than trial and error — which in this case meant re-sending the same harmless request repeated times.

Suggested improvement

• Scope the mid-response classifier's sensitivity to the content being generated in that response, not to the conversation having touched a sensitive topic at any earlier point.
• When a response is interrupted mid-tool-call, avoid discarding tool calls that had already started and completed successfully (e.g., a file read), so retries don't need to repeat completed work.
• Consider a narrower or more specific interruption message when the triggering span is clearly disjoint from the actual disputed content (e.g., a one-line UI text diff), to help users/developers understand what to change.

Environment

• Claude Code (desktop app), models used in-session: Claude Opus 4.8 / Opus 5.5 / Sonnet 5 / Sonnet 5.5 (model was switched mid-session via /model)
• Reproducible pattern: ask Claude to decline a sensitive networking request once, then continue the same conversation with ordinary unrelated engineering tasks in the same project.

What Should Happen?

Claude should continue normally when asked unrelated, benign follow-up requests later in a long session — even after it has earlier (correctly) declined one specific sensitive request. Instead, an automated mid-response safety classifier repeatedly interrupts and discards in-progress responses to later, unrelated requests in the same conversation, including a plain request to add a static UI text label and a request to review an unrelated set of file changes. The interruption also discards tool calls that had already completed successfully (e.g. a build that had already started), so work has to be redone.

Error Messages/Logs

Your response above was stopped by a safety classifier — this is not a tool or API error. The rest of it was withheld, and tool calls in it that had not finished did not run.

Steps to Reproduce

1. Start a long Claude Code session in a project with networking-related code.
2. At some point, ask Claude to review/build something it correctly declines (in my case: a feature whose stated purpose was bypassing a network filter).
3. Continue the SAME conversation with ordinary, unrelated engineering requests later on (e.g. "add a text label above an IP input field" — a one-line, benign UI string change with no bypass/security implications).
4. The response is interrupted mid-generation (in one case, mid-tool-call, after a build command had already been kicked off) with: "Your response above was stopped by a safety classifier..."
5. Re-sending the same benign request, sometimes rephrased, is needed one or more times before it goes through.

Note: the interruption fires even when the response being generated at the time contains no disputed content itself — it appears to key off the conversation having touched the sensitive topic earlier, not off the content of the current response.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.293 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This happened in the desktop app's Code tab, not a terminal session. The pattern: once a conversation includes any discussion of network/firewall-adjacent topics — including ones Claude explicitly declines — later unrelated requests in that same conversation become unreliable, with silent loss of already-completed tool calls. No actionable detail is given in the interruption message (which span triggered it, whether rephrasing would help), so recovery is trial and error.