Caps Lock keypress leaks '[57358u' into input when using VS Code integrated terminal
Bug Report
Environment:
- Claude Code in VS Code integrated terminal
- VS Code has
terminal.integrated.enableKittyProtocolenabled (default since VS Code 1.86) - macOS
Description
Every time Caps Lock is pressed, the literal string [57358u appears in the Claude Code input field. This does not happen in other terminals (iTerm2, Terminal.app, etc.).
Root Cause
VS Code's integrated terminal advertises Kitty keyboard protocol support and sends modifier-only key events (e.g. Caps Lock = keycode 57358). Claude Code receives the raw escape sequence \e[57358u but does not filter/discard modifier-only key events that produce no printable character, causing them to leak into the input as literal text.
Expected Behavior
Modifier-only key events (Caps Lock, Shift, Ctrl, Alt, etc.) should be silently ignored by Claude Code and never appear as text in the input.
Workaround
Disabling terminal.integrated.enableKittyProtocol in VS Code fixes the noise, but breaks Shift+Enter (newline in Claude Code input) since the terminal can no longer distinguish Shift+Enter from Enter without the Kitty protocol.
Suggested Fix
Claude Code should filter out modifier-only key events (keycodes with no associated printable character) received via the Kitty keyboard protocol before passing them to the input handler.
5 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Additional context from a macOS Korean user
This issue is especially impactful for Korean (한국어) users on macOS because Caps Lock is remapped to the Korean/English IME toggle key (한영키) by default. Korean users press this key dozens of times per minute while typing mixed Korean/English text, making
[57358uappear constantly in the input field.Reproduction
[57358uis inserted into the input on every keypressAnalysis
The Kitty Keyboard Protocol spec defines modifier-only keys with keycodes in the 57xxx range:
| Keycode | Key |
|---------|-----|
| 57358 | Caps Lock |
| 57359 | Scroll Lock |
| 57360 | Num Lock |
| 57361 | Print Screen |
| 57362 | Pause |
| 57363 | Menu |
| 57441-57444 | Shift (L/R), Ctrl (L/R) |
| 57445-57446 | Alt (L/R) |
| 57447-57448 | Super (L/R) |
| 57449-57450 | Hyper (L/R) |
Suggested fix: When parsing CSI u sequences (
\e[<keycode>u), discard any event where the keycode falls in the modifier-only range (57358–57450). These keys have no printable output and should never be passed to the input handler.Note on auto-close
The linked "duplicates" (#16843, #28518) are about numpad keys and arrow key repeats — related to KKP parsing but different root cause (those are printable/actionable keys being mishandled, while this is about modifier-only keys leaking through). This issue should remain open.
This is a regression in v2.1.83 — v2.1.81 does not exhibit this behavior.
+1 — Potentially the same root cause, different keycode.
I use F19 as a keybind for voice dictation on macOS. Since upgrading to v2.1.83, holding F19 floods the input with
[57382u(F19 in the Kitty keyboard protocol). This only happens in Claude Code — no other terminal application is affected.Confirmed regression: v2.1.81 does not exhibit this behavior. v2.1.83 does.
This seems consistent with the suggested fix in this thread — Claude Code should discard CSI u sequences for keycodes that have no printable output, rather than passing them through to the input handler.
Environment:
I also experienced this issue, and it was resolved after updating to Claude Code v2.1.89.
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.