Claude Code apagou ou reescreveu mais do que devia? Como reduzir o raio de uma tarefa

como definir o escopo de uma tarefa no Claude Code antes de editar arquivos
Resposta rápida

Se o Claude Code apagou ou reescreveu mais do que você pediu, o problema quase sempre é raio de tarefa: pedido vago, sem alvo e sem etapa de leitura antes da edição. Definir o Claude Code escopo é dizer o arquivo, a restrição e o padrão de exemplo, usar o plan mode (read-only, Shift+Tab ou claude --permission-mode plan) pra ver a proposta antes de aprovar, e conferir em que modo de permissão você está com /permissions. Se o estrago já aconteceu, /rewind restaura o código da sessão, mas não desfaz o que veio de comando bash. Git continua sendo a camada de verdade!

Fala aí, beleza? Você pediu um ajuste bobo, trocar uma mensagem de erro, e voltou um diff gigante com três arquivos reescritos e um que simplesmente sumiu

A sensação é sempre a mesma: "mas eu não pedi isso"

E não, isso não é azar isolado seu. Existem relatos públicos no repositório do Claude Code de coisas nessa linha, tipo a issue #29120, onde o pedido era excluir um asset de release de um repositório específico e a exclusão aconteceu em dois, ou a issue #23913, com relato de 2.229 arquivos-fonte não rastreados pelo git apagados sem instrução do usuário e sem passar pela Lixeira do Windows

Tem também a issue #27137, sobre usar escrita de arquivo inteiro no lugar de edição cirúrgica e perder conteúdo em silêncio, e a issue #30988, com o título mais direto possível: "Claude just randomly batch deletes files uninstructed"

Importante ser honesto aqui: são relatos públicos, não estou afirmando que isso é bug ativo do produto hoje

O que dá pra fazer é o que este post é: reduzir o RAIO da tarefa antes de soltar o agente, e saber o que fazer quando o estrago já aconteceu

(o post assume que tu já tem o CLI rodando, se você ainda travou antes disso dá uma olhada nos erros comuns de instalação do Claude Code e volta aqui)

Domine o Claude Code do básico ao avançado
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!

O Claude Code já apagou ou reescreveu: dá pra desfazer?

O sintoma é claro: arquivos sumiram ou voltaram diferentes, e você quer o estado de dois minutos atrás

A causa da dor não é falta de rede de segurança, é desconhecimento dela. O Claude Code faz checkpoint automático do estado do código antes de cada prompt seu, e guarda snapshots dos 100 checkpoints mais recentes da sessão

Ou seja: em muitos casos o "antes" ainda está lá, você só não sabia

A solução é o menu de rewind:

  1. Deixe o campo de prompt VAZIO. O erro comum deste passo é apertar Esc duas vezes com texto digitado: nesse caso o duplo Esc só limpa o texto e o menu não abre
  2. Rode /rewind, ou aperte Esc duas vezes com o campo vazio
  3. Escolha a ação no menu: Restore code and conversation, Restore conversation, Restore code, Summarize from here, Summarize up to here ou Never mind. O erro comum aqui é restaurar a conversa achando que restaurou o código, são ações separadas de propósito
  4. Leia o aviso no fim. Se aparecer "Restored the code, but skipped N files", esses N arquivos são symlink ou hard link, que o rewind pula

E se liga nos limites, porque é aqui que a galera se ferra:

  • alterações feitas por comandos como rm, mv e cp NÃO são rastreadas, só o que passou pelas ferramentas de edição de arquivo do Claude
  • mudanças manuais feitas fora do Claude Code, e edições de outras sessões rodando ao mesmo tempo, normalmente não são capturadas
  • symlink e hard link ficam de fora do restore

Um ponto bom: checkpoints são salvos junto com a conversa, então dá pra rodar /rewind depois de retomar a sessão

A prevenção é tratar o rewind como o que ele é, uma rede de segurança PARCIAL, e não como backup

Git continua sendo a camada de verdade, commit pequeno antes de soltar tarefa grande resolve o que o checkpoint não cobre 🙂

Por que pedidos amplos convidam reescrita

Sintoma: você escreve "melhora o módulo de autenticação" e recebe o módulo inteiro reescrito, com bônus de arquivo de teste ajustado que ninguém pediu

Causa: pedido sem alvo obriga o agente a INFERIR o escopo. E inferir escopo é exatamente onde ele erra

A documentação oficial de boas práticas é bem direta nisso: "The more precise your instructions, the fewer corrections you’ll need. Claude can infer intent, but it can’t read your mind. Reference specific files, mention constraints, and point to example patterns"

Traduzindo o espírito da coisa: ele adivinha intenção, não lê sua mente

A solução tem quatro peças, e todas cabem num prompt só:

  • alvo: qual arquivo, qual função, qual comportamento (o @ referencia arquivos direto no prompt)
  • restrição explícita: "só este arquivo", "não mexa nos testes"
  • padrão de exemplo: aponte um trecho do próprio código que já faz certo
  • mudança incremental: um passo, não uma refatoração

