Checkpoints and Rollbacks: Your Undo Button for Agent Work

Before a risky step, save a checkpoint. If an agent goes sideways, roll back cleanly instead of trying to patch your way out of a mess.

The basic habit

Before letting an agent make a large or risky change - a big refactor, a schema migration, anything touching many files - commit your current working state first. That commit is your checkpoint: a known-good point you can always get back to.

Why a clean rollback beats digging deeper

When an agent's change goes wrong, there's a pull to ask it to fix its own mistake - "that broke the tests, please fix it." Often that works. But sometimes each fix attempt adds more changes onto an already-confused state, making the diff harder to review. Rolling back and starting over with a more specific prompt is frequently faster than untangling a fix-on-a-fix spiral.

Two layers of checkpoints

Git commits are the durable layer - they survive as long as your repo does, and they're what you'd use for a real rollback. Some tools add a lighter, session-scoped layer: Claude Code's checkpointing snapshots file state before each prompt, letting you rewind within a session without a git commit for every step.

This is about mechanics, not strategy

Knowing when an agent is stuck and what to do about it strategically is a separate skill. Checkpoints and rollbacks are the mechanical tool that makes acting on that judgment cheap and safe: a clean point to return to is what makes abandoning an approach easy to execute.

EXAMPLE

$ git add -A && git commit -m "checkpoint: before auth refactor" # agent attempts refactor, tests fail # agent's fix attempt also fails $ git reset --hard HEAD~0 # back to the checkpoint commit # retry with a narrower, more specific prompt this time

🛠️ EXERCISE — TRY IT YOURSELF

Practice the checkpoint-before-risky-step habit on a real (or throwaway) repo.

Pick a repo you can safely experiment in, or create a throwaway one.
Before making a risky change, commit the current state with a clear checkpoint message.
Let an agent (or do it yourself, simulating an agent) attempt a moderately risky change, like a refactor across a few files.
If something breaks in a way that's hard to untangle, roll back with `git reset --hard` to your checkpoint instead of trying to patch forward.
Retry the change with a more specific prompt or plan, and compare how much cleaner the second attempt is.

✅ SELF-CHECK

☐ Did you commit a clear checkpoint before the risky step, with a message that actually describes the known-good state?
☐ If you rolled back, was the retry noticeably cleaner or more successful than trying to patch the broken state forward?

QUICK QUIZ

What's a key limitation of Claude Code's session checkpointing (the /rewind feature)?