[macOS] Korean (Hangul) IME composition is a daily usability blocker for CLI real-time typing — consolidating related reports

Status Open
Reported on v2.1.235
Maintainer reply None cached
Activity 0 comments · opened Aug 19, 2026

Summary

Korean IME input in the CLI's raw-mode TUI is broken enough that native Korean speakers effectively cannot type Korean directly into the prompt in real time. This has been reported piecemeal across several issues; filing this to consolidate impact and ask for prioritization, since the underlying architecture issue (raw-mode stdin reading bypasses OS IME composition/preedit handling) affects every symptom below.

Environment (one reporter's setup)

  • Claude Code: 2.1.235
  • OS: macOS (Darwin)
  • Terminal: iTerm.app (TERM_PROGRAM=iTerm.app, TERM=xterm-256color)
  • Locale: LANG=ko_KR.UTF-8, all UTF-8
  • Input method: macOS built-in Korean IME

Symptoms observed / reported (macOS)

  • Jamo (자모) appear separated instead of composing into syllable blocks, or syllables get dropped/eaten mid-composition
  • Composition feels noticeably laggier than plain ASCII input
  • Cursor / composition window position drifts or misbehaves during composition
  • Text after the cursor visually disappears while composing mid-line, reappearing only on commit (see #75507)
  • Last Korean character dropped in some input widgets, e.g. AskUserQuestion "Other" field (see #77486)
  • Ctrl+C (SIGINT) doesn't register while Korean IME composition is active (see #81929)

Related open issues (macOS + cross-platform)

  • #75507 — text after cursor disappears during mid-line composition (macOS, iTerm2)
  • #77486 — AskUserQuestion "Other" field drops last Hangul character (macOS)
  • #81929 — Ctrl+C doesn't work during Korean IME composition (iTerm2/Ghostty)
  • #1547 — IME input causes performance issues and duplicate conversion candidates (macOS)
  • #73050 — Korean/English input source reverts automatically (macOS, desktop app)
  • Cross-platform architecture writeup: #65519 (closed, Windows) has a good root-cause analysis — raw-mode TUI (Ink) reads keystrokes before IME composition completes and repositions the terminal cursor on every render, which detaches the OS IME preedit window from the caret.
  • Canonical fix that landed: #22853 (closed) fixed outright character loss, but the residual rendering/timing issues above are still open.

Impact

Korean is a significant part of the Claude Code user base. Right now the only environment where real-time Korean typing works correctly is the browser-based web app (claude.ai/code), because a native <textarea> gets IME composition events for free. The CLI — which many users specifically need for local/dev workflows — is not comfortably usable for native Korean input. Current workaround (compose in another app and paste) is a real productivity cost for anyone doing iterative back-and-forth work in Korean.

Ask

Please prioritize the underlying raw-mode/IME-composition handling in the Ink-based TUI layer (anchoring the real cursor to the IME preedit window, and buffering keystrokes until composition commits) rather than patching each symptom individually — the symptoms above look like the same root cause surfacing in different UI contexts.

View original on GitHub ↗