Claude Code worktree: revisa cualquier PR ejecutándolo de forma autónoma

TL;DR En otra terminal, claude --worktree "#1234", con las comillas. Claude Code descarga el PR en .claude/worktrees/pr-1234 y arranca dentro, así que puede instalar, compilar y pasar los tests del cambio mientras tú sigues en tu rama. Con auto mode lo hace sin pararse a pedir permiso. Acepta también la URL del PR de GitHub o del MR de GitLab, y funciona con PRs de forks.

Te piden revisar un PR justo cuando tienes cambios a medias. Leer el diff es rápido, pero no te dice si el cambio funciona. Para eso hay que ejecutarlo, y ejecutarlo en tu checkout significa hacer stash, cambiar de rama, reinstalar y perder el hilo.

--worktree acepta un número de PR. Claude Code descarga ese PR en una carpeta propia, arranca la sesión dentro y tu checkout principal ni cambia de rama ni pierde lo que no has commiteado.

Qué hace

claude --worktree "#1234"

1. Descarga el commit de cabeza del PR desde origin (pull/1234/head en GitHub, merge-requests/1234/head en GitLab).
2. Crea un worktree en .claude/worktrees/pr-1234, en una rama worktree-pr-1234.
3. Arranca Claude Code ahí dentro, con el código del PR como directorio de trabajo.

Las comillas no son opcionales: sin ellas, tu shell trata #1234 como un comentario y --worktree se queda sin nombre.

En vez del número vale la URL: la de un PR de GitHub o, desde la v2.1.233, la de un merge request de GitLab (https://gitlab.com/grupo/repo/-/merge_requests/123). Claude Code solo lee el número y siempre descarga desde tu origin, así que los PRs abiertos desde un fork también funcionan. Lo comprobé con uno.

Un PR real, revisado de principio a fin

Lo probé con el PR #877 de ky, una librería de HTTP de código abierto. En mi checkout tenía un cambio sin commitear en source/index.ts. Lancé esto:

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."

En 3 minutos y 19 turnos, sin una sola petición de permiso, Claude:

• Instaló las dependencias, compiló y pasó la comprobación de tipos.
• Pasó los tests que cubren el cambio: 251 de 251.
• Separó lo que no era del PR: 46 tests de navegador que no arrancaron porque no hay Playwright instalado, y un error de lint en un fichero que el PR no toca.
• Escribió un script propio para comprobar el comportamiento en cinco casos, y los cinco salieron como decía el PR.
• Me dejó cuatro puntos para el autor. El primero, un cambio incompatible que convendría avisar en las notas de versión: con parseJson y un schema a la vez, una respuesta vacía que antes validaba ahora lanza un error.

Mientras, en mi terminal:

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

Mi rama y mi cambio, donde los dejé. Coste de la revisión a precio de API: $0,46 con Opus 5.5.

Estas salidas son de una ejecución con -p. En una sesión interactiva lanzas claude --worktree "#877" --permission-mode auto y le escribes el prompt al abrirse.

Para que trabaje solo

• Auto mode. Una revisión así ejecuta decenas de comandos (npm install, builds, tests, scripts). En modo manual te pediría permiso en cada uno. Con --permission-mode auto los aprueba un clasificador y solo se detiene ante lo arriesgado (cómo funciona auto mode).
• Tu .env. El worktree es un checkout limpio, sin tus ficheros ignorados. Si los tests los necesitan, lístalos en .worktreeinclude y se copian solos.
• El .gitignore. Añade .claude/worktrees/ para que no te aparezca como carpeta sin seguimiento (el ?? .claude/ de arriba).
• La primera vez en un repo, en modo interactivo, Claude Code te pide confiar en el directorio. Si no lo has abierto nunca ahí, lanza claude una vez antes.

Cuando termines

En una sesión interactiva, al salir, Claude Code comprueba el worktree. Si está limpio, lo borra junto con su rama. Si tiene cambios o commits nuevos, te pregunta si lo conservas o lo borras.

Con -p no hay pregunta: el worktree se queda, y además bloqueado. Para quitarlo:

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

Sin el unlock, git se niega a borrarlo. Y cuidado con la rama: si Claude crea otra dentro del worktree (en mi prueba creó pr-877-review), bórrala también. Cada worktree es una copia del repo en disco, así que conviene no acumularlos.

Si el autor sube cambios

Si vuelves a lanzar claude --worktree "#1234" con el worktree aún en disco, Claude Code lo reabre donde estaba. No descarga los commits nuevos del PR. La documentación lo dice expresamente para los nombres que son referencias a un PR; yo no lo he probado.

Para revisar la versión nueva, borra el worktree como arriba y vuelve a lanzarlo.

Leer el diff o ejecutarlo

• /code-review lee el diff y busca fallos. Es rápido y no ejecuta nada.
• --worktree "#1234" pone el PR a funcionar. Es lo que haces cuando la pregunta es si funciona, no solo si está bien escrito.

Si quieres que la revisión ocurra en GitHub sin abrir tu terminal, eso es Claude Code en GitHub Actions. Y si los worktrees te suenan nuevos, empieza por tres Claudes en paralelo con un solo comando.

Documentación oficial: Branch from a pull request · Reuse a worktree name · Clean up worktrees

Requisitos

• Un repositorio git con origin en GitHub, GitLab u otro host que publique las referencias de los PRs.
• Claude Code v2.1.233 o superior para las URLs de GitLab. Todo lo de arriba está ejecutado en la v2.1.284, el 30 de septiembre de 2026, salvo lo marcado como documentación.