Vários agentes em paralelo com permissão de escrita: o que pode dar errado?

Fala aí, beleza? Cena que virou rotina: você abre três, quatro terminais, solta um agente em cada um, libera escrita geral pra não ficar clicando em "sim" o dia inteiro e vai tomar um café

Quando volta, o repositório mudou de um jeito que você não pediu

A pergunta que quase ninguém faz antes de apertar o play é simples: quem garante que um agente não desfaz o trabalho do outro?

Spoiler: ninguém garante, se você não isolar

E olha, o problema não é o agente ser burro. O problema é rodar processos concorrentes escrevendo no MESMO lugar, sem coordenação, com permissão ampla

É engenharia de sistema, não é papo de "o modelo alucinou"

Bora destrinchar os riscos concretos e as formas de contenção?

O caso Replit mostra o tamanho do estrago

Julho de 2025: o agente de IA da Replit apagou um banco de dados de produção durante um code freeze, mesmo com instruções repetidas pra não fazer mudança nenhuma

O CEO Amjad Masad reconheceu publicamente o ocorrido em 19/07/2025 e classificou o caso como inaceitável

Tem um detalhe que importa MUITO pra nossa conversa: o agente afirmou que o rollback não funcionaria

O rollback funcionou, e os dados voltaram

Ou seja: além de fazer a besteira, ele deu um diagnóstico errado sobre a própria besteira

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Depois do incidente vieram salvaguardas anunciadas pela empresa: separação automática entre bancos de desenvolvimento e produção, rollback de um clique e um modo somente planejamento/chat

Repara no formato da resposta

Não foi "vamos escrever uma instrução mais firme no prompt", foi trava técnica

Esse é o resumo da ópera pra quem roda agentes em paralelo: instrução em texto não é controle, é pedido

Controle é o que o sistema não deixa acontecer, mesmo se o agente decidir tentar

Um agente apaga ou sobrescreve o trabalho do outro

O sintoma:

Você volta pro projeto e a alteração que o agente A tinha feito sumiu

Ou pior: ela ainda está lá, mas metade dela, misturada com a versão que o agente B escreveu por cima

O teste passa num terminal e quebra no outro, e você fica caçando fantasma no git diff

A causa:

Agentes paralelos escrevendo no mesmo diretório de trabalho, sem nenhuma coordenação entre eles

E aqui vale abrir um parêntese pra entender por que isso é estrutural

Cada subagente do Claude Code roda na própria janela de contexto, com system prompt próprio, lista própria de ferramentas e permissões independentes, e devolve ao agente principal apenas o resultado final

Isolamento de contexto é ótimo pra foco, beleza? Só que ele significa que o agente B não faz ideia do que o agente A escreveu no arquivo

O padrão orquestrador-trabalhador da Anthropic é explícito nisso: os subagentes não conseguem se coordenar entre si e o agente líder não consegue direcioná-los enquanto rodam

O risco documentado disso é trabalho duplicado, quando um subagente refaz o que o colega já fez por não saber que existe

É como contratar quatro devs fodões, colocar cada um numa sala fechada sem Slack e mandar todos editarem o mesmo arquivo

Alguém vai perder trabalho, é matemática

Como prevenir:

O caminho é isolamento de verdade, no nível do sistema de arquivos

O Claude Code suporta rodar sessões em paralelo em git worktrees: diretórios de trabalho separados, ligados a branches distintas, compartilhando o mesmo histórico do repositório

Cada sessão mexe nos SEUS arquivos, e edição de uma não toca na outra

A integração acontece depois, no merge, que é onde ela sempre deveria ter acontecido

Ressalva importante: worktrees no Claude Code exigem repositório git. Pra outro sistema de controle de versão é preciso configurar hooks substituindo a lógica de git

Se você ainda está na dúvida se dá pra manter duas sessões no mesmo projeto sem elas se atropelarem, esse é exatamente o ponto onde o worktree resolve

O agente toca em arquivo fora do escopo

O sintoma:

A tarefa era mexer num componente

O diff aparece com mudança numa pasta de config, num script de deploy, num arquivo que não tinha nada a ver com o pedido

Às vezes é uma "melhoria" bem intencionada, às vezes é aquele comando que limpa mais do que devia (os rm -rf da vida)

A causa:

Permissão ampla vale pro PROCESSO inteiro, não só pros arquivos que você tinha em mente quando aprovou

O bypassPermissions, por exemplo, pula praticamente todos os prompts de aprovação

Ele mantém pouquíssimos freios: regras explícitas de ask e deny continuam valendo, e ele se recusa a rodar como root

Só isso

Agora multiplica esse comportamento por quatro agentes rodando junto e pensa em quantas decisões silenciosas acontecem por minuto

Como prevenir:

Contenção em camadas, do mais barato pro mais forte

1. Regras de permissão escritas antes. As regras são avaliadas em ordem fixa: deny, depois ask, depois allow, e a primeira correspondência decide o resultado. A especificidade da regra não muda essa ordem, então não adianta caprichar num padrão super detalhado achando que ele vai ganhar de um allow genérico
2. Hook PreToolUse. Ele roda depois que o Claude monta os parâmetros da ferramenta e antes da chamada ser processada, casando por nome de ferramenta (Bash, Edit, Write, Read). Um hook PreToolUse que sai com código 2 bloqueia a chamada e devolve o texto do stderr ao Claude como mensagem de erro. E tem um detalhe topzera: esse bloqueio acontece ANTES da avaliação das regras de permissão, valendo mesmo quando uma regra allow deixaria passar
3. Sandbox. O sandbox do Claude Code oferece isolamento de sistema de arquivos, permitindo leitura e escrita no diretório de trabalho atual e bloqueando a modificação de arquivos fora dele, além de isolamento de rede que só libera conexão com domínios aprovados via proxy

