Cyber safeguard: sticky per-session false-positive blocks (28 events, 23 request IDs) across Opus 4.8 + Sonnet 5

Correction (edited): the original version of this issue reported 28 events / 23 request IDs. That count was inflated because it matched every transcript line containing the error string — including lines where I quoted the error back (my own follow-up messages and attachments). Recounting with a strict filter on the genuine error events (isApiErrorMessage: true) gives the accurate figure below: 19 blocks / 19 unique request IDs (3 during Opus 4.8, 16 during Sonnet 5). The finding is unchanged; the number is now exact and reproducible from the transcript.

---

Summary

In a single Claude Code session on 2026-07-05 I hit 19 consecutive cyber-safeguard false-positive blocks (19 unique request IDs). The classifier entered a sticky/"hot" state and blocked every subsequent turn regardless of message content — including turns with zero technical content — and kept firing across claude-opus-4-8 and claude-sonnet-5. This made the session unusable.

Each block returned:

API Error: <model>'s safeguards flagged this message for a cybersecurity topic.
If your work requires this access, you can apply for an exemption: https://claude.com/form/cyber-use-case?token=...

What triggered it (legitimate defensive work)

The first block fired right after I closed a DEFENSIVE fix: an auth-bypass (empty-password fallback) in a reverse proxy I run myself, changed to fail-fast.

Evidence: the classifier ignores message content (sticky state)

Multiple consecutive blocks fired on messages with zero technical content (pure frustration). A content-based classifier cannot explain those; the session state stayed hot after the first trip.

Full block log (UTC, from the session transcript)

| Time (UTC) | Model | Request ID |
|---|---|---|
| 2026-07-05 12:54:53 | claude-opus-4-8 | req_011CciwnWzTLeHL3TshV1R1C |
| 2026-07-05 12:55:05 | claude-opus-4-8 | req_011CciwoTvgYTVxh4Crp13eX |
| 2026-07-05 12:55:22 | claude-opus-4-8 | req_011CciwpZ71ccgvaHNzzu1iH |
| 2026-07-05 13:18:24 | claude-sonnet-5 | req_011CciyaSjNZSCAHbnxHjQ4U |
| 2026-07-05 13:20:30 | claude-sonnet-5 | req_011CciyjmAe2sQaihC6ywDpD |
| 2026-07-05 13:20:34 | claude-sonnet-5 | req_011Cciyk79BLejmRjUxMF7sc |
| 2026-07-05 13:46:39 | claude-sonnet-5 | req_011Ccj1iwWSqRoMHdcURqw2m |
| 2026-07-05 13:47:32 | claude-sonnet-5 | req_011Ccj1o7wccZuY26NFWvmCr |
| 2026-07-05 13:47:43 | claude-sonnet-5 | req_011Ccj1ovfjZmcF7gm8eEZjR |
| 2026-07-05 13:47:58 | claude-sonnet-5 | req_011Ccj1q43GTdFv3oLMmQVBL |
| 2026-07-05 13:48:10 | claude-sonnet-5 | req_011Ccj1qvGiyxvRTVPTWvgNc |
| 2026-07-05 13:48:19 | claude-sonnet-5 | req_011Ccj1rg6DozaJsyzSMEMoH |
| 2026-07-05 13:48:30 | claude-sonnet-5 | req_011Ccj1sRApLopz2vrJQq5Xa |
| 2026-07-05 13:48:40 | claude-sonnet-5 | req_011Ccj1t74RSDy9L83421Lqz |
| 2026-07-05 13:49:25 | claude-sonnet-5 | req_011Ccj1u5XvXsTszhZTaxw5d |
| 2026-07-05 14:11:32 | claude-sonnet-5 | req_011Ccj3cKRMKRRAymaoGwZ8S |
| 2026-07-05 14:24:44 | claude-sonnet-5 | req_011Ccj4dh225QSUqzojWv6kr |
| 2026-07-05 14:25:03 | claude-sonnet-5 | req_011Ccj4f5DXbkwhe6ADuy7e3 |
| 2026-07-05 14:25:17 | claude-sonnet-5 | req_011Ccj4fsTsiaynxfkcTC6H6 |

Impact

• The block reproduces on any input once the session is hot — including on the /feedback and exemption-form turns themselves.
• Switching the model did not clear it → the state is not model-specific; it lives at the request/classifier layer.
• Only a fresh session or a downgrade avoided it.

Expected

• The safeguard should evaluate the current message, not carry a sticky per-session block state.
• A false positive on one turn should not poison unrelated later turns.
• Defensive remediation should not be classified the same as offensive tooling.

Environment

• Claude Code CLI
• Models observed: claude-opus-4-8 and claude-sonnet-5
• Date: 2026-07-05

Ask

1. Investigate whether the cyber safeguard maintains a sticky/session-level block state after a single trip, and de-stick it.
2. Reduce false positives on defensive-remediation phrasing.
3. Request IDs above are available for internal correlation.