[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.

The report names no implementation file or test. Start with the captured session JSONL and the supplied Python detector to verify the five Cyrillic codepoints, then trace assistant-reply language handling in Claude Code 2.1.270. Done means the isolated substitution is understood and a repeatable regression check exists for the explicit Simplified Chinese instruction.

Written by the indexing model from the issue text.