[BUG] Regression v2.1.172: AltGr characters (@, €) swallowed in chat input on WSL2 — worked in v2.1.170

Still happening in 2.1.211

Root cause found + tested workaround + suggested fix

I dug into this on an affected setup (WSL2 Ubuntu + Windows Terminal, German layout, Claude Code 2.1.211). The character loss is not in keybinding/shortcut dispatch — it's in how Claude Code negotiates the terminal keyboard protocol. Here are byte-level captures that isolate it.

Environment

• WSL2 (Ubuntu) on Windows, Windows Terminal (WT_SESSION set)
• German keyboard layout; @ = AltGr+Q, € = AltGr+E
• Claude Code 2.1.211 (still reproduces; not fixed since the original report)

What the terminal actually sends for AltGr+Q

Captured directly in the terminal, same profile Claude Code runs in:

1. Normal / cooked mode (cat -v, or a raw single-char read) — the character arrives clean:

$ cat -v
@            # byte 0x40, no escape prefix, no modifiers

1. With the kitty keyboard protocol enabled at flags=1 — which is what Claude Code turns on at startup (ESC[>1u):

$ printf '\033[>1u'; IFS= read -rsn20 -t5 k; printf '\033[<u\n'; printf '%s' "$k" | xxd
00000000: 1b5b 3131 333b 3375              .[113;3u

That decodes to ESC[113;3u = base key 113 (q), modifier 3 (Alt) — the resolved @ is not in the message at all. The terminal reports the physical key event, and AltGr surfaces as an Alt modifier.

1. With the kitty "report associated text" flag added (flags=17, i.e. ESC[>17u):

$ printf '\033[>17u'; IFS= read -rsn20 -t5 k; printf '\033[<u\n'; printf '%s' "$k" | xxd
00000000: 1b5b 3131 333b 333b 3634 75      .[113;3;64u

Now it's ESC[113;3;64u — base key q, Alt, and the resolved character @ (codepoint 64) in the associated-text field.

Why the character is lost

Two independent issues, both on the client side:

1. Claude Code enables the kitty keyboard protocol with flags=1 (disambiguate only) and never sets the "report associated text" bit (16). So on a layout where AltGr+Q produces @, the terminal reports the base key q plus an Alt modifier and the actual @ is never transmitted. In cooked mode (capture #1) the OS resolves AltGr and hands over @ directly, which is why every other app — and plain bash in the same session — works fine.

1. Even if a fuller report arrived, it wouldn't be parsed. Claude Code's CSI-u key parser reads only two fields (key code + modifier). A three-field report like 113;3;64u doesn't match its pattern, so the associated-text field is never read.

Downstream, the key event carries an Alt/meta modifier, and the text-input layer discards any key that has ctrl or meta set — so the keystroke is dropped silently. This is also why the existing CLAUDE_CODE_ALTGR_AS_TEXT env var doesn't help here: that path only triggers for Ctrl+Alt combos, but under the kitty protocol Windows Terminal reports AltGr as Alt-only, and in any case the message carries the base key (q), not @.

Workaround (tested, works today)

Prevent Claude Code from enabling the kitty protocol, so AltGr characters arrive as plain bytes (capture #1 behavior):

env -u WT_SESSION claude

Windows-Terminal detection keys off WT_SESSION; with it unset, the terminal isn't in the kitty-enable allowlist, the protocol isn't turned on, and @/€ type normally. Make it permanent with an alias. Caveats: this disables kitty-protocol key disambiguation generally (fine for normal editing), and it won't help inside tmux (tmux enables the protocol independently). Use env -u (fully unset), not an empty value.

Note this is only an indirect workaround because there is currently no supported way to disable the kitty keyboard protocol — a CLAUDE_CODE_DISABLE_KITTY_KEYBOARD-style env var is itself an outstanding feature request (#27001, #27868). Shipping one would both give affected users a clean escape hatch and close those requests.

Suggested fix

1. When enabling the kitty keyboard protocol, also request the "report associated text" flag (bit 16, i.e. send flags 17 instead of 1). Terminals that don't support it ignore the extra bit, and the actual negotiated flags can be confirmed from the protocol's query response.
2. Extend the CSI-u parser to read the optional associated-text field (and colon sub-fields), and when a printable associated-text codepoint is present, insert it as literal text with modifiers cleared — so AltGr+Q yields @, not a dropped q. This is layout-agnostic: the terminal does the AltGr resolution and simply hands back the resolved character.
3. As a fallback for terminals that don't report associated text, broaden the existing AltGr-as-text heuristic to also handle Alt-only (not just Ctrl+Alt) printable keys on WSL/Windows.
4. Add a regression test that feeds ESC[113;3;64u (and the legacy ESC[27;... form) through the input pipeline and asserts @ is inserted — this class of bug has regressed repeatedly without one.
5. Separately, add a supported opt-out (e.g. a CLAUDE_CODE_DISABLE_KITTY_KEYBOARD env var), which is already requested in #27001 and #27868 — useful as an escape hatch for this and similar protocol-related input issues.

Still happening in 2.1.234