Checkpoints: A Safety Net You Can Rewind Anytime

📚 Series Navigation: The previous article 36 Slash Commands smoothed out that long list of commands starting with /, and /rewind also made an appearance there. This article specifically unpacks it—a Checkpoint is a "pre-edit snapshot" that Claude Code automatically saves for you, letting you rewind back to a certain state at any time. How it automatically records, how to rewind, what can and cannot be rolled back, and how exactly it divides labor with git, explained thoroughly in one article.

They say checkpoints are your "regret medicine", and with them as a safety net you can let go and let Claude go all out—to be honest, if you treat them like git, you will eventually crash.

Imagine someone who just started using Claude Code, heard about this /rewind thing, and completely relaxed, letting Claude change more than ten files in one breath, running several rm and mv commands to clean up directories in between. By the third round, they realize the direction is wrong, calmly type /rewind wanting to jump back—only to find that while the code partly reverted, not a single one of those files deleted by rm came back. They were immediately dumbfounded: "Didn't they say it can be undone?"

It can be undone, but what is undone are those files Claude modified using editing tools, not the traces left on your disk by the bash commands it ran, and certainly not permanent history like git. A checkpoint is a "session-level local undo", strong in speed, strong in automation, strong in that even the conversation can be rewound together; but it has distinct boundaries, and it cannot handle things that cross the line.

This article does two things: First, it explains this set of "automatic saving + rewinding" checkpoints until you can operate them with your eyes closed; second, it nails down its boundaries—what can be recovered, what cannot, when you should rely on it, and when you must use git. Only by clarifying the boundaries is it a true safety net, otherwise it's a safety net that will deceive you.

After reading this article, you will get:

• A one-sentence explanation of what a checkpoint is, and when it automatically saves for you (no manual operation needed).
• The two opening methods: /rewind and "double-click Esc on an empty input box", and what the options in the rewind menu do.
• A "can rollback vs cannot recover" comparison table—code and conversation can be reverted, bash side effects and external states cannot.
• A clear division of labor between checkpoints and git: when to use which, and why one cannot replace the other.
• A hands-on practice you can run along with that provides expected outputs: personally create a "wrong edit" and then rewind back.

---

01 What is a Checkpoint: It Secretly Takes a Snapshot Before Every Time You Speak

Let's give the conclusion first: A checkpoint is a "pre-edit snapshot" of your code that Claude Code automatically takes for you—every time you send a prompt, it takes one; if you want to revert to one later, a simple /rewind jumps you back.

You've already seen it briefly in Article 07, knowing that if a mistake is made, /rewind can catch it. This article goes deeper. Think back to your rhythm when working with Claude: you issue an instruction → it goes through the "think → do → see" cycle, modifying a few files → you look at the results and issue the next instruction (this cycle was covered in Article 03). What a checkpoint does is, before every instruction lands, it first takes a picture of the code state at that time to keep as a record.

Analogy: A DVR's timeline playback. The set-top box in your house that can record playback records programs continuously, but it drops a "chapter marker" everywhere a program switches. If you want to rewatch a certain segment, you don't have to fast forward from the beginning, you just drag to that chapter marker and click to jump over. Checkpoints have this flavor: Every prompt you send is a chapter marker on the timeline; /rewind is dragging the whole tape back to a certain marker to start over. The only difference is—DVR playback is just "watching", while checkpoint playback truly reverts the code and conversation back to that moment, letting you record again with a different approach.

The official positioning of it is like this:

As you work with Claude, checkpointing automatically captures the state of your code before each edit. This safety net lets you confidently execute ambitious, large-scale tasks knowing you can always revert to a prior code state.

Pay attention to that word—automatically. This is the most satisfying point about checkpoints, and its biggest experiential difference from git: You don't have to do anything. With git, you have to remember to git commit, if you forget to commit, it's not saved; with checkpoints, Claude silently takes snapshots in the background, you never have to worry "did I save it?".

The official documentation lists four of the most typical uses, and I'll match each with a real scenario you will encounter:

