Files
claude-howto/08-checkpoints/checkpoint-examples.md
T
Luong NGUYEN 8f045173d1 docs: sync to Claude Code v2.1.212 (#154)
* docs: sync to Claude Code v2.1.212

Bumps tutorial coverage from the v2.1.206 baseline (2026-07-11 sync) to
v2.1.212, plus a repo-internal accuracy audit that surfaced defects
independent of the version delta.

Fixed:
- Dead `#` memory-shortcut removed from 02-memory/README.md (two places
  documented a discontinued quick-memory-add pattern as working, directly
  contradicting the file's own commands table)
- Auto mode opt-in -> opt-out on Bedrock/Vertex/Foundry (v2.1.207)
- `auto` permission mode mislabeled "Research Preview" across
  09-advanced-features/README.md, CATALOG.md, README.md, and the vi/ja/zh/uk
  translations (auto mode is GA, gated only by plan/model/provider)
- `/fork` / `/branch` history corrected: they were a single aliased command
  only from v2.1.77 to v2.1.161, not "renamed" as previously stated
- `effort` frontmatter enum in 04-subagents/README.md completed with `xhigh`
- Bundled-skills count reconciled in CATALOG.md (9 -> 10)
- INDEX.md Skills section count and Feature Coverage Matrix Total column
  fully recomputed and reconciled (Skills: 22, Plugins: 39)
- Stale 2.1.160 footer cluster (5 files) bumped to 2.1.212
- QUICK_REFERENCE.md fully resynced (was 52 versions behind)
- 02-memory/README.md's Memory Hierarchy section rewritten: replaced a
  fabricated 8-tier strict-precedence model with the verified structure
  (CLAUDE.md files are concatenated into context, not overridden; 4 real
  location tiers; rules and auto memory are separate mechanisms)
- 02-memory/README.md's Memory Architecture diagram no longer conflates
  claude.ai's 24h synthesis cycle with Claude Code's continuous auto memory
- Import recursion depth corrected (was documented as 5, actually 4 hops)

Added:
- Subagent output scanning (v2.1.210) documented in 04-subagents/README.md
- Session-wide spawn caps (v2.1.212): WebSearch and subagent limits
- MCP long-running-tool auto-backgrounding (v2.1.212) in 05-mcp/README.md
- `claude auto-mode reset` and `/resume` picker (v2.1.212)
- Screen reader mode (v2.1.208): --ax-screen-reader / CLAUDE_AX_SCREEN_READER
- Task tool `mode` parameter deprecation note (v2.1.212)

Known gaps (deferred, not fixed this pass):
- 03-skills/blog-draft/ vs 03-skills/.claude/skills/blog-draft/: confirmed
  the latter is gitignored local testing scratch, not a repo duplicate

* fix(INDEX): correct Skills row arithmetic and stale changelog notes

INDEX.md's Skills header/matrix shipped as 22 (5+9+8) despite the PR's
own CHANGELOG claiming it was fixed to 21 — three independent counts
(file-type breakdown, filesystem listing, changelog intent) agree on
21; the Docs column was off by one. Also removes two stale CHANGELOG
"Known gaps" entries this same PR already resolved (memory hierarchy
rewrite, blog-draft gitignore confirmation) and adds the missing
Fixed-section bullet documenting the memory hierarchy rewrite.
2026-07-18 22:21:21 +07:00

9.2 KiB

Checkpoint Examples

Real-world examples of using checkpoints effectively in Claude Code.

Note: Checkpoints are created automatically with every user prompt. You do not need to manually save them. To rewind, press Esc twice (Esc+Esc) or use /rewind to open the checkpoint browser.

Example 1: Database Migration

Scenario

You need to migrate from MySQL to PostgreSQL but want to explore both a direct migration and a gradual dual-write approach.

Workflow

User: Let's implement a direct migration from MySQL to PostgreSQL
      [Checkpoint A created automatically]

Claude: I'll implement the direct migration...
[Changes database driver, updates queries, modifies schema]

User: Run the tests
      [Checkpoint B created automatically]

Claude: Running tests...
❌ 15 tests failing - connection pool issues

User: This approach has issues. Let's try the dual-write pattern instead.
[User presses Esc+Esc, selects Checkpoint A, chooses "Restore code and conversation"]

User: Now implement a dual-write pattern where we write to both databases

Claude: I'll implement dual-write migration...
[Implements dual-write layer, gradual migration strategy]

User: Run the tests

Claude: Running tests...
✅ All tests passing

User: The dual-write approach is clearly safer. Let's commit this.

Example 2: Performance Optimization

Scenario

Multiple performance optimization strategies to try.

Workflow

User: Let's optimize the API response time. Current: 450ms
      [Checkpoint "Baseline" created automatically]

Claude: I'll add database query caching...
[Implements Redis caching]

User: Run performance tests

Claude: Results: 280ms average response time (38% improvement)

User: Let me try a different approach.
[User presses Esc+Esc, selects "Baseline" checkpoint, chooses "Restore code and conversation"]

User: Try database query optimization instead

Claude: I'll optimize database queries...
[Adds indexes, optimizes N+1 queries]

User: Run performance tests

Claude: Results: 180ms average response time (60% improvement)

User: Let me also try a third approach.
[User presses Esc+Esc, selects "Baseline" checkpoint, chooses "Restore code and conversation"]

User: Try response compression and CDN

Claude: I'll add compression and CDN...
[Implements gzip, sets up CDN]

User: Run performance tests

Claude: Results: 320ms average response time (29% improvement)

User: Query optimization was the best. Let me go back and combine it with caching.
[User presses Esc+Esc, selects the checkpoint after query optimization, chooses "Restore code and conversation"]

User: Now add Redis caching on top of these optimized queries

Claude: [Adds Redis caching on top of optimized queries]

User: Run performance tests

Claude: Results: 95ms average response time (79% improvement) 🎉

User: Perfect! This is the winner. Let's commit this.

Example 3: UI/UX Iteration

Scenario

Trying different layouts for a dashboard.

Workflow

User: Let's redesign the dashboard with a sidebar layout
      [Checkpoint "Start" created automatically]

Claude: [Implements sidebar layout]

User: Show me a screenshot

Claude: [Shows screenshot]

User: The sidebar feels cramped. Let's try a top navigation instead.
[User presses Esc+Esc, selects "Start" checkpoint, chooses "Restore code and conversation"]

User: Try a top navigation layout

Claude: [Implements top navigation]

User: Show me a screenshot

Claude: [Shows screenshot]

User: Better, but let's try a card-based grid layout
[User presses Esc+Esc, selects "Start" checkpoint, chooses "Restore code and conversation"]

User: Try a card-based grid layout

Claude: [Implements card grid]

User: Show me a screenshot

Claude: [Shows screenshot]

User: This is great! But can we combine the top nav with the card grid?
[User presses Esc+Esc, selects the checkpoint after the card grid, chooses "Restore code and conversation"]

User: Add top navigation to the card grid layout

Claude: [Adds top navigation to card grid]

User: Perfect! This is the final design.

Example 4: Debugging Session

Scenario

Hunting down a tricky bug with multiple hypotheses.

Workflow

User: There's a memory leak in the application
      [Checkpoint "Before debugging" created automatically]

Claude: Let me investigate...
[Analyzes code]

User: I think it's in the event listeners. Let's fix those.

Claude: [Fixes event listener cleanup]

User: Run memory profiler

Claude: Still leaking memory - event listeners weren't the issue

User: Let me go back and try a different hypothesis.
[User presses Esc+Esc, selects "Before debugging" checkpoint, chooses "Restore code and conversation"]

User: Maybe it's the database connections?

Claude: [Implements connection pooling fixes]

User: Run memory profiler

Claude: Still leaking - not the connections either

User: Let me go back and try another angle.
[User presses Esc+Esc, selects "Before debugging" checkpoint, chooses "Restore code and conversation"]

User: Let's check for circular references

Claude: [Finds and fixes circular references in cache]

User: Run memory profiler

Claude: ✅ Memory leak fixed! The circular references in the caching layer were the culprit.

User: Excellent! Let's commit this fix.

Example 5: API Design Evolution

Scenario

Designing a REST API with multiple iterations.

Workflow

User: Create a REST API for our blog platform
      [Checkpoint "Before API design" created automatically]

Claude: [Creates basic CRUD API]

User: This is too simple. Let's add pagination and filtering

Claude: [Adds pagination and filtering]

User: We need better resource relationships

Claude: [Implements HATEOAS links]

User: Actually, let's try GraphQL instead of REST
[User presses Esc+Esc, selects "Before API design" checkpoint, chooses "Restore code and conversation"]

User: Implement a GraphQL API for our blog platform instead

Claude: [Implements GraphQL API]

User: I think REST is better for our use case.
[User presses Esc+Esc, selects the checkpoint after HATEOAS, chooses "Restore code and conversation"]

User: Let's finalize the REST approach.

Example 6: Configuration Management

Scenario

Testing different configuration approaches.

Workflow

User: Move configuration to environment variables
      [Checkpoint "Original config" created automatically]

Claude: [Implements env var configuration]

User: Test in development

Claude: Works locally but deployment issues in production

User: Let me try a different approach.
[User presses Esc+Esc, selects "Original config" checkpoint, chooses "Restore code and conversation"]

User: Try a config file approach with validation

Claude: [Implements YAML config with JSON schema validation]

User: Test in development

Claude: ✅ Works well, good validation errors

User: Can we also support env vars for sensitive values?

Claude: [Adds env var override for secrets]

User: Test deployment

Claude: ✅ All environments working correctly

User: Perfect! This is production-ready.

Example 7: Test Strategy

Scenario

Implementing comprehensive testing.

Workflow

User: Add unit tests for the auth module
      [Checkpoint created automatically]

Claude: [Adds Jest unit tests]

User: Run tests

Claude: 45 tests passing, 78% coverage

User: Add integration tests too

Claude: [Adds integration tests]

User: Run tests

Claude: 89 tests passing, 92% coverage, but tests are slow (3 minutes)

User: The tests are too slow. Let's optimize.

Claude: [Optimizes test setup, adds parallel execution]

User: Run tests

Claude: 89 tests passing, 92% coverage, 35 seconds ✅

User: Great! Now add E2E tests for critical paths

Claude: [Adds Playwright E2E tests]

User: Run all tests

Claude: 112 tests passing, 94% coverage, 2 minutes

User: Perfect balance of coverage and speed!

Example 8: Using Summarize from Checkpoint

Scenario

After a long debugging session, you want to condense the conversation while preserving context.

Workflow

User: [After 20+ messages of debugging and exploration]

[User presses Esc+Esc, selects an early checkpoint, chooses "Summarize from here"]
[Optionally provides instructions: "Focus on what we tried and what worked"]

Claude: [Generates a summary of the conversation from that point forward]
[Original messages are preserved in the transcript]
[The summary replaces the visible conversation, reducing context window usage]

User: Now let's continue with the approach that worked.

Key Takeaways

  1. Checkpoints are automatic: Every user prompt creates a checkpoint -- no manual saving needed
  2. Use Esc+Esc or /rewind: These are the two ways to access the checkpoint browser
  3. Choose the right restore option: Restore code, conversation, both, or summarize depending on your needs
  4. Don't fear experimentation: Checkpoints make it safe to try radical changes
  5. Combine with git: Use checkpoints for exploration, git for finalized work
  6. Summarize long sessions: Use "Summarize from here" to keep conversations manageable

Last Updated: July 18, 2026 Claude Code Version: 2.1.212 Sources: