Edit Queued Message with `Option + Up` (⌥↑ edit) Not Working on MacOS terminal or iTerm.

[omar-hanafy]

What version of Codex is running?

codex-cli 0.42.0

Which model were you using?

gpt-5-codex

What platform is your computer?

MacOS 15.6.1 (24G90)

What steps can reproduce the bug?

• Wirte a prompt and press enter.
• Queue another prompt while in progress.
• Press ⌥↑ to edit queued prompt.

What is the expected behavior?

to be able to edit queued messages.

What do you see instead?

nothing happenning.

Additional information

is there anything wrong I might be doing? I usually use iTerm, but tried MacOS Terminal.app, cursor terminal, JetBrains, Warp, and Ghostty and all of them are not working.

[vuyelwadr]

same thing happens for me so I dug into why ⌥↑ (“Alt+Up edit”) is a no-op on macOS terminals where Option isn’t set to send Meta.

• Environment: macOS Sequoia 15.6 (24G84) on a 16‑inch MacBook Pro (Nov 2024, Apple M4 Pro, 48 GB RAM), Apple Terminal (default settings), codex-cli 0.42.0 (tui main).
• Repro: queue a couple of messages (start a long-running task, hit Enter twice), then press ⌥↑. The status panel shows ⌥↑ edit, but nothing happens.
• Raw key capture: running cat -vet and pressing ⌥↑ prints ^[[A, which is the same escape sequence produced by a plain Up arrow. With Option configured to send Meta, the sequence changes to ^[ [ 1 ; 3 A or ^[ [ 1 ; 9 A.
• Crossterm behaviour: because the terminal emits ^[[A, crossterm normalizes Up and Option+Up into a single event: KeyEvent { code: KeyCode::Up, modifiers: KeyModifiers::NONE, kind: KeyEventKind::Press, … }.
• Codex handling: the edit-queued-message branch in ChatWidget::handle_key_event (codex-rs/tui/src/chatwidget.rs:1023) checks modifiers.contains(KeyModifiers::ALT). With the modifier bit absent, the branch never runs. The chat composer
  already consumes bare KeyCode::Up for history navigation (codex-rs/tui/src/bottom_pane/chat_composer.rs:870+), so no edit action is triggered.