Windows Desktop: pending follow-ups stall after completion; manual resume processes only the last of three

Environment

• Codex desktop app on Windows.
• Observed September 4, 2026.
• Exact desktop app version not captured.

What happened

Pending follow-up messages do not automatically start a new turn after the current assistant turn finishes.

In the reported three-message case, none of the three pending messages fired after completion. After manually resuming/steering, only the last message was processed. The assistant answered that message and ended its turn again, without processing the earlier two.

The pending cards expose a Steer control. This report describes the visible behavior; the internal distinction between queued and steered messages has not been verified.

Steps from the observed sequence

1. While the assistant is working, add several follow-up messages so they appear as pending cards.
2. Let the current assistant turn finish normally.
3. Observe that the pending messages remain and no next turn starts.
4. Manually resume/steer a pending message.
5. Observe that only the last of three messages is processed, followed by another completed assistant turn; the earlier messages are not processed.

Expected behavior

Pending follow-ups should dispatch as intended after completion, without requiring manual intervention. Multiple accepted messages should be handled in the intended order, or the UI should clearly indicate any replacement or rejection.

Actual behavior

The queue stalls at the turn boundary. Manual intervention processes only the last message in the reported three-message case. This report does not establish that the earlier messages were permanently deleted.

Evidence

The reporter captured screenshots showing pending cards both while the assistant was working and beneath a completed assistant response. A test message eventually arrived after manual intervention; that does not demonstrate automatic queue recovery. The three-message/last-only behavior is the reporter's observation, not an independently instrumented reproduction.

Related reports

• #34026 — Windows desktop follow-ups trapped in the queue after completion. A stale “thinking” state has not been confirmed in this case.
• #23100 — Queued messages do not dispatch until a task is selected. Focus dependence has not been tested here.

Root cause is unknown; no backend dispatch trace has been inspected.

No source files, tests, or entry points are named. Start by reproducing the Windows sequence with three pending follow-ups, then compare the behavior with related reports #34026 and #23100. Done means pending messages dispatch automatically after completion in the intended order, or the UI clearly indicates replacement or rejection.