How to review what Claude or Cursor changed in your Markdown files

Checked November 2026 against the Claude Code, Cursor and Git documentation linked below. Coffee isn't affiliated with any of them.

Take a snapshot before the AI tool starts, then compare against it. With Git, that means a commit followed by git diff --word-diff, which shows the words that changed rather than whole paragraphs. Without Git, copy the file first and compare with the copy. Claude Code and Cursor also have their own rewind, which is useful while the session is open.

Below is how each one works, where it falls short, and what I built into Coffee for this.

Why Markdown is awkward to review

In code, a changed line is usually short. In Markdown, a paragraph is often one long line, so an ordinary diff shows you two walls of text and leaves you to find the word that moved. When you ask a tool to tidy a note, it can touch dozens of those lines.

The things to catch are small: a number that changed, a name that got corrected to the wrong name, a sentence that quietly went missing. You need a view that makes those obvious.

With Git

If your notes are in a repository, this is the most dependable way, and it costs nothing.

git add -A && git commit -m "Before the AI edit"
# let the tool work
git diff --word-diff
git restore -p notes.md

--word-diff marks removals as [-like this-] and additions as {+like this+}. --color-words does the same in colour, which is easier on a long file. git restore -p walks through each changed block and asks whether to discard it.

The catch is that blocks follow lines, so in prose you often get to keep or discard a whole paragraph at once. For anything finer, edit the file by hand.

Without a repository

Git can compare any two files, with no repository involved:

cp notes.md notes.before.md
# let the tool work
git diff --no-index --word-diff notes.before.md notes.md

You do have to remember the copy every time, and undoing means pasting by hand.

Inside Claude Code and Cursor

Both can roll back their own work, though each has limits worth knowing.

In Claude Code, run /rewind or press Esc twice, pick a prompt, and choose Restore code. It tracks edits made by its file editing tools. A file that only a shell command changed isn't tracked, and neither are changes from outside the session. Its docs say plainly that this doesn't replace version control.

In Cursor, edits are applied as the agent works. You review them in the diff view and reject what you don't want, or hover over an earlier message and use Restore Checkpoint to roll back everything after that point.

These are good for the moment you spot a mistake. They're less good a day later, or when you've used two tools on the same folder, because each is built around its own session.

In Coffee

Coffee looks at the file instead of the tool. It watches the folder, and it remembers each note as you last read it. If the text on disk is different, whether it changed while the note was open or while Coffee was closed, a small bar at the top says how many changes there are since you last read it.

Press Review and you get every change as a card, under the heading it falls in, with the old text and the new text. Each card has Keep and Undo, and there's Keep all and Undo all at the bottom. Undo is an ordinary edit, so ⌘Z brings it back.

Launch page.md

Since it only reads the file, it works with Claude, Cursor or anything else that edits the file. A colleague's change gets the same treatment once it reaches your folder through Git or a synced folder. There's more on the review page.

On macOS 26 with Apple Intelligence, the panel adds a sentence or two describing the changes, written on your Mac. Without that, it gives a count and the sections involved.

What Coffee's review won't do

• It compares whole lines. A changed paragraph shows as old paragraph and new paragraph, with no highlight on the changed word. For a long paragraph, git diff --word-diff is easier to read.
• It needs a first read. The first time Coffee opens a note there's nothing to compare with, so changes made before that don't show up as changes.
• It can't tell you who did it. It sees that the file changed, and that's all.
• It skips private notes. Locked notes stay out of review, as they do from search and AI.
• It isn't version control. It holds what you last read, and version history holds earlier copies on this Mac. If you need a record to share, or history that survives a new Mac, use Git.

If you happen to have unsaved typing at the moment a file changes on disk, Coffee keeps what's on your screen and saves the other version beside it as a copy with "(conflict)" in its name.

A routine that works

1. Before you start, commit, or at least read the note in the app you'll review in.
2. Ask for one kind of change at a time. "Fix typos" and "shorten the intro" are easier to check as two passes than as one.
3. Read the changes before you read the result. A finished note reads well even when it's wrong.
4. Check numbers, names, dates and links first, because that's where a mistake does the most harm.
5. Keep or undo, then commit, so the next round starts from something you've checked.