How do I review the diffs of several agents at once?

Give each agent its own branch, get an overview with git diff --stat main...<branch> for every branch, then read each diff in full, one branch at a time. Before you merge anything, test the branches merged together. Two changes that pass on their own can still break each other.

There is no single command that reviews five agents at once. The method below makes the loop fast and stops you from missing work.

Step 1: make sure every agent has its own branch

Reviewing is only possible if the changes are separated. If three agents edited the same checkout, their changes are mixed in one working tree and you can't tell them apart.

With Claude Code, start each session in a worktree:

claude --worktree auth-magic-link
claude --worktree fix-rounding

Each one lives under .claude/worktrees/<name>/ on a branch named worktree-<name>. With plain git, git worktree add ../app-fix-rounding -b fix-rounding does the same for any agent. See using git worktrees with Claude Code for setup details.

Step 2: list what exists

git worktree list
git branch --list 'worktree-*' --format='%(refname:short)'

The first command shows every checkout and the branch it's on. The second lists the branches Claude Code created.

Step 3: get an overview of every branch

Loop over the branches and print a summary per branch:

for b in $(git branch --list 'worktree-*' --format='%(refname:short)'); do
  echo "== $b"
  git diff --stat main..."$b"
done

The three dots matter. git diff main...branch compares the branch with the point where it left main, so you see only what the agent did, not what landed on main since. Git defines A...B as git diff $(git merge-base A B) B.

The overview answers the first questions fast: which agent touched far more files than its task needed, which one edited a lockfile, which two touched the same file.

Step 4: check for uncommitted work

The branch diff only sees commits. Agents often leave work in the working tree. Check each worktree:

git -C .claude/worktrees/fix-rounding status --short
git -C .claude/worktrees/fix-rounding diff HEAD --stat

If you skip this, you can approve a branch that is missing half its change.

Step 5: read each diff in full

Now take one branch at a time:

git diff main...worktree-fix-rounding

Inside a running session you can also review without leaving it:

• /diff in Claude Code shows the changes in the working tree, including the edits Claude made so far. In fullscreen rendering it opens as a panel next to the conversation and updates while you work.
• /code-review in Claude Code reviews a target for correctness bugs. Pass main...worktree-fix-rounding to review one branch against another, or a PR number. It runs as a background subagent and counts toward your usage like the rest of the session.
• /diff and /review in Codex CLI show the Git diff, including untracked files, and ask Codex to review the working tree.

An automated review is a second reader, not a replacement for yours. Read the diff yourself first, then compare notes.

Step 6: test the branches together

Each branch can be correct on its own and still conflict with another one in behavior: one agent renames a function another one starts calling. Merge them in a scratch worktree and run the tests there:

git worktree add ../app-integration -b integration main
cd ../app-integration
git merge worktree-auth-magic-link
git merge worktree-fix-rounding
npm test

When you're done, remove the scratch checkout with git worktree remove ../app-integration.

Step 7: one pull request per branch

git push -u origin worktree-fix-rounding
gh pr create --base main --head worktree-fix-rounding --fill

gh pr diff <number> --name-only gives you the file list of an open PR when you come back to it later.

Limits of this method

• It's sequential. You read one diff at a time, and you switch between the terminal running the agent and the terminal where you read its diff.
• It's easy to forget a worktree. A branch you never listed is a branch you never reviewed.
• Uncommitted changes hide. The branch diff and the PR both ignore what the agent didn't commit.
• Semantic conflicts don't show in any diff. Only the integration test run catches them.

If you prefer a GUI for the reading part, the Claude Code desktop app has a diff view where you can comment on lines and Claude applies the changes. It covers Claude sessions only.

With Kanbell

Kanbell is a macOS app (Apple Silicon) with one window per project. The Git panel sits next to the terminals: changes, diffs, history and worktrees for that project.

• The worktrees are listed in the same window as the terminals where their agents run.
• Changes and diffs sit beside the terminals, so you read them without opening another terminal.
• History shows the commits, so you can check what landed before you open a PR.

Kanbell doesn't review, merge or open pull requests for you. You still run /code-review, the integration tests and gh pr create in the terminals. What it removes is the hunting: which worktree, which branch, which terminal. If several agents are running, the orange dot and ⌘⇧J tell you which one waits for you while you read the others' diffs.