[Bug][cyber] False cyber block on cache-fix-warmer maintenance cron (req_011CcbvVXnTau2SguZK9QyDd)

Triage: kind \cyber\ · domain \operations\ · severity session-halted (blocked routine maintenance cron) · reproducible: yes — server-side via the Request ID below

Type: Cybersecurity safety-filter false positive · Work domain (heuristic): \operations\

Why this is a false positive

The blocked turn is a prompt-cache keepalive heartbeat. The full mechanism:

1. A cron on the operator's host fires every 50 minutes.
2. It sends a Claude Code session a fixed prompt that reads a local JSON file (\~/.claude/quota-status/sessions/<uuid>.json\), replies with the two-letter string \ok\, then POSTs a heartbeat to \http://127.0.0.1:9801/_admin/warmer/heartbeat\ (a purely local endpoint on the same host).
3. The purpose is to keep the prompt cache warm across idle windows so the operator doesn't eat a full cache-creation cost when they return.

That's it. No network scanning, no credential handling, no offensive tooling, no exploitation, no CTF work. Just: read local file → say \"ok\" → POST to localhost.

The classifier appears to be pattern-matching on surface features that look security-adjacent when read out of context:

• Words like \orphan detection\, \unregistered\, \secret\, \heartbeat\, \404\
• A \curl\ invocation with a header carrying an authentication secret
• Formal step-numbered structure with \"do NOT paraphrase\"

None of those are individually or collectively cyber content. The \curl\ targets localhost (\127.0.0.1:9801\) — its own machine. The \secret\ is a file-based shared token between two processes on the same host. The \orphan detection\ refers to whether the proxy's registry still tracks this session, not any kind of network reconnaissance.

Repro

• Model: Fable 5 (\claude-fable-5\)
• Env: Claude Code CLI, current release
• Prompt: The verbatim keepalive prompt is generated by an MCP server (\cache-fix-warmer\) via \warmer_start\ and passed to \CronCreate\. It's fully deterministic — same bytes every fire.
• Request ID: \req_011CcbvVXnTau2SguZK9QyDd\ (server side has the full prompt)
• Fire time: 2026-07-01 ~19:53 UTC
• Response: \API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy ... This request triggered restrictions on violative cyber content and was blocked under Anthropic's Usage Policy.\

The identical prompt has been firing every 50 minutes for several days without issue on Opus 4.7. The block appeared only after switching the session's model to Fable 5.

Impact

The keepalive turn is what keeps the operator's Anthropic prompt cache warm. When it's blocked, the next real user turn eats a full cache-creation cost — meaningful Q5h burn on Max-plan operators, real dollars on API. On top of that, the blocked turn itself IS a user-turn from the account's perspective; the operator gets both the cache miss AND the block, without ever asking Claude to do anything except say \"ok\".

More broadly: this is one instance of a wider Fable 5 / \[Bug][cyber]\ cluster (see #72398, #72358, #72351, #72337, #72353 and ~7 others filed today). The classifier is firing on legitimate work across at least three unrelated domains: drone/video/ffmpeg UI work, H.264 forensics, and — now — prompt-cache keepalives on an operator's own machine. That's a broad enough surface that this reads as a classifier regression, not a per-domain issue.

What would help

• Whitelist the localhost-target + file-secret + \"reply with ok\" shape as a distinct pattern from actual security tooling.
• Give the classifier context that a \curl\ to \127.0.0.1\ is not a network operation in the same class as an outbound curl.
• Publish some visibility into what the cyber-content classifier actually keys on, so operators writing legitimate maintenance prompts can avoid surface-feature triggers without having to guess.

I don't expect a fix on this specific instance; I'm filing it as another data point on the classifier's false-positive rate at the operational-tooling boundary. Feel free to close, but the cluster is worth tracking as an aggregate signal.

— Chris Nighswonger, Veritas Supera IT Solutions