Claude Code worktree: review any PR by letting Claude run it on its own

TL;DR In a second terminal, claude --worktree "#1234", quotes included. Claude Code fetches the PR into .claude/worktrees/pr-1234 and starts inside it, so it can install, build and run the change's tests while you stay on your branch. With auto mode it does all of that without stopping to ask. A GitHub PR URL or a GitLab MR URL works too, and so do PRs from forks.

A review request lands right when you're mid-change. Reading the diff is quick, but it doesn't tell you whether the change works. For that you have to run it, and running it in your own checkout means stashing, switching branches, reinstalling, and losing your place.

--worktree takes a PR number. Claude Code fetches that PR into its own folder, starts the session there, and your main checkout keeps its branch and its uncommitted work.

What it does

claude --worktree "#1234"

1. Fetches the PR's head commit from origin (pull/1234/head on GitHub, merge-requests/1234/head on GitLab).
2. Creates a worktree at .claude/worktrees/pr-1234, on a worktree-pr-1234 branch.
3. Starts Claude Code inside it, with the PR's code as the working directory.

The quotes aren't optional: without them your shell reads #1234 as a comment and --worktree gets no name at all.

A URL works in place of the number: a GitHub pull request or, since v2.1.233, a GitLab merge request (https://gitlab.com/group/repo/-/merge_requests/123). Claude Code only reads the number and always fetches from your origin, so PRs opened from a fork work too. I checked with one.

A real PR, reviewed end to end

I tried it on PR #877 of ky, an open-source HTTP library. My checkout had an uncommitted change in source/index.ts. I ran this:

claude --worktree "#877" --permission-mode auto \
  "Review this pull request by running it. Install the dependencies, run the tests \
that cover the change, and check that it does what the PR says. Don't commit or push. \
Finish with a short verdict: what you ran, what passed or failed, and anything \
you'd flag to the author."

In 3 minutes and 19 turns, without a single permission prompt, Claude:

• Installed the dependencies, built the package and passed the type check.
• Passed the tests that cover the change: 251 out of 251.
• Set aside what wasn't the PR's doing: 46 browser tests that couldn't start because Playwright isn't installed, and a lint error in a file the PR doesn't touch.
• Wrote its own script to check the behavior in five cases, and all five came out as the PR describes.
• Left me four points for the author. The first was a breaking change worth calling out in the release notes: with parseJson and a schema together, an empty response that used to validate now throws.

Meanwhile, in my terminal:

$ git branch --show-current
main
$ git status --short
 M source/index.ts
?? .claude/

My branch and my change, right where I left them. Cost of the review at API list price: $0.46 on Opus 5.5.

These outputs come from a -p run. In an interactive session you launch claude --worktree "#877" --permission-mode auto and type the prompt once it opens.

So it works on its own

• Auto mode. A review like this runs dozens of commands (npm install, builds, tests, scripts). In manual mode you'd approve each one. With --permission-mode auto a classifier approves them and it only stops for the risky ones (how auto mode works).
• Your .env. The worktree is a clean checkout, without your ignored files. If the tests need them, list them in .worktreeinclude and they're copied over.
• The .gitignore. Add .claude/worktrees/ so it doesn't show up as an untracked folder (the ?? .claude/ above).
• The first time in a repo, interactively, Claude Code asks you to trust the directory. If you've never opened it there, run claude once first.

When you're done

In an interactive session, Claude Code checks the worktree on exit. If it's clean, it removes it along with its branch. If it has changes or new commits, it asks whether to keep or remove it.

With -p there's no prompt: the worktree stays, and it stays locked. To remove it:

git worktree unlock .claude/worktrees/pr-877
git worktree remove .claude/worktrees/pr-877
git branch -D worktree-pr-877

Skip the unlock and git refuses. Watch the branches too: if Claude creates one inside the worktree (in my run it created pr-877-review), delete that as well. Each worktree is a full copy of the repo on disk, so don't let them pile up.

When the author pushes fixes

Run claude --worktree "#1234" again while the worktree still exists and Claude Code reopens it where it was. It doesn't fetch the PR's new commits. The docs state this explicitly for names that are PR references; I haven't tested it.

To review the new version, remove the worktree as above and launch it again.

Read the diff, or run it

• /code-review reads the diff and hunts for bugs. It's fast and runs nothing.
• --worktree "#1234" puts the PR to work. It's what you reach for when the question is whether it works, not only whether it reads well.

If you'd rather have the review happen on GitHub without opening your terminal, that's Claude Code in GitHub Actions. And if worktrees are new to you, start with three Claudes in parallel with one command.

Official docs: Branch from a pull request · Reuse a worktree name · Clean up worktrees

Requirements

• A git repository whose origin is on GitHub, GitLab, or another host that publishes PR refs.
• Claude Code v2.1.233 or later for GitLab URLs. Everything above was run on v2.1.284 on September 30, 2026, except what's marked as coming from the docs.