Numpad keys output raw Kitty codepoints in Windows Terminal (WSL2) since v2.1.83

Bug Description

Since Claude Code v2.1.83, numpad keys (Enter, 0-9, /, *) and Caps Lock output raw escape sequences instead of functioning normally. Numpad Enter prints [57414u instead of submitting input. This is a regression — v2.1.81 worked correctly in the same environment.

The root cause appears to be a change in Kitty keyboard protocol detection: v2.1.83 now probes terminal capability (CSI ? u query) rather than relying solely on the TERM_PROGRAM allow-list. Windows Terminal (1.25+) responds affirmatively to this probe, causing Claude Code to activate Kitty enhanced mode — but the input decoder does not handle numpad-specific Unicode functional codepoints (U+E000 range: 57358–57441).

Environment

| Component | Value |
|-----------|-------|
| Claude Code | 2.1.83 |
| Platform | WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2) |
| Terminal | Windows Terminal (stable, installed 2026-02-18) |
| Shell | bash |
| TERM | xterm-256color |
| TERM_PROGRAM | (not set) |
| KITTY_WINDOW_ID | (not set) |

Steps to Reproduce

1. Install Claude Code v2.1.83 on WSL2
2. Launch via Windows Terminal (any recent stable version)
3. Open claude in the terminal
4. Press Numpad Enter — observe [57414u printed instead of submission
5. Press Numpad 0–9, Numpad /, Numpad \* — observe raw sequences
6. Press Caps Lock — observe [57358u printed

Expected vs Actual

| Action | Expected | Actual |
|--------|----------|--------|
| Numpad Enter | Submit input (same as main Enter) | Prints [57414u |
| Numpad / | Types / | Prints raw escape sequence |
| Numpad 0–9 | Types digit | Prints [57417u, [57419u–[57424u, etc. |
| Caps Lock | Toggle caps (no visible output) | Prints [57358u |

Main keyboard Enter and other non-numpad keys work correctly.

Regression Bisect

| Version | Date | Status |
|---------|------|--------|
| 2.1.80 | Mar 20 | ✅ Working |
| 2.1.81 | Mar 21 | ✅ Working |
| 2.1.83 | Mar 25 | ❌ Broken |

The regression window is v2.1.81 → v2.1.83.

Root Cause Hypothesis

v2.1.83 changed how Kitty keyboard protocol support is detected:

• Before (≤2.1.81): Checked TERM_PROGRAM against an allow-list (iTerm.app, kitty, WezTerm, ghostty). Windows Terminal was not on this list, so the protocol was never activated.
• After (2.1.83): Appears to use a direct capability probe (CSI ? u query). Windows Terminal 1.25+ responds to this probe, so Claude Code now activates Kitty enhanced keyboard mode.

The problem: Claude Code's input decoder does not map the numpad-specific functional codepoints defined in the Kitty protocol spec. These are Unicode codepoints in the 57344–57441 range (private use area) that represent numpad keys, modifier keys, and media keys. When received, they pass through unhandled and are printed as raw text.

Affected codepoint range (from Kitty spec):

| Key | Codepoint |
|-----|-----------|
| Caps Lock | 57358 |
| Numpad / | 57410 |
| Numpad Enter | 57414 |
| Numpad 0 | 57417 |
| Numpad 1–9 | 57418–57426 |

Reference: https://sw.kovidgoyal.net/kitty/keyboard-protocol/#functional-key-definitions

Attempted Workarounds (all failed)

1. Set TERM_PROGRAM to "windows-terminal" in ~/.claude/settings.json env block — no effect, confirming detection no longer uses env var check
2. CSI reset (printf '\e[<u') in ~/.bashrc — no effect
3. Full terminal restart after both changes — no effect

Suggested Fix

Either:

1. Map numpad codepoints: Add handling for Kitty functional codepoints 57408–57441 (numpad block) and 57358 (Caps Lock) in the input decoder, mapping them to their standard equivalents
2. Exclude Windows Terminal: Add Windows Terminal to a deny-list for Kitty protocol activation
3. Provide an opt-out: Add a setting (e.g., CLAUDE_NO_KITTY_PROTOCOL=1) to disable the capability probe

Option 1 is the most correct long-term fix.

Related Issues

• #17386 — Numpad Enter [57414u output
• #16801 — Numpad / raw sequence output
• #17400 — Numpad Enter + Shift+Space decoding
• #38624 — Caps Lock [57358u leak
• #11192 — Shift+Enter CSI u sequence insertion