[Bug] Non-ASCII characters appearing unexpectedly in Claude Code output

@matthew-semasoftware What languages do you have enabled on your computer, English only?

@skelouse only English and Thai, no Chinese at all.

Adding a corroborating data point - the same 状态 sequence, independent occurrence - in case it helps with needs-repro.

What happened: In an otherwise 100%-English assistant response (~300 words), a single word was emitted as the Chinese 状态 instead of the English "status":

Here's the 状态:

Worth noting: 状态 means "status/state." So this looks like a semantically-correct, token-level language switch — the model reached for the equivalent Chinese token for one word mid-sentence; rather than random bytes, mojibake, or an encoding fault. (To the original reporter's worry: this isn't a sign of compromise; it reads as a multilingual-model "code-switching" leak where a single output token surfaces in another language that carries the same meaning.)

Context that may correlate:

• Model: Claude "Fable 5" (claude-fable-5)
• A very long-running session — a week+ of continuous work with many context compactions
• Heavy sustained multi-agent orchestration throughout
• The session had hit a usage limit and was switched to API-based billing partway through
• Platform: macOS, Claude Code CLI

It was a single isolated token: fluent English immediately before and after, no other anomalies in the surrounding output. Happy to share more detail if useful.

I have a current Opus 5 recurrence of the same semantically appropriate Chinese-for-English substitution.

In an otherwise English assistant response, the persisted raw session text contains:

Rung 8 is近 black for several families

The unexpected character is 近 (U+8FD1). It occurs in an assistant text block generated by claude-opus-5 at 2026-08-13T14:38:49.536Z, not in user input, a tool result, model thinking, or a source file. A scan of the complete raw JSONL session found no other CJK character.

Environment:

• Claude Desktop Code on Windows
• Claude Code 2.1.227
• Model: Opus 5 (claude-opus-5)

Because 近 means “near/close” and appears where English “near” or “nearly” would fit, this is consistent with mixed-script model generation rather than random bytes or a display-only glyph problem. That classification is an inference; the transcript proves the persisted character and its message source, but not the internal tokenization or root cause.

This appears closely related to #80053, #82041, and #83324.

I also experienced this "Chinese character insertion" a while ago on the iOS app in the normal chat interface with Fable 5 in a longer session.