[Bug] Overzealous AUP classifier blocks legitimate defensive-security development repeatedly

Bug Description
Title: Paying subscriber repeatedly blocked by false-positive AUP/safety classifier on a legitimate defensive-security project I am a paying subscriber working on my own commercial DevSecOps product ("Sentinelle"), comparable to OWASP ZAP / Burp Suite / Nessus. It performs authorized security testing ONLY against applications I own. The safety/AUP classifier interrupts my sessions repeatedly. Every time I run a security audit on MY OWN code, the conversation gets flagged and I am forced to restart from scratch — losing tokens and progress each time. This is happening even with a project-level CLAUDE.md that clearly states the work is authorized defensive security on owned infrastructure. Impact: - I cannot do legitimate, authorized security work that I am paying for. - Repeated false positives waste my paid tokens with no result. - The classifier does not say which message triggered it, so I cannot adjust. - I am near the end of an important project and keep getting reset to zero. Request: 1. Reduce false positives for legitimate defensive-security / pentest tooling developed against owned/authorized targets. 2. When CLAUDE.md establishes authorized-security context, weight it before refusing. 3. Tell the user WHICH input triggered the classifier so it can be addressed. This is the documented "overzealous classifier" problem (see The Register, Apr 2026, and issues #52272 / #57949 / #61659). As a paying customer I expect to be able to do authorized security work on my own projects without being reset. Environment: Claude Code, model claude-opus-4-8 (1M context), Linux.

Environment Info

• Platform: linux
• Terminal: gnome-terminal
• Version: 2.1.168
• Feedback ID: 3a6db469-2803-4878-90f5-e075978d667f

Errors

[]