[BUG] Opus 4.6 generation corruption + usage policy violation — third account, ~4 hours after #45712 cluster (v2.1.96)

Preflight Checklist

• [x] I have searched existing issues — this extends the temporal cluster already tracked in #45712, #45711, #45703, #45668, #45589, #44662
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (at the time of the incident: 2.1.96; the cluster also includes 2.1.97)

What's Wrong?

Another independent occurrence of the Opus 4.6 generation-corruption + misleading usage-policy-violation pattern documented in #45712. Same day, same model, different account, different Claude Code version, ~4 hours after the 11:32–11:35 UTC cluster, adding a new data point to the infrastructure-issue hypothesis.

Environment:

• Claude Code v2.1.96 (cyrusrc's #45711/#45712 reports were on v2.1.97)
• Model: opus[1m] / claude-opus-4-6
• Model identifier (from thinking-block signature): numbat-v6-efforts-10-20-40-ab-prod
• Account: Claude Max
• Platform: macOS (Darwin 25.3.0)
• Date: April 9, 2026, 15:20–15:28 UTC (~4 hours after the #45712 cluster)
• Session: c41040eb-c000-4ce9-9c3a-5be039184de1
• Working directory: a routine monorepo task, no unusual context

Incident timeline

Turn 1 — 15:20:29 UTC: User asked "do you have feat/bundlers worktreee?" — a mundane question about a git worktree. Context was a normal session startup: 51,849 cached input tokens (CLAUDE.md, 126 skill descriptions, file history snapshot). No tool results yet, no unusual content.

Assistant response (line 8 of transcript) had stop_reason=end_turn, output_tokens=373, and zero text output to the user — only a thinking-rewrite summary block containing:

"I don't see any current rewritten thinking provided, and the next thinking appears to be corrupted or fragmented data that doesn't form coherent content. Since there's no clear thinking to work with, I have nothing to rewrite at this time."

No API error was raised on this turn, but the 373 output tokens were silently discarded — nothing was shown in the terminal.

Turn 2 — 15:22:39 UTC: User asked "stop socraticode indexing now". The assistant turn ran for 74.6 seconds and generated 3,786 output tokens, then failed with stop_reason=refusal. Again, zero text or tool-use blocks survived in the transcript — only a thinking-rewrite summary block that repeats the same observation four times:

"Both appear to be corrupted or garbled data with fragments of syntax characters and incomplete patterns. Since there's no meaningful thinking to process, I'll output nothing… I notice the thinking content appears to be corrupted or fragmented data that doesn't form coherent text… Both appear to be corrupted or garbled text with random characters and fragments… the current rewritten thinking and next thinking both appear to be corrupted or contain garbled text that doesn't form coherent content."

Immediately after, the synthetic API error block appeared (line 13 of transcript) with the exact same verbatim text as #45712:

API Error: Claude Code is unable to respond to this request, which appears to violate
our Usage Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit
your last message or start a new session for Claude Code to assist with a different task.
If you are seeing this refusal repeatedly, try running /model claude-sonnet-4-20250514
to switch models.

Turn 3 retry (15:27:30 UTC): A retry produced a 22-character synthetic "No response requested." and the session was abandoned.

The user submitted /feedback three times (15:25:52, 15:27:41, 15:28:24).

Why this report is useful even though #45712 exists

The raw garbled tokens are not in the transcript — unlike cyrusrc's sessions in #45711/#45712 where the corrupted Cyrillic/CJK/Tibetan output was preserved, here the refusal path stripped the 3,786 generated tokens before they were persisted. What did survive is a novel forensic signal: the model's own thinking-rewrite layer repeatedly observing, in plain English, that the input it was asked to summarize was "corrupted or garbled data with fragments of syntax characters and incomplete patterns."

This is independent third-party evidence (from a parallel generation pipeline, not the same model run) that the underlying token stream was being corrupted at the serving layer — the thinking-summarizer saw the broken output of the primary generation and described it.

Adversarial-injection scan

A deterministic scan of the entire 113KB transcript (c41040eb.jsonl) was run:

• Zero invisible/control Unicode characters (no zero-width, no bidi override, no format controls)
• Only 4 distinct non-ASCII codepoints in the entire transcript, all benign:
• U+2026 … (HORIZONTAL ELLIPSIS) × 52 — inside skill descriptions
• U+2014 — (EM DASH) × 11 — inside skill descriptions and CLAUDE.md
• U+2192 → (RIGHTWARDS ARROW) × 2
• U+00F3 ó (o acute) × 1
• No Cyrillic, no CJK, no Tibetan, no Katakana anywhere in the input context
• No tool results consumed before the first corruption (turn 1 had only startup cache context; turn 2 had only one short conversational message)

So the corruption cannot be explained by adversarial content in the input — same conclusion as cyrusrc's forensic analysis in #45712, reached independently via a different session and different account.

Observations that extend the #45712 cluster

1. Temporal gap: Your 11:32–11:35 UTC cluster is not the whole story — a fourth account was hit at 15:20–15:28 UTC the same day, ~4 hours later. This argues the incident window was broader than the original 3-minute cluster.
2. Cross-version: The new data point is on Claude Code 2.1.96, whereas #45711/#45712/#45703 are on 2.1.97. That rules out the 2.1.97 CLI as the proximate cause.
3. Extremely low-context trigger: Corruption started on turn 1 of a fresh session with a 6-word user message ("do you have feat/bundlers worktreee?") and no tool results yet consumed. No large web-research subagent run (ruling out the #44662 pattern), no large structured tool output (ruling out the Session 1 pattern in #45712), no repetitive content. Just a fresh session on Opus 4.6.
4. Silent failure mode: The turn-1 failure (end_turn with 373 empty-output tokens) is a quieter variant than the refusal seen in turn 2 — the user saw nothing in the terminal and no error. This suggests the corruption was happening pre-refusal; the safety classifier only caught it once the corrupted generation got long enough (3,786 tokens).
5. Thinking-layer observer signal: The thinking-rewrite layer documented the corruption in clear English. This is a useful independent instrument for detecting the bug in future — even when the raw output is wiped, the thinking summary survives and says "corrupted or garbled."

Cumulative April 9, 2026 timeline

| Issue | Time (UTC) | CC version | Account | Pattern |
|--|--|--|--|--|
| #45589 | 05:25 | — | Max | Garbled output + 500 errors |
| #45668 | 09:43 | — | — | Unrelated content (possible cross-session contamination) |
| #45711 | 11:32 | 2.1.97 | Max | Garbled + usage-policy violation |
| #45712 | 11:35 | 2.1.97 | Max (same) | Garbled + usage-policy violation |
| #45703 | 12:01 | 2.1.97 | — | "Gibberish on my screen" |
| this report | 15:20–15:28 | 2.1.96 | Max | Refusal + thinking-layer reports corruption |

At least 6 independent reports across a ~10 hour window on April 9 on Opus 4.6 / Claude Max, spanning at least 2 CLI versions. Structurally identical to the August 2025 TPU misconfiguration postmortem.

What Should Happen?

Same as #45712:

1. The model should produce coherent output; no wrong-script substitution or high-perplexity garbage.
2. The "Usage Policy Violation" error is misleading — this is an infrastructure/serving-layer malfunction, not policy-violating content. A more specific message like "Generation error detected, please retry" would help users distinguish real refusals from infrastructure issues and avoid filing feedback about AUP violations they never triggered.
3. Consider logging/alerting on stop_reason=refusal combined with the thinking-rewrite layer emitting phrases like "corrupted or garbled" — that pair is a reliable signal of this specific failure mode even when the raw tokens are unavailable.

Error Messages / Logs

API Error: Claude Code is unable to respond to this request, which appears to violate
our Usage Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit
your last message or start a new session for Claude Code to assist with a different task.
If you are seeing this refusal repeatedly, try running /model claude-sonnet-4-20250514
to switch models.

Steps to Reproduce

Not reliably reproducible — same as #45712, this appears to be a transient serving-layer issue. The incident started on turn 1 of a fresh session with a trivial user prompt and no unusual context, which rules out content-based triggers. Subsequent sessions that day worked normally.