Interrupting and steering an AI agent: redirecting without losing the work
Interrupting and steering changes an AI agent's course while it works. What Claude Code, Codex and Cursor do, and how to design queues and recovery.
Why is it necessary to interrupt?
An agent can head in the wrong direction from the second step and keep going for minutes. If the person cannot stop it, their only options are to wait and undo afterwards, or cancel everything and start over. Both cost more than a timely correction.
Interrupting is also a sign of trust. Knowing that the agent can be stopped at any moment lets people delegate bigger tasks, because the cost of a mistake is bounded.
When to stop and when to wait?
Not every correction needs an interruption. Three situations are worth separating:
- The correction can wait. The agent is on track, but you spot a detail for the next step. Queue it: it arrives when the current step ends.
- The direction is wrong, but the damage is reversible. Interrupt, keep what was done and redirect. Here undo works as a safety net.
- The next step is irreversible. Interrupt before it happens, for example before sending, charging or deleting. In a good design this is almost automatic: the system pauses before that step and asks for approval, as part of human control.
To avoid mixing it up with another topic: here the person interrupts the agent. When the agent is the one interrupting the person, the topic is agent notifications.
How do the tools handle it today?
According to the official documentation consulted on October 30, 2026, all three tools separate “give a new instruction” from “stop”, but with different keys:
| Tool | Message while it works | Stop | Go back |
|---|---|---|---|
| Claude Code | Enter queues it; it reaches Claude when the tool calls in progress finish, within the same turn. Ctrl+Enter sends it now | Esc stops the response or tool call and keeps the work done; Ctrl+C interrupts the operation | /rewind or Esc twice: restores code, conversation or both |
| Codex (CLI) | Enter injects instructions into the current turn; Tab queues for the next turn | The commands page names no key for stopping the turn | Esc twice with an empty composer edits the previous message and forks the chat. It recommends Git checkpoints to revert changes |
| Cursor | Enter queues until the task finishes; Cmd+Enter sends instantly, to redirect | In its CLI, a second Enter interrupts the turn | Checkpoints: restoring reverts files, not messages |
Two notes. In Claude Code, /btw lets you ask a side question while the agent works without interrupting the main turn; it answers only from what is already in context. And Cursor also describes a follow-up that steers the agent without interrupting it: on cursor.com/agents, the “Send now” button (or Enter twice) delivers the message at the next tool call, and Tab queues it for later. In its CLI, Enter steers the active run at a safe point.
What should the interruption look like?
A well-designed interruption answers three questions at once:
- What was stopped? The step or tool in progress, named in plain words.
- What was kept? The changes already finished, listed.
- What happens now? The response or change in progress is discarded, or the new instruction goes to the next turn.
If the interface does not show what was kept, the person does not know whether they can trust the state. A list of three files already edited gives reassurance; a screen that says just “interrupted” raises doubts about everything else.
It also helps to separate queuing from replacing. Queuing adds an instruction for later; replacing discards what the agent was about to do. The tools above handle it with different keys (Enter and Tab in Codex, Enter and Cmd+Enter in Cursor), and the design should name the two actions separately, because they do not have the same effect.
How do you redirect without losing what was done?
Redirecting means giving a new instruction that starts from the current state, not from the beginning. For it to work:
- Use the real context. The instruction must refer to what the agent already did: “Keep the changes in
styles.css, but do not touchtheme.ts”. - Do not ask to start over unless you must. A “start again” erases useful work. Ask first which part is useful.
- Keep the thread. The conversation should show the correction next to the step that motivated it, so whoever reviews it understands why the course changed.
If a redirection is not enough, you need to go back. In Claude Code, rewind restores the code, the conversation or both, and can also summarize the conversation from a given point. Its limits matter: it only tracks changes made with the file editing tools. A file that only terminal commands changed is not tracked, and a subagent’s edits are normally not restored either. That is what Git is for; each case is covered in undoing what an agent did.
And to reduce the need to interrupt, there is plan mode: the agent researches and proposes a plan without editing your code, and edits stay blocked until you approve it. In Claude Code you turn it on with Shift+Tab or /plan.
Example
Illustrative example (a hypothetical design, not a specific tool): an agent is asked to update the texts of a sign-up form. Halfway through, it starts changing the error messages too, which the legal team has not yet approved.
The designer sees the change in the progress view and presses the stop button. The interface shows: “Stopped at ’error messages’. Kept: 4 label texts. Pending: nothing”. She writes: “Leave the error messages as they are, only change the labels”. The agent resumes from that point. If it had also reached a send step, the earlier pause would have prevented the irreversible step.
When should you NOT interrupt?
- When the agent is in a step that cannot be stopped halfway, such as a database migration, and there is no rollback plan. Interrupting there can leave something broken.
- When the person interrupts out of impatience, without a concrete correction. The agent loses the thread and nobody gains anything.
- When the interruption does not make clear what is kept. It is better to ask for a short confirmation than to stop without saying anything.
One more habit: record each interruption with the exact step where it happened, the instruction that followed and whether the agent applied it. If people keep interrupting for the same kind of error, the problem is in the agent’s plan, and it is better fixed with plan mode or clearer instructions than by stopping it all the time.
Common mistakes
- Interrupting without saying what was kept.
- Using the same action to queue and to discard.
- Asking to start over when only one part is wrong.
- Allowing the interruption of an irreversible step without a prior warning.
- Relying only on the tool’s undo and not having Git as a backup.
- Not showing the correction next to the step that motivated it.