Rollback in Claude Code: what a checkpoint is and what it will not bring back

The agent changes files for real, and sometimes it changes the wrong ones. Not because it's broken - it just read the task differently than you meant it. The good news: Claude Code takes the code snapshots on its own, without any input from you, and a failed attempt can be wound back in a couple of keystrokes.

The worse news: those snapshots have a boundary. Everything the agent types into files happens inside a guarded perimeter, and from there it can be brought back. Anything that happens outside that perimeter stays outside the fence: the snapshots never saw it and can't restore it. Better to know where that fence runs ahead of time, not at the moment something goes missing.

Below: how rollback works, where its fence runs, how long it lasts, and what covers whatever is left outside it.

What a checkpoint is

A checkpoint is a snapshot of the files the agent is about to edit, taken before it touches them. It's not a backup of the project and not an entry in version history - it's a working restore point inside the current session, meaning inside your conversation with the agent.

The main thing worth reading this section for: the snapshot is taken automatically before every message you send. You don't create it, don't configure it, and can't forget to trigger it. Send a message and the point already exists.

Your message
Code snapshot
Agent edits
Next message
New snapshot

Notice the order: snapshot first, edits after. That's exactly why going back to a point means "put the code back the way it was before this message". You're not picking a moment in time - you're picking one specific message of yours, after which everything gets undone.

One more clarification that makes the rest easier. A checkpoint is about code. Claude Code can rewind the conversation too, but that's a separate choice in the menu: code and conversation come back together or on their own, whichever you decide.

How to open the rollback menu

There are two ways in, and they do the same thing:

the /rewind command in the input line. It has the familiar aliases /undo and /checkpoint;

the Esc Esc keys, if the input line is empty.

If the menu didn't open

Most likely there was text in the input line. In that case the first Esc Esc just clears what you typed, and no menu appears. The text isn't lost: it goes into the input history, and the up arrow brings it back. Press Esc Esc again on the now-empty line, and the menu opens.

What opens is a list of your messages for this session. Not a list of files and not a timeline - actual messages, one for each thing you sent. You pick the one after which everything went sideways.

A special case: if you ran /clear earlier in this same running agent, recent versions add an extra row at the top of the list. It takes you back to the conversation that was going on before the clear. Clearing, as you can see, doesn't burn anything down.

What the menu offers

Pick a point and the agent asks what exactly to do with it. There are six options:

Menu item	What it does
`Restore code and conversation`	bring both the code and the conversation back to the chosen point
`Restore conversation`	bring back only the conversation, leave the files as they are
`Restore code`	bring back only the files, leave the conversation as it is
`Summarize from here`	fold the conversation from this point onward into a summary
`Summarize up to here`	fold the conversation up to this point, leaving the rest as is
`Never mind`	close the menu without doing anything

The first thing worth knowing about this table: the set of options changes. The two code items show up only when the agent actually changed files after the chosen point. If it didn't, there's nothing to bring back, and those rows simply aren't there. So if you see four items instead of six, it's the same program.

The two Summarize rows stand apart. They don't touch code - they work with the length of the conversation, folding a chunk of it into a short summary. They can't reach files on disk at all. Why this comes in handy is a separate, sizable topic; here it's enough to know it's not a rollback and it won't bring code back.

And a small thing that saves your nerves. After restoring a conversation, the text of that exact message returns to the input line. No need to recall what you wrote and retype it - tweak the wording and send it again.

What rollback brings back, and what it doesn't

Inside its own zone, rollback is reliable. It brings back two things: the file edits the agent made with its own editing tools, and the conversation history in this session.

Here's what stays outside the fence.

Changes made by terminal commands. The agent can do more than edit files - it can also run commands. If a file was deleted with rm, moved, or overwritten by a copy, the snapshot never saw it and can't bring it back.
Changes made outside the agent. Files the agent never touched during this session aren't affected by rollback at all: you edited them yourself in the editor, another program overwrote them, a second session was running alongside - all of that stays as is, and the menu can't restore or undo it. But if you hand-edited a file the agent also edited, restoring the code brings that whole file back to the snapshot - your edit included.
Subagent edits. If the agent handed part of the work to a helper subagent, that subagent's edits usually don't make it into the snapshots, and rollback won't bring them back. Undo them with git.
The rare case of symlinked files. Rollback skips these and says so plainly on a separate line. If you run into it, you'll figure it out - no need to prepare for it in advance.

