¿Qué no aísla un git worktree para los agentes de IA de programación?

Un git worktree aísla archivos y rama, no comportamiento. Tres cosas siguen compartidas con tu checkout principal: el directorio .git del repositorio, los plugins de ámbito de proyecto y las aprobaciones de permiso guardadas. Por eso dos agentes de IA de programación trabajando en worktrees separados todavía pueden alcanzarse, y por eso la pregunta útil no es si el worktree aísla, sino qué estás protegiendo exactamente: tus archivos, o tu máquina.

Esto se volvió discusión pública el 30 de julio de 2026, cuando un hilo en Hacker News titulado "Git worktrees are not an isolation boundary for coding agents" reunió 35 comentarios. Los que tratan del tema se dividen entre gente que corre agentes en worktrees a diario y gente que considera el planteo un hombre de paja.

¿Qué aísla de verdad un git worktree para un agente de IA de programación?

Un git worktree le da al agente de IA de programación su propio directorio de trabajo y su propia rama, sacados del mismo repositorio. Las ediciones hechas por un agente en ../proyecto-feature-a no aparecen en tu checkout principal, y las dos ramas avanzan de forma independiente hasta que alguien las integra. Para el fallo que la mayoría intenta evitar, que es dos agentes escribiendo el mismo archivo con minutos de diferencia y el segundo ganando en silencio, el worktree lo resuelve por completo.

Esa es la frontera que se compra, y es real. En Hacker News, el usuario markush_ resumió el lado positivo en una línea: "The big advantage of using worktrees is the shared git state, it makes it so much easier to cherry-pick and move commits around those worktrees", es decir, la gran ventaja es justamente el estado compartido de git, que facilita mover commits entre worktrees. El repositorio compartido no es un descuido de diseño. Es la funcionalidad, y es lo que hace al worktree más barato y más rápido que un segundo clon. Cubrimos la mecánica de crear uno, y las dependencias y artefactos de build que no vienen con él, en nuestra guía de git worktree para agentes de IA. Este artículo empieza donde aquel termina: después de que los worktrees existen y los agentes siguen chocando.

¿Qué sigue compartido entre el worktree y el checkout principal?

La documentación de Claude Code, de Anthropic, responde esto directamente en una sección llamada "What worktrees share with the main checkout", leída el 12 de agosto de 2026. Nombra tres elementos, y cada uno tiene una consecuencia distinta para quien corre agentes de IA en paralelo.

• El directorio .git del repositorio. Según la documentación, los comandos git ejecutados dentro de un worktree escriben en el directorio .git compartido del repositorio principal, y agrega que el sandbox permite esas escrituras, de modo que comandos como git commit funcionan desde dentro de un worktree con el sandbox activado.
• Plugins de ámbito de proyecto. Los plugins instalados en ámbito de proyecto desde el checkout principal también cargan en los worktrees del mismo repositorio, así que no hay que reinstalarlos en cada uno. La documentación ata ese comportamiento a la versión 2.1.200 de Claude Code o posterior.
• Aprobaciones de permiso guardadas. Elegir "Yes, don't ask again" para un comando de Bash dentro de una sesión en worktree guarda la regla en el .claude/settings.local.json del checkout principal, así que pasa a valer en el principal y en todos los demás worktrees de ese repositorio, y sobrevive a la eliminación del worktree. La documentación registra que esto cambió en la versión 2.1.211: antes, la aprobación se guardaba dentro del worktree y se perdía con él.

El tercer punto merece releerse. Un permiso que le diste a un agente, en un directorio desechable, para librarte de un aviso molesto, se vuelve permiso permanente para todos los agentes que corras en ese repositorio después.

¿Un agente de IA dentro del worktree puede tocar el checkout principal?

Por git puro, sí, y puedes probártelo en unos treinta segundos. Como el .git es compartido, un proceso corriendo dentro del worktree puede escribir en .git/hooks, y los hooks puestos ahí se ejecutan cuando tú haces commit desde el checkout principal. Este bloque trabaja en un directorio temporal, hace la demostración y borra todo lo que creó:

d=$(mktemp -d) && cd "$d"
git init -q demo && cd demo
git -c user.email=a@b.c -c user.name=t commit -q --allow-empty -m first
git worktree add -q ../agent-a -b agent-a
cd ../agent-a
printf '#!/bin/sh\necho "hook written from the worktree"\n' > "$(git rev-parse --git-common-dir)/hooks/pre-commit"
chmod +x "$(git rev-parse --git-common-dir)/hooks/pre-commit"
cd ../demo
git -c user.email=a@b.c -c user.name=t commit -q --allow-empty -m second
cd "${d:?}"; git -C demo worktree remove --force ../agent-a; rm -rf "${d:?}/demo" "${d:?}/agent-a"

En una configuración por defecto de git, sin core.hooksPath definido, el segundo commit imprime hook written from the worktree. Lo ejecutamos en git 2.50.1 el 12 de agosto de 2026. Si tu máquina define core.hooksPath, cosa que hacen husky, lefthook y muchas configuraciones corporativas, git busca los hooks en otro lugar y el comando no imprime nada: la demostración queda silenciosa, no equivocada. El ${d:?} de la última línea no es adorno. Hace que el shell aborte en vez de expandirse a una cadena vacía si mktemp llegara a fallar, y esa es la diferencia entre borrar un directorio temporal y borrar una ruta en la raíz.

