Implementation in Codex is controlled movement through slices, not one big jump to the finish. After the plan is approved, the agent is given the right to execute only the next logical slice of work, not everything at once. If the task is long, a milestone is more useful than a promise to "do everything": a small checkable step leaves you a point of control and prevents a large incomprehensible change from accumulating. The discipline of slices is what separates controlled implementation from a stream of edits you can only watch.
The right to interrupt a turn is a key tool, and it should not be neglected. If the agent has gone into an unrelated refactor, runs too broad a command or repeats the same failure without a new hypothesis - you stop it without waiting for the end. A new short instruction in the same chat is almost always cheaper than a late rollback of a large wrong change. Waiting for the agent to "figure it out itself" when it is clearly stuck means paying in tokens and time for what a single phrase could stop.
An interruption is framed concretely, not emotionally. A good stop sounds like this: stop, do not change files anymore, show the current git diff and explain which lines are needed for the original goal and which are not. Separately you ask to separate your earlier changes from the agent's. Such a wording does not just slow the agent down but returns it to the goal and makes visible what exactly is already done and how well it matches the task.
Viewing the diff has a subtlety to remember. /diff shows the git state, not guaranteed only the last turn's changes. That means it includes your earlier edits and everything accumulated in the working tree, not only what the agent did in the last step. If you need exactly the last-turn boundary, the desktop app has the Last turn mode for that. Confusing the git state with a single step's changes is a frequent source of misjudging what happened.
It helps to see the interruption wording as a ready tool once. Below is a short stop request that returns the agent to the goal and separates the sources of changes. You return to this form each time a turn goes the wrong way: it is cheaper than letting the agent finish a wrong path and then rolling it all back. Managing implementation is first of all the ability to stop in time, not only the ability to set the task precisely.
Narrow checks along the way matter more than one big run at the end. After each significant slice you run a targeted signal - the very test or command that proves the specific change - rather than the whole suite on every step. A broad run on every step is both slower and blurs the signal: it is unclear what exactly got fixed. A narrow check along the way and a full run at the end are the right order, the same as in manual work on a bug.
# An interruption that returns the agent to the goal
Stop. Do not change files anymore.
Show the current git diff and explain which lines are needed for the original goal.
Separate my earlier changes from yours.
# /diff shows the git state, not only the last turn's changesSteer, interrupt, inspect, verify are not separate techniques but one management cycle. You steer the agent to the next slice, interrupt if it has gone astray, inspect the diff separating yours from the agent's, and run a narrow check before expanding. On each turn you keep control over what exactly goes into the change. Implementation without this cycle turns into an accumulation of edits that is more expensive to take apart than to do anew.
The typical implementation failures are predictable. Giving the agent "do everything" instead of the next slice and getting a large incomprehensible change. Not interrupting a clearly stuck turn and paying for it with a rollback. Confusing the git state with the last turn's changes when viewing the diff. And running the whole suite on every step instead of a narrow signal. Lead the implementation by slices, interrupt in time, inspect the diff consciously and verify narrowly along the way - then the movement toward the result stays controllable.