Six files changed, and the agent said 'done.' You didn't watch it write any of them. Now there's a merge button, or a keep button, or nothing but the next prompt waiting for you to type into it, and you don't know git well enough to check what actually happened before you press it — including whether one of those six just hardcoded a credential you'd want to catch first.
Here's the thing nobody's telling you: the reason this feels new is that it is new. Claude Code on the web ships with file edits pre-approved — the mode dropdown in your session reads 'Accept edits,' not 'Manual,' and it reads that way from the moment you open a project, before you've touched a setting. The terminal version went the other way on 3 July 2026, in release v2.1.200: the mode that used to be called 'default' got renamed to 'Manual'; the label changed, not the behaviour — that mode already stopped before every file write to ask you first. So if you're on the CLI and it's still asking, you already have the safety net. If you're in the browser, or in VS Code set to apply edits automatically, you don't — and that's the door this piece walks through.
Which one are you actually running
Check the mode indicator before anything else, because it decides where you look next.
Where you stand: browser (claude.ai/code) and VS Code set to apply edits automatically both write files with no prompt, though Bash still asks; Terminal, as of v2.1.200, defaults to 'Manual' and asks before every write unless you've switched to 'Accept edits' or 'Bypass' yourself.
If you're on the CLI in Manual mode, you already saw six prompts, one per file, and said yes to each. This piece is still useful to you for the skim and the revert path, but the panic moment it's built for — 'it did six things and I never saw any of them' — only exists in Accept Edits mode, wherever you're running it.
The one panel that shows every line
Forget reading six files top to bottom. You want the same thing a code reviewer wants: red lines removed, green lines added, nothing else.
In the browser or VS Code, that's the diff view built into the session — a 'Files changed' panel that lists every touched file and opens each one as a colored diff, same convention GitHub uses. You don't type anything. Click the file, read the colors.
In the terminal, type this with no arguments:
/diff
It opens an interactive viewer with two sources you can flip between with the arrow keys: Current, which is everything uncommitted in your working directory, and Per-Turn, which replays the changes turn by turn, in the order the agent made them. Per-turn is the one that matters here, because it survives you having already run 'git add' — it's reconstructed from the conversation, not from git state.
Underneath all of these, the actual mechanism is git, and it's worth seeing once so the colored panel stops feeling like magic. I made a small repo, let a stand-in for the agent touch four files — one edit, one new file, one deletion — and ran the plain command:
$ git status --short M app.py D notes.md ?? config.py ?? utils/
Four files, one line each, no need to open any of them yet. Then the counts, before the content:
$ git add -A && git diff --staged --stat app.py | 5 ++++- config.py | 4 ++++ notes.md | 1 - utils/helpers.py | 2 ++ 4 files changed, 10 insertions(+), 2 deletions(-)
That's the same list your diff panel shows you, just in text. Ten lines added across the whole change is a small task even when it touches four files — that's information before you've read a single line of code.
Worth flagging before you go further: once you've run 'git add', plain 'git diff' goes quiet on those files. It compares your working tree to the index, and 'add' just made the two identical, so nothing shows. Every diff command from here on needs '--staged' to show you anything at all — that's not a bug, it's what staging means, but it will bite you the first time you forget it.
How to skim six files without reading six files
You don't read all six. You read the shape of the change, and then you read the one file that doesn't match the shape.
Start with what git diff --stat gave you: a list of filenames and how much moved in each. Three questions, in order:
- Does every touched file belong to the task you asked for? If you asked for a login form and 'config.py' shows up new, that's the file you open first — not last.
- Is anything deleted that you didn't expect to lose? 'notes.md' showing a D is a one-second check: was that meant to go?
- In the files that do belong, is the diff proportional to the ask? Ten lines for 'fix the login bug' is normal. Two hundred lines touching a file you never mentioned is not — that's the diff you actually read line by line.
Here's what that third file looked like in my test, opened with the same command as before, scoped to one path:
$ git diff --staged -- config.py +API_KEY = "sk-live-a1b2c3d4e5f6g7h8i9j0" + +def get_key(): + return API_KEY
Four lines, and it's the one thing that looks wrong — a credential, hardcoded, in a file that wasn't part of the ask. You'd never catch that from 'six files changed, done' in the chat. You'd catch it in about four seconds from the file list, because it's the file that doesn't belong.
Compare that to app.py, which did belong and is fine on inspection:
$ git diff --staged -- app.py -print('hello') +def greet(name): + return f"hello {name}" + +print(greet("world"))
One line replaced by four, and it does exactly what it says — nothing here that wasn't asked for. That's the skim: stat first, outliers second, everything else gets a glance, not a read.
Getting back to before — and what doesn't come back
Two tools, and they undo different things.
/rewind (or double-tap Esc when the input box is empty) opens a menu with checkpoints — one per turn, taken automatically after every response, of every file Claude touched. You can restore code only, conversation only, or both. It's the fastest way back, and it's scoped to files Claude edited in that session. It does not roll back anything the agent ran through the shell: an npm install, a database migration, a file it deleted with an 'rm' command rather than an edit tool. Those already happened. Checkpoints also skip symlinked files, and they expire — Claude Code deletes them after 30 days.
git restore works on any file in a git repo, checkpoint or no checkpoint, and it's worth knowing the exact behavior rather than trusting it by feel. I tested it against my four-file change. Restoring the modified file put it back exactly as it was:
$ git restore --staged --worktree app.py $ cat app.py print('hello')
Restoring the new file — config.py, the one with the hardcoded key — didn't leave an empty version behind. It deleted the file outright:
$ git restore --staged --worktree config.py $ ls config.py ls: cannot access 'config.py': No such file or directory
That's correct behavior — there was no earlier version of config.py to go back to, so 'restore' means 'make it not exist' — but it's not what most people expect the first time, so know it before you run it on a file you meant to keep half of. And the same limit applies as with /rewind: git restore reverts what's in the working tree. It has no idea what commands ran along the way. If the agent 'pip install'-ed a package, restoring the files doesn't uninstall it.
Why this matters
Auto-approve took away the one moment where you used to get asked. It didn't take away the risk — it just moved the checkpoint from before the change to after it, and put it on you. 'Done' in a chat window is a claim, not a receipt. The diff panel is the receipt, and it costs you thirty seconds to read once you know what you're looking for: the file that doesn't belong, the deletion you didn't expect, the change that's ten times bigger than the ask. Neither /rewind nor git restore undoes a command that already ran — which is exactly why the thirty seconds before you keep the change matters more than the thirty seconds after.
Final thought
Next time an agent finishes a multi-file task — even one that looks fine, even one you're not worried about — open the diff panel anyway, before you keep anything. Find the file that doesn't match the rest of the list, and read that one first. The habit is worthless if the first time you use it is the time you're already scared.