Clase 5 · 20 min
Dos agentes en el mismo checkout no dan error: uno borra el trabajo del otro en silencio. Worktree le da a cada uno su propia copia y convierte la pérdida silenciosa en un conflicto visible a la hora del merge. Sandbox hace lo mismo con los permisos: el revisor lee, pero no escribe. En esta clase compruebas las dos cosas sin gastar cuota.
Empezar la clase
Objetivo: darle a cada agente que escribe un worktree propio y a cada revisor un sandbox de solo lectura, y comprobar la diferencia.
Haz clic en cada una. El ensayo de más abajo prueba las dos primeras.
Worktree aísla archivos, no procesos: dos worktrees todavía comparten puertos, base de datos local y cuota.
Repositorio desechable y dos agentes falsos que leen, piensan (A 2 s, B 1 s) y escriben el archivo completo.
E=${TMPDIR:-/tmp}/ensaio-multi/wt; rm -rf $E && mkdir -p $E && cd $E
git init -q repo && cd repo && git config user.name ensaio && git config user.email ensaio@local
printf 'versao = 1\nnome = treino\ncor = azul\n' > config.txt && git add -A && git commit -qm base
# un "agente" lee el archivo, piensa $4 s y escribe el archivo completo (como la herramienta Write); A piensa más que B
agente() { c=$(cat "$1/config.txt"); sleep "$4"; printf '%s\n' "$c" | sed "$2" > "$1/config.txt"; echo "$3 gravou"; }
echo "## A) dois agentes no MESMO checkout"
agente . 's/azul/verde/' A 2 & agente . 's/versao = 1/versao = 2/' B 1 & wait
cat config.txt
git checkout -q config.txt
echo "## B) um worktree para cada agente"
git worktree add -q ../wt-a -b agente-a && git worktree add -q ../wt-b -b agente-b
agente ../wt-a 's/azul/verde/' A 2 & agente ../wt-b 's/versao = 1/versao = 2/' B 1 & wait
git -C ../wt-a commit -qam "A: cor" && git -C ../wt-b commit -qam "B: versão"
git merge -q agente-a && git merge -q --no-edit agente-b && cat config.txt
git worktree list | wc -l## A) dois agentes no MESMO checkout B gravou A gravou versao = 1 nome = treino cor = verde ## B) um worktree para cada agente B gravou A gravou Auto-merging config.txt versao = 2 nome = treino cor = verde 3
En A, los dos dijeron "gravou", pero solo una de las dos modificaciones sobrevivió: A leyó el archivo antes de que B escribiera y, como piensa más, escribió encima, y la versión 2 desapareció. En B, las dos modificaciones entraron.
Las esperas diferentes (A 2 s, B 1 s) fijan el orden para que el ensayo dé siempre el mismo resultado (18 de 18 rondas iguales el 19/10/2026). Con esperas iguales, quien escribe al final cambia en cada ronda, pero nunca quedan las dos modificaciones.
Dos worktrees cambiando la MISMA línea (cor roxo × cor preto), capturado en el mismo repositorio:
Auto-merging config.txt CONFLICT (content): Merge conflict in config.txt Automatic merge failed; fix conflicts and then commit the result. saída: 1
En un checkout único, esto sería una pérdida callada. Aquí git se detiene y lo muestra. Quien lo resuelve es el orquestador (o tú), no uno de los dos agentes.
Claude Code 2.1.303 y Codex CLI 0.163.0, según las docs leídas el 19/10/2026.
claude --worktree [nombre] crea el worktree en .claude/worktrees/[nombre] y abre la sesión allí. Necesita al menos un commit y, en el modo interactivo, que la carpeta esté marcada como de confianza (ejecuta claude una vez en ella).
Los archivos ignorados por git, como .env, no van al worktree; lístalos en un .worktreeinclude en la raíz para copiarlos.
Los hooks con ${CLAUDE_PROJECT_DIR} siguen corriendo en el checkout principal; lo que acompaña al worktree es el campo cwd del hook.
En el frontmatter, isolation: worktree le da al subagente un worktree temporal, que desaparece solo si no cambia nada.
Ojo: la branch parte de la branch predeterminada, no del HEAD de tu sesión. Lo que no commiteaste no está ahí.
La sesión en segundo plano (claude --bg) entra en un worktree antes de editar. Los agent teams no aíslan: divide los archivos por dueño.
Una limpieza periódica elimina los worktrees creados por Claude que superaron cleanupPeriodDays y no guardan trabajo.
codex exec --worktree "[pedido]" corre en un worktree gestionado (no se combina con resume ni con --ephemeral). En la TUI, /worktree.
Sandbox: -s read-only para quien solo revisa, -s workspace-write para quien ejecuta. La doc pide evitar --dangerously-bypass-approvals-and-sandbox fuera de una VM dedicada.
codex sandbox corre un comando cualquiera con las mismas reglas que Codex usa en los suyos. No llama a ningún modelo.
E=${TMPDIR:-/tmp}/ensaio-multi/sbx; rm -rf $E && mkdir -p $E && cd $E
codex sandbox -c sandbox_mode=read-only -- bash -c 'echo x > a.txt 2>/dev/null && echo "read-only: gravou" || echo "read-only: bloqueado na pasta"'
codex sandbox -c sandbox_mode=workspace-write -- bash -c 'echo x > b.txt && echo "workspace-write: gravou na pasta"; echo x > ~/fora-sbx.txt 2>/dev/null && echo "gravou fora" || echo "workspace-write: bloqueado fora da pasta"'
ls; ls ~/fora-sbx.txt 2>&1 | tail -1# terminal 1: abre la sesión ya dentro del worktree (no hace falta pedir nada) cd ~/treino-multi && claude --worktree treino-a # terminal 2, con la sesión abierta: cd ~/treino-multi && git worktree list | grep -c ".claude/worktrees/treino-a" git branch --list worktree-treino-a # terminal 1: /exit (worktree sin cambios: elige remover, si pregunta). Después: git worktree list | wc -l
bash: line 1: a.txt: Read-only file system read-only: bloqueado na pasta workspace-write: gravou na pasta bash: line 1: ~/fora-sbx.txt: Read-only file system workspace-write: bloqueado fora da pasta b.txt ls: cannot access '~/fora-sbx.txt': No such file or directory
Edición declarada: la ruta de la carpeta personal aparece como ~. El read-only no escribió ni dentro; el workspace-write escribió b.txt y fue bloqueado fuera.
El worktree parte de un commit. En un git init recién creado, claude --worktree termina antes de llamar al modelo (capturado con Claude Code 2.1.303):
Error creating worktree: Failed to resolve base branch "HEAD": git rev-parse returned no commit for HEAD (for example in a new repository, or on a branch without a commit yet), so Claude Code has nothing to base a worktree on. (…) saída: 1
Haz un commit y vuelve a correrlo.
Dos ensayos y un worktree de verdad.
Corre el ensayo de los dos agentes.
Listo cuando: en A, solo uno de los dos cambios sobrevive: el cat config.txt muestra versao = 1 y cor = verde (el cambio de B desapareció); en B, muestra versao = 2 y cor = verde; la última línea es 3.
Corre el ensayo del codex sandbox.
Listo cuando: aparecen read-only: bloqueado na pasta, workspace-write: gravou na pasta y workspace-write: bloqueado fora da pasta, y ls muestra solo b.txt.
En el proyecto de práctica, abre claude --worktree treino-a en una terminal y verifica desde otra. Al salir, un worktree limpio se elimina (en una sesión con nombre, Claude pregunta antes).
Listo cuando: con la sesión abierta, git worktree list | grep -c ".claude/worktrees/treino-a" → 1 y la branch worktree-treino-a existe; después de salir, git worktree list | wc -l → 1 (si quedó, git worktree remove .claude/worktrees/treino-a).
Pregunta 1 de 4
Dos agentes editaron el mismo archivo en el mismo checkout y los dos dijeron "gravou". ¿Qué puede haber pasado?competencia
Pregunta 2 de 4
¿Por qué el conflicto en el merge de dos worktrees es una buena señal?competencia
Pregunta 3 de 4
Un subagente con isolation: worktree no encuentra el cambio que hiciste y no commiteaste. ¿Por qué?
Pregunta 4 de 4
¿Qué sandbox de Codex darle a un revisor que solo ejecuta pruebas y lee?
Elige una alternativa. La explicación aparece después de tu intento.