• Exploring alternative approaches: A implementation is done but unsatisfactory, revert to the starting point and try approach B, the starting point is intact, no fear of "breaking it by trying and not being able to go back".
• Recovering from errors: It finished modifying a file, but the tests failed instead, and you are too lazy to manually pick it back line by line—revert to the previous checkpoint, clean.
• Iterating on features: Let Claude rewrite an entire module for practice, after it's done you find it's worse than before—jump back to before the rewrite, as if nothing happened, dare to let go and try.
• Freeing up context space: Chatting back and forth while debugging became a long string, you want to keep the setup instructions at the beginning but discard the trial and error in the middle—this is where "summarize" comes in (covered in Section 03).

Notice the common thread among these four categories: They are all "I want to boldly charge forward, but I'm afraid I won't be able to come back if I break it"—checkpoints exist to eliminate this "fear".

💡 One-sentence summary: Checkpoints are the code snapshots Claude automatically takes before every edit, adding a "chapter marker" every time you send a prompt, and later a /rewind can rewind the code and conversation back to that moment—fully automatic, no manual saving needed.

---

02 When Exactly Does it Save, Where Does it Save, How Long Does it Stay

Since checkpoints are "automatic", you must know the rules of its automation—at what timing does it take a snapshot, where are the snapshots kept, and for how long. The official documentation writes these three points very clearly, I'll match them for you one by one.

Trigger timing: One checkpoint for every prompt

The rule is just one sentence: Every time you send a prompt, Claude Code creates a new checkpoint. Official original words:

A new checkpoint is created for every user prompt.

So the density of the "chapter markers" on the timeline follows the rhythm of your speech—if you issue ten instructions, there are ten points you can jump back to. This also explains why what is listed in the rewind menu later are exactly every prompt you sent in this session: each prompt is both a "start of action" and a "save point you can revert to".

Drawing this rhythm out, you will instantly understand how checkpoints "drop points along the way" of your conversation:

What this diagram shows is: every time you send a prompt, Claude drops a checkpoint (blue node) before acting; when it gets to prompt 3 and you realize it's messed up, a /rewind can follow that dashed line and jump back to checkpoint 1, undoing the changes of prompts 2 and 3 along with the conversation—this is exactly the essence of its ability to "rewind at any time".

Where it's saved: Hidden in your ~/.claude

Snapshots aren't just remembered out of thin air in memory; they land on the disk. The official documentation (claude-directory.md) specifically names it:

file-history/<session>/ — Pre-edit snapshots of files changed by Claude, used for checkpoint restoration.

That is to say, the "pre-edit snapshots" of each session are stored in this ~/.claude/file-history/<session>/ directory. You don't need to touch it, but knowing it's there has two benefits: one is understanding that checkpoints are actually backed by physical files, not magic; the other is if one day you're curious how much space Claude Code is taking on your machine, you know this part belongs to it.

Cross-session: Close and reopen, the saves are still there

Since it landed on the disk, it has a very practical feature—checkpoints persist across sessions. Official original words:

Checkpoints persist across sessions, so you can access them in resumed conversations.

What does this mean? You work halfway today and Ctrl+D to exit, tomorrow you use claude --resume (or --continue) to continue this session, and that string of previous checkpoints is still there, you can still /rewind back to some point yesterday. It's easy to mistakenly think that /rewind only works in the currently open window and resets to zero when closed—but actually, continuing a session from three days ago, those old prompts in the rewind menu can amazingly still be jumped to, they truly exist on the disk and follow the session. So for this "saving" matter, it can even withstand the hurdle of "shutting down and restarting", governed only by that cleanupPeriodDays deadline.

How long it stays: Default 30 days, adjustable

Checkpoints won't stay forever, the official set an automatic cleanup:

Automatically cleaned up after 30 days (configurable).

Which switch specifically is this "configurable"? It's cleanupPeriodDays in settings.json (Article 31 specifically covered user-level / project-level configuration of settings.json). The official settings.md says it defaults to 30 days for cleaning up records of inactive sessions, minimum 1 day, setting to 0 will be directly rejected—this value simultaneously governs the retention of checkpoint snapshots. Advice for beginners: Don't touch it. The default value is enough, and the progress you truly need to save long-term should be handed over to git anyway (detailed in Section 05 below), instead of counting on checkpoints to save it for you for half a year.

One day flipping through ~/.claude wanting to clear space and noticing this file-history directory, you'll finally realize: So this is where the pile of /rewind "regret medicine" every day has been silently catching things. Usually, you don't even perceive its existence at all, which is precisely the benefit of being "automatic".

