[BUG] Unbound Alt+<key> combinations (e.g. Alt+R) consumed by TUI on Windows, cannot reach IME for shortcuts
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
What's Wrong?
On Windows with a Chinese IME (微信输入法 / WeChat Input), pressing Alt+R triggers the IME's voice input in every other application (browser, VSCode, Notepad, etc.). Inside the Claude Code CLI TUI, Alt+R does nothing — the keystroke is silently consumed before reaching the IME.
The same applies to any unbound Alt+<key> combination: the TUI swallows it regardless of whether it's mapped in keybindings.json.
What Should Happen?
When Alt+R (or any unbound Alt+<letter>) is pressed, the TUI should pass the key event through to the input stream so the IME can act on it, rather than silently consuming it.
Expected: IME receives Alt+R → voice input toggles, same as every other Windows application.
Steps to Reproduce
Prerequisites: Windows machine with a Chinese IME that uses Alt+R as a shortcut (e.g., 微信输入法 voice input).
- Open Windows Terminal and run
claude - Wait for the chat prompt
- Press
Alt+R - Actual: nothing happens. IME is not triggered.
- Verify outside Claude Code in the same terminal: press
Alt+R— IME voice input fires correctly. - Verify in a GUI app (browser, VSCode):
Alt+Rworks.
Root Cause (Analysis)
The Claude Code TUI input layer intercepts all Alt+<letter> key combos in raw mode. Even when no matching action exists in keybindings.json, the key event is consumed by the TUI event loop and dropped — it never reaches the OS/IME input pipeline.
This is related to #53451 (AltGr characters swallowed by TUI on Windows / Conpty), but distinct:
| | #53451 | This Issue |
|---|---|---|
| Modifier | AltGr (Ctrl+Alt), produces characters | Pure Alt, consumed by IME |
| Layout | European AltGr (Polish, German, etc.) | Chinese IME (and any IME using Alt shortcuts) |
| Scenario | Cannot type a character | Cannot trigger IME function via keystroke |
Workaround
None. Setting "alt+r": null in keybindings.json does not help — the TUI consumes the key below the keybinding layer.
The only option is to rebind the IME's shortcut away from Alt+R, which is disruptive (IME voice input works fine everywhere else).
Environment
- Claude Code: 2.1.183 (native installer)
- OS: Windows 11 Home China 10.0.22631
- Terminal: Windows Terminal Preview
- Shell: Git Bash (running via Windows Terminal)
- IME: 微信输入法 (WeChat Input),
Alt+Rbound to voice dictation - Keybindings: Default, with
~/.claude/keybindings.jsonfully read (noalt+rbinding present)
Claude Model
Sonnet (default)
Related Issues
- #53451 — Windows: Polish (and other AltGr-dependent) characters not typed on native Windows / Conpty (
platform:windows,area:tui, closednot_planned)
---
Cross-posted on behalf of a user from the Chinese community (issue filed by Claude Code agent).
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