Restore immediate send on 'enter' and queueing of message via 'tab'
Resolved 💬 5 comments Opened Mar 5, 2026 by vialogos Closed Mar 5, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
0.110.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.2 xhigh
What platform is your computer?
WSL2
What terminal emulator and version are you using (if applicable)?
VSCode terminal
What issue are you seeing?
Both on 'enter' and 'tab' steer messages are being queued, instead the previous behavior, where 'enter' sent the message directly and 'tab' would queue it.
This is cumbersome, I keep finding myself sending a message, seeing it get queued, having to hit CTLR + C to stop the turn and get my message back, then hit 'enter' agiain.
What steps can reproduce the bug?
Uploaded thread: 019cbe96-779d-7190-a368-ea755fa90bdd
What is the expected behavior?
Please restore the ability to send messages instantly via 'enter' and queue them via 'tab'.
Additional information
_No response_
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I'm not able to repro this in general. I did find a potential problem that might explain this if you were in plan mode specifically. Can you tell me whether you were using plan mode at the time you saw this?
Interesting. On 5.2 xhigh it happens for each message. On 5.4 xhigh, the ! steer message just appears briefly and then the message is sent. Here is a screenshot of me using first 'enter' and then 'tab' and both messages are queued.
<img width="450" height="326" alt="Image" src="https://github.com/user-attachments/assets/335873ba-6f37-42be-928f-2b9a11ab2cb4" />
Ah, I think this is an intended change in behavior. Queuing waits util the end of the turn. Steering injects the prompt at the end of current tool call. Previously, the UI showed the steering prompt injected immediately into the stream, which gave the wrong impression. It now waits until the current tool call is complete and then appears in the stream.
So I think this is working as intended.
alright, thanks for clarifying.