fix(tui): queue steer Enter while final answer is still streaming to prevent dead state

[guidedways]

Summary

This fixes a TUI race (#11008) where pressing Enter with Steer enabled while the assistant is still streaming the final answer could put Codex into a non-recoverable “running” state (no further prompts handled until exiting and resuming).

Root Cause

In steer mode, InputResult::Submitted could submit immediately even while a final-answer stream was active. That immediate submission races with turn completion and can strand turn state.

Fix

When handling InputResult::Submitted, we now queue instead of immediate-submit if a final-answer stream is active (stream_controller.is_some()).

This keeps behavior deterministic:

• Prompt is preserved in the queue.
• on_task_complete() drains queued input through maybe_send_next_queued_input().
• Follow-up prompts continue in FIFO order after completion.

Why this resolves the “dead mode”

The problematic timing window is now converted into queueing, so prompts entered during final streaming are not lost and are processed after the current output ends. The model continues handling prompts normally without requiring /quit + resume.

Tests

Added regression coverage in tui/src/chatwidget/tests.rs:

• steer_enter_queues_while_final_answer_stream_is_active
• steer_enter_during_final_stream_preserves_follow_up_prompts_in_order

Both fail on old behavior and pass with this fix.

[guidedways]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[charley-oai]

FWIW I think we should always queue steer at least until the end of a currently-generating assistant message or in-progress toolcall (because it weirdly breaks up the UI)

[guidedways]

FWIW I think we should always queue steer at least until the end of a currently-generating assistant message or in-progress toolcall (because it weirdly breaks up the UI)

I believe that's what Claude Code does - if you enter a prompt while it's working, it'll queue your request till it's at least finished with its ongoing stream / message. That would fix this and the oddities reported with Steer in other issues #11062

[guidedways]

Some other issues may also be related to this PR: #11047

[etraut-openai]

Thanks for the contribution @guidedways!