False positive on Claude Code Usage Policy classifier — please stop over-flagging legitimate engineering work

Resolved 💬 8 comments Opened May 23, 2026 by minjun0207 Closed Jul 4, 2026

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?

  1. It interrupts legitimate paid work. I am a paying user using Claude Code as a professional engineering tool.
  2. It is demonstrably a false positive. The flagged content is build logs and inter-agent coordination messages.
  3. 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.

  1. The recovery instructions (esc esc / new session) destroy accumulated working context, which is extremely costly in

long-running engineering sessions.

What I am requesting

  1. Stop false-positive flagging on routine engineering content — shell commands, build output, process IDs, and inter-agent

coordination messages are not policy violations.

  1. Review the two Request IDs above and confirm they were false positives.
  2. Tune the classifier so that ordinary developer workflows (especially those using MCP tools, shell utilities, and

multi-agent coordination) are not penalized.

  1. 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

  1. It interrupts legitimate paid work. I am a paying user using Claude Code as a professional engineering tool.
  2. It is demonstrably a false positive. The flagged content is build logs and inter-agent coordination messages.
  3. 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.

  1. The recovery instructions (esc esc / new session) destroy accumulated working context, which is extremely costly in

long-running engineering sessions.

What I am requesting

  1. Stop false-positive flagging on routine engineering content — shell commands, build output, process IDs, and inter-agent

coordination messages are not policy violations.

  1. Review the two Request IDs above and confirm they were false positives.
  2. Tune the classifier so that ordinary developer workflows (especially those using MCP tools, shell utilities, and

multi-agent coordination) are not penalized.

  1. 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_

View original on GitHub ↗

This issue has 8 comments on GitHub. Read the full discussion on GitHub ↗