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

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
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:
- 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
- Rode
/rewind, ou aperte Esc duas vezes com o campo vazio - Escolha a ação no menu:
Restore code and conversation,Restore conversation,Restore code,Summarize from here,Summarize up to hereouNever mind. O erro comum aqui é restaurar a conversa achando que restaurou o código, são ações separadas de propósito - 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,mvecpNÃ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 é.
Formações
Formação Vibe Coding
Do Prompt ao Produto: Crie Software Real com IA
- 474 aulas
- 20 projetos
- 39h 27min
Blog | Mais populares
As diferenças de var, let e const
Como fazer redirecionamento com PHP
Neste artigo você vai aprender a como fazer redirecionamento com PHP, utilizaremos abordagens fáceis de entender e de aplicar Fala programador(a), beleza? Bora aprender mais […]
Checklist de segurança n8n VPS pública: guia essencial para proteger sua instalação
Checklist de segurança n8n VPS pública: guia essencial para proteger sua instalação A popularidade da automação de processos com o n8n está em alta, principalmente […]