Bringing these three points together into a table:

Dimension	Rule	What you need to do
When to save	Every time a prompt is sent, automatically builds a checkpoint	Do nothing, just speak normally
Where it's saved	~/.claude/file-history/<session>/	Don't touch, just know where it is
Cross-session?	Persists across sessions, usable after resuming conversation	Can be found even if closed and reopened
How long it stays	Default cleans up according to cleanupPeriodDays	Don't change; hand long-term progress to git

💡 One-sentence summary: Checkpoints save one for every prompt, landing in ~/.claude/file-history/, do not get lost across sessions, and default to cleaning up according to cleanupPeriodDays; you just need to know this set of rules, no operation needed—it's fully automatic.

---

03 How to Rewind: /rewind, Double-click Esc, and That Rewind Menu

Now that you know it silently saves in the background, let's learn how to call it out to use. There are only two entry points, memorize them: the /rewind command, or double-clicking Esc on an empty input box.

Two Entry Points

First, type the slash command in the session:

/rewind

Second, much faster—when the input box is empty, press Esc twice in a row:

(Input box is empty, press Esc Esc consecutively)

Both of these will pop up the same rewind menu. Official original words:

Run /rewind, or press Esc twice while the prompt input is empty, to open the rewind menu.

There is a pitfall buried since Article 14 here that must be hammered on the blackboard again:

If the prompt input contains text, double Esc will clear it rather than opening the menu. Cleared text is saved to your input history, so you can recall it by pressing Up after you're done with the rewind menu.

Translating into human words: When there is text in the input box, double-clicking Esc is "clearing this text", not opening the menu. If you want to rewind, first make sure the input box is empty. Beginners easily stumble here—typing half a sentence and wanting to go back, frantically pressing Esc, the text is gone and the menu didn't appear, looking bewildered. Remember: empty it first, then Esc Esc. If you are unsure, just obediently type /rewind, it doesn't care if the input box is empty or not.

What are you choosing in the Rewind Menu

When the menu pops up, it lists every prompt you sent in this session—which is that string of "chapter markers" on the timeline. You first pick a "point you want to revert to", and then choose "how to revert". This second step is the key, because there's more than one way to revert.

For the several operations given officially, I'll translate them one by one:

Menu Option	What it does	When to select
Restore code and conversation	Revert code and conversation together to that point	Want to scrap the whole round and start over: pretend those few sentences never happened
Restore conversation	Only revert the conversation, leave code as is	Want to keep the resulting code, but the chat skewed and you want to reorganize the conversation
Restore code	Only revert code changes, keep conversation	Code was broken and needs rollback, but still want to use the previous discussion
Summarize from here	Compress this and subsequent conversation into a summary	Chop off a side-tracked discussion branch, keeping the complete details of earlier parts
Summarize up to here	Compress the conversation before this into a summary	Squash lengthy preliminary setup, keeping the complete details of recent work
Cancel	Do nothing, return to list	Clicked wrong / just looking

For the two options in the middle that "only revert half", beginners often murmur "why split them to revert". Giving a real scenario for each will make it clear:

• Only "Restore code": You chatted back and forth with Claude for five rounds and finally settled on a plan, it made the changes, but the code crashed when run. You want to revert this pile of rotten code, but the ins and outs of those five rounds of discussion cannot be lost (explaining it all over again is too tiring)—at this time select "Restore code", the code goes back to before the changes, the conversation remains untouched, letting it rewrite with its original understanding.
• Only "Restore conversation": Conversely, you are quite satisfied with the code it produced and want to keep it, but this round of conversation got skewed by a few irrelevant questions you asked, getting messier the more you chat—select "Restore conversation", revert the conversation to the point before it skewed, leave the code in its current state, and you reorganize your thoughts to continue directing.

Do you see it—"Restore code / Restore conversation" are two knobs given to you to split and fine-tune, you don't have to revert "code and conversation" together. Among these, the most commonly used is actually "Restore code": the plan is fine, Claude just wrote it poorly, reverting the code and letting it rewrite is much less trouble than describing the requirements from scratch.