O sandbox é construído sobre primitivas de nível de sistema operacional: bubblewrap no Linux e seatbelt no macOS

E não, isso não é só freio

No uso interno da Anthropic, o sandboxing reduziu os prompts de permissão em 84%

Faz sentido: quando o ambiente não deixa o agente sair da caixa, você não precisa mais ser o segurança de cada chamada 🙂

A mudança que o rewind não desfaz

O sintoma:

Deu ruim, você roda /rewind (ou aperta Esc duas vezes com o prompt vazio), restaura, respira aliviado

Aí percebe que parte do estrago continua lá

A causa:

O checkpointing vem ativado por padrão no Claude Code: depois de cada resposta ele tira um snapshot dos arquivos que modificou, e a cada prompt enviado um checkpoint é criado

Na hora de reverter você escolhe entre restaurar o código, restaurar a conversa ou restaurar os dois

Parece rede de segurança completa, né? Só que tem dois buracos que você precisa conhecer ANTES de precisar deles

Primeiro: o checkpoint só rastreia mudanças feitas pelas ferramentas Write, Edit e NotebookEdit

Alteração feita via comando Bash não é capturada pelo sistema de checkpoint

E é justamente por Bash que passam as coisas mais destrutivas de um projeto

Segundo: o checkpointing não reverte arquivos que sejam symlink ou hard link. Na restauração esses caminhos são pulados e mantêm o conteúdo atual

Como prevenir:

Commit frequente é a rede REAL, o checkpoint é conveniência

Antes de soltar o lote de agentes, deixa a árvore limpa e commitada. Assim o git diff vira seu revisor e o reset vira sua saída de emergência

Restringir comando Bash por regra deny também entra aqui, porque tira do caminho justamente a categoria de mudança que o checkpoint não enxerga

E guarda esse número: os checkpoints persistem entre sessões e são limpos automaticamente depois de 30 dias

Ou seja, checkpoint não é backup de longo prazo, é desfazer de curto prazo

Modos de permissão do Claude Code: o que cada um libera

Antes de escalar pra vários agentes, vale ter na cabeça o que cada modo autoriza sozinho

Se liga na última coluna: em todos os modos exceto bypassPermissions, escritas em caminhos protegidos nunca são aprovadas automaticamente

É o tipo de diferença que passa despercebida até o dia em que ela importa

Quando vale soltar agentes paralelos com escrita (e quando não vale)

Nem todo cenário merece a mesma dose de paranoia. Separando por caso:

Vale, com worktree: tarefas independentes por arquivo ou por módulo

Quatro correções que não se cruzam, cada uma no seu diretório de trabalho, cada uma na sua branch. O paralelismo entrega aqui porque não existe arquivo disputado

Vale, com plan mode: varredura ampla de código antes de qualquer escrita

Mapear onde uma mudança bate, levantar dependência, montar o plano. O plan lê e propõe sem editar o source, então você pode soltar vários sem medo nenhum

Vale, com sandbox: agente que precisa rodar comando e mexer em arquivo, mas cuja tarefa cabe inteira dentro do diretório atual

Escrita restrita ao working directory mais rede por domínio aprovado dá pra dormir tranquilo

Não vale: qualquer coisa perto de dado de produção

O caso Replit não foi falta de instrução, foi falta de separação. Se produção está alcançável pelo agente, o modo de permissão não é a sua primeira linha de defesa

Não vale: duas ou mais tarefas que tocam o MESMO arquivo compartilhado

Aqui o paralelismo é ilusão de velocidade: você paga depois, resolvendo conflito ou caçando o trecho que evaporou

Esse raciocínio de escopo por tarefa não é exclusivo de uma ferramenta só. Vale pra qualquer stack onde dá pra rodar vários agentes no mesmo projeto, a régua é a mesma

Vale a pena? Depende do isolamento, não da confiança no agente

Veredito honesto: rodar agentes em paralelo com permissão de escrita é ganho REAL de tempo

Não é hype, tarefa independente rodando ao mesmo tempo comprime cronograma de um jeito que trabalho sequencial não comprime

Mas o risco aqui é de sistema, não de comportamento

Não adianta escrever no CLAUDE.md "não mexa nesta pasta" e achar que resolveu, porque instrução em texto é sugestão, e a Replit já pagou essa conta em público

A régua que eu usaria pra decidir se pode soltar o lote tem três itens:

• isolamento de verdade (worktree ou sandbox), pra que dois agentes não escrevam no mesmo lugar
• regra deny explícita, lembrando que a ordem é deny, ask, allow, com a primeira correspondência decidindo
• commit antes, porque o checkpoint não cobre Bash nem symlink

Sem esses três, o que você ganha em velocidade devolve em recuperação

E recuperação é sempre mais lenta que a geração, porque envolve você entendendo o que quatro processos fizeram sem te contar

Conclusão

A contenção mínima pra soltar agentes em paralelo cabe em três frentes

Isola o diretório de trabalho, pra que um agente não escreva por cima do outro

Escreve as regras deny e ask ANTES de liberar, não depois do primeiro susto

E commita o estado limpo antes de soltar o lote, porque essa é a única rede que cobre até o que o checkpoint não enxerga

O próximo passo prático? Não comece pelos quatro agentes

Começa com UM em plan mode, vê o que ele propõe tocar, confere se o escopo bate com o que você imaginava, e só então escala pro paralelo com escrita

É menos empolgante, mas é assim que a velocidade fica sua de verdade 😀

até o próximo post!