Review the diff, checkpoints, and restore

Review the diff: keep and undo

When the agent proposes a change - whether from the sidebar, from inline edit, or applied from a chat suggestion - Cursor surfaces a diff for review. Agent edits can already be present in the working tree while the review surface is open, so Keep/Undo is an adjudication step, not a guarantee that disk state has remained untouched. Green for added lines, red for removed, laid over the file the way a code review would look.

This is the load-bearing half of the loop, and the one beginners skip. Two things to internalise:

• Keep and undo are per-change, not all-or-nothing. A multi-file proposal isn’t a single yes/no. Cursor surfaces per-change Keep / Undo controls (plus Keep All / Undo All for the whole run), so you can keep the edit in importer.ts, undo the one in report.ts because it changed behaviour you didn’t ask for, and re-prompt for just that file. Reviewing a diff means reading it, change by change, the same as you’d review a colleague’s PR - not skimming for red and clicking keep.

• Undo is a real answer, not a failure. When a proposal is wrong, undoing it and re-prompting with a sharper instruction is faster than keeping it and hand-fixing the mess. The diff is your veto, and using it freely is what keeps the agent’s latitude from becoming your liability. On budgetcli - code with your own money flowing through it - an undone diff costs you ten seconds; a kept-then-wrong one costs you a debugging session.

The mental model: the agent changes, Cursor shows, and you adjudicate. Review before committing, and use Undo or a checkpoint when the change is wrong.

Checkpoints and restore

Reviewing each diff protects you from the next edit. Checkpoints protect you from the last several. As the agent works through a task, Cursor records checkpoints at each significant change you can roll back to - restore returns your files to how they stood at that point, undoing the edits that came after. Your chat history stays intact; restore reverts the files, not the conversation, so you keep the thread of what you asked for and can re-prompt from where you left off.

Why this matters next to git: a single agent turn can touch several files before you’ve decided whether you like the direction. Git’s smallest safety net is a commit, and you don’t want to commit a half-finished, possibly-wrong agent run just to have an undo. Checkpoints give you a finer-grained, run-aware undo inside an un-committed run - let the agent go three edits down a path, decide at edit three that edit one took the wrong fork, restore your files to before edit one, and re-prompt. It’s the undo that understands “the agent’s last three steps” as a unit, which plain editor undo doesn’t.

Checkpoints don’t replace git; they sit under it. The rhythm is: explore with checkpoints while the work is still molten, commit with git once it’s green and reviewed.

Explore, review, commit: that rhythm has a name, and every gesture in this chapter is a beat inside it. Next: the four-beat loop.