Aula 5 · 20 min
Dois agentes no mesmo checkout não dão erro: um apaga o trabalho do outro em silêncio. Worktree dá a cada um a sua cópia e transforma a perda silenciosa em conflito visível na hora do merge. Sandbox faz o mesmo com as permissões: o revisor lê, mas não grava. Nesta aula você prova as duas coisas sem gastar cota.
Começar a aula
Objetivo: dar a cada agente que escreve um worktree próprio e a cada revisor um sandbox só de leitura, e provar a diferença.
Clique em cada um. O ensaio logo abaixo prova os dois primeiros.
Worktree isola arquivos, não processos: dois worktrees ainda dividem portas, banco local e cota.
Repositório descartável e dois agentes falsos que leem, pensam (A 2 s, B 1 s) e gravam o arquivo inteiro.
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
# um "agente" lê o arquivo, pensa $4 s e grava o arquivo inteiro (como a ferramenta Write); A pensa mais 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
Em A, os dois disseram "gravou", mas só uma das duas mudanças sobreviveu: A leu o arquivo antes de B gravar e, como pensa mais, gravou por cima, e a versão 2 sumiu. Em B, as duas mudanças entraram.
As esperas diferentes (A 2 s, B 1 s) fixam a ordem para o ensaio dar sempre o mesmo resultado (18 de 18 rodadas iguais em 19/10/2026). Com esperas iguais, quem grava por último muda a cada rodada, mas nunca sobram as duas mudanças.
Dois worktrees mudando a MESMA linha (cor roxo × cor preto), capturado no mesmo repositório:
Auto-merging config.txt CONFLICT (content): Merge conflict in config.txt Automatic merge failed; fix conflicts and then commit the result. saída: 1
No checkout único, isso seria uma perda calada. Aqui o git para e mostra. Quem resolve é o orquestrador (ou você), não um dos dois agentes.
Claude Code 2.1.303 e Codex CLI 0.163.0, pelas docs lidas em 19/10/2026.
claude --worktree [nome] cria o worktree em .claude/worktrees/[nome] e abre a sessão lá. Precisa de pelo menos um commit e, no modo interativo, da pasta marcada como confiável (rode claude uma vez nela).
Arquivos ignorados pelo git, como .env, não vão para o worktree; liste-os num .worktreeinclude na raiz para copiar.
Hooks com ${CLAUDE_PROJECT_DIR} continuam rodando no checkout principal; o campo cwd do hook é que acompanha o worktree.
No frontmatter, isolation: worktree dá ao subagente um worktree temporário, que some sozinho se ele não mudar nada.
Atenção: a branch parte do branch padrão, não do HEAD da sua sessão. O que você não commitou não está lá.
Sessão em segundo plano (claude --bg) entra num worktree antes de editar. Agent teams não isolam: divida os arquivos por dono.
Uma limpeza periódica remove worktrees criados pelo Claude que passaram de cleanupPeriodDays e não guardam trabalho.
codex exec --worktree "[pedido]" roda num worktree gerenciado (não combina com resume nem --ephemeral). Na TUI, /worktree.
Sandbox: -s read-only para quem só revisa, -s workspace-write para quem executa. A doc pede para evitar --dangerously-bypass-approvals-and-sandbox fora de uma VM dedicada.
codex sandbox roda um comando qualquer com as mesmas regras que o Codex usa nos dele. Não chama 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 a sessão já dentro do worktree (não precisa pedir nada) cd ~/treino-multi && claude --worktree treino-a # terminal 2, com a sessão aberta: cd ~/treino-multi && git worktree list | grep -c ".claude/worktrees/treino-a" git branch --list worktree-treino-a # terminal 1: /exit (worktree sem mudanças: escolha remover, se perguntar). Depois: 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
Edição declarada: o caminho da pasta pessoal aparece como ~. O read-only não gravou nem dentro; o workspace-write gravou b.txt e foi barrado fora.
Worktree parte de um commit. Num git init recém-criado, o claude --worktree sai antes de chamar o modelo (capturado com 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
Faça um commit e rode de novo.
Dois ensaios e um worktree de verdade.
Rode o ensaio dos dois agentes.
Pronto quando: em A, só uma das duas mudanças sobrevive: o cat config.txt mostra versao = 1 e cor = verde (a mudança de B sumiu); em B, mostra versao = 2 e cor = verde; a última linha é 3.
Rode o ensaio do codex sandbox.
Pronto quando: aparecem read-only: bloqueado na pasta, workspace-write: gravou na pasta e workspace-write: bloqueado fora da pasta, e ls mostra só b.txt.
No projeto de treino, abra claude --worktree treino-a num terminal e confira de outro. Ao sair, um worktree limpo é removido (numa sessão com nome, o Claude pergunta antes).
Pronto quando: com a sessão aberta, git worktree list | grep -c ".claude/worktrees/treino-a" → 1 e a branch worktree-treino-a existe; depois de sair, git worktree list | wc -l → 1 (se ficou, git worktree remove .claude/worktrees/treino-a).
Pergunta 1 de 4
Dois agentes editaram o mesmo arquivo no mesmo checkout e os dois disseram "gravou". O que pode ter acontecido?competência
Pergunta 2 de 4
Por que o conflito no merge de dois worktrees é um sinal bom?competência
Pergunta 3 de 4
Um subagente com isolation: worktree não acha a mudança que você fez e não commitou. Por quê?
Pergunta 4 de 4
Qual sandbox do Codex dar a um revisor que só roda testes e lê?
Escolha uma alternativa. A explicação aparece depois da sua tentativa.