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

Preflight Checklist

• [x] I have searched existing issues — closest match is #56781, closed as stale on 2026-06-03 without a fix; this is a fresh regression with a bisect window
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.173)

What's Wrong?

On German (and other European) keyboard layouts under WSL2 + Windows Terminal, AltGr-based characters can no longer be typed in the chat input since updating to v2.1.172/173. AltGr+Q (which produces @ on German layouts) inserts nothing.

This worked in v2.1.170. Bisect window: v2.1.171–v2.1.172.

The same characters work correctly in plain bash in the same WSL2 session and in all other applications.

Root Cause (analysis)

Windows synthesizes AltGr as Ctrl+Alt. The TUI now dispatches Ctrl+Alt+Q into shortcut handling before character insertion, so the @ never reaches the input. Same root-cause class as #56781.

Impact

@ is the file-mention trigger — a core interaction. Broken for German/French/Nordic/Polish/Italian layouts (see also #59045, #53451).

Workaround (verified)

~/.claude/keybindings.json, Chat context:

{"ctrl+alt+q": null, "alt+q": null, "ctrl+q": null}

Hot-reloaded, restores @ immediately. This suggests the regression is in keybinding/shortcut dispatch consuming Ctrl+Alt combos.

What Should Happen?

Ctrl+Alt+<printable key> on Windows/WSL should be treated as AltGr character input (strip the synthetic Ctrl) before shortcut dispatch.

Environment

• Claude Code 2.1.173 (native installer), regression introduced after 2.1.170
• WSL2 (Linux 6.6.x) on Windows, Windows Terminal, German keyboard layout