codex - 💡(How to fix) Fix Queued /clear drops later queued prompts

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

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.

Root Cause

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.

RAW_BUFFERClick to expand / collapse

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 /clear followed by /review so the review starts in a fresh context rather than paying for (or being biased by) the implementation transcript.
  • Queue /clear followed 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

  1. Start Codex CLI.
  2. Submit a prompt that keeps the current turn running long enough to queue follow-up input.
  3. While the turn is running, type /clear and press Tab to queue it.
  4. Type one or more additional prompts and press Tab to queue them after /clear.
  5. Wait for the active turn to complete.
  6. Observe that /clear runs and starts a fresh chat.
  7. Observe that the prompts queued after /clear are 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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING