TUI drops non-ASCII chars reported as Alt/Option-modified input

What version of Codex CLI is running?

codex-cli 0.130.0 locally.

Current main also appears affected. I reproduced the logic issue locally against upstream origin/main at 6a225e4005209f2325ab3c681c7c6beba2907d4d.

What subscription do you have?

ChatGPT Pro ($200 plan).
The subscription is not part of the repro path; this is local TUI input handling before any model turn.

Which model were you using?

GPT-5.5.
The model is not part of the repro path; the failing path is local composer input handling.

What platform is your computer?

Local platform command:

uname -mprs
Darwin 24.6.0 arm64 arm

The reported user environment is macOS with a Norwegian keyboard/input setup where typing æ, ø, and å reaches the TUI as Alt/Option-modified character input.

What terminal emulator and version are you using, if applicable?

Local terminal tooling available here:

Ghostty 1.3.1
tmux 3.6a

My current shell is noninteractive (TERM=dumb, no active TMUX), so it is not a valid live key-event capture environment.

Observed user setup is Ghostty/tmux-flavored. The Codex-side issue is independent of that specific terminal once the key event shape is:

KeyEvent { code: KeyCode::Char('æ'), modifiers: KeyModifiers::ALT, .. }

Codex doctor report

Not available in my installed CLI (codex-cli 0.130.0). codex --help does not list a doctor subcommand.

What issue are you seeing?

The TUI composer drops non-ASCII characters such as Norwegian æ, ø, and å when they are reported by the terminal as ALT + Char(...) / Option-modified character input.

This is distinct from the existing mojibake/file-editing reports such as #13743. In this case the character never appears in the composer input buffer.

What steps can reproduce the bug?

A minimal code-level repro is in codex-rs/tui/src/bottom_pane/textarea.rs:

1. Create a TextArea.
2. Send these key events after shortcut handling misses:

KeyEvent::new(KeyCode::Char('æ'), KeyModifiers::ALT)
KeyEvent::new(KeyCode::Char('ø'), KeyModifiers::ALT)
KeyEvent::new(KeyCode::Char('å'), KeyModifiers::ALT)

1. Observe that the textarea remains empty.

I verified this with a failing regression test before applying a local fix:

alt_norwegian_chars_insert_after_shortcuts_miss

Pre-fix result: empty buffer instead of æøå.

The feedback evidence below provides a PTY/ESC-prefix reproduction of this same event shape. A physical keyboard capture from the original Ghostty/tmux/macOS layout would still be useful, but is no longer required to show the Codex-side drop once ALT + Char(non-ASCII) is received.

What is the expected behavior?

After configured keymap shortcuts have first chance to handle the event, literal non-ASCII character input should be inserted into the composer.

Typing æøå should produce æøå in the composer, not an empty draft.

What is the actual behavior?

TextArea::input_with_keymap handles shortcuts first, then only inserts literal KeyCode::Char events when modifiers are exactly NONE or SHIFT:

if let KeyEvent {
    code: KeyCode::Char(c),
    modifiers: KeyModifiers::NONE | KeyModifiers::SHIFT,
    ..
} = event

So ALT + non-ASCII Char falls through after keymap handling misses and gets dropped.

Root-cause hypothesis

The final literal insertion guard is too broad for Alt/Option-modified text. It correctly avoids inserting ALT + ASCII because those are commonly terminal Meta shortcuts, but it also drops literal non-ASCII text where the produced character is already the intended input.

A narrow fix is to keep shortcut handling first, then insert ALT + non-ASCII characters while still rejecting ASCII control characters and preserving existing ALT + ASCII shortcut semantics.

This does not need to change the existing Windows AltGr path, which handles CTRL | ALT separately.

Local validation of a focused fix

I have a small local patch available if maintainers want it. It does the following:

• Adds a helper that inserts a text char when modifiers are empty/Shift, or exactly Alt with a non-ASCII char.
• Keeps all keymap shortcut handling ahead of literal insertion.
• Keeps ALT + ASCII as non-text so existing Meta/Alt shortcut behavior is preserved.
• Leaves Windows AltGr behavior unchanged.
• Adds textarea and composer regression tests for Norwegian æøå.

Validation run locally:

cargo check -p codex-tui
just fix -p codex-tui
cargo fmt --check
cargo test -p codex-tui alt_norwegian
RUST_MIN_STACK=8388608 cargo test -p codex-tui

The full codex-tui test run passed with RUST_MIN_STACK=8388608.

Feedback upload / live repro evidence

Uploaded feedback thread:

019e24ef-2c1a-7b72-8ee0-57b11bd0dc5a

This session was created specifically to capture the repro evidence for this issue. In that session:

1. I opened /keymap debug.
2. I sent an ESC-prefixed UTF-8 æ, which is the terminal byte shape for an Alt/Meta-modified character in this PTY test.
3. Codex reported:

``text
Detected: ⌥ + æ
Config key: unsupported - Only printable ASCII keys can be stored in tui.keymap.
Raw event: code=Char('æ'), modifiers=alt, kind=Press
Assigned actions:
none
``

1. Repeating the same path for ø and å showed the same raw event shape with modifiers=alt and no assigned action.
2. Back in the composer, ESC-prefixed æøå inserted nothing.
3. Plain æøå inserted normally in the same session.

Caveat: this is a PTY/ESC-prefix reproduction of the ALT + Char(non-ASCII) event shape, not a physical keyboard capture from the original Ghostty/tmux/macOS layout. It confirms that once Codex receives this event shape, /keymap debug sees no assigned action and the composer drops the characters.