Na prática fica mais ou menos assim:

Ajuste só @src/auth/login.ts

O que quero: trocar a mensagem de erro de senha invalida
Restrição: não editar outros arquivos, não tocar nos testes
Padrão: seguir o mesmo formato de erro que já existe em @src/auth/signup.ts

É feio? é. Funciona muito melhor que "melhora o login"? também 😀

E olha, raio grande custa caro em tempo, retrabalho e revisão de diff, coisa que pesa ainda mais pra quem anda de olho nos preços e planos do Claude Code

Pra prevenir, a jogada é não repetir restrição na mão toda vez. O CLAUDE.md é um arquivo markdown na raiz do projeto que o Claude Code lê no início de TODA sessão, feito justamente pra comandos de build, convenções, layout do projeto e regras do tipo "sempre faça X"

O comando /memory lista os arquivos de memória em escopo de usuário e de projeto, e se você selecionar um que não existe ele cria o arquivo

Então suas duas ou três regras de escopo favoritas viram padrão do projeto, não força de vontade

Como perceber o raio grande ainda na proposta, antes de aceitar

Sintoma: você só descobre o tamanho da mudança DEPOIS que ela foi aplicada

Causa: a edição rodou direto, sem etapa de leitura no meio

A solução é o plan mode, que é read-only. Nele o Claude Code lê arquivos, roda comandos de exploração e escreve um plano, mas não edita o código-fonte até o plano ser aprovado (exceto em sessões com bypass permissions disponível)

Pra ligar:

  • aperte Shift+Tab até a barra de status mostrar ⏸ plan mode on
  • ou já comece a sessão assim:
claude --permission-mode plan

Quando o plano aparece, você não está preso ao "aceita ou cancela". As opções incluem aprovar com modo automático, aprovar com aprovação manual de cada edição, ou No, keep planning, que segue no plan mode e te deixa dizer o que mudar

Essa terceira opção é a mais subestimada de todas, sério

E o que olhar no plano pra sentir o cheiro de raio grande?

  • número de arquivos tocados MAIOR do que você esperava pro pedido que fez
  • passos que falam em reescrever, em vez de ajustar

Se bater qualquer um dos dois, No, keep planning e corta escopo na conversa mesmo

A prevenção aqui é quase mecânica: leia a lista de arquivos do plano ANTES de qualquer clique de aprovação, não depois

Quando planejar vale a pena e quando é só overhead

Agora, planejar tudo também é bobagem, e a própria documentação avisa: plan mode adiciona overhead

Pra escopo claro e correção pequena, tipo corrigir um typo, adicionar um log ou renomear uma variável, peça direto

Planejar é mais útil quando existe incerteza sobre a abordagem, quando a mudança altera múltiplos arquivos, ou quando você não conhece o código que vai ser modificado

A régua fica assim:

Situação Plano vale? Por quê
Corrigir um typo Não escopo claro, correção pequena
Adicionar um log numa função Não escopo claro, correção pequena
Renomear uma variável Não escopo claro, correção pequena
Não sei qual abordagem seguir Sim incerteza sobre a abordagem
A mudança atravessa vários arquivos Sim mudança em múltiplos arquivos
Código legado que você nunca abriu Sim você não conhece o código a ser modificado

Decorou a tabela? então tu já decide sozinho, sem precisar de mim 🙂

O modo de permissão errado transforma sugestão em edição aplicada

Sintoma: as mudanças acontecem e você não confirmou nada

Causa: o modo de permissão ativo na sessão. O Claude Code tem mais de um, e eles mudam MUITO o comportamento

São eles: Manual (que é o padrão), acceptEdits (edições automáticas), plan, auto e bypassPermissions

Agora o que a documentação diz de cada um, resumido:

Modo O que a doc diz
Manual é o padrão
acceptEdits auto-aprova operações de arquivo dentro do diretório de trabalho
plan read-only, bloqueia edições até o plano ser aprovado
auto consta na lista de modos (não vou inventar o que ele libera)
bypassPermissions acesso autônomo, sem prompts

Duas leituras importantes dessa tabela

O acceptEdits não é terra sem lei: ele auto-aprova operação de arquivo dentro do diretório de trabalho, mas edições fora do escopo do projeto e caminhos protegidos como .git e .bashrc continuam pedindo confirmação, e comandos Bash que não são operação de sistema de arquivos seguem a permissão normal

Já o bypassPermissions dá acesso autônomo sem prompt, e a recomendação oficial de uso é apenas em ambientes isolados (containers, VMs, dev containers), onde o Claude Code não possa danificar o sistema host. Tome cuidado com esse aqui!

Como ver as regras ativas e de onde elas vieram:

A solução prática é parar de adivinhar em que modo você está, e o comando pra isso é o /permissions

/permissions

Esse comando lista todas as regras de permissão e o settings.json de onde elas vieram, que é a metade da resposta que ninguém procura

As regras vêm em três tipos: Allow (usa sem aprovação), Ask (pede confirmação) e Deny (impede o uso)

