Executar um único agente Codex é simples. Você abre um terminal, descreve uma tarefa e observa o trabalho acontecer. O problema começa quando são três. Um agente está refatorando o módulo de autenticação, outro está corrigindo um teste instável, um terceiro está rascunhando uma migração, e cada um vive em sua própria aba de terminal, com seu próprio histórico de rolagem. Dez minutos depois, você não lembra mais qual aba contém qual tarefa, se a migração terminou ou em qual branch a correção do teste foi parar. Os agentes estão bem. O que quebrou foi a sua capacidade de acompanhá-los.
Esse é o verdadeiro problema por trás de “gerenciar vários agentes Codex”. Não é a concorrência; o Codex roda em paralelo sem problemas em diretórios de trabalho separados. O problema é que o estado desse trabalho — o que cada agente está fazendo, o que terminou, o que falhou e o que precisa da sua revisão — acaba espalhado entre abas de terminal, pastas de worktree e a sua própria memória. Perder um desses pontos é perder o fio da meada.
O Sharkly existe exatamente para preencher essa lacuna. Você já tem agentes de código; o Sharkly os transforma em um time ao dar a cada execução de agente um registro compartilhado. Este artigo percorre primeiro a configuração manual, porque você precisa entender o que está automatizando, e depois mostra onde um quadro de tarefas se justifica. No final, você encontra um checklist que pode aplicar hoje mesmo.
O que “perder o fio da meada” significa de fato
Perder o fio da meada não é algo vago. É uma falha específica: o estado do seu trabalho não tem um único lugar onde morar. Quando você executa várias sessões do Codex manualmente, a verdade sobre cada tarefa fica dividida entre quatro lugares ao mesmo tempo. A instrução vive no terminal em que você a digitou, as mudanças vivem em um diretório de trabalho do Git, o status vive na sua cabeça e o resultado vive em um pull request que você ainda não abriu. Nada mantém esses quatro pontos sincronizados. Feche o terminal e a instrução se foi. Troque de aba e o status vira um chute. Quanto mais agentes você adiciona, mais cópias de “o que está acontecendo” você mantém — e você é o único ponto de integração que as mantém juntas.
Portanto, o objetivo de gerenciar vários agentes Codex é específico e vale enunciar com clareza: manter a tarefa, o progresso, as mudanças e o status de revisão de cada agente em um único lugar, em vez de dividi-los entre sessões de terminal privadas. Tudo o que vem a seguir é avaliado por esse único critério.
Etapa 1: isole cada agente com um worktree
O primeiro modo de falha é a colisão. Aponte dois agentes Codex para a mesma pasta e eles vão sobrescrever as edições um do outro, preparar os arquivos um do outro e produzir um diff que ninguém consegue ler. Os worktrees do Git resolvem isso de forma limpa, dando a cada agente seu próprio checkout do mesmo repositório, em seu próprio branch.
# One isolated working directory per task, each on its own branch
git worktree add ../repo-auth -b agent/auth-refactor
git worktree add ../repo-flaky -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration
Agora inicie uma sessão do Codex dentro de cada diretório. Cada agente enxerga apenas os próprios arquivos, faz commit no próprio branch e não pisa no trabalho dos outros.
cd ../repo-auth && codex # agent 1, auth refactor
cd ../repo-flaky && codex # agent 2, flaky test
Modo de falha a destacar aqui: worktrees resolvem colisões de arquivos, não o acompanhamento. Agora você tem três pastas com nomes quase idênticos e nenhum registro de qual tarefa cada uma contém. Adote uma convenção de nomes que codifique a tarefa (agent/<task>), porque em uma semana repo-2 e repo-3 não vão significar nada. Se quiser se aprofundar na mecânica, veja worktrees do Git para agentes de código com IA e o padrão mais amplo em executar várias tarefas do Codex ao mesmo tempo.
Etapa 2: mantenha as sessões à vista
Três agentes em três abas significa que você está a um Cmd+W acidental de matar uma tarefa em execução e perder seu histórico de rolagem. Um multiplexador de terminal como o tmux mantém cada sessão viva em janelas nomeadas das quais você pode se desconectar e depois se reconectar.
tmux new-session -d -s codex -n auth 'cd ../repo-auth && codex'
tmux new-window -t codex -n flaky 'cd ../repo-flaky && codex'
tmux new-window -t codex -n migration 'cd ../repo-migration && codex'
tmux attach -t codex
Janelas nomeadas (auth, flaky, migration) recuperam o rótulo que uma aba comum joga fora. Desconecte-se com Ctrl-b d, feche o notebook, reconecte-se na manhã seguinte e as sessões continuam lá.
Modo de falha a destacar aqui: o tmux mantém as sessões em execução; ele não diz quais delas precisam de você. Um agente que terminou há vinte minutos e um agente que encontrou um erro parecem idênticos vistos de fora: um painel silencioso. Você ainda precisa visitar cada janela e ler as últimas cem linhas para descobrir o status. Esse custo de verificação cresce a cada agente que você adiciona, e é o imposto que faz a configuração manual parecer mais pesada com o tempo.
Etapa 3: registre o status e a revisão em algum lugar duradouro
A última peça manual é justamente a que as pessoas pulam: anotar o que cada agente produziu e se você aceitou o resultado. O histórico de rolagem não é um registro. Ele desaparece, não é pesquisável entre tarefas e um colega de equipe não consegue lê-lo. A versão leve é uma checklist simples que você atualiza à mão.
TASK BRANCH STATUS REVIEW
auth refactor agent/auth-refactor done needs review
flaky test agent/flaky-test running -
db migration agent/db-migration failed: perm not reviewed
Esse é o trabalho inteiro em miniatura: um lugar duradouro onde progresso, bloqueios, resultados e revisão humana permanecem visíveis do pedido até a entrega. Mantenha-o com disciplina e você conseguirá gerenciar vários agentes a partir de um terminal por muito tempo. O detalhe é que você é o motor de sincronização, atualizando-o à mão toda vez que algo muda. Para saber mais sobre como tornar auditável a produção dos agentes, veja como acompanhar o trabalho concluído por agentes de código com IA.
Onde a configuração faça-você-mesmo para de escalar
Seja honesto sobre quando a abordagem manual é suficiente. Para um ou dois agentes Codex em tarefas bem delimitadas, worktrees + convenção de nomes + um arquivo de status mantido à mão é realmente suficiente. Não adicione ferramentas de que você não precisa; as peças móveis são quase zero e tudo cabe na sua cabeça.
A equação muda em um ponto previsível. Você sente isso quando:
- Você está executando três ou mais agentes e o custo de verificação (visitar cada painel, ler o final, memorizar o status) consome mais tempo do que os agentes economizam.
- O trabalho abrange mais de um repositório, então worktrees sozinhos deixam de ser um quadro único e claro.
- Alguém pergunta “o que os agentes estão fazendo agora?” e a única resposta honesta está no seu terminal e na sua memória.
Cada um desses pontos tem a mesma causa raiz apresentada no início do artigo: estado de trabalho sem um lar compartilhado. A configuração manual o mantém no único lugar que não escala: você. Times batem nesse muro mais rápido, e é por isso que as melhores ferramentas para gerenciar agentes de código com IA em paralelo convergem todas para o mesmo movimento: dar ao trabalho um lar fora do terminal.
O que um quadro de tarefas acrescenta
Um quadro de tarefas muda a unidade de gerenciamento de “uma sessão de terminal” para “uma Tarefa”. No Sharkly, você conecta o Computador no qual já executa o Codex e então atribui uma Tarefa a um Agente Codex, em vez de digitar em um painel. O Agente roda em seu próprio worktree isolado, e execução, progresso, bloqueios e resultados retornam para a Tarefa. Você para de verificar; o quadro já sabe o que terminou e o que falhou.
A divisão do trabalho é intencional e vale enunciar como um limite: o Sharkly não substitui o Codex. O Codex faz a execução. O Sharkly adiciona a tarefa compartilhada, o Computador, o contexto e a camada de revisão ao redor dele. Os agentes pesquisam, executam, testam e reportam; as pessoas definem a direção, concedem autoridade e aceitam o resultado. A automação para onde o seu julgamento é necessário, ou seja, no portão de revisão, não no código.
É isso que o arquivo de status manual tentava alcançar, agora de forma duradoura e compartilhada. Três coisas que o terminal não consegue oferecer surgem daí:
- Status sem verificação constante. Cada Tarefa mostra em execução, concluída, bloqueada ou precisa de revisão sem que você visite um painel.
- Um quadro único entre repositórios. Tarefas de vários repositórios e vários Agentes ficam em um único Espaço, então mais agentes não significa mais terminais para cuidar. É a mesma razão pela qual times executam Claude Code e Codex juntos a partir de um só lugar.
- Uma etapa de revisão que se sustenta. Os resultados aguardam em um portão human-in-the-loop com o resumo das mudanças e as evidências anexadas, de modo que nada é mesclado só porque você esqueceu que estava pendente.
Você pode construir tudo isso à mão com worktrees e disciplina, ou usar o Sharkly para gerenciar o fluxo de trabalho quando o número de agentes aumenta. O Codex permanece exatamente como está; o gerenciamento sai das suas costas. Se você já executa vários agentes Codex, esse é o problema em torno do qual o Sharkly foi projetado.
O checklist que você pode aplicar hoje
Quer você continue no manual ou migre para um quadro, este é o mínimo para não perder o fio da meada:
- [ ] Um worktree isolado por agente, em um branch nomeado conforme a tarefa, nunca dois agentes na mesma pasta.
- [ ] Uma convenção de nomes que codifique a tarefa, de modo que
agent/auth-refactorseja melhor querepo-3. - [ ] Sessões de longa duração (tmux ou um quadro) das quais você possa se desconectar e reconectar sem matar o trabalho.
- [ ] Um registro de status duradouro fora do histórico de rolagem do terminal: tarefa, branch, status, estado de revisão.
- [ ] Um portão de revisão explícito; nenhum branch é mesclado até que uma pessoa o aceite.
- [ ] Uma checagem de quantidade: com três ou mais agentes, ou dois ou mais repositórios, tire o status da sua cabeça.
Use a versão manual até que o imposto da verificação constante doa. Quando doer, execute seus agentes de código atuais pelo Sharkly para que o acompanhamento seja trabalho do quadro, não seu.
Perguntas frequentes
Quantos agentes Codex consigo executar de forma realista ao mesmo tempo? Tantos quantos sua máquina e seus limites de taxa permitirem; o teto que você atinge primeiro costuma ser humano, não técnico. Acompanhar três ou mais manualmente é onde a maioria das pessoas perde o fio da meada. Veja threads concorrentes e subagentes do Codex para os limites do lado da execução.
Um quadro de tarefas substitui o Codex? Não. O Codex executa; o quadro gerencia atribuição, isolamento, contexto e revisão ao redor dele. Eles se complementam.
