[MODEL] Opus 5 substitutes a Russian word stem for the Chinese word mid-sentence under an explicit "always respond in 简体中文" instruction

### Type of Behavior Issue

Claude ignored my instructions or configuration — specifically the output language.

### What You Asked Claude to Do

The session runs with an explicit language instruction in the system prompt:

> Always respond in 简体中文. Use 简体中文 for all explanations, comments, and communications
> with the user. Technical terms and code identifiers should remain in their original form.

The turn itself was ordinary: summarize, in Chinese, a GitHub issue I had just drafted in English.

### What Claude Actually Did

Mid-sentence, it substituted a **Russian word stem** for the Chinese word. Nothing in the session
is Russian — not the prompts, not the repository, not the files read, not the drafted issue.

```
以及警告不去重，每次工具调用печат一条。
^^^^^
```

Intended: `每次工具调用打印一条` ("prints one per tool call"). What was emitted: `печат`, the stem
of Russian *печатать* ("to print"). It is not even a complete Russian word, so this is a sub-word
substitution, not a quoted foreign term or a technical identifier the instruction exempts.

I swept the whole session transcript for codepoints outside CJK/Latin:

```
U+043F CYRILLIC SMALL LETTER PE
U+0435 CYRILLIC SMALL LETTER IE
U+0447 CYRILLIC SMALL LETTER CHE
U+0430 CYRILLIC SMALL LETTER A
U+0442 CYRILLIC SMALL LETTER TE
TOTAL suspicious chars in assistant text: 5
```

All five are that one token. Zero anywhere else in the session — so this is an isolated slip, not
a drifting language setting.

### Expected Behavior

`每次工具调用打印一条`. Under an explicit "always respond in 简体中文" instruction, a word should be
rendered in Chinese, or in English if it is a technical term. Never in a third language that
appears nowhere in the context.

### Why this is worth more than a typo

It is silent and it survives review. The surrounding sentence is fluent and correct, so the
sentence *looks* fine; a reader who does not know Cyrillic just sees one token of garbage and has
no way to guess the intended word. If such a token lands in a commit message, a README, a code
comment or a PR body — all of which I generate in this session — it ships. A user who reads only
Chinese has no defence against it, because the failure does not look like a failure.

Detection, for anyone who wants to check their own sessions:

```bash
python3 - ~/.claude/projects//.jsonl <<'PY'
import json,sys,re,unicodedata
susp = re.compile(r'[Ѐ-ӿͰ-Ͽ֐-׿؀-ۿ]')
for line in open(sys.argv[1]):
try: d=json.loads(line)
except: continue
if d.get("type")!="assistant": continue
for b in (d.get("message") or {}).get("content") or []:
if isinstance(b,dict) and b.get("type")=="text":
t=b.get("text","")
for m in susp.finditer(t):
print(d.get("timestamp","")[:19], unicodedata.name(m.group(),"?"),
"|", t[max(0,m.start()-40):m.end()+40].replace("\n"," "))
PY
```

### Permission Mode

Accept Edits was ON (bypass permissions).

### Can You Reproduce This?

No, only happened once. I cannot trigger it on demand, and I am reporting it because the
transcript preserves it exactly rather than because it is reproducible.

### Possible trigger, offered as a hypothesis only

The turn was unusually language-dense: it summarized **in Chinese** an English GitHub issue body
that had just been written, quoting shell commands, JSON keys and CLI flags, inside a long session
whose context already mixed Chinese instructions, English source code and Swift/Metal identifiers.
If there is a code-switching failure mode, "summarize English technical prose in Chinese" looks
like the shape that provokes it.

### Claude Model

Opus — `claude-opus-5[1m]`, Claude Code's "Concise" output style.

### Impact

Medium — Extra work to undo changes. Nothing broke, but the output was wrong in a way the user had
to catch by eye, and the same failure in generated code or an outward-facing document would not be
caught at all.

### Claude Code Version

2.1.270 (Claude Code)

### Platform

Anthropic API

### Additional Context

macOS 26.6.2 (Darwin 25.6.0), arm64, zsh.

Two open issues describe Cyrillic/Russian appearing on *other* surfaces — #82603 (auto-generated
session title comes out in Russian for a Ukrainian session) and #87946 (thinking summary is not in
the session's language). Neither covers the main assistant reply text, which is what this report is
about, but the recurring shape — Russian specifically, leaking into a non-Russian session — may be
the same underlying thing.