[BUG] Kitty keyboard protocol: Ctrl shortcuts fail on non-Latin keyboard layouts (e.g. Russian/Cyrillic)

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/27859
2. https://github.com/anthropics/claude-code/issues/19704

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

This is not a duplicate. Both suggested issues (#27859, #19704) are about non-Latin layouts in legacy terminals (Terminal.app, iTerm) that don't use the kitty keyboard protocol. My issue is specifically about the kitty keyboard protocol CSI encoding — kitty sends CSI 1092;5u (Unicode 'ф') instead of CSI 97;5u ('a') for Ctrl+A on Russian layout, and Claude Code doesn't handle this.

The fix requires either requesting the alternate-keys enhancement flag (bit 0b1000) or mapping non-Latin codepoints to their physical-key equivalents — neither of which is addressed by the closed issues.

Both #27859 and #19704 are closed, yet the problem persists on Claude Code 2.2.16 with kitty 0.41.1.

+1 — Same issue with Korean (Hangul) IME on macOS.

All Ctrl+key shortcuts (Ctrl+C, Ctrl+A, Ctrl+L, Ctrl+E, etc.) are silently ignored when the Korean input source is active. Switching to English immediately restores them.

Unlike this issue which is Kitty-specific, the Korean IME case reproduces across all terminals — Terminal.app, iTerm2, and cmux (Ghostty/libghostty-based). This suggests the root cause may not be limited to the Kitty keyboard protocol, but a broader issue in Claude Code's input handling for non-Latin input sources.

See #40291 for the full reproduction steps and environment details.

---

Workaround (임시 해결책)

Karabiner-Elements를 이용해 OS 레벨에서 Ctrl+키 입력 시 영문으로 전환 → 단축키 전송 → 한글 복원하는 방식입니다.
근본적인 해결은 아니지만, Claude Code에서 수정될 때까지 사용할 수 있습니다.

bash <(curl -fsSL https://raw.githubusercontent.com/pereng11/karabiner-korean-shortcuts/main/install.sh)

소스: https://github.com/pereng11/karabiner-korean-shortcuts

Same issue on Ghostty (macOS)

Reproduces on Ghostty 1.x with Russian (ЙЦУКЕН) layout. Specifically:

• Ctrl+C (Cyrillic С, U+0421) — does not interrupt/cancel. Physical key is the same as Latin C, but Claude Code receives a different codepoint.
• Ctrl+M (Cyrillic М, U+041C) — does not trigger image paste.
• Ctrl+V (Latin V) and Ctrl+C (Latin C on English layout) — work fine.

This confirms @pereng11's observation that the bug is not limited to kitty keyboard protocol — it's a broader issue in Claude Code's input layer. Ghostty uses a different protocol (fixterms/CSI u), yet the same root cause applies: the TUI matches keybindings by the Unicode codepoint of the current layout instead of the physical key position.

Suggested fix

Claude Code should normalize Ctrl+key combinations to their US-QWERTY physical equivalents before matching keybindings. A mapping table for common layouts (Cyrillic ЙЦУКЕН, Korean, etc.) would cover the majority of cases:

// Cyrillic → Latin physical key mapping (ЙЦУКЕН → QWERTY)
const CYRILLIC_TO_LATIN: Record<string, string> = {
  'й': 'q', 'ц': 'w', 'у': 'e', 'к': 'r', 'е': 't', 'н': 'y', 'г': 'u', 'ш': 'i', 'щ': 'o', 'з': 'p',
  'ф': 'a', 'ы': 's', 'в': 'd', 'а': 'f', 'п': 'g', 'р': 'h', 'о': 'j', 'л': 'k', 'д': 'l',
  'я': 'z', 'ч': 'x', 'с': 'c', 'м': 'v', 'и': 'b', 'т': 'n', 'ь': 'm',
};

Alternatively, if the terminal supports it (kitty protocol bit 0b1000, or CSI u with base-layout-key), use the reported base/alternate key directly.

Environment

• Ghostty 1.1.3
• macOS 15.4 (Darwin 25.3.0)
• Claude Code latest
• Russian (ЙЦУКЕН) layout

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Proposed fix with diff, vitest spec, and a zero-dep Node reproduction:

https://github.com/vetermanve/claude-code-non-latin-ctrl-keys

Same root cause as #36549. Three files, all backwards-compatible:

1. ink/termio/csi.ts — request Kitty progressive flag bit 2 in addition to bit 0:

ENABLE_KITTY_KEYBOARD = csi('>5u') // was '>1u'
This is the alternate-keys flag @Flamefork pointed at in #36549.

1. ink/parse-keypress.ts — extend CSI_U_RE to capture the optional base-layout-key group from the kitty CSI u syntax (keycode[:shifted:base-layout-key][;modifier...] u).

1. ink/parse-keypress.ts (CSI u branch) — when ctrl or super is held and the terminal provided a base-layout-key, route the matcher by that physical (US) key position. Plain typing (no ctrl/super) keeps the raw codepoint so non-Latin text input is untouched.

Why this rather than a per-layout transliteration table (oviron's comment in #36549): the terminal already knows which physical key was pressed under any layout — Cyrillic, Greek, Arabic, Hebrew, Armenian, Georgian, Korean Hangul IME, etc. — and the Kitty spec mandates
reporting it via the alternate-keys flag. One code path covers every script, no per-layout maps to maintain.

Terminals that don't implement bit 2 keep emitting the short CSI u form, which the extended regex parses identically — fully backward compatible.

Links:

• Unified diff: https://github.com/vetermanve/claude-code-non-latin-ctrl-keys/blob/main/PATCH.diff
• Zero-dep Node repro: https://github.com/vetermanve/claude-code-non-latin-ctrl-keys/blob/main/repro/repro-ru-ctrl-c.mjs
• Vitest spec: https://github.com/vetermanve/claude-code-non-latin-ctrl-keys/blob/main/src/ink/__tests__/parse-keypress.cyrillic.test.ts
• Full RFC write-up: https://github.com/vetermanve/claude-code-non-latin-ctrl-keys/blob/main/ISSUE.md

Reproduction output (broken parser vs fixed parser, side by side):

ctrl+c (RU layout, kitty alt-keys) broken: null fixed: name='c', ctrl=true pass
ctrl+e (RU layout, kitty alt-keys) broken: null fixed: name='e', ctrl=true pass
ctrl+v (GR layout, kitty alt-keys) broken: null fixed: name='v', ctrl=true pass
shift+Б (text typing) broken: null fixed: shift=true, name != 'b' pass
legacy kitty (no alt-keys) broken: name='c', ctrl=true fixed: name='c', ctrl=true pass
shift+enter broken: name='return' fixed: name='return' pass

Confirmed against claude-code 2.1.142 and npm @anthropic-ai/claude-code 2.1.150 / 2.1.152.

Happy to open a PR. Could a maintainer reopen #36549 and tag this for the input layer team?

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.