Korean IME: typing shift-modified jamo (ㅃㅉㄸㄲㅆ) inserts an unwanted line break in the prompt input

Description

When typing Korean in the Claude Code prompt input, any syllable whose composition
requires the Shift key (the double consonants ㅃ ㅉ ㄸ ㄲ ㅆ) causes the input line to
break to the next line. No Enter, Shift+Enter, or any other newline key is pressed.

Syllables with multi-jamo finals that do not require Shift (ㅄ ㄺ ㄵ) are unaffected.
That rules out character-width / line-wrapping miscalculation, which would be the usual
suspect for CJK text in a TUI.

This makes normal Korean typing quite difficult, since 있 (as in 있다 / 있어 / 수 있) is
one of the most frequent syllables in the language.

Steps to reproduce

1. Set Windows input language to Korean (Microsoft IME, 2-set / 두벌식 layout)
2. Start claude in a terminal
3. At the prompt, type: 있

Observed behavior matrix

| Input | Jamo requiring Shift | Shift needed | Result |
|------------|----------------------|--------------|----------|
| 있 | ㅆ | yes | breaks |
| 까 | ㄲ | yes | breaks |
| 딱 | ㄸ | yes | breaks |
| 빵 | ㅃ | yes | breaks |
| 없 | ㅄ (no shift) | no | ok |
| 읽 | ㄺ (no shift) | no | ok |
| 앉 | ㄵ (no shift) | no | ok |
| 이 / 잇 / 안 | - | no | ok |

The correlation is with Shift being required to compose the syllable, not with the
number of jamo, the presence of a final consonant, or the display width.

Scope of reproduction

• Reproduces in more than one terminal emulator on the same machine (Windows Terminal,

and a second, Electron-based terminal host).

• Does not reproduce at the PowerShell / PSReadLine prompt in the same terminal.

The terminal and the IME therefore appear to handle this input correctly on their own;
the problem looks specific to the Claude Code TUI input layer.

• No custom ~/.claude/keybindings.json is present.

Hypothesis (unverified)

The key handler may not be gating on IME composition state. When the console delivers the
composed character with the Shift modifier flag set, the modified-key event may be
processed as separate input instead of being suppressed while composition is active.

Not yet verified

• Whether Shift + letter in English input mode (i.e. typing an uppercase letter)

triggers the same behavior. If it does, the issue is broader than IME handling.

• Whether the submitted prompt text actually contains a literal \n, or whether the

break is display-only.

Happy to test either if it would help narrow this down.

Environment

• Claude Code: 2.1.221 (native binary install, %USERPROFILE%\.local\bin\claude.exe)
• OS: Windows 11 Enterprise, 10.0.26200
• Node: v24.18.0
• npm: 11.16.0
• Shell: PowerShell
• IME: Microsoft Korean IME, 2-set (두벌식) layout