Queued /clear drops later queued prompts
What issue are you seeing?
The TUI lets users queue follow-up prompts with Tab while a task is running, and it queues slash-led prompts without validating them until dequeue time.
If /clear is queued and additional prompts are queued after it, the queued /clear runs once the active turn finishes and starts a fresh chat — but the prompts queued after it are silently dropped. They do not run in the fresh chat and are no longer visible or recoverable in the queue.
Root cause: when the queued /clear is dequeued it requests a UI clear and stops draining the queue. Starting the fresh session replaces the chat widget, and the remaining queued prompts go with the old widget. Nothing carries them over to the new session.
Why this is useful
Being able to queue /clear as a boundary saves context and usage tokens: let the current task finish, then start the next queued prompt in a fresh chat so Codex does not spend tokens carrying the entire prior transcript into the next task.
Concrete examples:
- Queue
/clearfollowed by/reviewso the review starts in a fresh context rather than paying for (or being biased by) the implementation transcript. - Queue
/clearfollowed by a cleanup or validation prompt after a long implementation turn, avoiding a large context window for work that does not need the previous conversation. - Preserve queued work the UI has already accepted and displayed.
Steps to reproduce
- Start Codex CLI.
- Submit a prompt that keeps the current turn running long enough to queue follow-up input.
- While the turn is running, type
/clearand press Tab to queue it. - Type one or more additional prompts and press Tab to queue them after
/clear. - Wait for the active turn to complete.
- Observe that
/clearruns and starts a fresh chat. - Observe that the prompts queued after
/clearare dropped instead of running in the fresh chat.
Expected behavior
Queued prompts after /clear must not be silently dropped. /clear should create the fresh chat and then replay the remaining queued prompts, in order, in that new chat — the first one starts immediately and the rest stay queued behind it, exactly as if they had been queued in the fresh session.
/clear should keep working as a queue boundary even when more than one is queued: each queued /clear opens its own fresh chat for the prompts that follow it. For example, queuing /clear, A, /clear, B should run A in one fresh chat and B in a second fresh chat, rather than collapsing the two boundaries or dropping B.
The live composer draft and any pending steers do not need to be preserved across the clear (the draft stays recallable from history, and steers only apply to the turn that just ended); only the queued follow-up prompts must survive.
If preserving the queued prompts is not the desired product behavior, Codex should instead reject queueing after a queued /clear, or warn that /clear is a queue boundary and later queued input will be discarded.
Related
- #19151 tracks the same class of behavior for queued
/new.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