Claude Code /diff: Review Every Line Before You Commit

The single most useful habit in AI coding takes thirty seconds: before you keep anything Claude Code wrote, run /diff and actually read it. The command shows you exactly what changed (the lines removed, the lines added, file by file), so you’re approving real code instead of trusting a summary. It’s the difference between owning what ships and just hoping the AI got it right.

What /diff actually shows

When you type /diff in Claude Code, you get a list of the files that changed, each with its added and removed line counts, and you can open any of them to read the actual lines. Where it appears depends on how Claude Code draws the screen. In fullscreen mode it’s a panel beside the conversation that stays open and refreshes every time Claude edits a file; the docs say it needs a git repository, a terminal at least 110 columns wide and Claude Code v2.1.287 or later. Otherwise it’s a dialog above the prompt that you close when you’re done. One quirk of the panel: it hides test and generated files and folds changes made before this session into a single line; click those summary lines to expand them.

Two views matter. Current shows your working tree: Claude’s edits plus anything else you haven’t committed. And once Claude has edited files, a source picker offers one view for each prompt that led Claude to edit files, labelled T1, T2 and so on, showing only what Claude changed in that turn. Each file also has an ask button that attaches its diff to your next prompt, handy for “why did you change this?”.

If you’ve connected Claude Code to your editor (run /ide to link VS Code, Cursor, or Devin Desktop, the editor formerly called Windsurf), you get a second view on top: each edit Claude proposes opens in the editor’s own side-by-side diff viewer, your original on one side and the new version on the other. Either way, the point is the same: you see the change, not a paragraph describing it.

This matters because an AI’s description of its own work and the work itself aren’t always the same thing. “I updated the login function to handle empty passwords” sounds fine; the diff might show it also quietly touched three other files. Reading the diff is how you catch that.

/diff versus git diff: use both

People ask whether /diff replaces git diff. Partly. They overlap more than they used to:

• /diff, Current view reads from git and shows everything you haven’t committed, like git diff does. The turn views (T1, T2…) are the part git can’t give you: only what Claude changed after one prompt. One catch: a change Claude makes by running a shell command shows up only in Current, because the turn views come from Claude’s own file edits.
• git diff (or your editor’s Source Control panel) shows everything different from your last commit, regardless of what made the change, and it works the same in any tool.

The honest workflow uses both: the turn views while you’re working with Claude to review each step, then the Current view, git diff or a glance at the Source Control panel before you commit, to confirm the whole picture. If you’ve built the habit of committing before you prompt, that final diff is beautifully clean. Everything new is the AI’s work, clearly separated from yours.

The 30-second review habit

Here’s the loop worth burning into muscle memory:

1. Prompt Claude Code to make a change.
2. /diff to see what it did.
3. Read it. Not every character, but enough to understand the shape of the change and spot anything that touches files you didn’t expect.
4. Commit if it’s right, or tell Claude what to fix if it isn’t.

Four small steps, and they completely change your relationship with AI code. Without the diff, you’re accumulating changes you’ve never looked at, and the day something breaks, you have no idea which step caused it. With it, you always know.

When the diff looks wrong

Reading the diff is also your early-warning system. If /diff shows the AI rewrote a function you asked it to leave alone, or deleted a block you needed, you don’t have to accept it. Tell Claude to revert that part, or press Esc twice on an empty prompt (or run /rewind) to roll back to an earlier checkpoint. You then choose to restore the code, the conversation, or both. Just remember checkpoints are a quick local undo, not a substitute for git commits, which are your permanent, reliable save points.

This is exactly the discipline that separates people who get great results from AI coding tools from people who end up with a tangle they can’t explain: the good ones read every diff, and they never let the AI’s confidence stand in for their own review. A reasoning model can write impressive code and still make a wrong assumption about your project. The diff is where you catch it.

Set up Claude Code the right way

If you’re just getting started, our free AI for Coders tool gives you the exact setup for your machine: which assistant fits your work, the install command for your operating system, and a starter rules file so the AI follows your conventions. Pair that with the prompt → /diff → read → commit habit above, and you’ll be reviewing AI-written code like someone who actually owns it.

Keep reading

GuidesWhat Is an AI Agent? (Plain English, No Jargon)A chatbot answers your questions; an AI agent goes and does things for you. The difference in plain words, with an example you've probably heard of.GuidesBest AI Coding Tool 2026: An Honest, No-Hype ComparisonThere's no single winner. Here's a fair look at Claude Code, Cursor, Devin Desktop, Copilot, Cline and Aider: what each is genuinely best at, and who it's for.GuidesWhat Is Vibe Coding? (And Is It Safe for Beginners)Building software by describing what you want in plain language and letting AI write the code. What it's genuinely good at, plus the honest catch.