[Bug] Usage Policy classifier stuck in blocked state for legitimate kernel security work
Bug Description
Summary: Legitimate Linux kernel security/debugging work is being repeatedly blocked as a Usage Policy violation, including follow-up messages as innocuous as "Hi".
Context: I'm a Linux kernel engineer doing defensive security research — fuzzing kernel networking subsystems with syzkaller/BRF and writing C reproducers to confirm and fix crashes (e.g. a divide-by-zero I'm trying to reproduce so it can be patched and upstreamed). This is standard kernel debugging: a reproducer is the tool used to fix the bug, not to attack anything.
The problem: Requests like "create the file I can compile/run on the VM to trigger the bug" and "help find a reproducer for the divide-by-zero" are being rejected with "appears to violate our Usage Policy." Worse, once a session gets flagged, every subsequent message is blocked — including plain "Hi", "What's going on?", and "You okay?". The session becomes unusable and doesn't recover; only starting a brand-new session helps. This strongly suggests the classifier is weighting accumulated session context and getting stuck in a blocked state.
Why it's a false positive: The work is defensive kernel debugging (reproduce → fix → upstream). The trigger appears to be vocabulary overlap — "trigger the bug," "reproducer," "exploit a crash" — between fixing kernel bugs and attacking them, which are lexically near-identical but opposite in intent.
Impact: Blocks normal professional kernel development. Having benign messages like "Hi" rejected because of prior session context is especially disruptive.
Request IDs from the blocked turns:
req_011CbMvL4CzgzKmCJX4Bkk34
req_011CbMvTRtvUVb8SMWdkftkF
req_011CbMvVnf9NFGjxPmm6tuex
req_011CbMvcBHLfUV7DPTWdgMjS
req_011CbMvhgQggamokfpGmj8Dn
req_011CbMj5qpwVk2R86fhfPMGy (earlier turn, same session)
Environment Info
- Platform: linux
- Terminal: xterm-256color
- Version: 2.1.149
- Feedback ID: 272d13cc-8eaf-4c29-8096-2a6991ad44d9
Showing cached comments. Read the full discussion on GitHub ↗
13 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
seems like you cant use claude to any kind of cybersecurity thing anymore.
Everything getting blocked no matter what is the purpose or on what level of access you working on.
I got blocked for asking claude to review my own api (the api code not by doing any requests!) for vulnerabilities and fix them
Pretty much same here, wanted to run regression tests on my own fix!
Although after a while it gave me a link to request Anthropic for some Cyber Use Case program:
API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). This request triggered cyber-related safeguards. To request an adjustment pursuant to our Cyber Verification Program based on how you use Claude, fill out https://claude.com/form/cyber-use-case?token=3nFL2Nsc7hPTrkK2_lMRKG1dk6WxvD5tl0UmN4O-fkFFJzCaxHHWtZlQ8sxHxLKsJI_cKT61TKJC6TlL1_xFJSjb00bNFcpiv5v8SC0lTX1h1k1Wu_JSWN1eys4_PGb5-4HgPFGa8g.
I've submitted it, hoping it gets things working.
my advice just leave claude and go to gemini or codex, anthropic is way behind the new models from openai and google, and their filters dont try to stop you from working
Thanks! Will consider this.
Same for 'hunting bugs'. I have some projects like https://github.com/arsium/Open-TLS1.3.
When using those words, or even when it reads '...Crypto...' whatever the name it has,
<img width="685" height="88" alt="Image" src="https://github.com/user-attachments/assets/0fd87a7d-5c52-427a-936c-0a9d50bf6655" />
Don't bother with their piece of garbage cyber wankery application btw, these fucking shitstains will tell you that they'll "carefully analyze your application" and to reflect that, state TWO BUSINESS DAYS as the fucking wait time, except barely an hour later you get rejected, NO reason or ANY description what so fucking ever given in fact, of course, and told to reapply SEVEN TO TEN days later if you think this was an error. Ask me how I know :)
The "stuck in blocked state" you describe is the worst part of this bug: one false hit poisons the entire session — every subsequent message blocked, regardless of content — forcing a restart that kills in-flight background work and re-bills the full context in tokens. I hit the same thing on embedded firmware work (own ESP32 + eFuse via
esptool/espefuse). Request IDs:req_011Cbc2BcQzSvZu1XZD3gcFW,req_011Cbc2EFjcxGAKVP7FKbn5s.The per-session kill switch is the core defect: classification needs to be per-message and recoverable. Cross-linking the cluster: #63751, #64405.
@Call-me-Boris-The-Razor how did you manage to solve it? I have the same issue with a simple "hello world" project and the prompt "test"
Applied on their Cyber Verification Program: https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude
If your use cases and submission meets their review and usage policy guidelines, things should be unblocked.
Just pure shit. "things should be unblocked." . Nope. Completely false.
@arsium , I mean, you may be right. But it supposedly worked for me, not seeing any issues now. Just wanted to update that here.
I sent a demand like others. See this one.
<img width="661" height="385" alt="Image" src="https://github.com/user-attachments/assets/7bc214f9-2e48-4390-811a-f1cf438324ee" />
<img width="874" height="523" alt="Image" src="https://github.com/user-attachments/assets/d88d747a-05bb-4c47-9bca-b4fea853de64" />