And what is easiest to confuse here, is that "Restore" and "Summarize" are fundamentally two different things. Don't think they do similar jobs just because they are in the same menu:

• Restore = truly reverting the state backwards: reverting code, conversation, or both to the selected point. This is "turning back time".
• Summarize = not touching files on the disk, just compressing one side of the conversation into an AI-generated summary to free up context space. This is "tidying the desk", not rewinding.

The official documentation explains this difference very bluntly:

Restore options revert state: they undo code changes, conversation history, or both. Summarize options compress a portion of the conversation into an AI-generated summary without altering files on disk.

Did you notice—"Summarize" is actually the precision version of /compact from Article 19. /compact compresses the entire conversation at once, while "Summarize from here / up to here" lets you pick a point and compress only one side of it: chop off stray branches with "Summarize from here", squash lengthy openings with "Summarize up to here". The official docs also compare them like this:

This is similar to /compact, but more targeted: instead of summarizing the entire conversation, you choose which side of the selected message to compress.

There is also a considerate detail: After selecting "Restore conversation" or "Summarize from here", the original prompt of the selected message will automatically fill back into the input box, you can modify it and resend—equivalent to "reverting to before saying this sentence, giving you a chance to rephrase." (Selecting "Summarize up to here" is different: it leaves you at the end of the conversation with an empty input box.)

Two small issues where beginners often get stuck

"The rewind menu pops up empty / has few points to choose from"—Normal. The menu lists the prompts you sent in this session, if you just opened shop and only sent one or two sentences, naturally there are few points to revert to. Checkpoints are "accumulated as you work", the more you send, the more points you can revert to.

"My hand slipped, I chose the wrong point and reverted too far, can I revert back?"—Don't panic just yet. The checkpoint itself is left on the disk across sessions (as said in Section 02), and won't disappear just because you /rewind once; those points in the menu are usually still there, you can open the rewind menu again and pick a point further back to adjust. However, the specific behavior of the menu might vary across versions, the most solid is still that old rule: before doing high-risk work, git commit first—that "permanent history" of git is always your last line of defense when you have nowhere left to retreat (detailed in the next section).

💡 One-sentence summary: There are only two entries for rewinding—/rewind or double-click Esc on an empty input box; in the menu, first pick "which point to revert to" then pick "how to revert", "Restore" truly reverts state / "Summarize" only compresses context, never confuse these two; don't panic if you revert too far, the true fallback is an early git commit.

---

04 Where are the Boundaries: What Can be Rolled Back, What Absolutely Cannot

This section is the vital point of the whole article, and the pitfall mentioned at the beginning is exactly here. Checkpoints are not an omnipotent undo key, they only keep an eye on one type of thing—the direct changes Claude makes using "file editing tools". Anything crossing this line, they absolutely cannot handle.

The analogy is still that DVR: it only recorded the "picture on the screen", not "what actually happened in your living room". You rewind, the picture goes back, but the coffee you knocked over in the living room just now, the letter you sent out, the file you deleted—things that have already happened in the real world, rewinding cannot bring back. Checkpoints take "snapshots of code files", they can manage the back-and-forth of file contents; they cannot manage the real commotion Claude's running commands kicked up in your system.

Specifically what can be brought back and what cannot, the official documentation lists very clearly in the "Limitations" section, and I've organized it into a comparison table—you must memorize this table:

Category	Can it revert	Why
File contents modified by Claude using editing tools	✅ Can revert	This is exactly what checkpoints track
Conversation history	✅ Can revert	Rewind menu can restore conversation separately / together
Files modified by Claude running bash commands (rm / mv / cp…)	❌ Cannot recover	Bash changes are not tracked
Files not edited in the current session	❌ Cannot recover	Only tracks files touched in this session
Files you manually modified outside of Claude Code	❌ Cannot recover	External changes are not captured
Things modified by other concurrent sessions	❌ Cannot recover	Same as above, unless they happened to touch the same file
Side effects already sent out (sending requests, deleting DB rows, pushing...)	❌ Cannot recover	External state, checkpoints completely cannot reach

The ones you should engrave into your brain the most are the first two "Cannot recover"s, which the official documentation specifically pulled out to emphasize. First look at the bash command one:

