[BUG] Windows (CP950/Big5): IME-typed Chinese input corrupted — console Big5 bytes decoded as UTF-8, garbled text sent to model

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Traditional Chinese Windows machines (system ANSI codepage 950 / Big5), Chinese text typed via IME into the Claude Code interactive prompt is intermittently corrupted: the Big5-encoded bytes of the typed text are decoded as UTF-8, producing U+FFFD replacement characters plus stray ASCII characters. ASCII input is unaffected.

This is not just a rendering bug — the corrupted text is what actually gets sent to the model. In one reproduction, Claude itself replied (translated): "Your message arrived garbled on my side (looks like an encoding issue — the Chinese characters all became □), so I can't read the original text completely."

Smoking-gun evidence — the mojibake decodes back to the original text exactly:

The user typed 設計 (Big5: B3 5D AD 70). The prompt echo showed �]�p:

'設計'      → Big5 b3 5d ad 70 → decoded as UTF-8 → �]�p    (matches screenshot exactly)
'設計與'    → �]�p�P
'的玩法機制' → �����k����                                    (matches screenshot exactly)

Big5 lead bytes (0x81–0xFE) are invalid UTF-8 → � (U+FFFD); Big5 trail bytes in the ASCII range (0x40–0x7E) survive as random ASCII like ], p, P, G@. This signature is unambiguous: the console delivered CP950 bytes and Claude Code decoded stdin as UTF-8.

Key observations:

• Affects both the live input box and the echoed user message (gray > line) after submit — and the bytes sent to the model.
• Paste is affected too, not just IME keystrokes (composing in Notepad and pasting still garbles), consistent with the console input codepage conversion path rather than IME composition itself.
• Reproduces in Windows Terminal, standalone PowerShell 7.5.4, and the VS Code integrated terminal.
• Intermittent but frequent — sometimes input goes through fine, suggesting two different console input paths (Unicode vs. ANSI/codepage) and only the codepage path corrupts.
• chcp run inside Claude Code's Bash tool reports 65001 (UTF-8) — but that's the shell Claude Code spawns. The hosting console (chcp in the same PowerShell before launching claude) reports 950.
• Reproduced on multiple machines in our company (Traditional Chinese Windows 11, default codepage 950), by multiple users, on both v2.1.161 and v2.1.162.

What Should Happen?

IME-typed / pasted CJK text should arrive intact regardless of the hosting console's legacy codepage — e.g. read console input via the Unicode path (ReadConsoleW / win32-input-mode), or decode stdin bytes using the console input codepage instead of assuming UTF-8.

Error Messages/Logs

# Example echoed user message (identifiers typed in ASCII survive, Chinese garbles):
�\ÛErosProRuleSetting��TrackEvent�]�p �¿Ü�����k���EventCountCondition ���G@��
# Original (reconstructed): ...ErosProRuleSetting 的 TrackEvent 設計與 ... EventCountCondition 的玩法機制...

Steps to Reproduce

1. Traditional Chinese Windows 11 (system locale zh-TW, ANSI codepage 950 / Big5; chcp in a fresh PowerShell shows 950)
2. Open PowerShell (or Windows Terminal, or VS Code integrated terminal) and run claude
3. Type Chinese text using the Microsoft Bopomofo (注音) IME, e.g. 設計
4. Intermittently (high frequency, not 100%), the input box and the submitted message echo show �]�p-style mojibake instead of 設計, and the model receives the corrupted text

Environment

• Claude Code: 2.1.161 and 2.1.162 (native Windows)
• OS: Windows 11, Traditional Chinese, system codepage 950 (Big5)
• Terminals: Windows Terminal, PowerShell 7.5.4 standalone, VS Code integrated terminal (all reproduce)
• IME: Microsoft Bopomofo (注音)

Related Issues

• #46486 — Big5 (950) garbled output from PowerShell commands (closed as duplicate of #43024, NOT_PLANNED) — this report is the input side
• #6094 / #3961 — older Unicode input corruption reports (closed)
• CHANGELOG 2.1.94 fixed the same class of bug ("CJK text corrupted with U+FFFD in stream-json input/output when chunk boundaries split a UTF-8 sequence") for stream-json — interactive console input on CP950 systems appears to be an uncovered path

Workaround (untested, pending verification)

Running chcp 65001 in the hosting console before launching claude, or enabling Windows' "Beta: Use Unicode UTF-8 for worldwide language support" — will report back once verified.