What a coding checkpoint leaves behind

Undo is a comforting word

The source file is back where it started. The generated CSV is not, and the remote destination still has the newer copy. A coding checkpoint can have worked exactly as intended while leaving that combination behind. Before using undo as a reason to try a broad change, I would want to know which parts of the workflow the button can return and which parts will still need somebody’s attention afterwards.

Anthropic announced Claude Code checkpoints on 29 September 2025, with options to restore code, conversation or both. The announcement limited the feature to Claude’s edits, excluding user edits and bash commands, and recommended version control alongside it. [1] These qualifications affect how an experiment should be prepared: the available rewind covers a defined part of the session, rather than every change the workflow might produce.

We use undo rather generously in software conversations. A source snapshot, database restore, deployment rollback and external correction can each be useful, but they do not take the same things back. The person deciding whether an experiment is reversible needs the narrower description. It lets them prepare for the part a checkpoint covers without mistaking a convenient local recovery for a return of the whole working system to an earlier moment.

Follow a catalogue through five kinds of state

Consider an original illustrative catalogue task. Version 1 of an exporter produces columns sku and name. A tracked code edit changes it to version 2, which writes product_code and name. A shell command generates a new CSV with that header. A person separately updates an operations note, and the new CSV is then sent to a remote destination. That last step is only a recorded example in this article; no external upload is performed.

Now choose a code-only rewind to the earlier checkpoint. In the scope model, the exporter returns to version 1. The shell-generated CSV remains version 2, the person’s separate note remains revised and the remote copy remains where it was sent. The conversation may still discuss the version 2 approach if it was not restored. Each outcome follows a different state boundary; there is no single universal earlier moment that the entire workflow has resumed.

The clean source tree can actually make the leftover CSV easier to overlook. A later command may reuse the version-2 file already present while a recipient continues consuming its product_code header. Neither fact contradicts the successful code restore. The generated and remote artefacts need their own checks, including how far the recipient got. A local diff cannot tell us whether another system has merely received a file or already used its records.

The ledger here is an authored scenario, not a test of Claude Code in a particular installation. The current checkpoint documentation reinforces the separation between tracked file edits and shell modifications. [2] The original announcement already supports the central historical point. More detailed current options or limits should be checked for the version actually being used, rather than assumed to have existed unchanged in September 2025.

Regeneration is a separate recovery action

For the local CSV, a sensible next step may be to regenerate from the restored exporter and verify the expected header. Before doing so, check what the command reads and writes. Does it overwrite only a disposable local file, or does it also publish, update a database or send notifications? A command named export can contain several effects. Re-running it to repair one artefact should not accidentally repeat the rest.

Keep generated output traceable to its source and inputs where the workflow needs that assurance. A manifest can record exporter revision, input snapshot and output identifier or digest. The point is not to add elaborate metadata to every scratch file. It is to avoid treating whichever CSV happens to be present in the directory as proof that it matches the current source. A digest establishes identity of bytes; the manifest explains which operation produced them. For this example, inspect the literal first line: sku,name belongs to the restored contract, while product_code,name reveals the stale generated output. That small acceptance check catches the mixed state directly.

The remote copy needs its own decision. If nobody has consumed it and the destination supports safe replacement, publishing a corrected file may be enough. If another team already imported version 2, replacing that file does not restore their records. Before another publication, establish whether the receiver will replace the earlier import, add another batch or reject the restored sku,name header. Those are different recovery paths, even though the same corrected CSV could be sent through each. The appropriate contact, reconciliation or compensating update follows the actual receiving process. Keep its original reference and known outcome so the operator can identify what was consumed; a second successful upload cannot by itself establish that the first import was reversed.

The separately edited operations note may still be useful after the experiment ends. Perhaps it explains why the abandoned change was considered in the first place. Resetting every newer file would remove that person’s work along with the unwanted code. Inspect what each edit belongs to and recover the intended scope. Newer is not a synonym for mistaken, particularly in a workspace where more than one person or process can be doing useful work.

Code and conversation can disagree after recovery

Keeping the conversation while restoring code can be helpful: the failed approach and its lessons remain available. It can also leave statements that are no longer true. “The exporter now writes product_code” was accurate before the rewind and false afterwards. The next instruction should establish the current files and desired contract, instead of trusting the latest prose summary as a live description of the working tree.

Restoring the conversation without code has the reverse problem. The assistant may be returned to a plan that predates changes still present on disk. Neither mode is inherently wrong. They answer different recovery needs. After either operation, inspect the actual diff and relevant files, then state what remains. A short reconciliation of the session’s understanding with the workspace can prevent another round of changes built on stale assumptions.

This is also why checkpoints and version control serve different purposes. The announcement recommends their combined use, and the documentation describes checkpoints as session recovery rather than permanent collaborative history. [1][2] A deliberate version-control boundary can record the reviewed source state and separate unrelated edits. It still does not reverse remote effects, restore every ignored artefact or settle the meaning of a data migration by itself.

In a shared workspace, ownership matters before any broad reset. Another person or process may have made useful changes after the assistant began. Inspect what will be affected and use the narrow recovery operation that matches the intended change. A convenient undo feature should reduce the cost of exploration, not make somebody else’s work an unexamined part of the experiment.

Define the recovery proof before the broad change

For the catalogue task, a practical recovery check names the things that must agree: exporter header contract, regenerated CSV, destination version and any downstream import status. The code diff is one item in that check. The remote reference is another. If the destination’s state is unknown, leave it unknown and investigate; do not infer reversal from a clean local tree.

The scope can also change what work is delegated. Trying a layout variant in isolated files may be comfortably reversible. A command that changes a shared schema or distributes a customer-facing file has a different recovery cost. Keep the exploratory stage local where possible, review the proposed effect and use the appropriate authorised process for the external step. The checkpoint remains valuable, but its usefulness does not widen its coverage.

A recovery handover could say: version-1 source restored; local CSV regenerated and checked; revised note retained; remote version 2 still needs a decision. The next person can continue from that account without repeating the local restore. “Rolled everything back” sounds more reassuring but leaves them a discovery exercise about what everything included. Naming the remaining remote work makes an incomplete recovery manageable instead of making the incompleteness a surprise.