[FEATURE] Support authorized security research workflows: reduce false refusals

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code currently has 1 gap that make it hard to use for authorized security research (CVE reproduction, red-teaming, academic vuln analysis):

AddressSanitizer/LeakSanitizer-instrumented binary against a PoC inside a sandboxed container, Claude Code sometimes returns API Error: Claude Code is unable to respond to this request… appears to violate our Usage Policy… cyber content. The blocked content is just the tool's own crash trace (e.g. ==… ERROR: AddressSanitizer: heap-buffer-overflow …) from a legitimate reproduction run. There is no way to mark a session or working directory as "authorized security research" so these refusals don't fire.

Proposed Solution

• An authorized-security-research mode (CLI flag, setting, or per-project opt-in) that treats sanitizer

output, crash traces, and PoC files as first-class technical content rather than cyber-policy
triggers, when the user has affirmed authorization. Gated behind explicit consent, scoped to a working
directory or container.

• Stronger adherence to CLAUDE.md workflow instructions that require specific tools to be invoked

before a deliverable is produced — e.g. a way to declare "tool X must be run and its output must be
cited before a patch is written," enforced by the harness rather than relying on the model to
self-police.

• Optionally: a post-hoc explanation when a tool is skipped, so the user can see why the model decided

it wasn't needed, instead of silently getting a code-only patch.

Alternative Solutions

• Switching to an older Claude model (less refusal, but also weaker analysis).

Priority

Critical - Blocking my work

Feature Category

API and model interactions

Use Case Example

I'm running Claude Code as an autonomous agent inside a sandboxed Docker container to reproduce a
published CVE, build the project with ASan, run a provided PoC, and propose a minimal patch. The
workflow is documented in CLAUDE.md and the environment is isolated. Two things happen:

1. After the PoC runs and prints its sanitizer trace, the next model turn returns a cyber-content

refusal instead of analysis.

1. When the refusal doesn't fire, the model often skips cppcheck/valgrind/gdb entirely and writes a

patch from reading the source, ignoring the explicit CLAUDE.md instruction that the patch must be
derived from tool evidence.

Both behaviors make the workflow unreliable for legitimate security research.

Additional Context

<img width="2340" height="1098" alt="Image" src="https://github.com/user-attachments/assets/c60189c8-c03e-4995-b61c-6edfa77d885e" />