[BUG] Pasting Korean (CJK) into the prompt is mojibaked (UTF-8 -> Windows-1252) with the no-flicker renderer on Windows (still repros in 2.1.167)

Resolved 💬 2 comments Opened Jun 6, 2026 by ssatem Closed Jun 7, 2026

Preflight

  • Searched existing issues. This is the input / paste-in direction, which is distinct from the already-closed copy-out issues (#42417 fixed in v2.1.97 via Set-Clipboard; #42899 / #42954 / #50605). The v2.1.97 copy-side fix does not touch this path.
  • Closest parent for the input direction is #3961 (Unicode input handling, Windows), closed as not planned / stale — but it still reproduces on the current 2.1.167, and now has a precise mechanism + a deterministic toggle, so re-filing with new evidence.
  • Single bug. Using the latest version (2.1.167).

What's wrong

Pasting Korean text from the Windows clipboard into the Claude Code prompt renders as Windows-1252 (Latin-1) mojibake in the input box. The correct UTF-8 bytes (3 per Hangul syllable) are decoded as single-byte Windows-1252 at the TUI input boundary.

  • Clipboard (correct): 안녕하세요
  • Shown in the prompt: 안녕하세ìš"

This is the input/paste direction. The previously reported and partially fixed issues were all the output/copy direction (OSC 52 / clipboard write, UTF-8 → CP949/CP932). This is a different code path.

Mechanism (verified)

  • The pasted bytes are valid UTF-8 (e.g. = EC 95 88).
  • They are mis-decoded as Windows-1252, not CP949/EUC-KR — the garble is Latin accented characters (ì í Â …), the canonical "UTF-8 read as Latin-1" signature, not the CP949 Hangul-mojibake signature (?쒕옒洹) seen in the copy-out issues (#42954).
  • Setting CLAUDE_CODE_NO_FLICKER=0 (disabling the no-flicker renderer) fixes the paste — confirming the no-flicker renderer's input path is implicated. The same renderer is already known to break CJK copy (#42899 / #42954 / #42417 / #50605); those issues only documented the copy direction. This report adds the paste/input direction.

Environment

  • OS: Windows 11 (10.0.26200), system code page ACP/OEMCP = 949 (Korean)
  • Terminal: VS Code integrated terminal
  • Shell: Windows PowerShell 5.1
  • Claude Code: 2.1.167 (native install)
  • Reproduces regardless of the chcp channel reading (OS ACP stays 949).

Steps to reproduce

  1. Windows 11, Korean system locale (ACP 949). Leave CLAUDE_CODE_NO_FLICKER unset (default no-flicker) or set =1.
  2. Copy Korean text (e.g. 안녕하세요) to the clipboard.
  3. Launch claude in the VS Code integrated terminal.
  4. Paste into the prompt (Ctrl+V).
  5. Observed: 안녕하세ìš" (Windows-1252 mojibake). Expected: 안녕하세요.

Workaround

  • Set CLAUDE_CODE_NO_FLICKER=0 in ~/.claude/settings.json (loses flicker-free rendering) — restores correct paste. Forcing the PowerShell console + $OutputEncoding to UTF-8 also helps.
  • Or paste via a @path / file reference instead of inline.

Is this a regression?

No — never worked with the no-flicker renderer; predates the current version.

Why this is worth re-filing despite #3961 being closed

#3961 (input, Windows) was closed not-planned/stale, but the defect persists on the current 2.1.167, now with (a) a precise mechanism (UTF-8 → Windows-1252 at the no-flicker input boundary) and (b) a deterministic toggle (CLAUDE_CODE_NO_FLICKER). This may help prioritize the input-side fix alongside the already-shipped copy-side fix.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