Se você leu meu post sobre worktrees no Claude Code, sabe que a mágica da coisa toda é a flag: --worktree. Você executa, e um agente trabalha na sua própria cópia isolada do repositório. Você lança três instâncias, e tem três agentes rodando em paralelo sem interferir um no outro. Mágica pura.
Agora você abre o Codex CLI, procura a flag equivalente e… não existe.
Não há --worktree. Não há --tmux. Não há isolation: worktree para agentes customizados. A issue #12862 está aberta no GitHub pedindo exatamente essa funcionalidade, com algumas pessoas que já implementaram isso em seus forks, mas nada foi incorporado oficialmente. O paralelismo nativo do Codex CLI, até hoje, não existe.
Isso significa que você não pode trabalhar em paralelo com o Codex? Não. Significa que você precisa dar um jeito. E por “dar um jeito”, quero dizer usar três comandos do git e tomar alguns cuidados para não quebrar a cara.
O plano: worktrees manuais + um Codex por diretório
A ideia é a mesma do Claude Code, mas sem a automação. Você cria os worktrees, executa os agentes e limpa tudo depois. É artesanal, mas funciona.
| |
Agora você tem quatro diretórios: o principal e três worktrees. Cada um com sua branch, sua staging area e seu HEAD independente. Eles compartilham o banco de dados do git (o .git/), mas, fora isso, são cópias isoladas.
O próximo passo é lançar um Codex em cada um:
| |
Três agentes, três tarefas, zero interferência entre eles. Cada Codex enxerga apenas seu próprio worktree e trabalha na sua branch.
O bug que vai te pegar: sessões compartilhadas
Essa é a parte que não aparece em nenhum tutorial oficial. Existe um bug conhecido (#11435) no Codex CLI: todas as instâncias compartilham o diretório de sessão ~/.codex/. Se você lançar três instâncias do Codex em paralelo, elas podem carregar o contexto de outra instância, corrompendo a execução.
Em termos simples: o agente que deveria corrigir testes, de repente, acha que está implementando autenticação, porque leu a sessão do outro.
A solução é forçar um diretório de sessão diferente para cada instância:
| |
Se CODEX_HOME não funcionar na sua versão (a variável mudou de nome em algumas versões), a alternativa drástica é criar um config.toml separado em cada worktree:
| |
Não é elegante. É uma gambiarra. Mas funciona, e é o que temos até que a issue #12862 seja resolvida.
Automatizando um pouco: um script wrapper
Se você precisar fazer isso com frequência, um script pode evitar erros:
| |
Uso:
| |
Cada execução cria um worktree, uma sessão isolada, lança o Codex e limpa a sessão ao final. O worktree permanece para que você possa revisar o resultado antes de fazer o merge.
Com tmux: paralelismo visual
Se quiser ver os três agentes trabalhando ao mesmo tempo, o tmux é seu aliado:
| |
Três painéis, três agentes, tudo à vista. Não é o mesmo que claude --worktree --tmux, mas o resultado visual é idêntico.
Ferramentas de terceiros que já resolvem isso
Se montar tudo isso manualmente parecer complicado, existem soluções automatizadas criadas pela comunidade:
parallel-code: executa Claude Code, Codex e Gemini CLI em worktrees separados automaticamente. Você define a tarefa e o agente, e ele cuida de criar o worktree, lançar o processo e gerenciar a sessão.
ccmanager: gerenciador de sessões para múltiplos agentes com isolamento por worktree. Mais completo, suporta diversos CLIs de agentes.
Ambos são projetos comunitários, não oficiais. Mas preenchem o vazio deixado pela OpenAI.
O que a Codex App tem (e o CLI não)
Para esclarecer: o Codex App de desktop (lançado em março de 2026) já possui worktrees nativos. Quando você cria um thread, pode escolher o modo “Worktree”, e as automations rodam em worktrees dedicados em segundo plano.
Mas o App exige a aplicação de desktop rodando. Se você trabalha em um servidor, em um container de CI ou simplesmente prefere o terminal, o App não serve. E o CLI, usado nesses contextos, não possui a funcionalidade.
É como se o Git tivesse worktrees na GUI, mas não na linha de comando. Absurdo, mas é a realidade.
Comparação honesta
| Capacidade | Claude Code | Codex CLI | Codex CLI + worktrees manuais |
|---|---|---|---|
| Criar worktree | --worktree (1 flag) | Não existe | git worktree add (manual) |
| Sessões paralelas | --tmux (1 flag) | Bug #11435 | tmux manual + sessões separadas |
| Agentes isolados | isolation: worktree | Não existe | Script wrapper |
| Limpeza automática | Sim | N/A | Manual (git worktree remove) |
| Merge de volta | Automático | N/A | git merge padrão |
O Claude Code tornou os worktrees invisíveis — um detalhe de implementação que nem passa pela sua cabeça. No Codex CLI, os worktrees são encanamento que você mesmo tem que instalar.
Funciona? Sim. É a mesma coisa? Não. A diferença entre ter automação nativa e “dar um jeito” é como dirigir um carro automático ou usar um de manivela. Ambos chegam ao destino, mas em um, você aproveita a viagem. No outro, você ganha calo na mão.
Enquanto aguardamos a issue #12862
A boa notícia é que há pessoas trabalhando nisso. A issue já possui implementações em forks, votos e certa tração. É uma questão de tempo.
Enquanto isso, os worktrees manuais funcionam. Não são bonitos, não são automáticos, mas permitem paralelismo real no Codex CLI hoje. Três comandos de git, um pouco de tmux e atenção ao bug de sessões compartilhadas. É tudo o que você precisa.
E se você está se perguntando por que o Claude Code já resolveu isso há meses e o Codex ainda não — bom, às vezes a vantagem de ser segundo é que você pode copiar o que funciona. Mas é preciso copiar, e isso ainda não aconteceu.
TL;DR: Codex CLI não possui --worktree nem --tmux. Para trabalhar em paralelo, crie worktrees com git worktree add, execute um Codex em cada um com sessões separadas (atenção ao bug #11435 de sessões compartilhadas) e use tmux para visualizar tudo. Ou instale parallel-code ou ccmanager que automatizam o processo. A Codex App de desktop já possui worktrees nativos, mas o CLI ainda não.