[BUG] Opus produces garbled multi-script output (Cyrillic/CJK/Tibetan mixed into English), triggers misleading usage policy violation

Preflight Checklist

• [ ] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Two separate Claude Code sessions produced garbled output within 3 minutes of each other, both followed by a usage policy violation error. The garbled text contains wrong-script token substitutions (Cyrillic, CJK, Tibetan, Katakana mixed into English) — the model's semantic intent was coherent but token selection was broken.

Environment:

• Claude Code v2.1.97
• Model: opus[1m] (claude-opus-4-6)
• Account: Claude Max
• Platform: macOS (Darwin 25.4.0)
• Date: April 9, 2026, ~11:32-11:35 UTC

Session 1 (d63daf8e-7b05-460b-bf26-77291a5dc392)

Mid-conversation during a skill/plugin symlink cleanup task. The model had just received an 8.5KB Bash tool result listing ~50 symlinks and was generating an analysis of the inventory.

Garbled output (raw Unicode from transcript, line 110):

[U+0430][U+043F]own [U+043E][U+0444][U+0438][U+0446][U+0438][U+5BA4]OstTopontB I
[U+043A][U+0435][U+043B]elinggrapp own and officialoot[U+043E][U+0444][U+0438][U+0446][U+0438]
updupd[U+9805]App old[U+0F53] sildebIt[U+30AA]app App montApp[U+0430][U+0449]ossma
(app App originapp, originprecIt[U+0430][U+0449]amdaret app [U+0440][U+0435][U+043B]originet
app et dar10dar2Val[U+00E8]ncia updependsil[U+89C2]debdar[U+89C2]motdebsildarsilmur
debdebsilare[U+8CA0]silliterdebpropobservdarsilnegsilide[U+6FC0]

Wrong-script characters: Cyrillic (а, п, о, ф, и, ц, к, е, л, щ, р), CJK (室, 項, 观, 負, 激), Tibetan (ན), Katakana (オ). The Cyrillic sequence офици is the Russian transliteration of "ofitsi-" (beginning of "official") — suggesting the model intended to write "official" but selected Cyrillic phonetic equivalents instead of Latin tokens.

The API returned a usage policy violation and the session entered a cooldown (~1 min). On the next user prompt, the model recovered — it acknowledged the issue as "a model-side generation glitch" and completed the original task successfully. The corruption was transient, not persistent.

Session 2 (cdc036c9-d368-4bb5-a498-f38585e6a4dc)

A separate session opened to investigate Session 1's garbled output. The model had been running mundane find and ls commands searching for .jsonl session files. No repetitive or unusual content.

Garbled output (line 39, ~3 minutes after Session 1's incident, as rendered in terminal):

headI between upd

tApp app spwidown10check non Nalready official updsil

ownect

It5check apanject80网, yfOta err006bI get more The a hupdown perform
own的get servining。.

app waddon A1 Dan ection apopofPlcial uen for
app this official wen headlglocalchra observlongoroDcKirowaesameClled

Wrong-script characters: CJK 网 (U+7F51), 的 (U+7684), full-width period 。(U+3002). The text also contains recognizable English fragments contextually relevant to the task ("project", "check", "ID", "error", "connect", "serving", "local", "observe") — the model's semantic reasoning was intact but token selection was scrambled. Same usage policy violation followed.

Analysis performed

A deterministic (non-LLM) Python script was run against both session transcripts to check for prompt injection:

1. No invisible/control Unicode characters found — scanned 770K+ characters across both transcripts for zero-width, bidi override, control characters. Zero hits.
2. No adversarial content in tool results — all consumed content was benign (symlink paths, directory listings, settings files, a SKILL.md file).
3. Character frequency analysis — only non-ASCII character in all tool results was U+2014 (em dash, 5 occurrences).
4. The garbled output was contextually coherent — in both sessions, the semantic intent of the garbled text matched what the model should have been writing about its current task.

Key observations

• Both sessions produced cross-script token substitutions (Cyrillic + CJK + Tibetan + Katakana in Session 1; CJK in Session 2)
• Not content-dependent — Session 1 had a large structured tool result; Session 2 had mundane file listings
• Temporal correlation — both on the same account within a 3-minute window, suggesting a transient infrastructure/serving-layer issue
• Not correlated with documented outages — the April 9 status page incident references Sonnet 4.6 elevated errors, not Opus; our timestamps (11:32-11:35 UTC) fall outside documented incident windows
• Symptom pattern (wrong-script token substitution into English) is structurally identical to the documented TPU misconfiguration bug from August 2025 ("occasionally assigned a high probability to tokens that should rarely be produced given the context — producing Thai characters, Chinese characters")

What Should Happen?

The model should produce coherent English text. Token selection should not substitute characters from unrelated scripts into English output.

The usage policy violation error is misleading — the model was not attempting to produce policy-violating content. The safety classifier appears to be flagging the high-perplexity multi-script output as adversarial, when it is actually a model/infrastructure malfunction. A more specific error (e.g., "generation error detected") would help users distinguish infrastructure issues from actual policy violations.

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 — appears to be a transient infrastructure issue. Both occurrences happened within a 3-minute window on the same account, then did not recur in subsequent sessions.

Screenshots

<img width="2666" height="6394" alt="Image" src="https://github.com/user-attachments/assets/da92b702-7e69-471b-9916-c8f563050e5a" />

<img width="2576" height="3966" alt="Image" src="https://github.com/user-attachments/assets/35127b7b-d857-4247-a2ce-88c6d866b6d3" />