Ctrl+C does not work when non-English keyboard layout is active (e.g. Ukrainian)

[Alexandr-Kravchuk]

Describe the bug

Ctrl+C does not cancel the current operation or clear input when a non-English keyboard layout (e.g. Ukrainian) is active. Nothing happens at all — the CLI simply ignores the key combination.

Switching back to an English (US) keyboard layout makes Ctrl+C work as expected again.

This likely affects all non-Latin keyboard layouts (Cyrillic, CJK, Arabic, etc.) where the physical key sends a different character code than ASCII c.

Affected version

0.0.406

Environment

• OS: macOS
• Terminal: iTerm2
• Keyboard layout: Ukrainian (standard macOS layout)

Steps to reproduce the behavior

1. Start copilot in interactive mode
2. Send a prompt and wait for the agent to start working
3. Switch keyboard layout to Ukrainian (or any other non-English layout)
4. Press Ctrl+C
5. Actual: Nothing happens — the operation is not cancelled
6. Switch keyboard layout back to English
7. Press Ctrl+C
8. Expected: The operation is cancelled (this works correctly with English layout)

Expected behavior

Ctrl+C should cancel the current operation regardless of the active keyboard layout. The shortcut should be matched by the physical key position (scancode) rather than the character produced by the current layout.

Additional context

This is a common issue in terminal applications that match key events by character rather than by physical key / scancode. Many terminal frameworks solve this by normalizing modifier+key combinations to their US-layout equivalents.

Related issues:

• Additional Keyboard Shortcuts #139 — Additional Keyboard Shortcuts
• Common editing shortcuts like Ctrl+A, Ctrl+E, etc. are not working as expected in user input (should support Readline/Emacs style and not be remapped) #1069 — Common editing shortcuts not working as expected
• Carry over terminal key-bindings (e.g. ubuntu terminal key bindings) #540 — Carry over terminal key-bindings
• Vietnamese IME Input Rendering Issue in Copilot CLI Overlay #838 — Vietnamese IME Input Rendering Issue

[Alexandr-Kravchuk]

Root Cause Analysis

I investigated the bundled source code from @github/copilot npm package (v0.0.406) and found the exact root cause.

The Bug

When kitty keyboard protocol is enabled (iTerm2, WezTerm, Ghostty, etc.), pressing Ctrl+C with a non-English layout sends a CSI-u escape sequence containing the Unicode codepoint of the local character instead of ASCII c.

Layout	Escape sequence sent by terminal	Codepoint	Char	Result
English	ESC[99;5u	99	c	✅ Parsed as ctrl+c
Ukrainian	ESC[1089;5u	1089	с (Cyrillic)	❌ name stays empty

The D_r kitty protocol parser only assigns name for characters in the a-z / A-Z ASCII range. Non-Latin characters fall through with name="", so all consumer checks like y === "c" && N.ctrl fail silently.

Proposed Fix (2 changes)

1. Enable kitty protocol report-alternate-keys flag:

The kitty keyboard protocol spec supports a flag that tells the terminal to include the US-layout equivalent of the pressed key as an extra parameter in the CSI-u sequence. This is fully automatic — the user still just presses Ctrl+C as usual, but the terminal transparently adds the base Latin codepoint.

- process.stdout.write("\x1B[>1u")  // mode 1: disambiguate
+ process.stdout.write("\x1B[>9u")  // mode 9: disambiguate + report-alternate-keys

With this flag, the terminal sends three parameters instead of two:
ESC[1089;5;99u — where 99 (Latin c) is the US-layout equivalent, appended automatically by the terminal.

2. Use the US-layout equivalent in the D_r parser:

The third CSI-u parameter is already captured by the existing regex but currently unused. Add a fallback that uses it when ctrl is set and the primary character is non-Latin:

// After existing A-Z name resolution, add:
if (e.ctrl && !e.name && l) {
  let alt = parseInt(l, 10);
  if (!isNaN(alt)) {
    let altChar = String.fromCharCode(alt);
    if (altChar >= 'a' && altChar <= 'z') e.name = altChar;
    else if (altChar >= 'A' && altChar <= 'Z') e.name = altChar.toLowerCase();
  }
}

Verification

Test 1 - English Ctrl+C:                                          PASS
Test 2 - Ukrainian Ctrl+C (current behavior, no US-layout equiv): BUG CONFIRMED (name is empty)
Test 3 - Ukrainian Ctrl+C (with US-layout equiv from terminal):   FIX WORKS (name = "c")

Impact

This fix would resolve the same issue for all Ctrl+key shortcuts (Ctrl+A, Ctrl+E, Ctrl+W, Ctrl+U, Ctrl+K, etc.) on any non-Latin keyboard layout (Ukrainian, Russian, Arabic, Chinese, Japanese, Korean, etc.). No user-facing changes — everything works transparently.