Dá para usar Claude Code e Codex no mesmo projeto ao mesmo tempo?

Dois agentes editando o mesmo arquivo ao mesmo tempo é a forma mais rápida de perder trabalho sem nem perceber que perdeu

Quem já assina os dois sente essa vontade rápido: por que deixar um agente parado enquanto o outro trabalha? Aí bate o receio, e é um receio legítimo

Um salva o arquivo, o outro sobrescreve, e você fica com um repositório que ninguém sabe explicar

A boa notícia é que os dois produtos já resolveram isso do mesmo jeito: isolamento por diretório

Neste post eu mostro como abrir cada agente no seu próprio worktree, onde cada ferramenta guarda as coisas, quais conflitos aparecem na prática e como dividir as tarefas pra um não desfazer o do outro

O que você precisa antes de rodar os dois em paralelo

A lista é curta, mas o primeiro item não é negociável:

• O projeto precisa ser um repositório Git: os worktrees do Codex usam git worktree por baixo, então projeto sem Git simplesmente não entra nessa brincadeira
• Claude Code e Codex instalados e autenticados, cada um no seu login
• Saber onde cada um coloca as coisas, porque eles não moram no mesmo lugar

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Essa última parte é a que mais confunde:

O CODEX_HOME por padrão é ~/.codex, que é onde o Codex guarda o estado local dele

E cada ferramenta lê o seu próprio arquivo de regra: o Claude Code carrega o CLAUDE.md no início de toda sessão, o Codex lê o AGENTS.md automaticamente antes de começar o trabalho

Se você já passou por rodar duas sessões do Claude Code no mesmo repo, a lógica aqui é a mesma, só que agora com dois produtos diferentes disputando o mesmo .git

Como rodar Claude Code e Codex em paralelo no mesmo repositório

1. Abra a sessão isolada do Claude Code

claude --worktree feature-login

A versão curta funciona igual:

claude -w feature-login

Isso cria o diretório .claude/worktrees/feature-login na raiz do repo e a branch worktree-feature-login

Se você omitir o nome, o próprio Claude Code gera um (a doc dá bright-running-fox como exemplo) 😀

O erro comum deste passo: entrar no worktree e estranhar que os arquivos que você estava editando na sessão principal não estão ali. É isso mesmo que a gente quer! Caminho separado e branch separada significam que uma sessão não lê o estado de arquivo em andamento da outra, mesmo compartilhando o mesmo histórico e o mesmo .git

2. Leve os arquivos gitignored para o worktree novo

Cria um .worktreeinclude na raiz do projeto, com sintaxe de .gitignore:

.env
.env.local

O Claude Code copia pra cada worktree novo apenas os arquivos que casam com o padrão E estão no gitignore

E isso vale pra todo worktree que ele cria: os da flag --worktree, os de subagente e as sessões paralelas do app de desktop

O erro comum deste passo: tentar usar o .worktreeinclude pra duplicar arquivo versionado. Não vai: arquivo que está no Git nunca é duplicado por esse mecanismo

3. Abra o chat do Codex no worktree dele

Aqui muda o ponto de partida, e isso importa MUITO

O worktree do Codex parte do commit HEAD da branch que você selecionou ao iniciar o chat, e se essa branch tiver alterações locais, o Codex aplica as alterações não commitadas no worktree

Ou seja: o que está sujo na sua árvore vai junto

O erro comum deste passo: procurar a branch do Codex depois pra fazer merge. Ela não existe, o worktree fica em detached HEAD justamente pra não poluir as branches do repositório

4. Dê a mesma regra de projeto pros dois

No lado do Claude Code, o CLAUDE.md é lido no começo de cada sessão e aceita importar outros arquivos:

@docs/padroes-de-codigo.md
@docs/comandos.md

Os importados também carregam no início da sessão

No lado do Codex, o AGENTS.md é carregado automaticamente, e dá pra criar o primeiro rodando dentro de uma sessão do CLI:

/init

O Codex monta uma cadeia de instruções por escopo: o global no diretório home dele e depois os do projeto

O erro comum deste passo: escrever regra só num dos dois e achar que o outro adivinha. São arquivos de produtos diferentes, mantenha o conteúdo espelhado na mão

5. Ajuste a política de execução do Codex

A configuração fica em .codex/config.toml, e o Codex resolve config em camadas: os arquivos do projeto, da raiz até o diretório atual (o mais próximo vence), mais o ~/.codex/config.toml, além dos perfis com --profile

As duas chaves que você quer olhar são approval_policy e sandbox_mode

sandbox_mode = "workspace-write"
approval_policy = "on-request"

Esse par é citado na doc como o preset de automação local de menor risco

E o sandbox não é teatro: ele aplica restrição de sistema de arquivos e de rede no nível do kernel, com Seatbelt no macOS e Landlock + seccomp no Linux

6. Feche o ciclo trazendo o trabalho de volta, um de cada vez

Do lado do Claude Code o trabalho está na branch worktree-<nome>, então você integra por ela

Do lado do Codex não tem branch, o worktree está em detached HEAD, então decida o destino daquele trabalho antes de sair do chat

O erro comum deste passo: querer integrar os dois ao mesmo tempo. Paralelo é pra produzir, integração é fila indiana

Os conflitos mais comuns e como evitar cada um

Um agente reverte a edição do outro:

Causa: as duas sessões estão apontando pro mesmo diretório de trabalho

Enquanto o diretório é o mesmo, não existe prompt que salve, os dois estão escrevendo no mesmo arquivo físico

