›_ Codex Issues
Codex Issues / #19151

Allow queued prompts after queued /new

Resolved 💬 6 comments Opened Apr 23, 2026 by JoeRoddy Closed May 31, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.123.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Darwin 25.4.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

WarpTerminal 0.2026.04.15.08.45.02

What issue are you seeing?

Codex CLI lets users queue prompts with Tab while the current turn is running. Queued prompts normally run after the current turn completes.

If /new is queued, and additional prompts are queued after /new, the queued /new runs and creates a new chat, but the remaining queued prompts after /new are dropped. They do not run in the newly created chat and do not remain visible/recoverable in the queue.

This loses user-entered prompts without an explicit warning.

What steps can reproduce the bug?

  1. Start Codex CLI.
  2. Submit a prompt that keeps the current turn running long enough to queue follow-up input.
  3. While the current turn is running, type /new and press Tab to queue it.
  4. Type one or more additional prompts and press Tab to queue them after /new.
  5. Wait for the active turn to complete.
  6. Observe that /new runs and creates a new chat.
  7. Observe that the prompts queued after /new are dropped instead of running after the new chat is created.

What is the expected behavior?

Queued prompts after /new should not be silently dropped.

Expected behavior should be one of:

  • /new creates the new chat, then subsequent queued prompts run in that new chat in order.
  • Or Codex rejects/warns when queuing prompts after a queued /new, making clear that /new is a queue boundary.
  • Or Codex preserves the remaining queued prompts and lets the user decide what to do with them.

In all cases, user-entered queued prompts should remain recoverable unless explicitly discarded.

Additional information

I searched open issues and did not find an exact duplicate. Related but not identical issues include:

  • #17285 queued prompts behave like steer prompts / multiple queued prompts sent simultaneously
  • #13078 sending a message near the end of a response does not queue it
  • #15842 pending queued/steer input can get stuck
  • #13892 queued follow-ups mixed with pending steer state
  • #15137 control slash commands during active runs

View original on GitHub ↗

6 Comments

etraut-openai contributor · 2 months ago

This is currently by design, not a bug. I'll change this to a feature request.

JoeRoddy · 2 months ago

@etraut-openai the messages successfully queue in the ui. If it's by design, then an error should be surfaced if a user attempts to queue a new message while /new is already queue'd.

<img width="940" height="385" alt="Image" src="https://github.com/user-attachments/assets/bd6b5ded-0fe4-4408-966d-5ed4177dfd2b" />

etraut-openai contributor · 2 months ago

Queued messages are not parsed until they are dequeued, so /new isn't recognized as a new command until after it its dequeued.

Keep in mind that /new creates an entirely new conversation. I'm not convinced that retaining queued commands that are part of one conversation should be replayed in the context of a new conversation.

JoeRoddy · 2 months ago

so i almost had an "oh wow!" eureka moment with this product, when i queue'd /new and experimented with queueing something else after (assuming it would emit an error). when it didnt error i had an immediate revelation and got excited with how powerful it could be, because i thought i could compose long chains of actions, while simultaneously retaining full control over when to reset the context window:

eg:

long running dev command
/new
long running cleanup command
/new
long running code review command

this would let me compose long sequences of work, and then step away from my computer for 30 minutes while it operated. when /new resolved, and nothing happened with the command that the cli let me queue, it effectively felt like a broken promise.

JoeRoddy · 2 months ago

<img width="600" height="99" alt="Image" src="https://github.com/user-attachments/assets/07d3ed44-03c7-45e1-866b-e32191ed6157" />

@etraut-openai i still find myself wanting to do this constantly. i want to fully clear the context window before the reviewer starts, to not bias the review.

i can queue a review after /compact but then the reviewer will know its reviewing its own changes.

as a user it just feels like an arbitrary restriction on my ability to compose the queue.

etraut-openai contributor · 1 month ago

This feature request hasn't received enough upvotes, so I'm closing.