Windows + AZERTY: Shift+letter never registers when kitty keyboard protocol is enabled (CSI-u decoder regression)

[flupkede]

Summary

On Windows with an AZERTY keyboard layout, Shift + any letter key is silently dropped by opentui-based apps (reproduced in opencode TUI) when the host terminal advertises support for the kitty keyboard protocol. Shift combined with non-letter keys works most of the time, and Caps Lock works for uppercase input — only the Shift-modifier-with-letter path is broken.

Disabling the kitty keyboard protocol in the terminal makes the bug disappear entirely, which points at opentui's CSI-u decoder.

Environment

• OS: Windows (native, no WSL)
• Keyboard layout: AZERTY
• Terminal: WezTerm
• opencode: 1.14.46 (also reproduced on 1.14.41)

Workaround that confirms the cause

config.enable_kitty_keyboard = false

After restarting WezTerm and opencode, Shift+letter is inserted correctly. Re-enabling kitty keyboard reproduces the bug.

Likely root cause

Probably same class as #818. Shift+letter is sent as CSI-u (ESC[97;2u for Shift+a). ConPTY splits or delays these reads, parser drops the sequence. Caps Lock bypasses CSI-u by sending the uppercase codepoint directly.

Possibly related

• stdin parser: CSI timeout flush drops split escape sequences #818 (CSI timeout flush)
• InputRenderable rejects non-ASCII characters (accented letters, Unicode) #752 (InputRenderable rejects non-ASCII)
• Keyboard input randomly dropped during typing and navigation #592 (keyboard input dropped)