Windows: Polish (and other AltGr-dependent) characters not typed in CLI input on native Windows / Conpty

Environment

• Claude Code: 2.1.119
• Node.js: 22.22.2
• OS: Windows 11 Enterprise 24H2 (build 26200.x)
• Terminal: Windows Terminal 1.24.10921.0 (default PowerShell profile)
• Shell: PowerShell 7.6.1 (Core)
• Active keyboard layout: Polish (Programmers) — KLID 00000415, verified via [System.Windows.Forms.InputLanguage]::CurrentInputLanguage
• System locale: pl-PL
• Beta UTF-8 worldwide language support: ON (ACP=OEMCP=MACCP=65001)
• Console encoding inside process: [Console]::InputEncoding = [Console]::OutputEncoding = utf-8 (CP 65001)

Repro

1. On a Windows machine with Polish (Programmers) layout active in Windows Terminal.
2. Run claude so the TUI prompt has focus.
3. Press AltGr+a (the standard binding for ą on Polish Programmers).
4. Expected: ą is inserted in the prompt.
5. Actual: nothing happens. The character is swallowed before reaching the input.

Same behaviour for the full AltGr-mapped Polish set: ą ę ć ł ń ó ś ź ż (and capitalised variants with Shift+AltGr+letter).

Confirmed NOT the cause

Verified on the affected machine:

• System encoding is UTF-8 end-to-end (Beta UTF-8 worldwide ON).
• Active keyboard layout is Polish (Programmers); the same key combos produce ą correctly in every other Windows process tested in the same Windows Terminal tab: pure pwsh prompt, node -i REPL, Codex CLI, GUI apps.
• Pasting ą from the clipboard into the claude prompt works — it is only direct keyboard input that is dropped.
• Not a Windows Terminal config issue: confirmed by Codex CLI working with Polish input in the same WT tab/profile.

Workaround tested and ALSO failing

PowerToys Quick Accent (Microsoft Win32 utility that injects the chosen accented character via SendInput) also fails to deliver characters into claude. It works in every other Windows app on the machine. This is a strong signal that the issue is not specifically AltGr scancode handling — it is unicode characters delivered through the normal Windows input pipeline being dropped at the TUI layer.

Probable root cause (hypothesis)

On Windows, Conpty delivers KEY_EVENT_RECORDs with both a virtual-key code + modifier flags and a UnicodeChar field. AltGr on Polish Programmers maps AltGr+a to:

• wVirtualKeyCode = VK_A
• dwControlKeyState = RIGHT_ALT_PRESSED | RIGHT_CTRL_PRESSED
• UnicodeChar = U+0105 (ą)

If the input handler dispatches on (modifier flags + VK) to detect shortcuts (e.g. Ctrl+Alt+A) before falling through to UnicodeChar, then on AltGr layouts the unicode character is silently dropped. The same logic explains why injected unicode (PowerToys SendInput) is also lost — it arrives as a synthesised key event with UnicodeChar set but the dispatcher has already classified it as a non-character event.

This is consistent with Node readline raw-mode behaviour on Windows when Conpty key events are not pre-decomposed into character vs control streams.

Related issues (cross-platform variants of the same family)

• #22174 — macOS Polish via Option key (open, platform:macos)
• #42523 — WSL2 AltGr @ for Nordic (open, platform:wsl)
• #14440 — macOS Polish in Terminal.app (closed as duplicate)

Impact

Hard blocker for CLI use by speakers of any AltGr-dependent layout — Polish, Czech, Hungarian, German Extended, Slovak, Spanish-International, Croatian, Slovenian, etc. Forces:

• using Claude Code Desktop app instead of CLI, or
• Codex CLI instead of Claude Code, or
• continuous ASCII transliteration during a session.

Suggested fix direction (for triage)

At the input layer: if the incoming key event has a non-zero UnicodeChar and the modifier combination is RIGHT_ALT_PRESSED | RIGHT_CTRL_PRESSED (the canonical AltGr signature on Win32), prefer the UnicodeChar payload over treating the event as a Ctrl+Alt shortcut. Equivalently: short-circuit shortcut dispatch when UnicodeChar is set and the only active modifiers are AltGr's pair.