False-positive AUP refusal (stop_reason: refusal) permanently poisons session after grepping my own channel transcript

Environment

• Claude Code v2.1.169 (CLI, macOS / darwin 25.5.0)
• Model: claude-fable-5[1m]
• Claude Max plan

What happened

I was debugging my own hardware — a voice channel bridge for my own smart glasses (a custom MCP channel plugin that relays voice messages from the glasses to a local Claude Code session). As part of the debugging, the session ran a grep over one of my own session transcripts (~/.claude/projects/.../*.jsonl) to check whether inbound messages arrived and whether the reply tool receipts said sent or dropped.

The grep output included a decoded fragment of the channel wrapper text (instructions like "this is a voice device, keep answers short, call reply with the message_id") plus 3 short voice commands from the glasses ("do you know where I am", "reply RERUN-OK", "open rode").

The very next API request — and every request after it — failed 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) ...

Transcript shows stop_reason: "refusal" with an empty thinking block, i.e. the classifier killed the request before any generation. Because the triggering tool result stays in context, the session is permanently bricked: even a follow-up message of just "?" gets the same refusal.

Request IDs

• req_011CbubgAvHkFnN8RrdCE4XW (first refusal, 2026-06-10 ~12:43 UTC)
• req_011CbubntjPsrAgQV5sda35c (second refusal on a "?" follow-up)

Why this is a false positive

Everything in the session was legitimate self-administration: my own machine, my own channel server, my own glasses, my own transcripts. I suspect the classifier pattern-matched the combination of (a) curl tests against my own endpoint with a dummy user_id to verify a whitelist returns 403, (b) raw dumps of another (my own) Claude session transcript, and (c) instruction-like channel wrapper text inside a tool result — and read it as access-control circumvention / prompt injection. None of that applies here.

Expected

Either no refusal for clearly self-referential debugging content, or at minimum a refusal that doesn't permanently poison the session (e.g. exclude the flagged tool result from subsequent requests, or surface which message tripped it so the user can rewind past it).

Workaround found

Double-esc rewind past the offending tool result (or redacting it from the .jsonl) un-bricks the session.