Le pides a Claude Code que mejore una landing y, antes de que termine, abres otra sesión para añadir pruebas. Ambas escriben en la misma carpeta. Una cambia un componente que la otra acaba de leer; la segunda deja archivos sin guardar y ya no sabes qué commit pertenece a cada encargo. Dos agentes pueden ahorrar tiempo solo si sus cambios tienen una frontera clara.

Git worktree permite dos directorios de trabajo vinculados al mismo repositorio, cada uno en una rama distinta. No duplica la historia completa como otro clon. Claude Code puede ejecutarse desde cada directorio en terminales separados. Anthropic también documenta sesiones de escritorio con worktrees automáticos; aquí usamos los comandos explícitos de Git para que puedas ver la separación y revisarla. Comprobé creación, listado y eliminación de dos worktrees en un repositorio temporal; no ejecuté dos sesiones de Claude para este artículo.

Elige tareas de verdad independientes

Ejemplo: una sesión mejora el texto y la jerarquía visual de una landing; la otra añade pruebas a un endpoint de API ya existente. Ambas parten del mismo commit. Si las pruebas necesitan una función que la primera aún está escribiendo, no son independientes: espera a integrar esa función o cambia el alcance de la segunda tarea. Define antes qué archivos puede tocar cada sesión, qué resultado esperas y qué comando probará el cambio. Evita poner a ambos agentes a editar el mismo package.json o la misma migración.

Prepara los dos espacios

En la raíz de tu repositorio comprueba que la rama base es la correcta y que no dependes de cambios sin commit. Los nuevos worktrees parten del commit actual; no heredan archivos modificados sin registrar. Sustituye los nombres de carpetas si ya existen. Estos comandos de Git se probaron localmente en una carpeta temporal:

git status --short
git worktree add -b feature/landing ../miapp-landing
git worktree add -b feature/tests ../miapp-tests
git worktree list

Abre una terminal en ../miapp-landing y otra en ../miapp-tests. En cada una ejecuta claude con un encargo acotado. Por ejemplo, en la primera: «Mejora el encabezado móvil de la landing; no toques la API. Muéstrame la captura o el diff y ejecuta el build». En la segunda: «Añade pruebas al endpoint de registro existente; no cambies la landing. Ejecuta la suite y explica fallos». Esos prompts son plantillas de trabajo, no pruebas de que Claude produzca un resultado correcto.

Si usas Claude Code Desktop, su documentación explica que las sesiones de un repositorio Git pueden recibir worktrees aislados automáticamente. No mezcles ese flujo con la creación manual de los mismos directorios sin comprobar dónde están tus sesiones. En terminal, el directorio actual decide qué copia ve Claude. Confírmalo con pwd y git branch --show-current antes de autorizar cambios.

Lo aislado y lo compartido

Los archivos versionados y el índice Git quedan separados por worktree. La base de datos de desarrollo, un servidor local, el puerto 3000, servicios externos, claves y archivos fuera del repositorio pueden seguir siendo compartidos. Si los dos agentes arrancan la misma app con el mismo puerto, uno fallará. Si usan la misma base, una migración de una rama puede romper la otra. Asigna puertos y datos de prueba distintos, y usa credenciales de desarrollo con permisos mínimos. Los archivos ignorados como .env no aparecen mágicamente en el nuevo directorio; prepara valores locales sin copiarlos a Git.

La configuración de Claude también merece atención: la documentación de settings explica que parte de los ajustes compartidos puede leerse desde el checkout principal, mientras las rutas de permisos se interpretan según el directorio de la sesión. Revisa /status en cada sesión si dependes de reglas, conectores o hooks. Un worktree evita choques de archivos; no es un sandbox de seguridad completo.

Integra con criterio y limpia

En cada carpeta revisa git diff, ejecuta pruebas, confirma únicamente los archivos del encargo y abre una PR por rama. Comprueba que el cambio de landing no rompe móvil y que las pruebas del endpoint fallan cuando el comportamiento esperado se rompe. Revisa ambas PR por separado, integra una y luego actualiza o rebasea la otra antes de fusionarla. Si aparecen conflictos, resuélvelos tú con el comportamiento final a la vista; no aceptes una combinación automática a ciegas.

Cuando cada worktree esté limpio y su trabajo integrado, desde el repositorio principal usa git worktree list y git worktree remove ../miapp-landing (y lo mismo para ../miapp-tests). Git se niega a quitar un worktree sucio sin forzar; revisa antes de borrar. Quitar el directorio no borra automáticamente la rama, que puedes eliminar después de confirmar la fusión. En la prueba local, Git creó ambos directorios, los listó y los eliminó correctamente.

Fuentes y alcance

Git: documentación oficial de worktree; Anthropic: sesiones paralelas de Claude Code Desktop; Anthropic: configuración en worktrees. Revisado el 10 de noviembre de 2026. Se probaron comandos de Git, no una ejecución paralela de Claude ni la calidad de las PR.