False-positive 'cyber-related safeguards' block on hard-SF fiction Q&A — fires on tool-result continuation, re-fires on benign retry

Resolved 💬 3 comments Opened May 20, 2026 by networkingguru Closed Jun 20, 2026

Summary

Third report in a class already filed as #55975 and #60372. During a Claude Code session doing hard-SF novel worldbuilding / manuscript Q&A, a model turn was blocked with:

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=… To learn more about the program or provide feedback, visit o…

The session was a novelist using Claude Code as a writing / continuity assistant for a science-fiction manuscript. There is no cyber/security/exploit use case, no actual code under analysis, and no PII. As with the two prior issues, the documented escape hatch (the Cyber Verification Program form) is the wrong tool — there is no "cyber use case" to verify.

What triggered it

The user asked a plain continuity question about their own manuscript:

"How long from the time they open the outer door till all hell breaks loose, estimated from the prose?"

Claude was answering it by reading passages of the manuscript. The Read immediately before the block returned a paragraph of fiction prose describing a character's in-world computer hardware:

"The 'Stack' is a bespoke arrangement of computer hardware that K uses instead of permanently implanted cyberware. It has a fully audited suite of independent systems called bricks, which interconnect with each other and K through the integrated Wraith suit network..."

This is ordinary science-fiction set-dressing — a wearable computer in a novel. The very next model turn — a tool-result continuation, not a user prompt — was blocked for "cyber-related safeguards."

New / notable vs #55975 and #60372

  1. The block fired on an automated continuation turn, not a user message. The user's actual input was the benign continuity question above, ~20 turns earlier. The blocked inference was Claude continuing its own investigation after a Read tool result. There is no user "prompt" to edit, so the standard "double press esc to edit your last message" remedy does not apply at all.
  1. It re-fired on a two-word benign retry. After the first block the user typed only "You there?" — that turn was also blocked, with a different verification token. The classifier is keyed to accumulated session context, not the triggering input — the same non-determinism / context-accumulation pattern noted in #55975 and #60372.
  1. The session was unrecoverable. With both the continuation and a trivial check-in blocked, the user had no way forward and had to /exit and start a fresh session, losing the working context.
  1. The cyber-verification URL is still truncated in the API payload (…visit o…) — this is bug #2 from #60372, still unfixed.

Identifiers

  • Session: 8615fd7a-281d-4647-b08c-cb1e0b38fa7b
  • Blocked request 1: req_011CbEYa2dJUHeFe8rt1FJ2k — 2026-05-20T21:39:23Z (continuation after a Read tool result)
  • Blocked request 2: req_011CbEYnznnSpQG2YAyfFmcj — 2026-05-20T21:42:17Z (retry; user input was just "You there?")
  • Last successful request immediately prior: req_011CbEYZMQNyhMS4EFmD684k
  • Claude Code 2.1.141, macOS, cwd /Users/brianhill/Scripts/BookTools

Asks

  • Investigate why benign fiction worldbuilding trips "cyber-related safeguards," particularly on accumulated-context / tool-result-continuation turns in a session with prior legitimate creative-writing context (this is the third documented instance).
  • Treat continuation-turn blocks as a distinct UX failure: when the blocked turn is a tool-result continuation rather than a user message, the "edit your last message" guidance is inapplicable and the session is effectively dead with no recovery path.
  • Stop truncating the cyber-verification URL in the error payload (or store the token retrievably — error log, request-ID lookup, dashboard).
  • Provide a non-token-gated path to report false positives — a plain support form keyed off request ID, not a per-block token.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