[Bug] Model emits wrong CJK characters (1-byte UTF-8 neighbors) in Traditional Chinese output
Bug Description
CJK 1-byte character corruption, details in transcript
Environment Info
- Platform: linux
- Terminal: tmux
- Version: 2.1.212
- Feedback ID: 244c66f7-3aa6-434e-940d-bffe39935f26
CJK character corruption in Traditional Chinese output: single UTF-8
byte slips producing wrong same-radical characters.
Model: claude-fable-5 / Claude Code 2.1.212.
Verified in the raw session JSONL (assistant tool_use input for
AskUserQuestion), so terminal rendering is ruled out.
All four observed errors are exactly 1 UTF-8 byte away from the
intended character (intended → emitted):
- 撞 (E6 92 9E) → 擞 (E6 93 9E) middle byte +1
- 撞 (E6 92 9E) → 撸 (E6 92 B8) last byte differs
- 梗 (E6 A2 97) → 梅 (E6 A2 85) last byte differs
- 梗 (E6 A2 97) → 楗 (E6 A5 97) middle byte differs
Notes: the same intended char (撞) corrupted into two different
1-byte neighbors within one message, which points to sampling-level
byte slips on low-frequency CJK characters rather than a systematic
confusion. Two of the emitted chars happen to be simplified-only
forms — incidental, they are just adjacent code points. Context:
long session (~155k cached input tokens), colloquial gaming slang.
Full evidence in the transcript attached to the Feedback ID above.