Skip to content
Lesson 9 of 14

Checkpoints and Safe Experimentation

8 min read

The Fear of Breaking Things

Every developer has felt it: you want to try a risky refactor, experiment with a new architecture, or rip out a dependency, but the fear of breaking your working code holds you back. Version control helps, but managing experimental branches for every small idea adds friction. You end up playing it safe when you should be exploring.

Claude Code solves this with checkpoints -- lightweight snapshots of both your conversation and your code state that let you rewind to any previous point in seconds. With checkpoints, experimentation becomes free. Try anything, and if it does not work, roll back instantly.

What Are Checkpoints

A checkpoint is a snapshot that captures two things simultaneously: the state of your conversation with Claude and the state of your code on disk. Every time Claude uses a tool -- edits a file, runs a command, creates a new file -- a checkpoint is automatically created. This means you always have a complete timeline of every change Claude has made during your session.

You do not need to do anything to create these automatic checkpoints. They happen in the background every time Claude takes an action. However, you can also think of specific moments in your workflow as natural checkpoint boundaries: before starting a refactor, before switching approaches, before merging experimental code.

Viewing and Restoring Checkpoints

To see your checkpoint timeline, use the /rewind command (which is also aliased as /checkpoint):

/rewind

This shows you a timeline of all checkpoints in your current session, each labeled with a description of what action was taken. You can scroll through the timeline and select any point to restore.

When you select a checkpoint, Claude Code offers two restoration options:

Restore code only. This reverts your files on disk to the state they were in at that checkpoint, but keeps your current conversation intact. Use this when the conversation is still valuable and you just want to undo file changes.

Restore code and conversation. This reverts both your files and your conversation to that checkpoint. Use this when you want a complete do-over from a specific point, as if everything after that checkpoint never happened.

Try this: start a session, ask Claude to make a few changes to a file, then run /rewind to see the timeline. Select an earlier checkpoint and choose "Restore code only" to see your files revert while keeping the conversation.

The Experimentation Workflow

Checkpoints unlock a powerful workflow pattern:

1. Note your current state (checkpoint exists automatically)
2. Ask Claude to try a risky change
3. Evaluate the result
4. If good → keep it and continue
5. If bad → /rewind to the checkpoint before the change
6. Try a different approach from the same starting point

This is fundamentally different from working without checkpoints. Without them, you would need to mentally track what changed, manually undo edits, or manage Git stashes. With checkpoints, the entire undo operation is a single command.

Here is a concrete example. Suppose you want to refactor a React component from class-based to functional with hooks, but you are not sure about the best approach:

You: Refactor UserProfile from a class component to a functional component using hooks.
     Use useState for local state and useEffect for the API call.

Claude: [makes the changes — checkpoint created automatically]

You: Hmm, the useEffect dependency array looks wrong and the tests are failing.
     /rewind

[Timeline appears, you select the checkpoint before the refactor]

You: Let's try a different approach. Refactor UserProfile to a functional component,
     but use React Query instead of useEffect for the API call.

Claude: [makes different changes from the same clean starting point]

You just tried two completely different approaches from the same starting point, without any manual cleanup.

Branching Conversations

Sometimes you do not want to go back -- you want to go sideways. The /branch command (also aliased as /fork) creates a new session that starts from your current point but diverges from there:

/branch

This is like creating a Git branch but for your entire Claude Code session. The original session remains untouched, and you get a new session where you can explore a completely different direction. Both sessions share the same starting state but evolve independently.

Use branching when you want to:

  • Explore two competing approaches in parallel
  • Keep a working session stable while testing something experimental
  • Let a subagent investigate a problem without affecting your main workflow

Session Management

Claude Code provides several commands for managing your sessions across time:

Resume a previous session. If you close your terminal and want to pick up where you left off:

# Resume the most recent session
claude --resume

# Resume a specific named session
claude -r "refactor-auth"

Rename your current session to make it easier to find later:

/rename refactor-auth-module

List recent sessions to see what is available to resume:

/resume

This shows your recent sessions with their names, dates, and brief descriptions. You can select any session to jump back into it with full context.

Try this: name your current session with /rename, exit Claude Code, then resume it with claude --resume to verify the session is fully restored.

Combining Checkpoints With Subagents

In the previous lesson you learned about subagents -- focused AI agents that work in isolation. Combining subagents with checkpoints gives you maximum safety for experimental work:

You: Create a subagent in a worktree to experiment with replacing Express with Fastify.
     Test the migration and report back on performance differences.

Claude: [creates subagent in isolated worktree]
        [subagent makes changes, runs benchmarks]
        [subagent reports: Fastify is 2.3x faster but requires rewriting 4 middleware functions]

You: Interesting. Those results look promising. Apply the Fastify migration to the main codebase.

Claude: [applies changes — checkpoint created]

You: Actually, the middleware rewrite is too much work right now. /rewind

[Files revert to pre-migration state, but you keep the performance data from the subagent report]

The subagent did all the exploratory work in an isolated worktree, so your main codebase was never at risk. When you tried to apply the changes and changed your mind, a single /rewind put everything back. You kept the knowledge but discarded the code changes.

When Checkpoints Save You

Wrong refactor direction. You asked Claude to restructure a module and it took an approach that does not fit your architecture. Instead of manually undoing dozens of file changes, one /rewind puts you back to the pre-refactor state.

Broken tests after changes. Claude made a series of changes that seemed right but broke your test suite in unexpected ways. Restore the checkpoint, analyze what went wrong, and try again with better constraints.

Bad merge resolution. You asked Claude to resolve merge conflicts and it chose the wrong side on several conflicts. Rewind and give more specific instructions about which changes to keep.

Experimental dependency swap. You wanted to try replacing one library with another. The swap introduced subtle bugs. Rewind instantly instead of trying to debug every issue.

Cascading edits gone wrong. A change to one file triggered Claude to update ten other files, and some of those updates introduced errors. Rewind takes you back before the cascade started.

Practical Tips

Name your sessions. When you start working on something significant, run /rename with a descriptive name. Future you will appreciate being able to find the session quickly.

Use branching for A/B comparisons. When you want to compare two approaches, branch the session and try one approach in each. Compare results without any cleanup.

Combine with Git. Checkpoints operate independently from Git. Use checkpoints for rapid iteration within a session, and Git commits for the changes you want to keep permanently. Once you are happy with the result of an experiment, commit it.

Do not fear the rewind. The whole point of checkpoints is to remove the cost of experimentation. If you find yourself hesitating before asking Claude to try something, that is a signal that you should be using checkpoints more aggressively.

Review the timeline. Periodically check /rewind to see the timeline of changes in your session. It serves as a log of everything Claude did, which is useful for understanding a long session's history.

Checkpoints transform Claude Code from a tool you use cautiously into one you use boldly. Every experiment is reversible, every approach is testable, and the cost of trying something new is effectively zero.