Checkpointing does not track files modified by bash commands. For example, if Claude Code runs rm file.txt, mv old.txt new.txt, cp source.txt dest.txt... these file modifications cannot be undone via rewinds. Only direct file edits made via Claude's file editing tools are tracked.

This is the pitfall at the beginning—Claude deleted the file using rm, not using editing tools, so /rewind cannot save it. Highlight: "Claude modifying files" falls into two types—modifying with its editing tools (tracked, reversible), and modifying with bash commands (untracked, unrecoverable). In your eyes, both are "it touched my files", but in the eyes of a checkpoint, they are worlds apart.

How to distinguish on the spot which route it is taking? Look at the tool call name it prints out while working (Article 14 mentioned Ctrl+O can expand detailed transcripts):

• Seeing editing tools like Edit, Write, MultiEdit moving—tracked by checkpoint, /rewind can save if it goes wrong.
• Seeing Bash running commands like rm, mv, cp, > (redirect overwrite)—not tracked, /rewind cannot save if it goes wrong.

These two are written crystal clear in the transcript. Form the habit of "glancing at the tool name when letting it do high-risk work", and you can judge before it actually acts: if this step messes up, do I still have this /rewind regret medicine. If the judgment is "no", then obediently git commit first.

Look again at the "external changes" point:

Checkpointing only tracks files that have been edited in the current session. Manual changes you make to files outside of Claude Code, as well as edits from other concurrent sessions, generally won't be captured unless they happen to modify the same files as the current session.

Meaning: changes you make yourself with another editor, or by opening another Claude Code session, the checkpoints of this session do not recognize.

There is a ground rule worth following here: Whenever letting Claude do work that carries irreversible side effects like "deleting files, moving directories, modifying databases, sending requests", never count on /rewind as a fallback—if a git commit is needed, commit first, if a backup is needed, backup first. Checkpoints are only truly reliable regret medicine in scenarios like "it broke the code using editing tools".

Putting "what beginners think it can save" and "what it can actually save" side by side establishes the counter-intuitive point at the beginning:

Thing that went wrong	Beginner thinks /rewind can save	Reality	The real way to save
Claude broke code using editing tools	✅	✅ Can save	/rewind
Claude ran rm and deleted wrong file	✅	❌ Cannot save	Early git commit / backup
Claude ran a script writing to DB, altered data	✅	❌ Cannot save	DB backup / transaction rollback
Claude git push'ed it up	✅	❌ Cannot save	Revert at git level (remote changed)
You messed up file manually with another editor	✅	❌ Doesn't recognize	Your own undo / git

The "❌" in the middle rows are all variations of the pitfall at the beginning—their common point is that "the change happened outside the checkpoint's field of vision": it either went through bash instead of editing tools, or happened outside Claude Code, or simply pushed the changes to an external system. As long as the consequence of a matter falls outside "code files on disk", checkpoints cannot reach it. Memorizing this one sentence is less brain-taxing than memorizing that limitations table.

💡 One-sentence summary: Checkpoints only handle files modified by editing tools + conversation, these two can be reverted; bash command side effects (rm/mv), external changes, and sent requests are uniformly unrecoverable—a one-sentence judgment: if the consequences fall outside "code files", it cannot reach them, don't treat /rewind as insurance.

---

05 Division of Labor with Git: Local Undo vs Permanent History, Neither Can Replace the Other

Speaking to this point, that opening phrase "don't treat checkpoints like git" can be thoroughly explained. A lot of people struggle when they first start, "Now that I have checkpoints, do I still need git?"—The answer is: Yes, and the two don't compete for jobs at all.

The official documentation nails this relationship in one sentence, which is worth framing:

Think of checkpoints as "local undo" and Git as "permanent history."

Analogy: Scribbling on a draft notebook vs a formal document submitted for archiving. Checkpoints are like you scribbling on a draft notebook—if you write a stroke wrong, easily erase it and rewrite, fast, casual, only meaningful to yourself, and when the notebook is used up (after 30 days) you just throw it away. Git is like you printing out the final draft, signing it, and filing it in a filing cabinet—leaves a trace, can be shown to others, can be traced back to any version, permanently saved. You wouldn't skip archiving a formal document just because a draft notebook can be erased, nor would you use a formal document to edit back and forth for drafting just because it needs archiving. You must have both, each doing its own job.

