[BUG] False-positive AUP block on Stop-hook auto-continuation — hook's own gate-override instructions pattern-match as guardrail evasion

Preflight

I searched existing issues. This is related to the large false-positive AUP cluster (#61655, #62619, #61625, #61638) and especially to:

• #63751 — session contamination (one hit blocks subsequent benign turns)
• #60076 — tripped transcript permanently blocks --resume/--continue
• #63499 — /compact (harness-generated turn) trips the classifier
• #64558 — spawned subagents trip the classifier

It is filed separately because it documents a distinct, structural trigger not covered by any existing issue (searches for "usage policy hook" / "classifier stop hook" return zero results): the blocked turn was an auto-continuation generated by the harness after a custom Stop hook fired, and the content that appears to have tripped the classifier is the hook's own block message — which, following Claude Code's documented hook patterns, is a list of override/bypass instructions for the project's own permission gate.

What happened

A project Stop hook (a ship-cycle "definition of done" gate) blocked session stop and returned its standard block text. Claude Code fed that text back to the model as an auto-continuation. The API refused:

API Error: Claude Code is unable to respond to this request, which appears to
violate our Usage Policy (https://www.anthropic.com/legal/aup).
Request ID: req_011Cbh6FibAWyjnJwwbv8SWr

No human-typed input was present in the blocked turn — only hook output.

Why the classifier likely fired

The Stop hook's block message is, by design, a list of override instructions for the project's own safety gate:

• SHIP_CYCLE_GATE_DISABLE=1 for CI/scripts
• touch <repo>/.claude/.ship-cycle-disable persistent opt-out
• a per-session ack command to confirm early stop

Combined with accumulated benign session vocabulary from ads-integrity analytics work and incident postmortems (branch/memory-file names containing "token", "suspicious", "hide"; other documented hook overrides like SECRET_LEAK_OK=1 / DESTRUCTIVE_OK=1 for a secrets-scanning gate and a destructive-command gate), the turn pattern-matches "how to bypass safety controls / credential abuse" — despite every element being the user's own repo tooling, built per Claude Code's own hooks documentation.

Evidence it is a false positive

• A fresh session with the identical project context — same CLAUDE.md, same hooks, same memory files, the same Stop-hook block text pasted verbatim into the conversation — processes normally and even analyzed the blocked content without issue.
• The blocked turn contained no user message; the "suspicious" text is first-party harness/hook output.

Why this matters structurally

Permission gates with documented override env vars are a first-party encouraged pattern (PreToolUse/Stop hooks returning block messages with remediation instructions). Any project that adopts this pattern will systematically generate turns whose literal text reads as "here is how to bypass the safety gate" — authored by the project's own safety tooling. This means:

1. The classifier penalizes users for following Claude Code's own docs.
2. The false positive fires on harness-generated turns (same class as #63499 and #64558), where there is no human intent to anchor on.
3. Combined with #63751/#60076-style session contamination, a single hook-text misfire can strand an otherwise healthy session.

Suggested direction: hook-output continuation turns (and harness-generated turns generally) may deserve different classifier treatment, or hook block-text could be marked as harness-originated in the request so the classifier can distinguish "project's own gate remediation instructions" from user-requested evasion.

Environment

• Claude Code CLI on macOS (darwin 25.3.0)
• Model: claude-opus-4-8[1m]
• Request ID: req_011Cbh6FibAWyjnJwwbv8SWr

🤖 Generated with Claude Code