Korean characters corrupted during streaming (U+FFFD replacement)

Description

Korean (Hangul) characters are intermittently corrupted during response streaming, appearing as U+FFFD (REPLACEMENT CHARACTER) or diamond symbols (◆) in the terminal. The corruption is already present in the session JSONL log, confirming this is not a terminal rendering issue.

Evidence

Case 1: stock-analysis PM session

• Expected: 봐드리겠습니다
• Actual: 봐드리겠���니다 (3x U+FFFD replacing 습)
• Session log hex dump confirms U+FFFD (not font fallback):

U+BD10 봐
U+B4DC 드
U+B9AC 리
U+ACA0 겠
U+FFFD �
U+FFFD �
U+FFFD �
U+B2C8 니
U+B2E4 다

Case 2: another session

• Expected: 걸러야하니까
• Actual: 걸���야 ��니까

Root Cause Hypothesis

The Korean character 습 (U+C2B5) is encoded as 3 bytes in UTF-8: EC 8A B5. When the streaming response splits a chunk boundary in the middle of a multi-byte UTF-8 sequence, each orphaned byte is decoded as U+FFFD. Three replacement characters for one 3-byte Korean character confirms a byte-level split.

Environment

• Claude Code: latest (via claude CLI)
• OS: macOS 15.4.1 (Darwin 25.3.0)
• Terminal: Ghostty 1.3.1 (ruled out as cause — corruption exists in session JSONL)
• Model: Claude Opus 4.6, Claude Sonnet 4.6
• Language: Korean (Hangul)

Reproduction

• Occurs intermittently during longer Korean-language responses
• More likely to occur mid-sentence on common Hangul syllables
• Not specific to any particular character — any multi-byte Korean char can be affected

Related

• Possibly related to #46471 (Enclosed Alphanumerics rendering), but this is a distinct UTF-8 streaming issue, not a font/glyph problem

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>