The official division of labor list:

• Continue using version control (like Git) for commits, branches, and long-term history
• Checkpoints supplement but do not replace proper version control

Putting them side-by-side, the difference is clear at a glance:

Dimension	Checkpoint	Git
Who triggers it	Automatic (every prompt)	Manual (you git commit)
Granularity	One for every prompt, very fine	One for each commit, you decide
Handles bash side effects?	❌ No	✅ Committed files can be restored
How long to keep	Defaults cleared with cleanupPeriodDays	Permanent (until you delete history)
Can share / collaborate?	❌ Purely local, only for you	✅ Visible to whole team when pushed
Best suited for	"This step is broken, jump back" instant regret	Milestones, permanent history, collaboration

Note: git also cannot handle external side effects like sent requests or database modifications, it only helps you restore committed files on disk.

When to use which, I'll give you a simple method:

• Small steps fast running, regret anytime → Checkpoint. Try a version, if it doesn't work /rewind, try another version, completely without touching git, silky smooth.
• Finished a decent phase, want to save it long-term → git commit. A feature is cleared, tests passed, commit a batch, this is the true "permanent archive".
• Need bash side effects to be rollbackable → Can only rely on git. As said in the previous section, checkpoints can't handle rm, but as long as you commit diligently, git can retrieve the state of the entire workspace.

A more stable rhythm is like this: While letting Claude work, rely on checkpoints to rewind and trial-and-error at any time; every time a runnable small phase is completed, immediately git commit to nail down a permanent archive point. These two cooperating together equate to "fine-grained handy undo" stacked on "coarse-grained permanent milestone", double insurance. The lesson that truly bites is: trusting checkpoints too much, not committing for an entire afternoon, resulting in the session crashing and reopening, and although the code files are still there, that long string of "chapter markers" is completely broken—wanting to revert to an intermediate state three hours ago is impossible. Therefore, it is even more important to develop the muscle memory of "commit when it runs through".

Regarding how git coordinates with Claude Code (letting it write commit messages for you, managing branches), Article 43 "Git Workflow" is a dedicated article. Here you just need to remember one thing first: Checkpoints are local undo, git is permanent history; the former supplements the latter, never replaces.

Finally, adding an advanced fork, mentioned by the official docs: If you want to try a different method and want to keep the current session completely intact, don't use "summarize" (it will alter the context of your current session), but use fork:

claude --continue --fork-session

It will fork a new branch based on the current session to try, leaving the original session intact. Just know this trick exists, when you really get to "wanting to try two lines of thought in parallel", look up "Continue / Resume Session" in Article 34 again.

💡 One-sentence summary: Checkpoint = automatic local undo (fine, fast, purely local, expires), git = manual permanent history (traceable, collaborative, never lost); small step trial-and-error rely on checkpoints, milestones and side-effect rollbacks rely on git, commit when a phase runs through.

---

06 Hands-on: Personally Create a "Wrong Edit", Then Rewind Back

Just reading without practicing won't help you remember. The following minimal workflow will take you through a complete loop of "Claude edits file → you regret → /rewind backwards". It doesn't rely on any complex project, find an empty folder anywhere to run it. Open terminal and follow along.

Step 1: Build a toy folder, put a file you can understand at a glance in it

mkdir ~/rewind-demo && cd ~/rewind-demo
git init
printf 'hello\n' > note.txt
git add note.txt && git commit -m "init: initial note"

Expectation: There is just one line hello in note.txt, and a git commit has been made (good for comparing the difference between checkpoints and git later).

Step 2: Start Claude, let it edit this file

claude

After going in, send the first instruction (this prompt will trigger the first checkpoint):

Change the content of note.txt to three lines: apple, banana, cherry, using editing tools

Expectation: Claude uses editing tools to change note.txt to three lines of fruit (in default mode it will give a diff and wait for you to approve first, approve it). Specifically emphasizing "using editing tools" is to make this change fall within the tracking scope of checkpoints—this is exactly the type /rewind can save.

Step 3: Send another one, changing it even more "beyond recognition"

Then delete these three lines entirely, replace with one line: This is the version I do not want

Expectation: note.txt now only has "This is the version I do not want" left. At this point you have sent two prompts, there are two chapter markers on the timeline.