Qué significa el resultado, dicho con cuidado. Ningún archivo versionado cambió y ninguna rama fue tocada, así que git status en el checkout principal sigue limpio. La escritura cayó dentro del directorio .git del checkout principal, que físicamente vive dentro de la carpeta del checkout principal. Y ese es justamente el punto: el cambio es invisible para el comando que la gente usa para buscar cambios, y un script que solo existió dentro del directorio aislado ahora corre en tu máquina, disparado por tu propio commit. El comando git rev-parse --git-common-dir es el truco, porque desde dentro de un worktree imprime la ruta del .git del repositorio principal, que es la superficie compartida.

El hilo de Hacker News no dejó esto abierto por mucho tiempo, y vale contar el intercambio entero porque ESTRECHA lo que la demostración prueba. El usuario alchaplinsky preguntó si un agente confinado a un perfil de sandbox "can still write a pre-commit hook that runs on your machine whenever you commit outside the sandbox", esto es, si todavía puede escribir un hook que corre en tu máquina cuando haces commit fuera del sandbox, y terminó con "Or am I missing something?". El usuario sbysb, que había recomendado esa herramienta de sandbox y la corre con un perfil armado por su equipo, respondió que "All git config and hooks are not writable inside the sandbox", o sea, que ahí la configuración y los hooks de git no son escribibles. Dentro del perfil que usa ese equipo, entonces, la respuesta es no. Y el mismo comentarista hizo enseguida la distinción más afilada de todo el hilo, que juega en contra de su propio armado: "this doesn't close all of these types of attacks, just the ones that are invisible", es decir, que aquello no cierra todos los ataques, solo los invisibles. Un agente todavía puede escribir un script y atarlo a tu código, pero eso llega como un cambio que puedes leer en un diff. Un hook de git no. Lo que el bloque de arriba agrega es la línea de base debajo de todo eso: en git puro, sin sandbox y sin ningún harness imponiendo nada, el mecanismo funciona exactamente como alchaplinsky lo describió. Esto no es una vulnerabilidad de git ni un defecto de ningún agente. Es el repositorio compartido haciendo lo que fue diseñado para hacer, y lo que queda establecido es estrecho y útil: aislamiento de archivo y aislamiento de proceso son propiedades distintas, y el worktree solo vende la primera.

¿Qué bloquea Claude Code dentro de un worktree, entonces?

El directorio .git compartido es justamente el hueco que la capa del harness existe para cerrar, y Claude Code publica lo que impone. En una sección titulada "How Claude Code enforces isolation", leída el 12 de agosto de 2026, la documentación lista cuatro verificaciones aplicadas mientras la sesión está aislada en un worktree, válidas para la sesión y para todo subagente que ella cree.

Claude Code bloquea un Edit, Write o NotebookEdit que apunte a una ruta del checkout principal. Bloquea un comando de Bash, PowerShell o Monitor cuyo directorio de trabajo resuelva al checkout principal. Bloquea comandos que redirijan git al checkout principal, sea por git -C, por --git-dir, por las variables GIT_DIR y GIT_WORK_TREE, o por un cd antes de ejecutar git. Y bloquea comandos cuya forma no puede verificar estáticamente como limitada al worktree, como la expansión de llaves y los heredoc con delimitador sin comillas, una verificación que la documentación dice que no se puede desactivar.

La lectura práctica para quien corre agentes en paralelo: tu garantía de aislamiento viene del harness, es decir, de la capa que ejecuta el agente, sea Claude Code, Codex o un ejecutor que escribiste tú. No viene de git. Si cambias el harness o lanzas el agente por un envoltorio que se salta esas verificaciones, la frontera que creías tener se va con él.

¿Un git worktree aísla la base de datos, el servidor de desarrollo o los puertos?

No, y ese es el choque que sorprende a quien hizo todo bien. El worktree copia archivos versionados. No le da al agente de IA un PostgreSQL propio, un Redis propio, un puerto 3000 propio ni una pila Docker propia. Cinco agentes en cinco worktrees comparten una base de datos de desarrollo, y una migración destructiva ejecutada por cualquiera de ellos cae sobre los cinco.

El hilo de Hacker News está lleno de gente que chocó con esto y construyó alrededor. Un comentarista, francislavoie, describió un hook de Claude que ejecuta un script propio de creación de worktree, copiando node_modules y el .env al worktree nuevo "plus doing some edits to the .env to isolate it so it can run in parallel", esto es, editando el .env para que ese worktree corra en paralelo, y dándole a cada uno su propio nombre de proyecto en Docker Compose. Otro, madarco, dijo de una herramienta de sandbox que otro comentarista acababa de recomendar: "nono is great but you'll still won't be able to run multiple dev servers, dbs or test in the browser", o sea, que ni con ella se podrían correr varios servidores de desarrollo, varias bases o probar en el navegador. El comentarista que recomendó la herramienta, sbysb, lo discutió en el comentario siguiente, respondiendo que "With our profile setup you can do all three of those things", que con su configuración las tres cosas sí son posibles. No somos árbitro de esa discrepancia, porque el punto sobre worktrees no depende de ella, y el punto es NUESTRO y no de ninguno de los dos: nada en git worktree add asigna un puerto, una base de datos o un perfil de navegador.

