How to Stop a Claude Code Task Midway (and Keep a Record)

To stop Claude Code in the middle of a turn, press Esc. It stops the current response or tool call so you can redirect, and Claude keeps the work done so far. Ctrl+C also interrupts a running operation. If you want the changes gone as well, press Esc twice on an empty prompt, or run /rewind, and restore the code, the conversation or both to an earlier prompt. Background work is stopped separately, from /tasks. Before you close the session, have Claude write where it got to on the card it was working on, so whoever picks it up next starts from a note rather than from scratch.

Esc, Ctrl+C, and when to use which

• Esc interrupts Claude mid-turn↗ (opens in a new tab). Files it already edited stay edited, and the conversation stays open, so your next message can be “stop, do it this way instead”. On a permission prompt, Esc declines the action.
• Ctrl+C interrupts a running operation too. If nothing is running, the first press clears the prompt and a second press exits Claude Code, so it is the key to reach for when you mean to leave.
• You do not always need to stop. Type a message and press Enter while Claude works, and Claude Code queues it rather than interrupting; Claude reads it at the next opportunity.

Most interruptions are corrections, not cancellations: Claude has gone down the wrong path and you want it back. For those, Esc and a one-line redirect is all it takes. The rest of this article is for the other kind, where the work stops for today.

Undoing what it did: rewind and checkpoints

Claude Code takes a checkpoint of your code before each prompt you send that starts a turn. Press Esc twice with the prompt empty, or run /rewind (also /checkpoint or /undo), and pick a point. The options are:

• Restore code and conversation — both go back to that point.
• Restore conversation — the conversation rewinds, your files stay as they are.
• Restore code — the files go back, the conversation stays.
• Summarize from here, or up to here — compress part of the conversation to free context, without changing any file.

Know the limits before you rely on it. Checkpoints track edits made with Claude’s file-editing tools only: a file changed by a Bash command, such as rm, mv or a code generator, is not restored. Edits made by most subagents are not restored either. Changes from other sessions are not captured. The documentation↗ (opens in a new tab) says it directly: checkpoints are for quick recovery inside a session, not a replacement for git. Commit before a risky step and you have an undo that works everywhere.

Stopping background work

Interrupting a turn and stopping background work are separate controls. Background shells, monitors and subagents are listed and stopped from /tasks; Ctrl+X Ctrl+K stops every background subagent in the session; a background session is stopped with claude stop <id>. The full picture, including what each list forgets, is in Claude Code background tasks.

Scheduled loops↗ (opens in a new tab) have their own stop. Esc stops a self-paced /loop while it waits for its next run. A loop on a fixed interval keeps going until you cancel it; ask Claude “what scheduled tasks do I have?” and then to cancel the one you want.

Stopping a headless run

A claude -p run started from a script or a scheduler has no Esc. The documentation↗ (opens in a new tab) distinguishes two signals. SIGINT ends the turn in progress. SIGTERM, which is what kill and most process supervisors send, makes Claude Code exit with code 143 and leaves that turn unfinished, with no result recorded for it; it also terminates any Bash command still running. When you resume such a session, the interrupted turn stays as it was unless you set CLAUDE_CODE_RESUME_INTERRUPTED_TURN=1.

Picking it up again

claude --continue          # the most recent conversation in this directory
claude --resume            # choose from the session picker
claude --resume bu-042     # a session you named (claude -n bu-042 when you started it)

Resuming↗ (opens in a new tab) brings back the conversation, and checkpoints are saved with it, so /rewind still works after a resume. What it cannot bring back is a different person or a different machine. A colleague picking up the work tomorrow, or you on a laptop, starts a fresh session with none of that context. That is the gap the handover note fills.

Leave a note on the card

When you stop for good, you have one useful moment: Claude still has the whole session in context. Press Esc to stop the work, then ask for the handover before you close anything.

Stop here. Comment on BUG-042 with:
- Stopped: why we stopped.
- Done: what is finished, with the commit if there is one.
- Not done: what is left, in order.
- State: the branch, and whether anything is uncommitted.
- Next step: the first thing the next session should do.
Then update the plan on BUG-042 with what you learnt, and move it to "next".

If you stopped Claude because it was heading the wrong way, put that in the note as well: “Stopped: it was rewriting the whole parser; the fix belongs in one function.” The next session reads the same card and would otherwise make the same wrong turn. One sentence about the dead end saves it the hour.

On a fenbs board this is two tool calls: fenbs_comment for the note, and fenbs_update_item to rewrite the plan and move the card. The two boxes on every card suit it well. The problem, written when the card was filed, stays as it was. The plan is the part that changes: it is meant to be rewritten whenever something is learnt, each version replacing the last, and History records each change and who made it. A session that stopped halfway has usually learnt the most useful thing about the job, so that is where it should go.

Which lane to leave it in

• Back to Next Up, if anyone else might pick it up. A card in In Progress reads as claimed, and a claim with nobody behind it blocks the next session from taking it.
• Stay in In Progress, only if you are resuming the same session yourself shortly. Say so in the comment: “Paused, resuming after lunch.”
• Back to To Do, if stopping revealed it is not ready: a missing decision, a question for someone else. Write the question in the comment.

The next session then starts the way every session should: read the card, read the last comment, carry on. It does not need your transcript and it does not need you. For the rhythm that makes that normal rather than a special effort, see a task-tracking workflow for Claude Code.