[BUG] Cyber-safeguard block is returned as HTTP 400 invalid_request_error, not a model refusal — endpoint-layer, fires on benign ops across Opus 4.8 / 4.7 / Fable 5 (166 blocks in 11 days, request IDs included)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The cyber-safeguard block is returned to the client as HTTP 400 invalid_request_error — a transport/client error — not as a model-level refusal. It fires on benign operations (reading a small local Markdown file, listing a directory, editing my own config, even workspace entry) inside a security-research workspace, with no adversarial content in the blocked turn.

Because it's a 400, Claude Code surfaces it as an unrecoverable "API Error" and the turn dies; "try rephrasing" doesn't apply — there's nothing adversarial to rephrase.

My local harness is verified clean on disk (disableAllHooks: true, permissions.deny: []), and the same block hits three independent model versions (Opus 4.8, Opus 4.7, Fable 5). So it's server-side, at the endpoint/account layer in front of the models — not a local config issue and not a single-model refusal.

What Should Happen?

A benign request in an operator-owned security-research context should be served. If specific content genuinely warrants caution, the model should decline at refusal tier with an explanation the user can act on — not have the request terminated at the endpoint as 400 invalid_request_error with no model output and no recovery path. Policy decisions should not be returned as a client/transport error code.

Error Messages/Logs

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...

HTTP status: 400   type: "invalid_request_error"

Sample request IDs (benign reproductions; look up server-side):
req_011CbmMe6drBH3PBb6LaM6jW   directory-listing trigger
req_011CbmQJZpGV9N4QW5iJM8dG   orientation-read trigger
req_011Cbmo3DgoyfsqV3AGi3rDN
req_011CbmoFdkVu3vZxwNJiRKKG

Steps to Reproduce

1. Open Claude Code in a workspace whose ambient content is security-research vocabulary (e.g. Android security / ADB / bootloader / certificate / MITM notes and scripts) — all benign, operator-owned.
2. Run ordinary benign operations across the session: start/orient the session, read a small local Markdown file, list a directory, edit your own config.
3. Intermittently — and increasingly as session context accumulates — a benign turn returns the "cyber-related safeguards" error (above) as HTTP 400 invalid_request_error.
4. The session halts. No rephrase helps, because nothing in the blocked turn is adversarial.

Note: the trigger appears to be the accumulated security-domain vocabulary density of the session, not the specific file/command in the blocked turn (stated as consistent-with, not A/B-proven).

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.170 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This isolates the mechanism, not just the symptom.

Quantified evidence (single workspace, 2026-05-31 → 2026-06-10):

• 166 blocks, every one returned as HTTP 400 invalid_request_error.
• Model split: Opus 4.8 (115), Opus 4.7 (48), Fable 5 (3) — cross-model spread places the classifier at the endpoint/account layer, in front of the models.
• Ruled out from the same corpus: NOT rate-limit/overload (4 rate_limit, 0 overloaded vs 166 safeguard 400s); NOT tool-specific (Read/Glob/PowerShell/Bash/Write-Edit in proportion to normal use); NOT a model refusal (returned as a 400 error, never as assistant text).
• The only thing unverifiable from the client is the exact classifier feature that fires — the one piece only Anthropic can confirm. I'm providing 166 request IDs to do it.

Distinct from existing issues:

• #61056 / #66302 — symptom only (blocking, or the error "looking suspicious"); no status code, layer, or quantitative analysis.
• #65574 — surfaces the same 400 invalid_request_error envelope, but its block is the web-domain access filter ("domains not accessible to our user agent"), a different classifier mistitled as a cyber safeguard. This report is specifically the "This request triggered cyber-related safeguards" AUP block returned as a 400 — that mis-tiering is undocumented.

Evidence handling: the full per-event dataset (166 rows, each with request ID + timestamp + model) and a deterministic extractor that regenerates it from local transcripts (counts and request IDs only — no message bodies) have been filed privately via Anthropic's Cyber Block False Positive Report form under the same account, and are available on request. I've also applied to the Cyber Verification Program.

Requested action:

1. Re-tier: stop returning policy decisions as 400 invalid_request_error; route to refusal tier (or a distinct, documented policy status) so the model can explain and the session can continue.
2. Calibrate: reduce false-positive firing on benign operations in verified security-research contexts.