# Edit checkpointing: rolling back an agent's changes

> Atlas snapshots file changes as git patches during a session, so edits an agent made can be diffed and rolled back after they were written.

Atlas snapshots file changes as git patches while a session runs, each recording a hash and the list of files it touched. That means an edit an agent made 20 turns ago can still be diffed and rolled back, without relying on editor undo history that a background formatter or a second tool may already have overwritten.

## Key takeaways

- Changes are snapshotted as git patches, each with a hash and file list.
- Rollback survives editor restarts and does not depend on undo history.
- Checkpointing is the backstop behind plan review and diff approval.
- Snapshots are local, stored alongside the repository they describe.

## Why editor undo is not enough

Undo history is per-editor, per-buffer, and lost on restart. An agent that edits 12 files in a session writes most of them outside any buffer you have open, so there is often nothing to undo in the place you would think to look.

The failure is quiet and arrives late. You notice something wrong an hour later, reach for undo, and find the history is gone or applies to the wrong file. A checkpoint recorded at edit time does not have that problem, because it was written by the thing doing the editing rather than by the thing displaying it.

## What a checkpoint records

Each Atlas snapshot stores 2 things: a hash identifying the state and the list of files that changed. Patches are the same format git already speaks, so restoring is a patch application rather than a bespoke file-copy scheme.

Using patches instead of full copies keeps the record small and makes it inspectable with tools you already have. It also means a checkpoint composes with the rest of your git workflow rather than fighting it, which matters when a session's work eventually has to become a commit.

## Where rollback sits among the other safeguards

Checkpointing is the 3rd safeguard, not the first. A read-only plan agent catches the wrong approach, per-edit diff review catches the wrong lines, and snapshots catch what both let through and you only recognized later.

Each layer handles a failure the others cannot. Planning cannot know how an edit will actually be written, diff review cannot know how a change will behave once the whole session lands, and rollback cannot prevent anything. Keeping all three is what makes an agent's changes reversible rather than merely visible.

## FAQ

### How do I undo changes an AI coding agent made?

Atlas snapshots file changes as git patches during a session, so an edit can be diffed and rolled back after it was written.

### Does rollback depend on my editor's undo history?

No. Checkpoints are written by Atlas at edit time and survive editor restarts, including for files you never had open.

### What does a checkpoint actually store?

A hash identifying the state and the list of files that changed, recorded as a git patch.

### Do checkpoints leave my machine?

No. Snapshots are stored locally alongside the repository they describe.

---

Canonical HTML: https://runatlas.sh/resources/features/edit-checkpointing
Source of truth: aeo_pages row `/resources/features/edit-checkpointing` (segment: Platform) (this file is generated from it, never hand-edited).
Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.