AltGr characters (@, [, {…) can't be typed on international keyboards — works in terminal, fails in Claude Code (follow-up to #18221)

Summary

On international keyboard layouts that rely on AltGr (Right-Alt) to produce common programming characters, those characters cannot be typed into the Claude Code prompt at all. The exact same keystrokes work correctly in a standalone terminal (Windows Terminal / PowerShell) — they only fail inside Claude Code. The only workaround is to copy-paste the characters from another application, which makes the CLI painful to use for everyday coding.

This is a follow-up to #18221 ("Alt/Option keyboard shortcuts break international keyboard layouts"), which was closed as not planned and is now marked stale. I'm reopening the conversation because this is a basic text-input correctness bug, not a shortcut-customization request: it prevents users from typing characters that are essential to writing code (@, [, ], {, }, \, etc.).

Steps to reproduce

1. Use a keyboard layout where common symbols require AltGr — e.g. Portuguese (PT):

• @ = AltGr + 2
• [ = AltGr + 8
• ] = AltGr + 9
• { = AltGr + 7
• } = AltGr + 0
• € = AltGr + E

1. Open a normal terminal (Windows Terminal / PowerShell) and type those combos — they produce the characters correctly.
2. Open Claude Code in that same terminal and try to type the same combos into the prompt — nothing is inserted. The keystroke is swallowed.

Expected behavior

AltGr-composed characters should be inserted as literal text, exactly as they are in the host terminal.

Actual behavior

The keystroke is consumed and no character appears. The user must copy-paste @, [, {, etc. from another app to write any code or commands that need them.

Likely cause

On Windows, AltGr = Left-Ctrl + Right-Alt. Claude Code's input layer appears to treat the Alt half of that chord as a Meta modifier (the same handling used for Alt-based shortcuts), so the OS-composed character is intercepted as a key chord instead of being passed through as text. Because the terminal itself composes the character correctly, the problem is specifically in Claude Code's key handling — not the terminal.

A targeted fix would be to not treat a key event as an Alt/Meta shortcut when the Ctrl modifier is also present (i.e. when it's an AltGr composition), and instead let the composed character through as literal input. Unbound AltGr combinations should never be swallowed.

Environment

• Claude Code: 2.1.178
• OS: Windows 11 Pro (10.0.26100)
• Keyboard layout: Portuguese (PT) — AltGr-based
• Host terminal: Windows Terminal / PowerShell (AltGr works here; fails only in Claude Code)

Why this matters

This affects a large share of non-US keyboard layouts (Portuguese, German, Spanish, French, Polish, Brazilian, and many others) where @, [, ], {, }, and \ all live behind AltGr. For those users, Claude Code is effectively unable to accept basic programming characters from the keyboard. Closing #18221 as not planned leaves a meaningful population of users unable to type in their own language layout. Please consider reopening / re-prioritizing.

_Related: #18221_