Solução: worktree dos dois lados, claude --worktree <nome> de um lado e o worktree do Codex do outro

Como prevenir: nunca abra o segundo agente na raiz do projeto "só pra dar uma olhada rápida"

O worktree do Codex já nasce com alterações que você não pediu:

Causa: ele parte do HEAD da branch escolhida e aplica as alterações não commitadas dessa branch no worktree

Solução: antes de abrir o chat, olhe o estado da branch que você vai selecionar

Como prevenir: comece o chat com a árvore limpa quando você quiser um ponto de partida previsível

A sessão isolada não roda porque falta o arquivo de ambiente:

Causa: o arquivo está no gitignore, e worktree não é cópia da sua pasta, é checkout do Git

Solução: .worktreeinclude na raiz, listando o que precisa viajar junto

Como prevenir: coloque esse arquivo no repositório logo no primeiro dia, antes de precisar dele às 23h

O repositório enche de branch:

Causa: comportamentos diferentes. O Claude Code cria a branch worktree-<nome> a cada worktree, o Codex fica em detached HEAD pra não criar branch nenhuma

Solução: trate a branch worktree-<nome> como descartável depois que o trabalho dela foi integrado

Como prevenir: nome de worktree que descreve a tarefa, não teste2 nem novo 🙂

Como dividir as tarefas para um agente não desfazer o do outro

Isolar o diretório resolve o conflito de arquivo

Mas ainda dá pra ter conflito de intenção: dois agentes resolvendo o mesmo problema de formas diferentes

A divisão que funciona é a que dá fronteira clara pra cada um:

• Por camada: um no backend, outro no front. As mudanças raramente pisam no mesmo arquivo
• Por feature: cada agente no seu worktree, cada worktree com uma feature fechada
• Implementação x revisão: um escreve, o outro lê o resultado e escreve teste. Aqui o segundo agente nem precisa editar o mesmo código

Do lado do Claude Code dá pra empurrar isso pra dentro da própria sessão: um subagente customizado pode rodar em worktree próprio com isolation: worktree no frontmatter dele

---
name: revisor
isolation: worktree
---

E tem um detalhe bom aí: quando o subagente termina sem alterações, o Claude Code remove o worktree temporário sozinho, sem lixo sobrando

Do lado do Codex, o trabalho não interativo é o que combina melhor com paralelo, porque não exige você olhando a tela:

codex exec "rodar a suíte de testes e listar as falhas"
codex exec resume --last
codex exec resume <SESSION_ID>

A flag --json faz ele emitir eventos em JSON por linha, o que ajuda quando você quer acompanhar sem ficar lendo terminal

Se o seu caso não é um repo com dois agentes e sim dois repos diferentes, a lógica de separação muda um pouco e eu já falei disso em trabalhar em dois projetos ao mesmo tempo

O que aprendi rodando os dois agentes de verdade

Eu já rodei dois agentes em paralelo numa mesma sessão de gravação, cada um na sua própria pasta em branco, pra comparar resultado lado a lado

Não foi Claude Code contra Codex: foi Codex contra Antigravity

Mas a mecânica é exatamente a que eu descrevi aqui, e foi ela que deixou a comparação de pé

Antes de mandar qualquer prompt, eu criei um arquivo de contexto do projeto (análise, stack, regras e comandos) e usei o MESMO arquivo nos dois, copiando na mão de uma pasta pra outra e abrindo os dois pra conferir que eram idênticos

Depois apliquei 5 prompts idênticos em cada ferramenta, cada prompt cobrindo uma etapa do projeto

E fechei cada prompt com uma trava explícita de escopo (não cria upload, não cria formulário, nada além do que foi pedido), porque em comparação anterior eu senti as ferramentas passando do que eu tinha pedido

Essa parte vale pro seu repo compartilhado: agente sem limite no prompt é agente mexendo em arquivo que não era dele

Sobre custo, uma coisa me surpreendeu: a cota do plano Pro do Codex não chegou a 50% durante os testes e a gravação do mini curso, considerando as janelas de cota que eu acompanho

Ou seja, manter dois agentes ligados no mesmo projeto costuma pesar menos do que a galera imagina

O que muda mesmo não é o consumo, é a interpretação: o mesmo pedido vira código diferente em cada um

Uma confissão de bastidor: mesmo com a documentação descrevendo disparo de vários agentes em paralelo, na prática eu achei difícil confirmar se aquilo estava de fato acontecendo

Por isso eu prefiro o isolamento explícito, com worktree e pasta separada: dá pra olhar o diretório e ver o que existe, sem fé

Veja o teste em vídeo

No vídeo abaixo eu mostro os 5 prompts idênticos rodando e o comportamento de cada agente diante do mesmo pedido, do setup até o polimento

Próximo passo

A regra central é uma só: paralelo funciona quando cada agente tem diretório e ponto de partida próprios, e a integração acontece um de cada vez

O resto é consequência disso

Seu próximo passo, na ordem:

1. Cria o worktree da primeira sessão com claude --worktree <nome>
2. Escreve o CLAUDE.md e o AGENTS.md do projeto, com o mesmo conteúdo de regra
3. Coloca um .worktreeinclude com os arquivos de ambiente que precisam viajar
4. Começa com uma tarefa pequena e bem separada em cada agente antes de escalar

Depois que o primeiro ciclo fechar sem susto, aí sim você abre o terceiro worktree

Bora testar? 😀

até o próximo post!