›_ Claude Code Issues
Claude Code Issues / #77386

Ctrl-based shortcuts don't fire with non-Latin (Cyrillic) keyboard layout — Kitty keyboard protocol reports layout-dependent codepoint

Open 💬 0 comments Opened Jul 14, 2026 by pashgo

Description

When a non-Latin keyboard layout (e.g. Russian/Cyrillic) is active, Ctrl-based keyboard shortcuts inside the Claude Code TUI do not fire. Switching the OS layout to a Latin one (US/ABC) makes them work again.

Crucially, the same shortcuts work fine in a plain shell running in the same terminal with the Cyrillic layout active — so this is not a terminal or OS issue. It is specific to how Claude Code consumes keyboard input.

Environment

  • Claude Code: 2.1.208
  • OS: macOS 26.3 (25D125)
  • Terminal: Ghostty (TERM=xterm-ghostty, embedded in agterm)
  • Active layouts: ABC (US) + Russian

Steps to reproduce

  1. Switch the OS keyboard layout to Russian (Cyrillic).
  2. In a plain shell in the terminal, type foo bar and press Ctrl+A → cursor jumps to start of line, Ctrl+E → end. Works. ✅
  3. Launch claude in the same terminal, keep the Cyrillic layout active, and try any Ctrl-based shortcut (e.g. history / undo / reverse-search). Nothing happens. ❌
  4. Switch the layout to English (ABC) → the same shortcuts work. ✅

Expected

Ctrl-based shortcuts should fire regardless of the active keyboard layout, exactly as they do in the shell.

Actual

Ctrl-based shortcuts are silently ignored while a non-Latin layout is active.

Root cause analysis

The difference between the shell and Claude Code is the keyboard input protocol:

  • A plain shell / readline receives Ctrl+A as the legacy C0 control byte 0x01, which is layout-independent (always "a").
  • Claude Code (since 2.1.0, for Shift+Enter support) enables the Kitty keyboard protocol (progressive enhancement / CSI-u). In that mode the terminal reports the layout-dependent Unicode codepoint of the key plus modifier flags. On a Russian layout, physical A produces ф (U+0444), so the terminal sends CSI 1092 ; 5 u (codepoint 1092 = 0x444, modifier 5 = Ctrl). Claude Code's shortcut matcher looks for Ctrl + a (codepoint 97), which never matches.

This is why the shell works (legacy encoding) but Claude Code does not (Kitty protocol + layout-dependent codepoint).

Proposed fix

The Kitty keyboard protocol already provides a layout-independent key via the alternate-keys field (progressive-enhancement flag 0b1000 / "Report alternate keys"). With that flag set, the terminal sends the codepoint as unicode-key-code:shifted-key:base-layout-key, where base-layout-key is the key on the standard US layout, independent of the active layout. Ghostty (and kitty, WezTerm, etc.) report this field.

Claude Code should:

  1. Request the "Report alternate keys" enhancement flag, and
  2. Match Ctrl/Alt-based shortcuts against the base-layout-key (falling back to the primary codepoint) instead of the layout-dependent primary codepoint.

That makes shortcuts fire for any keyboard layout while preserving the Kitty protocol benefits.

Related (closed) issues — same underlying cause, still reproducible on 2.1.208

  • #18221 — Alt/Option keyboard shortcuts break international keyboard layouts
  • #11997 — Alt-arrow word navigation broken with Cyrillic and non-Latin characters
  • #3015 — Ctrl+Backspace and Ctrl+Arrow navigation issues with Cyrillic text
  • #17400 — Kitty keyboard protocol: keys not decoded (Ghostty + German keymap)

View original on GitHub ↗