Step 4: Open rewind menu, rewind

Make sure the input box is empty, then press Esc twice in a row (or directly type /rewind):

(Input box is empty, Esc Esc)

Expectation: Pops up the rewind menu, listing the two prompts you just sent. Select the point before the first prompt (the time changed to three lines of fruit), then select "Restore code and conversation".

Step 5: Verify rewind success

Go back to the terminal (or use ! in the session to run), take a look at the file:

! cat note.txt

Expectation: note.txt changed back to the single line hello—both your changes were fully reverted, code and conversation went back to before the edits. Seeing hello come back = checkpoint rewind success. This is the power of "local undo": without typing a single git command, relying purely on checkpoints cleanly reverted two rounds of changes.

Step 6 (Crucial contrast): Verify bash side effects cannot come back

Now intentionally let it use a bash command to delete the file, experiencing the boundary from Section 04. Send in the session:

Use a bash command (rm) to delete note.txt

After it finishes deleting, /rewind again trying to revert to the point before deleting, select "Restore code". Then look:

! ls

Expectation: note.txt did not come back, cannot find it in ls. This confirms—Things changed by bash commands (rm), checkpoints cannot track, /rewind cannot save. Want to get it back? This is when it's git's turn to take the stage:

git checkout note.txt

(This line will use that init commit in git to restore the file.) Expectation: note.txt comes back carrying hello—git, this "permanent history", fills the gap that checkpoints cannot reach.

Running through these six steps, you have personally verified the two core things of this article: Checkpoints can smoothly rewind editing tool changes (Step 5), but cannot manage bash side effects—that relies on git (Step 6). These two positive and negative results are much easier to remember than explaining the boundary ten times.

💡 One-sentence summary: This practical exercise lets you see with your own eyes—what editing tools change, /rewind reverts with one click; what bash rm deletes, checkpoints are helpless against, must rely on git checkout to retrieve. One positive and one negative, and the boundary is engraved.

---

07 Summary

This article has thoroughly dismantled Claude Code's "automatic safety net"—checkpoints are the code snapshots it automatically takes before every edit, letting you rewind anytime, but they have clear boundaries, and act as partners with git, not stand-ins.

String the core points into a table, keep it in your pocket:

What you want to figure out	Conclusion	Key point
What is a checkpoint	Code snapshot automatically taken before each prompt	Fully automatic, no manual saving
How to rewind	/rewind or double-click Esc on empty input box	Double Esc with text clears it, won't open menu
What to select in menu	First "which point to revert to" then "how to revert"	"Restore" reverts state / "Summarize" compresses context, don't mix
What can be rolled back	Files changed by editing tools + conversation	These two can revert
What cannot come back	Bash side effects, external changes, sent requests	Changes from rm/mv uniformly cannot be saved
Relationship with git	Local undo vs permanent history	Small step trial-and-error relies on it, milestones & side effects on git

You should now be able to: Explain clearly what checkpoints are and when they automatically save for you; use /rewind or double-click Esc to open the rewind menu, distinguish the difference between "Restore" and "Summarize"; have a clear boundary line in mind—changes by editing tools can revert, bash side effects and external states cannot; and know how it divides labor with git and when you should commit. Only by engraving this boundary firmly is a checkpoint a safety net that can truly catch you, rather than a "fake regret medicine" that will deceive you at a critical moment.

Back to the opening sentence: checkpoints are indeed regret medicine, but they cure "code modified poorly", they cannot cure "deleted the wrong thing with rm"—feel free to /rewind the former, but obediently git commit in advance to catch the latter. Distinguishing these two medicines will save you from taking a tumble like the one at the beginning.

---

Next article 38 "Plugin Reference Manual"—Skills, Hooks, Subagents, MCPs you've learned along the way, and the various commands in this article, how are they packaged into a "plugin" that can be installed, uninstalled, and shared with others? Article 24 got you started; this article spreads out the complete structure and manifest fields of a plugin to be referenced as a manual. Think about it: If you want to make your handy configuration into an "install and play" package for a friend, what exactly does it look like inside?

---

Recommended Reading

• Parallel Tasks: Let Several Claudes Work Simultaneously, Not Wait in Line
• MCP: Connecting Claude to the External World
• VS Code Integration