TUI can get stuck with 'Messages to be submitted after next tool call' when sending during active output

What version of Codex CLI is running?

codex-cli 0.116.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

GPT-5.4

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

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

tmux 3.4

What issue are you seeing?

When the model is still outputting and I press Enter to send a new message immediately (not queueing a later draft manually, but trying to submit right away), the TUI can get stuck showing:

Messages to be submitted after next tool call (press esc to interrupt and send immediately)

In the broken case:

• the current output stops
• no further tool call happens
• the pending message is never sent automatically
• the footer/status remains in the pending-steer state indefinitely

So from the user's perspective, the message is accepted into the UI, but it never actually becomes the next turn.

This looks different from normal queued follow-up behavior. The problem is specifically the "send immediately while output is still in progress" path getting stuck after the active output finishes.

What steps can reproduce the bug?

1. Start a normal turn in the TUI so the model is actively streaming output.
2. While output is still in progress, type a follow-up message.
3. Press Enter before the current turn has fully finalized.
4. Observe that the TUI shows:

Messages to be submitted after next tool call (press esc to interrupt and send immediately)

1. Wait for the current output to stop naturally.

Observed result:

• the message stays in the pending-steer preview
• it is not submitted automatically after output stops
• the TUI appears stuck in this state until manually interrupted or otherwise recovered

What is the expected behavior?

One of these should happen reliably:

• if the current turn is still steerable, the pending message should be consumed and become the next model request automatically
• if the current turn is already ending and can no longer accept steer input safely, the message should be converted into a normal queued follow-up and sent as the next turn after completion
• in either case, the TUI should not remain indefinitely stuck on Messages to be submitted after next tool call

Additional information

This appears to be a turn-finalization race between TUI pending-steer state and core pending-input handling.

From local code inspection, the rough failure mode seems to be:

• TUI classifies the submission as a pending steer because agent_turn_running is still true
• core accepts the input into active-turn pending_input
• if the input lands in the narrow window after the final run_turn() iteration has effectively ended but before teardown is fully complete, it can miss the path that would start the next follow-up request
• TUI then continues waiting for the pending steer to be cleared by the usual completion path, but that follow-up never starts, so the preview remains stuck

Relevant code paths I found while investigating:

• codex-rs/tui/src/chatwidget.rs
• codex-rs/core/src/codex.rs
• codex-rs/core/src/tasks/regular.rs
• codex-rs/core/src/tasks/mod.rs

Potentially related issues:

• #9811
• #1244

There is also an existing ignored/flaky core test that seems closely related to this class of behavior:

• core/tests/suite/pending_input.rs -> injected_user_input_triggers_follow_up_request_with_deltas