TUI: footer duplicates and “Working” status briefly disappears after interrupt + immediate resubmission #9811

Activity

1. dyxushuai

   added

   bugSomething isn't workingSomething isn't working

   on Jan 24, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displayIssues related to the terminal user interface: text input, menus and dialogs, and terminal display

   on Jan 24, 2026
3. etraut-openai commented on Feb 23, 2026

   

   etraut-openai

   on Feb 23, 2026

   Contributor

   More actions

   A proposed fix was submitted in this PR.
4. etraut-openai

   removed

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   on Feb 23, 2026
5. astral303 commented on Aug 21, 2026

   

   astral303

   on Aug 21, 2026

   More actions

   Fresh diagnosis against main at 536f86e: this is a cross-platform, terminal-independent pending-turn lifecycle bug. The original Linux/WezTerm environment is consistent with the shared code path involved.

   What happens

   1. The user interrupts an active turn and immediately submits another message. The TUI records that pending input should be sent after interruption through submit_pending_steers_after_interrupt.
   2. When the interrupted turn completes, on_interrupted_turn calls finalize_turn. This clears the active lifecycle and makes the bottom pane idle.
   3. The same interruption handler immediately resubmits the pending steer as a new turn.
   4. The submission path sets user_turn_pending_start = true, correctly recording that work has been submitted but has not emitted TurnStarted.
   5. update_task_running_state, however, derives the bottom-pane state only from an active turn, review mode, and MCP startup. It does not include the pending-start state.
   6. The TUI therefore has user_turn_pending_start set while bottom_pane.is_task_running() remains false.
   7. The gap ends only when TurnStarted invokes on_task_started.

   The status header may already say Working, but the status row is not rendered because the bottom pane considers itself idle.

   This also accounts for the footer artifact. The bottom pane temporarily loses the status row and contracts, moving the footer upward. When TurnStarted arrives, the row returns and the pane expands again. That height churn allows the previous and current footer rows to remain visible at different positions during the transition.

   Why the state is fragile

   Pending-start handling is split across several paths:

   • User turns set pending state in the message-submission path.
   • Compact, review, and user-shell commands set it in prepare_local_op_submission.
   • Review separately forces the bottom pane into its running state in submit_op.
   • prepare_local_op_submission runs before a direct channel send is known to have succeeded.
   • AppEventSender::send logs and swallows enqueue failures, so callers cannot distinguish accepted dispatch from rejection.
   • handle_turn_start_rejection finalizes shared turn state rather than releasing state owned specifically by the rejected attempt.

   Required invariant

   Once a start-producing operation is accepted by its local dispatch boundary, the TUI should remain task-running until either:

   • the corresponding TurnStarted consumes the pending reservation, or
   • that same dispatch attempt fails and rolls back its reservation.

   A rejected attempt must not clear an older accepted pending start.

   The task-running calculation should include pending-start state alongside active turns, review mode, and MCP startup. The same reservation lifecycle should cover UserTurn, Compact, Review, and RunUserShellCommand.

   Transport side effects should occur only after local acceptance:

   • For direct dispatch, reserve after submit_op successfully sends the command.
   • For app-event dispatch, have enqueueing report success.
   • Around the exact app-server start request, reserve before awaiting the request and roll back only that attempt's reservation if the request fails.
   • Apply interrupt cleanup only after its dispatch has been accepted in the AppEvent::CodexOp path.

   Suggested regression coverage

   A deterministic test does not need timing or a real terminal:

   • Submit a turn successfully but do not emit TurnStarted.
   • Assert that pending-start and bottom-pane task-running states are both true.
   • Render a snapshot containing one Working row and one footer.
   • Emit TurnStarted and verify that the bottom-pane height does not change.
   • Cover failed direct enqueue, app-server rejection, and a failed second attempt while an older reservation remains active.

   👍React with 👍1Reacted by John Xu
6. astral303

   added 6 commits that reference this issue on Aug 21, 2026

   Keep pending turn status visible before start

   ...

   aec7d4c

   Keep pending turn status visible before start

   ...

   72e8d3c

   Keep pending turn status visible before start

   ...

   af9d2d6

   Keep pending turn status visible before start

   ...

   7d241b6

   Keep pending turn status visible before start

   ...

   e134437

   Keep pending turn status visible before start

   ...

   440b68b
7. astral303

   added 2 commits that reference this issue on Sep 2, 2026

   Keep pending turn status visible before start

   ...

   dc9f2cb

   Keep pending turn status visible before start

   ...

   f877f65
8. astral303

   added a commit that references this issue on Sep 18, 2026

   Keep pending turn status visible before start

   ...

   94747ff
9. astral303

   added 4 commits that reference this issue on Oct 3, 2026

   Keep pending turn status visible before start

   ...

   741caa6

   Keep pending turn status visible before start

   ...

   9d68f96

   Keep pending turn status visible before start

   ...

   a154aa5

   Keep pending turn status visible before start

   ...

   ec7dcd6