fix(cli): stop pushing Kitty keyboard protocol that breaks Ctrl+C

Commit 2ae7884ffa added _EXTENDED_ENTER_KEYS_SEQ which pushes both the
Kitty keyboard protocol (CSI >1u) and xterm modifyOtherKeys level 2
(CSI >4;2m) on supported terminals (Ghostty, iTerm2, WezTerm, kitty).

Under the Kitty keyboard protocol, Ctrl+C is encoded as \x1b[99;5u
(codepoint 99='c', modifier 5=Ctrl) instead of \x03 (ETX). prompt_toolkit
3.x has no mapping for \x1b[99;5u, so the sequence leaks as literal
text '[99;5u' on screen. Worse, the kernel's INTR mechanism looks for
the raw \x03 character, so SIGINT never fires either — Ctrl+C is
completely dead.

Fix: drop the CSI >1u push from _EXTENDED_ENTER_KEYS_SEQ, keeping only
modifyOtherKeys (CSI >4;2m). Shift+Enter still works via the
\x1b[27;2;13~ sequence that modifyOtherKeys produces and prompt_toolkit
already maps (Keys.ControlM). The exit reset sequence still pops both
modes for safety.

Refs #56684.
This commit is contained in:
kshitij
2026-08-15 20:51:53 +05:30
parent 45af7a71fc
commit 165c889e5b
+9 -5
View File
@@ -3885,7 +3885,7 @@ _TERMINAL_INPUT_MODE_RESET_SEQ = (
"\x1b[0m" # reset text attributes
"\x1b[?25h" # ensure cursor visible
)
_EXTENDED_ENTER_KEYS_SEQ = "\x1b[>1u\x1b[>4;2m"
_EXTENDED_ENTER_KEYS_SEQ = "\x1b[>4;2m"
_BACKSLASH_LINE_CONTINUATION_RE = re.compile(r"\\[ \t]*$")
@@ -3920,10 +3920,14 @@ def _terminal_supports_extended_enter_keys(env: Optional[Mapping[str, str]] = No
def _enable_extended_enter_keys(output=None, env: Optional[Mapping[str, str]] = None) -> bool:
"""Ask allowlisted terminals to report Shift+Enter distinctly.
Writes both the Kitty keyboard protocol push (CSI >1u) and xterm
modifyOtherKeys level 2 (CSI >4;2m), mirroring the Ink TUI. The exit reset
sequence already pops/resets both modes, so this is safe across normal
exits, Ctrl+C, and SIGTERM cleanup.
Writes xterm modifyOtherKeys level 2 (CSI >4;2m), mirroring the Ink TUI.
We do NOT push the Kitty keyboard protocol (CSI >1u) here because
prompt_toolkit 3.x cannot parse Kitty CSI-u sequences for control
characters — Ctrl+C arrives as ``\\x1b[99;5u`` instead of ``\\x03``,
which neither prompt_toolkit's key bindings nor the kernel's INTR
mechanism can match, leaving Ctrl+C completely dead (#56684).
The exit reset sequence already pops/resets both modes, so this is
safe across normal exits, Ctrl+C, and SIGTERM cleanup.
"""
if not _terminal_supports_extended_enter_keys(env):
return False