Enter vs Tab in Codex CLI: Steering a Running Turn

While Codex CLI is executing, Enter and Tab both send what you have typed and do different things with it. Enter injects your message into the turn already in progress, changing what the agent is doing immediately. Tab queues the message until the current turn finishes, then delivers it as the next instruction. **This distinction does not exist in ordinary software, which is why it needs learning rather than guessing.** In an editor, nothing is happening while you type. With an agent, something is: files are being read, commands are running, edits are being made. Your message therefore has a meaningful relationship to time, and Enter and Tab are how you express which one you meant. Every other interface you have used collapses that choice because there was never a choice to make. **Use Enter when the agent needs to change course now.** It is heading for the wrong file. It has misread which environment you meant. It is about to run something you do not want run. It has misunderstood a requirement and every additional second of work compounds the error. In all of these the value of the message is entirely in its immediacy — delivered after the turn, it is a report on damage rather than a correction. **Use Tab when the work should happen afterwards.** Run the tests when you are done. Update the changelog. Then commit with this message. Queueing lets you keep typing while the agent works, which is genuinely useful on a long turn — you can line up the next three steps rather than sitting and watching, and each arrives cleanly once the previous finishes rather than fragmenting the current one. **Neither is destructive, but choosing wrong has an asymmetric cost.** A follow-up sent with Enter interrupts work that was going fine and may cause the agent to abandon a half-finished edit — untidy, recoverable. A correction sent with Tab arrives after the thing it was meant to prevent has already happened, which is the failure mode worth avoiding. When unsure, Enter is the safer default: interrupting unnecessarily costs a little time, and failing to interrupt can cost a working tree. **Ctrl+C is the third option, and it is different from both.** It cancels the current operation outright rather than steering it, returning control to the composer with the conversation intact. Reach for it when you do not want to redirect the work but to stop it — then look at /diff to see what actually landed before deciding what to ask for next. Be careful of the double tap: pressing Ctrl+C twice quits the session, and the reflexive double press carried over from killing terminal processes ends more than you intended. **Queueing more than one thing works.** Tab can be pressed repeatedly to line up several follow-ups while a long turn runs, and they are delivered in order as each turn completes. That is genuinely useful for a sequence you already know — implement, then test, then update the docs — because you can specify the whole chain once rather than waiting at the keyboard to issue each step. The caveat is that queued instructions were written before you saw the results of the work preceding them, so a queue longer than two or three steps tends to need revising anyway.