Guides · Reviewing an agent’s worktree

How to review what an AI agent changed in a Git worktree.

By Quentin Hermiteau, who makes Nori. Published .

Coding agents work best in their own Git worktree: a second folder on its own branch, sharing the repository’s history. You can run three of them at once and keep your own checkout untouched. The cost comes at the end, when you have to find each worktree, read what it did and decide what to merge.

This guide walks through that end, with plain Git commands that work with any agent. I make Nori, a Git client that does these steps in its interface, and the last section shows how; everything before it needs nothing but Git.

1. Find the worktrees

Start from the repository you cloned. Git lists every worktree that shares it:

git worktree list
/Users/me/shop                                  4f1c2ab [main]
/Users/me/shop/.claude/worktrees/fix-checkout   9e03d71 [worktree-fix-checkout]
/Users/me/.codex/worktrees/a1b2/shop            c7d8e90 (detached HEAD)

The first line is your own checkout. Each agent puts its worktrees in its own place:

  • Claude Code: claude --worktree <name> creates .claude/worktrees/<name> at the repository root, on a branch named worktree-<name>, started from the default branch. Add .claude/worktrees/ to .gitignore, as its documentation advises.
  • Codex: the Codex app creates worktrees under $CODEX_HOME/worktrees for the threads you start on a worktree, and for its automations.
  • T3 Code: under ~/.t3/worktrees, one folder per thread that has its own.

A worktree in (detached HEAD) has commits on no branch. Give it one before anything else, or those commits become hard to find once the folder is gone:

git -C /Users/me/.codex/worktrees/a1b2/shop switch -c codex/fix-search

2. Read everything it changed

An agent’s work lives in two places: the commits it made, and the files it changed but did not commit. Read both. Inside the worktree:

cd .claude/worktrees/fix-checkout
git fetch origin
git log --oneline origin/main..HEAD     # the commits it added
git diff --stat origin/main...HEAD      # files changed by those commits
git status --short                      # what it has not committed yet
git diff origin/main                    # all of it: commits and uncommitted work

The three dots in origin/main...HEAD compare from the point where the branch left main, so changes others merged into main since then do not show up as the agent’s. The last command, with no dots, compares the files on disk with origin/main; it is the closest to “what would change if I took this”, but it also shows what main gained since the branch started. Rebase first (step 3) and the two views agree.

Things worth a second look in an agent’s diff:

  • Lockfiles and dependency manifests it changed without being asked.
  • Deleted or weakened tests, and new skip or only markers.
  • Configuration, CI files and anything that touches secrets or credentials.
  • Generated files committed by mistake, and stray debug output.
  • Changes outside the area the task was about.

3. Bring it up to date

While the agent worked, main moved. Rebase the worktree’s branch onto it so the review and the tests see the code as it will be merged:

git -C .claude/worktrees/fix-checkout fetch origin
git -C .claude/worktrees/fix-checkout rebase origin/main

Commit or stash the agent’s uncommitted work first: Git refuses to rebase over local changes. If the rebase stops on a conflict, resolve it in that folder, then git rebase --continue, or git rebase --abort to go back to where you were.

4. Run it

A worktree holds only the files Git tracks. Dependencies, build output and ignored files such as .env are not there until you install or copy them. Claude Code copies the ignored files you list in a .worktreeinclude file, and the Codex app runs the setup script of a local environment. Otherwise, install dependencies in the worktree before running the tests, or the result says little about the change.

5. Push it and open the pull request

git -C .claude/worktrees/fix-checkout push -u origin HEAD
gh pr create --fill          # GitHub CLI
glab mr create --fill        # GitLab CLI

Rename the branch first if the agent’s name for it means nothing to your reviewers: git branch -m worktree-fix-checkout fix/checkout-total.

6. Remove the worktree without losing work

Once the branch is pushed or merged, remove the folder. The branch stays:

git worktree remove .claude/worktrees/fix-checkout
git branch -d worktree-fix-checkout     # only once merged; -d refuses otherwise
git worktree prune                      # forget worktrees whose folder is already gone

git worktree remove refuses when the worktree holds changes, and --force deletes them for good. Claude Code also locks the worktree of a running agent, so removal waits until the session ends or you run git worktree unlock. Check git status in the folder before forcing anything.

The same steps in Nori

Nori, the Git client I make, keeps these steps in one window:

  • Every linked worktree appears in the sidebar under its repository, named after the agent and the task: Codex, Claude Code or T3 Code, and the thread title or the first request.
  • Each row shows lines added and removed, and how far the branch is ahead of and behind its base, kept current while the agent works.
  • Clicking one shows everything it changed since its base, uncommitted work included: step 2 without the commands. From there, push it and open the pull or merge request.
  • Removing a worktree is guided: Nori can put a detached checkout on a branch, says when the work is already integrated, and keeps the branch when it removes the folder.

Nori does not start or steer agents, and does not create worktrees yet. More on Nori beside your agents.

Nori’s window, drawn on the app’s own design tokens: under Worktrees, the one Claude Code works in, with the lines it added and removed and its distance from its base (↑3 ↓1).

Sources

Download for Mac — free