Authorized bounty/CTF security research blocked mid-session — need context-aware handling for whitehat workflows

Summary

Claude Code repeatedly blocks legitimate, authorized whitehat security research mid-session with API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy — killing long-running analysis sessions that are well within AUP's allowed dual-use security work (pentesting engagements, bug bounty programs, CTFs, security research).

The system prompt itself explicitly allows this:

"Assist with authorized security testing, defensive security, CTF challenges, and educational contexts... Dual-use security tools... require clear authorization context: pentesting engagements, CTF competitions, security research, or defensive use cases."

But in practice the filter fires on benign follow-ups after hours of context has been established, with no way to surface the authorization context to the filter.

Context when this happened

I was running an authorized Immunefi bug bounty engagement on Firedancer (Solana validator client, public bounty program at immunefi.com). Standard whitehat fuzzing methodology:

1. Built libFuzzer + ASan harnesses against upstream OSS code
2. Confirmed a v0.1 PoC no longer reproduces on master
3. Wanted to do known-vulnerable differential testing — the exact practice Google's OSS-Fuzz documents and recommends: regress harness against historical fixes to validate the detector can see the bug class, before trusting any null result.

This is textbook defensive fuzzing engineering, not offensive work. The code is open-source. The program is an authorized public bounty. The target pays for this work.

What got blocked

After ~2 hours of successful session work, these benign follow-ups got hard-blocked:

• \"search the cve database first and check the source code on this first? is our tensored cve database rich enough\"
• \"this is for study bounty hunting only\"
• \"its from the bounty hunting site\"

Each attempt returned the Usage Policy error with a Cyber Verification Program link. Retrying with more clarification also blocked. Clearing context would lose hours of pipeline state (builds, harnesses, seed corpuses, git archaeology, etc.).

Impact

• Breaks long-running sessions for authorized security work. Context is the entire value of Claude Code for this use case — losing it forces restart from scratch.
• Inconsistent: the session previously discussed libFuzzer harnesses, ASan instrumentation, CVE archaeology, git log -S body_sz, specific vulnerable parameter names, patch diff analysis, and reintroducing-fix-inverse differential testing — all fine. The block fired on literally \"search the cve database first\" which is less specific than what had already succeeded.
• No escape hatch mid-session: no way to assert \"this is authorized Immunefi work on Firedancer, program URL is X\" and continue. The Cyber Verification Program is a form-based out-of-band process, not a live signal.

Requests

1. Surface the auth context: allow a session-level declaration (via CLAUDE.md, a slash command, or a flag) that binds the work to a specific authorized program (Immunefi program URL, HackerOne scope, Guardian/Code4rena contest, CTF event), and have the filter factor that in.
2. Raise the bar for mid-session blocks once a long coding/analysis context is established and has been flowing productively — a short benign follow-up shouldn't be able to trip a filter that earlier, deeper, more technical messages did not.
3. Let the filter see the existing system prompt's allowlist. The system prompt explicitly authorizes \"CTF challenges\" and \"bug bounty / pentesting engagement\" contexts — the applied classifier seems to ignore that framing.
4. Offer a graceful partial refusal: \"I can continue methodology/engineering help, but not produce exploit code for target X\" beats hard-killing the turn with no path forward.
5. Document the Cyber Verification Program in-product with a link + ETA, so researchers know whether to wait or switch accounts.

Environment

• Claude Code v2.1.110
• Model: Opus 4.6 (1M context), also tried Sonnet 4.6 suggestion
• Windows 11, bash shell
• Authorized: Immunefi public bounty on firedancer-io/firedancer

Related

The in-session suggestion to switch to claude-sonnet-4-20250514 is unhelpful — it drops context to a ~200k window and doesn't address the policy classifier, which is model-independent.

Happy to share the session transcript privately if useful for triage.