Las mitigaciones baratas, en el orden en que las intentaríamos: darle a cada worktree su puerto mediante un .env editado, darle a cada uno su nombre de proyecto en Docker Compose, y hacer que la suite de pruebas use una base en memoria o una base por worktree en vez de la base de desarrollo compartida. Nada de eso viene de git worktree add. Es preparación que escribes una vez y reutilizas.

¿Cómo copiar el .env y el node_modules a un worktree nuevo?

El worktree es un checkout nuevo, así que los archivos ignorados por git como .env y .env.local simplemente no están ahí, y esa es, por nuestra experiencia, la primera cosa que se rompe en un worktree recién creado. Claude Code documenta un mecanismo para esto: un archivo .worktreeinclude en la raíz del proyecto, con la sintaxis de gitignore, listando los archivos a copiar a cada worktree nuevo. Según la documentación leída el 12 de agosto de 2026, solo se copian los archivos que coinciden con un patrón y además están ignorados por git, de modo que un archivo versionado nunca se duplica, y esto vale para worktrees creados con --worktree, para worktrees de subagente y para sesiones paralelas en la aplicación de escritorio.

Una advertencia que la página declara, y una que agregamos por nuestra cuenta. La página dice que, si reemplazas la creación de worktree por un hook WorktreeCreate, la copia tiene que ocurrir dentro de tu script. La nuestra, que la página no hace: el ejemplo de la propia página lista config/secrets.json, y un .worktreeinclude que lista un archivo de secretos es una decisión sobre radio de daño, porque pone una copia de ese archivo en todo directorio donde trabaja un agente.

Worktree, clon o contenedor: ¿cuál pide tu caso?

Las tres opciones responden a tres preguntas distintas, y el hilo de Hacker News discutió todas. El usuario firasd enmarcó la elección por lo que se quiere preservar: "[t]he answer is: non-pushed changes", los cambios aún no empujados, que es lo que protegen tanto el worktree como el clon. Un clon separado te da un .git propio, así que la superficie de hooks compartidos descrita arriba desaparece, y es más barato de lo que parece: como el usuario alchaplinsky observó en el mismo hilo, git clone --shared escribe un archivo de alternates que apunta a tu almacén de objetos y copia cero objetos. Confirmamos ese comportamiento el 12 de agosto de 2026.

Para aislamiento de proceso y de red, ninguno de los dos sirve. El usuario QuercusMax lo dijo en dos frases: "If you want to properly isolate things, use containers. That's not what worktrees are for", es decir, si quieres aislar de verdad, usa contenedores, porque no es para eso que existe el worktree. Ese es el techo honesto. Un contenedor o una máquina virtual es lo que quieres antes de dejar a un agente de IA corriendo sin supervisión, porque es la única opción de esta lista que aísla lo que el agente puede ejecutar, y no solo lo que puede editar.

Una regla de decisión gruesa: worktree para trabajo paralelo supervisado en una máquina en la que confías, clon cuando quieras un .git separado y hooks independientes, contenedor cuando el agente corre sin nadie mirando.

Qué no prueba este artículo

La demostración del hook establece que un .git compartido es alcanzable desde un worktree, en git 2.50.1, el 12 de agosto de 2026, sin core.hooksPath definido y sin sandbox de por medio. No dice nada sobre si una herramienta de sandbox bloquea o no esa misma escritura, y un comentarista del hilo afirma que el perfil que usa su equipo sí la bloquea. Tampoco mide con qué frecuencia esto causa daño real, y no tenemos datos que digan que lo causa con frecuencia. Todo comentario citado aquí es la experiencia de una persona nombrada, no una encuesta, y el hilo tiene gente defendiendo la posición contraria con la misma convicción, incluido quien dijo que los worktrees funcionan como se espera para la mayoría.

Una divulgación sobre una de las fuentes. El usuario alchaplinsky, citado dos veces aquí, es Alex Chaplinsky, quien escribió el texto enlazado al hilo y lo envió a Hacker News. Un comentarista de ahí acusó a Chaplinsky de armar un hombre de paja para vender un producto. Chaplinsky no respondió a la acusación en el hilo, y nosotros no la probamos. Sí verificamos las dos afirmaciones técnicas de Chaplinsky que aparecen en este artículo, y las dos se sostienen.

Los comportamientos de Claude Code descritos vienen de la documentación del propio fabricante, leída el 12 de agosto de 2026, y no de pruebas nuestras de cada verificación. La documentación puede quedarse atrás del producto en ambos sentidos. Por último, este artículo trata solo de frontera de aislamiento. Si correr muchos agentes en paralelo es buena idea es otra pregunta, y la respondimos con menos confianza en cuántos agentes de IA se pueden correr en paralelo.