[BUG] AltGr+E and AltGr+plus intercepted in chat input on Windows IT keyboard, block € and ] symbols

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows with Italian keyboard layout, pressing AltGr+E inside Claude Code chat input does nothing — the keystroke is silently dropped. AltGr+E should produce the € (euro) symbol, which is the standard IT keyboard binding for that combo.

The bug is specific to Claude Code: AltGr+E works correctly in any other Windows app (Notepad, browser, the same Windows Terminal hosting Claude Code BEFORE claude is launched). It only fails INSIDE the Claude Code chat input.

Confirmed broken on Italian layout:

• AltGr+E (should produce €) → dropped
• AltGr+plus (should produce ]) → dropped

Other AltGr combinations on the Italian layout work fine (e.g., AltGr+ò produces @, AltGr+è produces [, AltGr+à produces #

Hypothesis: on Windows, AltGr+E is hardware-equivalent to Ctrl+Alt+E. The Ink/text-input layer appears to interpret this as a Ctrl-modified keystroke and drops the event before checking the AltGraph modifier state per W3C UI Events spec. Other AltGr+letter combos
don't collide with any reserved Ctrl shortcut and pass through.

What Should Happen?

AltGr+E in chat input should produce the € character, exactly like every other AltGr+letter combination on Italian keyboard does today. Same behavior as outside Claude Code.

Error Messages/Logs

Steps to Reproduce

Prerequisites: Windows machine with Italian keyboard layout (layout selectable via Win+Space).

1. Open Windows Terminal (any flavor: stable or Preview, both reproduce)
2. Without launching claude, in the cmd/PowerShell prompt: press AltGr+E → "€" appears correctly. Confirms keyboard + terminal work fine.
3. Launch claude:

$ claude

1. Wait for the chat input to be ready
2. In chat input, press AltGr+E → nothing appears. Keystroke is silently dropped.
3. Press AltGr+ò in same chat input → "@" appears correctly. Other AltGr combos work.
4. Repeat outside claude in the same terminal: AltGr+E works again.

Verified workaround attempt that did NOT fix it:

• Created ~/.claude/keybindings.json with null overrides for ctrl+e and ctrl+alt+e in contexts: Chat, Global, Confirmation, Transcript, ThemePicker
• /doctor reports no errors
• After full restart of claude, AltGr+E still dropped
• This confirms the intercept is below the keybindings.json layer (Ink text-input handler).

Workaround currently in use: copy-paste € from Notepad. AutoHotkey SendText would also bypass it but is third-party.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.141 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Environment:

• Windows 11 Pro 26200
• Windows Terminal Preview 1.25.x AND stable — reproduces in both
• Italian keyboard layout (IT)
• Node 22.13.1

Related issues (similar Windows non-ASCII / keyboard-input bugs):

• #6094 Unicode Character Input Corruption
• #14562 Prompt input displays corrupted characters in Windows Terminal
• #31539 Non-ASCII characters in input causing encoding issues
• #37332 Option as meta key conflicts with German keyboard layout (closest analog: AltGr collision on DE)

Why this matters specifically: on Italian keyboard the € symbol has only one standard binding, AltGr+E. There's no fallback combo (unlike German where Strg+Alt+E exists separately). Italian users writing financial/business content in Claude Code lose the ability
to type the most common currency symbol.

Suggested fix direction: in the Ink text-input event handler, when both Ctrl and Alt modifiers are set, check KeyboardEvent.getModifierState("AltGraph") (or the Windows equivalent VK_RMENU + VK_LCONTROL combo) and treat it as plain text input instead of as a
Ctrl-modified shortcut.