Editing a file and running a terminal command are different things

From the outside the difference is barely visible. The agent reports just as calmly whether it edited a file or ran a command that deleted one. To you those are two similar-looking messages on screen; to rollback they're fundamentally different events - it'll undo the first and not the second.

That's why a request to run a command that deletes, moves, or overwrites something deserves a closer read than a request for an ordinary edit. That's the moment when the safety net behind you is already gone.

The short version: rollback watches what the agent types into files, not everything happening on your machine.

How long a rollback lasts

Snapshots don't pile up forever. Every point is listed in the menu, but file snapshots are kept only for the last hundred: plenty for a single conversation, but not unlimited, and old ones are gradually pushed out.

Points, though, aren't tied to an open terminal window. They're saved along with the session, so you can close the terminal, come back tomorrow, pick up the same conversation - and the rollback menu will work as if nothing happened.

It doesn't stick around forever either. sessions and their snapshots get cleared out automatically after about a month, though the period is configurable if you want it different.

Which leads to a simple conclusion: rollback is good on the horizon of a single task - minutes, hours, one conversation with the agent. It isn't meant to be a store of project history, and that's not a shortcoming - just a different job. What covers longer spans comes next.

Four safety nets, each with its own job

Undo, snapshot, folder copy, and version history aren't four names for the same thing. They cover different time spans and different kinds of loss.

Safety net	Who creates it	What it saves	How long it lasts	Where it's powerless
Undo in the editor	you, with a keystroke	your latest edits in the open file	not long, depends on the editor	edits across several files at once, and usually anything written to disk outside the editor
Checkpoint	Claude Code, on its own	the code before every message you send	as long as the session, a hundred points	terminal commands, changes made outside the agent
Folder copy	you, by hand	the whole project at the moment you copied it	until you delete it	doesn't show what changed, and clutters up the disk
Version history, git	you, with a deliberate action	project states one after another	as long as the project exists	whatever you didn't manage to record in it

Pick a safety net by coverage first, then by how long it lasts. If Claude changes ordinary files with its own editing tools and touches nothing outside the session, a checkpoint covers a five-minute experiment just fine. If the work involves terminal commands or external changes, a checkpoint alone isn't enough, no matter how short. And only among the safety nets that fit the coverage should you look at duration: several days of work or an important milestone call for something that doesn't depend on the conversation with the agent.

Worth being blunt about the folder copy. As a one-off measure before something risky, it works: you copy it, go break things, and if it doesn't pan out, restore it. As a system it doesn't hold up. A week later you've got several nearly identical folders, and nobody remembers which one is current.

The last row is the only one that both keeps states for a long time and shows exactly what changed between them. That's git, and it's a big topic on its own - its own tool, its own set of commands, and we're not getting into it here. It's enough to understand its place in the table: the longest horizon, and the only protection against what rollback doesn't cover.

How this changes the way you work

It's not really about the set of buttons. Here's what rollback means in practice:

the snapshot happens on its own, but it's essentially free only for experiments with ordinary files through Claude's own editing tools. If terminal commands or changes outside the session are going to happen, pick a different safety net first;
the agent doesn't roll back for you. It might say it went the wrong way, but opening the menu and choosing is on you;
asking for a terminal command is a different class of action than asking for a file edit. Rollback won't cover the first, but will cover the second. The difference only shows up in the wording of the request, which is exactly why it's worth reading;
the bigger the step, the less rollback helps. You can still bring it back, but figuring out from a single menu exactly what came back gets harder the more the agent managed to do. Small steps win here too;
rollback and version history aren't competing with each other. One covers minutes and hours inside a single conversation, the other covers days, weeks, and project milestones.

A minute before a big edit

Before a genuinely risky move, it's worth spending a minute to lock in the state with something that outlives the session. Right now what you've got on hand is a folder copy - as a one-off measure before a risk, it does the job honestly.

But the real tool for this is git. It keeps states for as long as you want, shows exactly what changed between them, and doesn't clutter the disk with nearly identical folders. We'll cover how to use it separately - it's a big topic and deserves its own conversation. The habit of pausing a minute before a risk will serve you well either way, with it and without it for now.

Let the rollback menu be for quick experiments: as a last resort it works noticeably worse than it does as an everyday tool.

The contents of the rollback menu and the retention periods depend on your version of Claude Code and its settings, so yours may differ from what's described here. The menu itself will always show what your version offers.