To review an AI agent's changes in Lazygit before you commit, start the agent from a clean commit, open the file's diff with 0 (or Enter), stage only the hunks and lines you understand with Space, a and v, and leave everything else unstaged. Then check the staged diff, test exactly that snapshot with git stash push --keep-index --include-untracked, and commit it in a small, named piece. Whatever you didn't stage is still in your working tree for the next round.

A coding agent can touch many files in one run. Lazygit makes the review fast because you can accept a change one hunk or one line at a time instead of all or nothing. The key references below are for Lazygit v0.66.3 (released 7 November 2026) and come from its own keybindings page and README. The Git commands come from the official Git documentation, and we ran the stash-and-test sequence ourselves with Git 2.47.3 on 10 November 2026.

Who this is for

  • You let Claude Code, Codex, Cursor or another agent edit a Git repository, and you want to decide what actually lands in a commit.
  • You already use, or want to try, Lazygit. If you're setting it up with fzf and Yazi, start with our terminal workflow guide, which covers basic hunk staging.
  • You don't need this for one-line changes you can read in git diff. It pays off when the agent's diff is bigger than you can hold in your head.

Start from a clean commit before the agent runs

Commit or stash your own work before you hand the repository to an agent. Then everything Lazygit shows afterwards is the agent's work, and nothing of yours gets mixed into the review. A separate branch for the agent task makes it easy to throw the attempt away.

This is our working habit, not a rule from either tool. It matters because the review below depends on reading the diff against a known starting point.

How do you see everything the agent changed?

Open lazygit in the repository. The Files panel lists every changed file, including new files Git isn't tracking yet. Untracked files are the easy ones to miss: an agent may create a helper, a fixture or a scratch file that a plain git diff doesn't show at all. git status --short marks them with ??.

Three view settings help with agent diffs:

  • Ctrl+w toggles whether whitespace-only changes are shown. Turn it on to hide reformatting noise while you read the logic, then turn it back off before you stage, so you know what you're committing.
  • } and { increase and decrease the lines of context around each change. The default is 3 (git.diffContextSize in the config file).
  • Ctrl+t opens the file in your configured external diff tool (git difftool) when the terminal view isn't enough.

How do you stage only the parts you understand?

Use the main view's selection modes. In v0.66.3:

  1. Select a changed file and press 0 (or Enter) to focus its diff in the main view.
  2. The selection starts on a whole hunk. Space stages that hunk and moves to the next one. Left/Right (or h/l) jump between hunks.
  3. If a hunk mixes a change you want with one you don't, press a to switch to line-by-line selection, then v to select a range of lines, and Space to stage just those lines.
  4. Staged lines move to the pane below. Tab switches between the unstaged and staged panes. Space in the staged pane unstages a selection.
  5. E opens the selected hunk in your external editor if you need to hand-edit what gets staged.

If a key doesn't do what this page says, your version may differ. Press ? in Lazygit to open the keybindings menu for the panel you're in.

The rule we use: stage a line only if you could explain why it's there. A debug print, a rewritten comment or an unrelated rename can stay unstaged until you decide.

What should you do with the parts you don't want?

Leave them unstaged first. Unstaged changes cost nothing and can be committed separately, sent back to the agent, or discarded later.

Two keys need care:

  • d in the main view discards the selected unstaged change. On a staged selection it unstages instead.
  • z (undo) uses the reflog to undo the last Git command, and Lazygit's own documentation says it does not include changes to the working tree. A discarded working-tree change is not something z brings back. Discard only what you're sure about, or stash it first.

To ask the agent about a specific change, select the lines and press Ctrl+o. Lazygit copies the selected diff lines to the clipboard, so you can paste exactly those lines into your next prompt instead of describing them.

How do you test exactly what you're about to commit?

Test the staged snapshot, not the whole working tree. Your working tree still holds the unstaged parts, so a passing test run there doesn't tell you the commit alone works. The Git stash documentation has an example for this case under "Testing partial commits":

git diff --staged            # read what will be committed
git diff --staged --check    # conflict markers or whitespace errors?
git stash push --keep-index --include-untracked
# run your tests here: only the staged changes are in the working tree now
git commit -m "fix: reject zero divisor"
git stash pop                # bring the unstaged parts back

What each step does, per the Git docs: --staged is a synonym of --cached and shows the changes staged for the next commit. --check warns if changes introduce conflict markers or whitespace errors. --keep-index leaves what you staged in place while stashing everything else, and --include-untracked stashes untracked files too, so a stray file the agent created can't make the tests pass by accident.

When we tried it on 10 November 2026 (Git 2.47.3, a two-file Python project), we simulated an agent run that fixed a divide-by-zero bug, added a debug print and created an untracked scratch.py. We staged only the fix. git diff --staged --check exited with status 2 and reported the trailing space the "agent" had left on the changed line. During the test run, only the staged file was modified and scratch.py was gone. After the commit, git stash pop brought back the debug line and scratch.py. That's one small case, not a benchmark. stash pop can conflict if you edited the same lines in the meantime, so pop before you start new changes.

Lazygit can do the same from its stash options (S in the Files panel shows variations such as stashing staged or unstaged changes). The Git commands above are spelled out so you can see what happens.

Commit in small pieces

Press c to commit the staged changes. You can do it straight from the diff view. A few related keys:

  • A amends the last commit with the currently staged changes.
  • Ctrl+f finds the commit your current changes build on, which helps when the agent's change is really a fix to an earlier commit. Lazygit's fixup documentation covers the flow.
  • w commits without running the pre-commit hook. We avoid it for agent changes: the hook is one of the few automatic checks between the agent and your history.

If the agent already committed, you can still review it. Select the commit, press Enter to see its files, then focus a file's diff. Lazygit's README notes that selecting a hunk in an old commit's diff and pressing d removes it from that commit, rewriting it with an interactive rebase in the background. Don't do that on commits you've already pushed to a shared branch.

A five-minute checklist

  • The repository was clean (or on a fresh branch) before the agent ran.
  • You checked the Files panel for untracked files, not only modified ones.
  • Every staged line is one you could explain.
  • git diff --staged --check is clean.
  • Tests pass with only the staged changes in the working tree.
  • The commit message says what the change does, not "AI changes".
  • Leftover unstaged parts are either committed separately, sent back to the agent or deliberately discarded.

FAQ

Isn't this the same as git add -p?

It's the same idea with a different interface. git add --patch walks through hunks and asks you to choose: y stages a hunk, n skips it, s splits it into smaller hunks and e lets you edit it by hand. When a hunk can't be split further, you have to edit the patch text. Lazygit lets you select individual lines instead, and shows the staged and unstaged panes side by side.

Does a clean staged diff mean the change is correct?

No. It means you know what you're committing. Whether it works is a separate check: run the failing case before and after, and look at what the tests actually assert. Our AI-generated code acceptance checklist, how to verify an AI bug fix and whether AI-written tests can fail cover that part.

Which Lazygit version does this match?

v0.66.3, the latest release on 10 November 2026. The README says the main view starts with a whole hunk selected. If your selection starts on single lines, or a key does something else, check ? in the app or the keybindings page for your release.

Can Lazygit undo a discard?

Not with z. Lazygit's undo is based on the reflog and only considers commits, not working-tree changes. Keep unwanted changes unstaged or stashed until you're sure.

Should the agent stage and commit by itself?

That's a team decision. Our view is that the human who reviews should do the staging, because staging is where you decide what you vouch for. Agents can still propose commit splits for you to check.