Enter key appends `[13u` instead of sending message in VS Code integrated terminal

[Mtrya]

What version of Kimi Code CLI is running?

kimi, version 1.22.0

Which open platform/subscription were you using?

Kimi Code

Which model were you using?

kimi-for-coding

What platform is your computer?

Linux 6.19.6-arch1-1 x86_64 unknown

What issue are you seeing?

In VS Code's integrated terminal, pressing Enter to send a message results in [13u being appended to the input instead of submitting. Kimi-cli works fine in other terminals (GNOME Terminal, Kitty, etc.) and other CLI tools (Claude Code, Codex) work fine in VS Code.

What steps can reproduce the bug?

My VS Code version is: (output of code --version) 1.111.0
To reproduce the bug, enter VS Code, open an integrated terminal, type kimi and enter, then type anything in kimi-cli and press enter.
The root cause is likely Kitty Keyboard Protocol that was introduced to VS Code in version 1.109.0, which sends keys as CSI-u sequences (e.g., \x1b[13u for Enter) and prompt_toolkit 3.0.52 doesn't support parsing these sequences, treating them as literal characters.
Minimal reproduction:

from prompt_toolkit.input.vt100_parser import Vt100Parser
parser = Vt100Parser(lambda k: print(k))
parser.feed('\x1b[13u')  # Kitty protocol Enter
# Result: Parses as [Escape, '[', '1', '3', 'u'] - NOT Enter key!

What is the expected behavior?

Should be parsed as Enter key

Additional information

Proposed fix: Emit the kitty keyboard protocol disable sequence (\x1b[<u) at shell startup in src/kimi_cli/utils/term.py.

[Br1an67]

I'd like to work on this issue. The root cause is that VS Code >= 1.109.0 enables the Kitty keyboard protocol, which encodes key presses as CSI-u sequences (e.g. \x1b[13u for Enter). prompt_toolkit 3.x doesn't parse these, so raw characters leak into user input.

I have a fix ready that applies two complementary strategies:

1. Send the Kitty protocol "pop" sequence (\x1b[<u) at shell startup to disable the protocol
2. Extend the keyboard listener's escape sequence parser to properly handle CSI-u keycodes as defense-in-depth

PR incoming shortly.

[Br1an67]

I've implemented the fix. The root cause is exactly as described: VS Code >= 1.109 enables the Kitty keyboard protocol, which sends keys as CSI-u sequences (e.g., \x1b[13u for Enter). prompt_toolkit doesn't parse these, so they arrive as literal text.

Fix: Added disable_kitty_keyboard_protocol() in term.py that emits the Kitty keyboard protocol pop sequence (\x1b[<u) at shell startup. This tells the terminal to fall back to legacy key reporting which prompt_toolkit understands.

PR incoming.

[Mtrya]

This issue appears to be resolved, possibly due to VSCode 1.112.0's xterm.js update (PR #5737) but I'm not sure. Anyway since the bug is resolved on my side and I cannot reproduce it anymore, I'm closing the issue for now - can reopen if it regresses.