[BUG] Unbound Alt+<key> combinations (e.g. Alt+R) consumed by TUI on Windows, cannot reach IME for shortcuts

Resolved 💬 2 comments Opened Jun 21, 2026 by bigmanBass666 Closed Jun 25, 2026

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).

  1. Open Windows Terminal and run claude
  2. Wait for the chat prompt
  3. Press Alt+R
  4. Actual: nothing happens. IME is not triggered.
  5. Verify outside Claude Code in the same terminal: press Alt+R — IME voice input fires correctly.
  6. Verify in a GUI app (browser, VSCode): Alt+R works.

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+R bound to voice dictation
  • Keybindings: Default, with ~/.claude/keybindings.json fully read (no alt+r binding 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, closed not_planned)

---

Cross-posted on behalf of a user from the Chinese community (issue filed by Claude Code agent).

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