Codex is halfway through a refactor. Tests are running. You look at the diff and find a database migration growing even though the brief said the schema was off-limits.
The obvious response is to stop the whole thing and start again. Often that is unnecessary. The work may still be useful and only the direction is wrong. Or perhaps the current turn is fine and you have simply remembered something which should happen afterwards.
Both cases look like “send another message” in the interface. They change very different parts of the work.
Figure 1 | A working model for the different states you may need to control. It is not an official OpenAI taxonomy.
Start by deciding which piece of work you are trying to change
Codex App Server uses a Thread as durable conversation state around a piece of work. A Thread can be resumed, forked and archived while retaining its event history.[3]
A Turn is one round inside that Thread. One user input can lead to many file reads, commands, tool calls, edits, test runs, failures and retries before the Turn finishes.[2]
So when a task drifts, I first ask whether the current Turn is still worth keeping.
If the payment-service refactor is sound but Codex has started inventing a schema migration, I would Steer it:
Keep the existing schema. Do not create a migration. Limit the change to the service layer and adapter.
Mid-turn steering puts the correction back into the active work instead of throwing away the context already gathered.[1][7]
If the refactor is fine and I have merely remembered “write the migration note afterwards”, I would Queue that request. It belongs next, not in the middle of the current task.[1]
If the REST design should stay intact while an event-driven alternative gets a proper investigation, I would Fork. The original history remains available and the alternative can grow without turning the main thread into a pile of contradictory steering messages.[1]
A small side question such as “why was this library deprecated?” can stay in Side and leave the main task alone.[1][8]
If the Turn was built on a premise I already know is wrong and the diff is filling with work that will be discarded, I would Interrupt it. Codex exposes a path for interrupting an in-flight Turn, and the official repository records the Esc / turn/interrupt behaviour as well.[9][10]
One boundary is worth keeping in mind: interrupting the Turn is not proof that every background terminal process has been terminated. Background processes may have their own lifecycle.
Figure 2 | Do not reach for Stop merely because the agent is still running. Use the smallest control that changes the state you actually care about.
Plan is useful when the unknown is bigger than the edit
“Login sometimes fails” is usually not a good implementation boundary.
The fault may sit in refresh-token handling, session state, a proxy, a backend dependency or the client. If nobody knows which layer is failing, editing immediately can produce an impressive-looking diff built on a guess.
Plan is useful because it lets Codex remove the uncertainty the environment can answer first: repository structure, configuration, tests, schema and relevant documentation. What remains should be the decisions which actually need judgement.[1][4]
Work spanning several services, migrations or compatibility constraints often benefits from that pass. The same is true when there are explicit do-not-touch areas or several implementation paths still competing.
A bounded bug with a known file and a focused test is different. I would normally fix it. Adding a planning ritual does not make a small task more mature.
Plan also does not change authority. Historical Plan/Code discussions in the Codex repository show mode instructions affecting how the agent collaborates, while OpenAI describes sandboxing and approval policy as separate execution controls.[5][6]
Plan helps avoid doing the wrong thing too early. Sandbox and Approval decide what execution is allowed to do even when the agent wants to do it.
The place you control Codex and the place Codex runs can be different
Mobile makes this easy to see.
I can use a phone to check a Thread, answer a clarification, handle an approval or steer the work while the repository, files, credentials, permissions and local setup remain on the machine actually running Codex.[11]
Changing the screen in my hand does not move the code into the phone.
Web works the same way. The browser can be the place where I delegate the task while a provisioned cloud environment keeps the worker and workspace alive. Closing the tab does not, by itself, mean the worker stopped.[3]
For ordinary decisions, I find three questions enough:
| Question | Typical examples |
|---|---|
| Where am I controlling it? | CLI, IDE, Desktop, Web, Mobile |
| Where is the work actually running? | Local, Worktree, Cloud, remote host / devbox |
| What can this job use? | Shell, Browser, Computer Use, MCP, Skills, Plugins |
There is no need to memorise those rows as a product taxonomy. They simply stop an interface change, an execution move and a new tool from being described as the same thing.
CLI suits a terminal-first loop.[2] If I am still reading code heavily, selecting ranges and editing alongside the agent, the IDE’s open files and selections are useful context.[12]
Desktop becomes more valuable when several Threads are alive at once. The Codex app puts projects, threads, review, worktrees and parallel work in one place.[13] One thread may be fixing a bug, another refactoring, and a third chasing a failing test. At that point I would rather see the workstreams than maintain a wall of terminal sessions.
Web is comfortable for delegation. Mobile is useful once I have left the workstation but still need to answer a question, inspect progress, approve an action or pull the work back on course.[3][11][12]
A task can start in CLI, be supervised later in Desktop, and be checked from Mobile without moving its execution environment. That is normal.
Surface switch, Handoff and Fork move different things
Moving from Desktop to Mobile while looking at the same host changes the control surface. The files and runtime can stay exactly where they were.[11]
Handoff is closer to moving the work into another execution context. The Codex app has used the term for flows such as moving a Thread between Local and Worktree.[1]
Fork does not move execution. It changes conversation history: the original path remains, and another path grows from it.[1]
The shorthand I use is simple: a surface switch moves me; Handoff moves where the work continues; Fork splits the history.
They can happen near each other. When something goes wrong, it still matters which state actually moved.
Authority comes last, and stays separate
Plan, Steer, Queue, Fork and Side change how the work proceeds. Sandbox and Approval constrain what the execution is allowed to do. OpenAI’s own account of Codex safety treats sandboxing and approval policy as separate controls.[6]
Browser and Computer Use add capabilities. Remote changes how a person can reach the work. Hooks can attach logic to lifecycle events. Those surfaces will keep evolving, but the everyday decision is less dramatic.
A small bug may be one CLI Turn from start to finish. Add Plan, Fork, Handoff or remote supervision when scope, risk, waiting time or parallel work makes them useful.
More controls do not make the workflow better by themselves. When Codex drifts, identify which state actually needs to change and use the smallest control that changes it.
References
- OpenAI, ChatGPT & Codex changelog. https://developers.openai.com/codex/changelog
- OpenAI, Michael Bolin, Unrolling the Codex agent loop, 23 January 2026. https://openai.com/index/unrolling-the-codex-agent-loop/
- OpenAI, Celia Chen, Unlocking the Codex harness: how we built the App Server, 4 February 2026. https://openai.com/index/unlocking-the-codex-harness/
- OpenAI Codex GitHub, Plan Mode issue #2101, historical rollout evidence. https://github.com/openai/codex/issues/2101
- OpenAI Codex GitHub, Mode switch Plan -> Code still behaves like Plan issue #10185, historical collaboration-mode evidence. https://github.com/openai/codex/issues/10185
- OpenAI, Running Codex safely at OpenAI, 8 May 2026. https://openai.com/index/running-codex-safely/
- OpenAI, Introducing GPT-5.3-Codex, 5 February 2026. https://openai.com/index/introducing-gpt-5-3-codex/
- OpenAI Codex GitHub, Docs: /side works in Codex App but is missing from App commands page issue #24817, 27 May 2026. https://github.com/openai/codex/issues/24817
- OpenAI Codex GitHub, Clarify or fire Stop hook when a turn is interrupted with Esc issue #22858, 15 May 2026. https://github.com/openai/codex/issues/22858
- OpenAI Codex GitHub, Error: turn/interrupt failed in TUI when submitting steer instruction during review issue #22815, 15 May 2026. https://github.com/openai/codex/issues/22815
- OpenAI, Work with Codex from anywhere, 14 May 2026. https://openai.com/index/work-with-codex-from-anywhere/
- OpenAI, Introducing upgrades to Codex, 15 September 2025. https://openai.com/index/introducing-upgrades-to-codex/
- OpenAI, Introducing the Codex app, 2 February 2026. https://openai.com/index/introducing-the-codex-app/