For a while I let Claude Code make only small, timid changes, because a big one felt like a gamble: if it went sideways, I would be untangling a mess I did not fully understand. So I under-used the most capable tool in my stack out of fear of the cleanup. That is a bad trade, and checkpoints are what fixed it.
A checkpoint is a save point Claude Code creates as it works. If a change goes wrong, you rewind to the last good one in a single step, no git required. It is an undo button for the agent's work.
Small feature, big behavior change. Once undo is cheap, you stop being timid, and timid is exactly the wrong way to use an agent. Here is how it works and why it matters more than it sounds.
An undo button for the agent
As Claude Code works, it saves checkpoints of your state. If a change sideswipes something, you rewind to the last good point in one step, rather than reconstructing by hand what it touched. It is the safety net that makes an agent's autonomy comfortable instead of nerve-wracking.
Crucially, none of this requires you to know git, which is the whole point for a non-engineer. You do not need to understand version control to have a reliable undo; you just rewind.
The mental picture that helps: checkpoints are the game-save of agentic work. Every meaningful step, Claude quietly drops a save point, so a session is not a single fragile thread you are afraid to disturb, it is a sequence of states you can jump back to. You did not set them up and you do not manage them, they are just there when a change goes wrong and you want the last good version back.
TipBefore you let the agent attempt something ambitious, remember the floor is a checkpoint away. The downside of a bold run is a single rewind, not an afternoon of cleanup.
It makes experimenting cheap
Because you can always snap back, you can let the agent attempt the ambitious version: the big refactor of a workflow, the from-scratch rewrite of a scoring script, the change you would normally be too nervous to try. If it works, keep it. If it does not, rewind and you have lost minutes, not your afternoon.
Cheap undo changes how boldly you work, and bolder attempts are where the good outcomes live. My timid phase produced timid results; the moment I trusted the rewind, the agent started doing things I would never have risked by hand.
This changes how you work, not just how you recover. When undo is free and instant, you stop hedging. You try the aggressive rewrite of the scoring logic instead of the timid one, because if it is worse you are one command from where you started. The whole tax of being careful, the small voice that says do not touch that, it is working, goes quiet, and you move faster because failure got cheap.
TipWhen you catch yourself thinking 'I'd love to try X but it's risky', that is precisely the moment to try it. The checkpoint is the risk-remover.
How a rewind actually goes
When something goes sideways, you run /rewind and Claude Code shows you the recent save points with a short label for each: before it rewrote the sequence generator, before it edited the account file. You pick the one to return to, and the session snaps back to that state. No stashing, no branch juggling, no reconstructing what changed by hand.
The skill is picking the right point to return to. Rewind to just before the step that went wrong, not all the way to the start, so you keep the good work and only redo the part that broke. Then give the redo a clearer instruction than the first attempt, because now you know exactly where it went off the rails.
TipRewind to just before the bad step, not to the beginning. You keep everything good and replay only the part that broke, with a sharper instruction the second time.
Checkpoints are not a replacement for git
Checkpoints handle in-session recovery; git handles durable history and collaboration. They solve different problems. Use checkpoints to rewind a bad step mid-task, and still commit real milestones to git so your work is versioned, shareable, and safe beyond this session.
The clean mental split: checkpoints are your undo while you work, git is your record once you are done. Lean on both, and do not mistake one for the other, a checkpoint will not save your work to a repo, and git will not rewind a half-finished run as smoothly.
The clean way to hold both in your head: checkpoints are for the session, git is for the record. Checkpoints let you experiment fearlessly inside a run and then fade into the background once the run is done. Git is where a change becomes permanent, shareable, and part of the history your team relies on. One is a scratchpad you can rewind, the other is the ledger you commit to.
TipRewind with checkpoints during a task; commit with git at the end of a good one. Different tools, different moments, both worth the habit.
When to lean on each
In practice the two work as a rhythm. You experiment inside a session, rewinding freely as you try versions, until you land on the change that is actually right. That is checkpoints doing their job. Then you commit the keeper to git, so it survives beyond the session and everyone gets it. That is git doing its job.
The mistake is using one for the other's role. Do not treat checkpoints as your version control, they are neither durable nor shareable. And do not reach for a git reset for a quick in-session undo when a rewind is instant and does not touch your history. Right tool, right layer.
- Checkpoints: fearless experimentation within a session, instant undo, no setup.
- Git: durable, shareable history, the change that outlives the session.
- The flow: rewind to explore, commit to keep.
What a checkpoint captures, and what it does not
It helps to know the edges. A checkpoint captures the state of your work as Claude Code was changing it, the files it touched, the point in the session, so rewinding puts those back the way they were. What it is not is a snapshot of your entire machine or your connected systems. If Claude wrote a row to your CRM through a connector, a rewind of the session does not reach into the CRM and pull that row back out.
This is why the read-first, write-carefully habit still matters even with checkpoints in place. Rewind is a clean undo for work on your files inside the session, which covers most of what you do day to day. For actions that reach out and change an external system, the safety lives in the approval step before the write, not in the ability to rewind after it. Know which kind of change you are making, and lean on the right protection for each.
Where checkpoints trip people up
The main mistake is leaning on checkpoints as your only safety and skipping git, so a great session's work lives nowhere durable and a closed window loses it. Checkpoints are in-session; they are not a backup. Commit the milestones.
The subtler one is staying timid even with the net in place, out of old habit. If you are still only asking the agent for tiny, safe changes, you are paying for a safety net you refuse to use. The whole value is that you can now be bold.
The subtlest trap is leaning on checkpoints as if they were git, then being surprised when they do not persist the way a commit does. They are a session convenience, not a backup. The moment a change is worth keeping past today, commit it. Checkpoints make the exploration safe, only git makes the result permanent.
TipDo not let checkpoints replace git, and do not let old caution outlast the net. Commit milestones to git, and let the agent attempt the bold thing.
Why this matters for GTM work
If you are building a GTM workflow, a lead-scoring setup, an analysis routine, a set of skills, checkpoints let you iterate hard without fear of breaking the working version. Try the change, keep it or rewind, and move faster because the downside is covered. That is how a fragile one-off becomes a system you actually trust to evolve.
It pairs with plan mode from earlier: plan mode keeps a wrong action from happening in the first place, and checkpoints clean up the ones that slip through. Together they are the seatbelt and the airbag.
So the next time you are tempted to only ask the agent for the safe, small change, ask instead: what is the bold version, and what is stopping me now that undo is one step away?
TipUse checkpoints to iterate boldly on a GTM workflow, then commit the version that works to git. Bold experiments plus durable milestones is the whole loop.
How to set it up
Work normally, checkpoints happen for you
Claude Code saves a checkpoint as it works, so you do not have to think about it while things are going well. Hand it a bold change, an account list to restructure, a generator to rewrite, and let it run.
Rewind the moment it goes sideways
When a change makes things worse, do not try to talk it back to the old version. Rewind to the last good state and start that step over.
Keep git for what git is for
Checkpoints are a fast undo inside a session, not version control. When a change is good and you want it to last, commit it. Checkpoints make experimenting cheap; git makes the keeper permanent.
TipTry the risky version. That is the whole point of a clean undo: you stop being precious about changes you can reverse in one command.
Frequently asked questions
What are checkpoints in Claude Code?
Automatic save points the agent creates as it works, so you can rewind to a known-good state if a change goes wrong, in one step and without git. They are an undo button for the agent's work.
How do I rewind in Claude Code?
Use the rewind control to snap back to a previous checkpoint. Check the docs for the current key or command, since the interface evolves, but the idea is a one-step return to a good state.
Are checkpoints the same as git?
No. Checkpoints handle in-session recovery; git handles durable history and collaboration. Use checkpoints to undo a bad step mid-task, and still commit real milestones to git.
Do I need to know git to use checkpoints?
No. Checkpoints work without any git knowledge, which is what makes running an agent feel low-risk for non-engineers. You just rewind.
Are checkpoints a backup of my work?
No, they are in-session recovery, not a backup. For durable, shareable history, commit milestones to git. Relying on checkpoints alone means a closed session can lose good work.
Why do checkpoints matter for GTM work?
They let you iterate hard on a workflow, scoring, analysis, skills, without fear of breaking the working version. Try a change, keep it or rewind, and move faster because the downside is one step away.
How do checkpoints and plan mode work together?
Plan mode prevents a wrong action by making you approve the plan first; checkpoints clean up anything that still goes sideways. One is the seatbelt, the other the airbag; use both for real work.
Will checkpoints make me too reckless?
They are meant to make you appropriately bold, not careless. Keep plan mode on for live-system work and commit milestones to git; within that, let the agent attempt the ambitious change, because undo is cheap.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 22, 2026; verify time-sensitive details against the official docs above before relying on them.