Alt+numeric keypad character input stops working in Codex TUI

Open 💬 1 comment Opened Aug 23, 2026 by bar971

What version of Codex CLI is running?

0.149.0

What subscription do you have?

pro

Which model were you using?

any

What platform is your computer?

windows 11

What terminal emulator and version are you using (if applicable)?

powershell 7

Codex doctor report

What issue are you seeing?

Alt+numeric keypad character input stops working in Codex TUI

What steps can reproduce the bug?

Steps to reproduce:

Open a normal PowerShell 7 session.
Press Alt+0126 using the numeric keypad. It correctly produces the ~ character.
Start Codex by running codex.
In the Codex interactive TUI, press Alt+0126 again.
Exit Codex and try Alt+0126 once more in PowerShell.

What is the expected behavior?

Alt+numeric keypad input should produce the corresponding character while using the Codex TUI.

Additional information

Actual behavior:
Alt+0126 does not insert the ~ character while Codex is running. After exiting Codex, the same key combination works
normally again in PowerShell.

This suggests that Codex’s Windows terminal input handling intercepts or disables Alt+numeric keypad character
composition.

View original on GitHub ↗

1 Comment

BigBrown10 · 4 days ago

Root cause identified; a tested fix is available on a fork branch if maintainers want it.

Mechanism

Traced through crossterm 0.29's Windows input parser (event/sys/windows/parse.rs):

While Alt is held, numpad digit records generated during an Alt code sequence are dropped by crossterm itself (is_only_alt_modifier && is_numpad_numeric_key returns None), so no digit events ever reach the app.
On Alt release, the console host delivers the synthesized character as a VK_MENU release carrying the char. Crossterm special-cases exactly this record and emits KeyEvent { code: Char(ch), modifiers: ALT, kind: KeyEventKind::Release }.
Codex text-insertion paths reject any char event holding an ALT modifier (has_ctrl_or_alt in tui/src/key_hint.rs, plus the ALT guards in bottom_pane/textarea.rs and chat_composer.rs; those guards are what keep real shortcuts such as Alt+A distinct from typed text, and shortcuts always arrive as presses).

Net effect on Windows: the whole sequence produces zero usable events, so nothing gets inserted.

Suggested fix shape

Rewrite char-bearing release events that hold ALT (without CTRL) into plain modifier-free presses in TuiEventStream::map_crossterm_event, before shortcut guards run. Such an event cannot be anything but an Alt code synthesis result: ordinary key releases carry no meaningful character payload on this path, while real shortcuts are presses, so no shortcut behavior changes.

Constraints to preserve:

CTRL+ALT (AltGr) sequences must stay excluded from the rewrite.
Synthesized control characters should keep flowing to the existing guards unchanged.
Surrogate-pair completions above U+FFFF arrive as presses and remain indistinguishable from shortcuts; a documented limitation of this approach.

Implementation

Unit tests plus a stream-level test using the exact event crossterm produces (Windows-gated, will run on the Windows CI lane):

Branch: BigBrown10/codex: fix/windows-alt-numpad-input
Commit: https://github.com/BigBrown10/codex/commit/476de50fb0830c9825795d35ccc450d0e3d70e32
New module: codex-rs/tui/src/tui/windows_composition.rs wired into codex-rs/tui/src/tui/event_stream.rs

Happy to adjust the shape, or to open the PR if invited.