Review the diff, checkpoints, and restore

Review the diff: keep and undo

When the agent proposes a change - whether from the Agent sidebar (Cursor’s chat panel), from inline edit (the Cmd/Ctrl+K edit scoped to a selection), 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 edit loop - read, propose, review, commit - and the step beginners skip. Two things to internalize:

• 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 (exact labels as of September 2026; Cursor’s review guide documents the current review controls), so you can keep the edit in importer.ts, undo the one in report.ts because it changed behavior 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, the course’s illustrative personal-finance API - 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 a checkpoint before each significant change - the state of all modified files at that moment - and restore returns your files to how they stood there, 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 (Agent overview, as of September 2026).

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, and Cursor’s docs say so plainly: they are stored locally, separate from Git, and are only for undoing Agent changes - git remains the tool for permanent version control. The rhythm: explore with checkpoints while the work is still molten, commit with git once it’s green and reviewed.

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