[BUG] Ctrl+J newline broken under Korean IME after v2.1.84 cursor tracking fix

Additional context: This is likely related to #16764 (Option+Enter newline regression in v2.1.1). In that issue's comments, a user reported the exact same Ctrl+J newline breakage starting from v2.1.1:

"Emacs-style Ctrl+j (newline) no longer inserts a line break. This worked correctly until just before upgrading to v2.1.1."

The root cause may trace back to the terminal keyboard mode changes introduced in v2.1.0:

• "Changed Shift+Enter to work out of the box in iTerm2, WezTerm, Ghostty, and Kitty without modifying terminal configs"
• "Fixed terminal keyboard mode not being reset on exit"

The v2.1.84 IME cursor tracking fix appears to have further broken this for CJK IME active states specifically, making Ctrl+J unresponsive only when Korean IME is engaged.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/17649
2. https://github.com/anthropics/claude-code/issues/39206
3. https://github.com/anthropics/claude-code/issues/38694

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

❌ Not a duplicate — here's why

The three suggested duplicates are all distinct issues:

#17649 (CLOSED) — AquaSKK Ctrl+J for IME mode switching

• Their problem: Ctrl+J should trigger AquaSKK's Hiragana mode switch (SKK_JMODE), but Claude Code swallows the key event
• Our problem: Ctrl+J should insert a newline in the chat input, but fails when Korean IME is active
• Different intent, different IME, different expected behavior

#39206 — Numpad Enter outputs raw CSI u sequence

• Their problem: Numpad Enter emits 57414u text instead of submitting (Kitty protocol parsing failure)
• Our problem: Ctrl+J produces no output at all — it's silently dropped, not mis-encoded
• Different key, different symptom

#38694 — Caps Lock IME switching intercepted

• Their problem: Caps Lock outputs [57358u instead of switching IME (Kitty protocol intercepting modifier keys)
• Our problem: Ctrl+J is a control character (LF, 0x0A), not a modifier key — and it produces no stray escape sequence
• Different key class, different symptom

---

What makes this issue unique

1. Ctrl+J worked as newline before v2.1.x — confirmed by a commenter in #16764 who reported the same Ctrl+J breakage at v2.1.1
2. IME-state-dependent: English input → Ctrl+J works. Korean IME active → Ctrl+J silently dropped. This is not a general keybinding failure.
3. chat:newline keybinding workaround doesn't fix it for Korean IME — the key event never reaches Claude Code's keybinding system when IME is composing
4. The v2.1.84 IME cursor tracking change made this worse by altering the input processing path for CJK composition

This is a regression in IME-aware key event dispatching, not a Kitty protocol encoding issue or an IME mode-switching conflict. Please keep this issue open.

Resolved in v2.1.85

The Ctrl+J newline issue under Korean IME is no longer reproducible as of v2.1.85.

The likely fix is this entry from the v2.1.85 release notes:

Fixed shift+enter and meta+enter being intercepted by typeahead suggestions instead of inserting newlines

While Ctrl+J / Korean IME isn't explicitly mentioned, the newline insertion path appears to have been corrected as part of this fix. Closing — will reopen if it regresses.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.