Lesson 31: Checkpointing and Forking

Day 31 of 50 · ~7 min read · Phase 4: Integrations

The Opening Question

You're working with Claude Code on a feature. You've had Claude make several edits, run tests, iterate. You're 20 minutes into the session and you've made progress.

Then you realize: "Wait, maybe there's a better approach."

But here's the problem: Claude's already made changes. You could ask Claude to revert them all manually. Or you could ask Claude to start over. Both are annoying.

Here's the question: What if you could instantly rewind to a previous point in time and try a different approach — while preserving the version you already built?

And more fundamentally: How do you fearlessly explore alternatives without losing your work?

Discovery

Question 1: What is a checkpoint?

A checkpoint is an automatic snapshot of your code at a specific moment in time.

Claude Code creates checkpoints automatically before significant changes. So if you're iterating with Claude and you realize you want to go back, you can just rewind.

Here's what a checkpoint looks like:

Initial state → [Edit 1] → Checkpoint 1 → [Edit 2] → [Edit 3] → Checkpoint 2 → Uh-oh, wrong direction!
                                                                               ↑ Rewind here

You can instantly jump back to Checkpoint 2, Checkpoint 1, or the initial state.

Pause and think: How much of your actual workflow involves "I wish I could go back 10 minutes"?

The answer is: a lot. This is why git exists. This is why you save frequently. Checkpointing automates that safety net for conversations with Claude.

Question 2: How do you actually rewind?

Claude Code gives you a simple way to rewind. You just press Escape twice (or use a command like /rewind).

When you rewind:

1. Claude stops whatever it's doing
2. Your codebase reverts to a previous checkpoint
3. You're back where you started (with the option to branch off)

For example:

Me: Add error handling to the payment module

Claude: [Makes changes, runs tests, iterates]
Claude: All tests pass! Here's what I did...

Me: Actually, wait. Let me think about this differently. 
[Presses Escape twice to rewind]

Me: Let's try a different approach. Use a try-catch wrapper instead...

Claude: [Starts fresh from the checkpoint, tries the new approach]

You didn't have to manually undo changes. You didn't have to start over from scratch. You just rewound.

Question 3: What about forking a conversation?

Rewinding is one thing. But what if you want to keep both versions?

That's where forking comes in. A fork is a branch of your conversation where you try a different approach while keeping the original intact.

Initial state
    ↓
Approach A (continue here with Claude)
    ↓
    ├─→ Try approach A.1 (fork here, explore alternative)
    │       ↓
    │       [Make edits]
    │       [Tests fail]
    │       [Abandon this fork]
    │
    └─→ Continue with original approach A (merge the results)

When you fork a conversation, you're saying: "I want to try something different. But keep my original work safe."

You can:

1. Fork at any point in the conversation
2. Try the new approach
3. If it doesn't work, discard the fork and go back to the original
4. If it works better, keep the fork and discard the original

Question 4: When do you fork versus rewind?

Use rewinding when:

• You realize you're going the wrong direction
• You want to abandon the last few changes and try again
• You don't need to keep the old approach

Use forking when:

• You want to compare two different approaches
• You're not sure which way is better yet
• You want to keep both options available until you decide

Here's a real example:

Me: I want to add caching to the API responses

Claude: [Approach 1: Redis caching]
[Makes changes, runs tests, works]

Me: Hmm, but I'm also wondering if in-memory caching would be simpler for our use case.
[Fork the conversation]

Claude: [Approach 2: In-memory caching on the fork]
[Makes changes, runs tests, also works]

Me: Actually, Approach 2 is cleaner. Let me discard Approach 1 and keep this fork.

With forking, you don't have to choose blindly. You can actually see both approaches working.

The Insight

Checkpointing and forking are about fearless exploration. Claude Code automatically saves your progress at key moments, so you can rewind to try a different direction without fear of losing work. Forking lets you explore multiple approaches in parallel and compare them before committing. Together, they transform conversations with Claude from "one path forward" into "explore the space freely."

The mental model: Checkpointing and forking are like git for conversations. Just as git lets you create branches and revert commits without fear, Claude Code lets you rewind and fork conversations. Your exploration is safe. Your work is preserved.

Try It

Let's practice checkpointing and forking.

1. Start a Claude Code session:

   claude
   

2. Ask Claude to make a few changes:

   Create a new utility function in utils.py called `format_currency` that takes a number 
   and returns a formatted currency string.
   

3. Watch Claude work. It'll make edits, maybe run tests.

4. Create a checkpoint. Claude may do this automatically, but you can also explicitly checkpoint by marking a moment.

5. Ask Claude to continue:

   Now add support for different currency symbols (USD, EUR, GBP)
   

6. Rewind. Realize you wanted a different approach. Press Escape twice or use /rewind.

7. Try a different direction:

   Actually, instead of hardcoding currency symbols, let me accept them as parameters.
   

8. Now fork a conversation. Start a new session and say:

   --fork-session
   

   (Or use your Claude Code client's fork feature)

9. In the forked version, try the original approach while the main branch tries the alternative.

10. Compare both versions. Which approach is cleaner? Better tested? Easier to extend?

Key Concepts Introduced

Bridge to Lesson 32

You've now learned how to navigate conversations with Claude fearlessly, rewinding when you want to change direction and forking when you want to explore alternatives.

Tomorrow is a big day: the first lab of Phase 4. You'll put everything together — testing, hooks, debugging, extended thinking, checkpointing — all in a guided project to build a real feature using Claude Code.

Tomorrow's mission: Build a feature using test-driven development, with hooks running tests automatically, all while using Claude as your pair programmer.

← Back to Curriculum · Lesson 32 →