False positive on Claude Code Usage Policy classifier — please stop over-flagging legitimate engineering work
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?
- It interrupts legitimate paid work. I am a paying user using Claude Code as a professional engineering tool.
- It is demonstrably a false positive. The flagged content is build logs and inter-agent coordination messages.
- It is reproducible. The classifier appears to over-fire on long sessions containing shell commands (e.g., kill <PID>, ps
aux), MCP reply payloads, and mixed-language technical content.
- The recovery instructions (esc esc / new session) destroy accumulated working context, which is extremely costly in
long-running engineering sessions.
What I am requesting
- Stop false-positive flagging on routine engineering content — shell commands, build output, process IDs, and inter-agent
coordination messages are not policy violations.
- Review the two Request IDs above and confirm they were false positives.
- Tune the classifier so that ordinary developer workflows (especially those using MCP tools, shell utilities, and
multi-agent coordination) are not penalized.
- Provide a more granular signal than a hard block when the classifier is uncertain — at minimum, do not destroy the user's
session context on a low-confidence flag.
I understand the importance of safety classifiers. But a classifier that blocks kill <PID> and swift test output is not
protecting anyone — it is degrading the product for legitimate users.
Please address this.
Regards,
A Claude Code user
What Should Happen?
While running Claude Code on the SPIRAL project — a normal, lawful software engineering workflow — my session was blocked
with the following message:
▎ "Claude Code is unable to respond to this request, which appears to violate our Usage Policy."
▎
▎ Request IDs:
▎ - req_011CbJnKgyNFxcRAKMNnZNqX
▎ - req_011CbJmZtJXERVFHDocsWTAP
The blocked content consisted entirely of:
- Standard build/test progress (swift test, Gate A pass logs)
- Routine process management (ps aux, killing a stuck background poll)
- A SIGN packet message to a collaborating agent (Codex) via the AgentBridge MCP server
- Engineering status updates in mixed Korean/English
None of this content violates the Anthropic Usage Policy in any reasonable interpretation. There is no harmful content, no
malicious code, no policy-violating intent — only ordinary day-to-day development work.
Error Messages/Logs
Steps to Reproduce
To whom it may concern,
I am writing to formally request that the Claude Code content classifier stop producing false positives on my legitimate
software engineering sessions.
What happened
While running Claude Code on the SPIRAL project — a normal, lawful software engineering workflow — my session was blocked
with the following message:
▎ "Claude Code is unable to respond to this request, which appears to violate our Usage Policy."
▎
▎ Request IDs:
▎ - req_011CbJnKgyNFxcRAKMNnZNqX
▎ - req_011CbJmZtJXERVFHDocsWTAP
The blocked content consisted entirely of:
- Standard build/test progress (swift test, Gate A pass logs)
- Routine process management (ps aux, killing a stuck background poll)
- A SIGN packet message to a collaborating agent (Codex) via the AgentBridge MCP server
- Engineering status updates in mixed Korean/English
None of this content violates the Anthropic Usage Policy in any reasonable interpretation. There is no harmful content, no
malicious code, no policy-violating intent — only ordinary day-to-day development work.
Why this is a problem
- It interrupts legitimate paid work. I am a paying user using Claude Code as a professional engineering tool.
- It is demonstrably a false positive. The flagged content is build logs and inter-agent coordination messages.
- It is reproducible. The classifier appears to over-fire on long sessions containing shell commands (e.g., kill <PID>, ps
aux), MCP reply payloads, and mixed-language technical content.
- The recovery instructions (esc esc / new session) destroy accumulated working context, which is extremely costly in
long-running engineering sessions.
What I am requesting
- Stop false-positive flagging on routine engineering content — shell commands, build output, process IDs, and inter-agent
coordination messages are not policy violations.
- Review the two Request IDs above and confirm they were false positives.
- Tune the classifier so that ordinary developer workflows (especially those using MCP tools, shell utilities, and
multi-agent coordination) are not penalized.
- Provide a more granular signal than a hard block when the classifier is uncertain — at minimum, do not destroy the user's
session context on a low-confidence flag.
I understand the importance of safety classifiers. But a classifier that blocks kill <PID> and swift test output is not
protecting anyone — it is degrading the product for legitimate users.
Please address this.
Regards,
A Claude Code user
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.149
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
This issue has 8 comments on GitHub. Read the full discussion on GitHub ↗