E entenda a ordem de avaliação, porque ela não é intuitiva: primeiro Deny, depois Ask, depois Allow. A PRIMEIRA regra que casa decide, independente de especificidade

Essas regras valem pras ferramentas do Claude Code, incluindo Bash, Read, Edit, WebFetch e MCP

Pra prevenir, escolha o modo padrão de forma consciente, no settings:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

E o que vale pra todo projeto vai no arquivo de nível de usuário, em ~/.claude/settings.json

Sessões paralelas colidindo no mesmo diretório

Sintoma: uma sessão desfaz ou sobrescreve o que a outra acabou de fazer, e o rewind não te salva

Causa: duas sessões trabalhando no MESMO diretório de trabalho. Lembra do limite lá de cima? o checkpoint normalmente não captura edições de outras sessões simultâneas

A solução é git worktree, que é um diretório de trabalho separado, com arquivos e branch próprios, compartilhando histórico e remoto do mesmo repositório. A edição de uma sessão não toca os arquivos da outra

O CLI já tem flag pra isso, que cria o worktree isolado e inicia o Claude nele:

claude --worktree
claude -w

E a prevenção que evita sujeira no seu checkout principal, direto da documentação de worktrees: coloca a pasta no .gitignore

.claude/worktrees/

Sem isso o conteúdo dos worktrees aparece como um monte de arquivo untracked no checkout principal, e aí você já sabe no que dá arquivo untracked sobrando por aí

O resumo do raio pequeno

No fim, reduzir raio é empilhar três camadas, e nenhuma delas sozinha resolve

Escopo no pedido: alvo com @, restrição explícita, padrão de exemplo, mudança incremental. Precisão custa alguns segundos a mais de digitação

Etapa de leitura antes da edição: plan mode ligado no Shift+Tab ou com claude --permission-mode plan, lista de arquivos lida antes de aprovar, e No, keep planning sem dó quando o plano incha

Controle de permissão e rede de segurança: /permissions pra saber que regra está valendo e de qual settings.json ela veio, /rewind com seus limites bem entendidos (nada de bash, nada de outra sessão, nada de symlink), git commitado antes das tarefas grandes, worktree quando rodar em paralelo

Seu próximo passo, hoje, são duas coisas rápidas: roda /permissions pra descobrir em que modo você está trabalhando sem saber, e abre o CLAUDE.md pra escrever as duas ou três regras de escopo que você já cansou de repetir no chat

O agente não lê sua mente, mas lê arquivo. É por isso que funciona 😀

até o próximo post!

Perguntas frequentes

O Claude Code apaga arquivos que eu não pedi para apagar, isso é bug confirmado?

Existem relatos públicos nesse sentido, como a issue #29120 (exclusão em dois repositórios quando o pedido era só um) e a issue #23913 (2.229 arquivos não rastreados apagados sem instrução). São relatos públicos, não uma confirmação de bug ativo no produto hoje. O que dá pra fazer na prática é reduzir o raio da tarefa antes de soltar o agente e commitar antes de pedidos grandes.

O /rewind do Claude Code desfaz um rm ou mv rodado no terminal?

Não. O checkpointing só rastreia arquivos alterados pelas ferramentas de edição do próprio Claude Code, comandos como rm, mv e cp ficam de fora. Por isso o rewind é uma rede de segurança parcial, e o Git continua sendo a camada de verdade para esse tipo de alteração.

Vale a pena ligar o plan mode para qualquer tarefa no Claude Code?

Não segundo a documentação oficial, porque plan mode adiciona overhead. Para escopo claro e correção pequena, tipo corrigir um typo, adicionar um log ou renomear uma variável, o recomendado é pedir direto. Ele compensa mais quando há incerteza sobre a abordagem, a mudança mexe em múltiplos arquivos ou você não conhece o código.

Dá para restaurar o código de uma sessão do Claude Code depois de fechar e reabrir o terminal?

Sim. Os checkpoints são salvos junto com a conversa, então é possível rodar /rewind mesmo depois de retomar a sessão. A ressalva é que mudanças manuais feitas fora do Claude Code, e edições de outras sessões simultâneas, normalmente não são capturadas.

O modo acceptEdits do Claude Code pode editar arquivo fora do meu projeto sem perguntar?

Não. O acceptEdits auto aprova operações de arquivo dentro do diretório de trabalho, mas edições fora do escopo do projeto e caminhos protegidos como .git e .bashrc continuam pedindo confirmação. Comandos Bash que não são operação de sistema de arquivos seguem a permissão normal.

Como ver quais regras de permissão estão ativas no Claude Code e de onde elas vêm?

O comando /permissions lista todas as regras (Allow, Ask, Deny) e mostra o arquivo settings.json de onde cada uma veio. A avaliação segue a ordem deny, depois ask, depois allow, e a primeira regra que casa decide, independente de quão específica ela é.



Subscribe
Notify of
guest

0 Comentários
Oldest
Newest Most Voted

Formações

Formação Vibe Coding

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

  • 474 aulas
  • 20 projetos
  • 39h 27min

Blog | Mais populares