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:

• Queued prompts behave like steer prompts; multiple queued prompts sent simultaneously #17285 queued prompts behave like steer prompts / multiple queued prompts sent simultaneously
• Sending a message near the end of a codex response does not queue it #13078 sending a message near the end of a response does not queue it
• TUI can get stuck with 'Messages to be submitted after next tool call' when sending during active output #15842 pending queued/steer input can get stuck
• TUI mixes queued follow-ups with removed steer state, causing "pending steer" leakage and delayed execution #13892 queued follow-ups mixed with pending steer state
• Allow control slash commands like /permission and /fork during an active run #15137 control slash commands during active runs