[Bug] False-positive Usage Policy violation kills sessions during routine bug fixing on user's own CRUD API code

Environment

• Claude Code version: 2.1.167
• Platform: macOS (darwin 25.3.0)
• Model: Opus 4.8 (claude-opus-4-8[1m])

Description

Sessions doing completely ordinary bug hunting and bug fixing on my own CRUD API are being killed mid-task with:

API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit your last message or start a new session for Claude Code to assist with a different task.

To be clear about what the "violating" work actually is:

• It is MY OWN code.
• Much of it is code that Claude Code itself wrote in earlier sessions.
• The activity is finding bugs in that code and fixing them. Standard CRUD endpoints, validation, Mongoose hooks. Nothing remotely adjacent to anything in the AUP.

So the loop is: Claude Code writes the code, Claude Code finds bugs in the code, and then Claude Code refuses to fix the code because fixing it "appears to violate" the Usage Policy. This is absurd, and I mean that literally, not rhetorically.

Impact

• The error terminates the working session. All accumulated context is lost.
• Every kill means re-paying tokens to rebuild context in a fresh session before any actual work resumes. The classifier is not just blocking requests, it is actively burning paid tokens on re-establishing state that the false positive destroyed.
• This is recurring, not a one-off, on the same repository doing the same legitimate maintenance work.

Expected behavior

Routine bug hunting and bug fixing on the user's own application code should never trip a Usage Policy classifier. At minimum, a false positive should not destroy the session and its context; it should be recoverable in place.

Related

Appears to be the same false-positive classifier class as #65271, #62619, #61088, #65116, #65750, #65454. The volume of open duplicates suggests the classifier's precision on ordinary debugging/security-adjacent vocabulary ("bug", "exploit a race condition", "injection test", etc.) needs review.