claude-code - 💡(How to fix) Fix False positive on Claude Code Usage Policy classifier — please stop over-flagging legitimate engineering work

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?

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.
4. 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.
2. Review the two Request IDs above and confirm they were false positives.
3. Tune the classifier so that ordinary developer workflows (especially those using MCP tools, shell utilities, and multi-agent coordination) are not penalized.
4. 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.
4. 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.
2. Review the two Request IDs above and confirm they were false positives.
3. Tune the classifier so that ordinary developer workflows (especially those using MCP tools, shell utilities, and multi-agent coordination) are not penalized.
4. 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