Undo & checkpoints
Byte-exact checkpoints before agent changes, a diff of every step, and a rewind that refuses to overwrite your own edits.
Agents change many files quickly. Undo makes that cheap to get wrong: before PaneScale lets an agent change your workspace on your behalf, it takes a checkpoint, and you can go back to it exactly.
When a checkpoint is taken
| Situation | Checkpoint | Where you undo it |
|---|---|---|
| A turn in Agent mode or Chat with Edit access | Before the turn | Rewind step under the answer |
| A Guided turn after you click Approve & implement | Before the edits | Rewind step under the answer |
| A card on the tasks board | Before the run | Undo in the card details |
| Adopting an autopilot result | Before applying | Undo adoption in the report |
| Applying a Point & Fix change | Before applying | Undo in the Point & Fix panel |
Interactive terminal panes are your own sessions; isolate them with worktrees instead. Checkpoints for Agent mode and Chat belong to the Undo for agents feature in Labs, which is on by default.
How checkpoints are stored
A checkpoint is a snapshot commit stored under a private ref in your repository, refs/panescale/checkpoints/<id>. It is written with a temporary index and without line-ending filters, so the stored content is byte for byte what was on disk — including files you haven’t committed yet.
Your HEAD, your index and your branches are never moved. Checkpoints don’t show up in git log of your branches and are never pushed.
When the step ends, PaneScale records a second snapshot of what the step left behind. Comparing the two tells it exactly which files the step added, changed or deleted.
Changes
Changes shows the files a step added, modified or deleted, each with its diff, so you can decide before rewinding.
Rewind
Rewind step restores the state from before the step — every file the step touched.
Rewinding is refusing: for every file, PaneScale first compares what is on disk with what the step left behind. If you edited a file yourself afterwards, that file is not overwritten — it is listed as edited after this step and kept. All other files are restored, and every restored file is read back to verify it.
| Result | Meaning |
|---|---|
| Restored | Every file is back to its earlier state |
| Partial | Some files were restored, others kept because they changed later |
| Refused | Nothing could be restored safely |
The notice after a rewind says how many files were restored and how many were skipped.
Good to know
- Checkpoints need a Git repository. In a folder without Git, agents can still work — there is just nothing to rewind to.
- A rewind only touches the files the step changed. Your other uncommitted work stays as it is.
- Rewinding a step doesn’t undo later steps. Rewind them in reverse order — newest first — if you want to go further back.