Como desfazer o que o Claude Code fez quando a alteração saiu pior que o original?

Fala aí, beleza? Poucas coisas doem tanto quanto aceitar tudo que o Claude Code sugeriu, rodar o projeto e descobrir que a versão de antes funcionava melhor 😅

Você vai dando enter, aceita, aceita, aceita… aí o teste quebra, um comportamento some, e bate o branco: e agora, como eu volto?

A boa notícia é que existe caminho de volta, e tem mais de um. Dentro da própria sessão o Claude Code guarda checkpoints do estado dos arquivos, e fora dela o Git guarda o histórico de verdade.

Este post é um guia de recuperação e de rede de segurança: como reverter o estrago agora, o que o rewind NÃO devolve, e como deixar um ponto de retorno pronto antes de soltar a próxima tarefa

Já adianto uma coisa, pra não criar expectativa errada: o rewind não é garantia de que nada se perde. Tem cenário que só o Git salva, e tem cenário que não volta de jeito nenhum se você não tinha commit

Antes de desfazer: o que você precisa ter em mãos

Antes de sair apertando coisa, três condições precisam estar de pé pra recuperação funcionar

• A sessão do Claude Code ainda acessível: os checkpoints são salvos junto com a conversa, então o /rewind continua disponível mesmo depois de você retomar a sessão com resume
• O projeto sob controle de versão: Git com commits, branches e histórico, porque é ele que segura o que o checkpoint não alcança
• Noção do limite de snapshots: o Claude Code guarda os snapshots de arquivos dos 100 checkpoints mais recentes de uma sessão, e esses snapshots são apagados na limpeza de retenção, por padrão cerca de 30 dias depois de a sessão salvar o último snapshot (período controlado pela configuração cleanupPeriodDays)

Formação Recomendada

Formação Claude Code

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

• 118 aulas
• 4 projetos
• 9h 33min

Conhecer formação

Por que checkpoint não substitui Git:

Essa parte é importante e muita gente confunde

A própria documentação de checkpointing posiciona os checkpoints como recuperação rápida no nível da sessão, e recomenda que você continue usando controle de versão pro histórico permanente

É como um Ctrl+Z gordo da sessão: MUITO útil pro susto do momento, mas não é onde mora a verdade do projeto

Se você conhece o fluxo de commit e branch, pensa assim: checkpoint é o que te salva nos próximos minutos, o Git é o que te salva na semana que vem

Passo a passo para reverter uma alteração do Claude Code

Beleza, o estrago já aconteceu. Bora desfazer na ordem certa

1. Pare de aceitar novas edições

Não manda "corrige isso aí" na sequência

Cada prompt novo que inicia um turno gera mais um checkpoint, e você só empilha camada de mudança em cima de um estado que já está ruim. Respira e resolve o estado primeiro

O erro comum deste passo: tentar consertar conversando, quando o que você queria era só voltar

2. Abra o menu de rewind

São dois caminhos pro mesmo lugar:

/rewind

Ou pressionando Esc duas vezes

O erro comum deste passo: ter texto digitado no campo de prompt. O atalho Esc + Esc só abre o menu de rewind se o input estiver vazio, senão o duplo Esc apenas limpa o que você escreveu. Limpa o campo antes, ou usa /rewind e pronto 🙂

3. Escolha o checkpoint

O Claude Code cria checkpoints automaticamente: cada prompt que inicia um turno gera um novo checkpoint com o estado dos arquivos ANTES das edições daquele turno, sem nenhuma configuração prévia da sua parte

Então a pergunta que você faz pra si mesmo é simples: qual foi o último prompt em que o projeto ainda estava bom? Volta pra ele

O erro comum deste passo: voltar longe demais por ansiedade e jogar fora turnos que estavam ok

4. Decida entre as três ações do menu

O menu de rewind oferece três caminhos, e eles fazem coisas bem diferentes:

O erro comum deste passo: escolher "código e conversa" no automático e perder todo o contexto que você levou meia hora construindo. Se o papo ainda vale, restaura só o código

5. Confira o resultado no working tree

Não confia só na mensagem da tela, olha os arquivos

Roda o projeto, roda o teste, dá um git status e vê se o diff bate com o que você esperava

O erro comum deste passo: assumir que TUDO voltou. O checkpointing rastreia apenas as alterações feitas pelas ferramentas de edição de arquivo do Claude (Write, Edit e NotebookEdit), e é exatamente sobre isso a próxima seção

Quando o /rewind não resolve: limitações e o que fazer

Aqui mora a pegadinha que faz o dev achar que o rewind "falhou"

Ele não falhou, ele só nunca teve aquele arquivo na mão 😀

Olhando essa tabela fica claro o recado: quem garante o seu código no fim das contas é o Git, não o checkpoint

E como eu recupero pelo Git?

Pro arquivo específico, o git restore restaura arquivos do working tree a partir do index ou de outro commit, descartando alterações não commitadas:

git restore --source=<commit> -- caminho/do/arquivo.js

Tome cuidado! Ele descarta o que não está commitado naquele caminho. Se tiver alguma coisa boa ali no meio, salva antes

Pra commit que já entrou no histórico, o Git tem dois comandos distintos e documentados separadamente: o git revert desfaz commits criando novo histórico, e o git reset move o estado do repositório. Em projeto compartilhado, criar histórico novo costuma doer menos que reescrever o que já foi empurrado

Como prevenir cada uma dessas:

A prevenção é sempre a mesma ideia, em três frentes

Commit estável antes de tarefa grande, revisar quando ele pede pra rodar comando de arquivo em vez de aprovar no automático, e não ficar com duas sessões mexendo no mesmo diretório

Esse último ponto conversa direto com a régua de quando o Claude Code deve decidir sozinho: quanto mais autonomia pra rodar bash, mais coisa acontece fora do alcance do checkpoint

Como criar um ponto de retorno antes de soltar a tarefa

Agora a parte que evita o incêndio. Se liga nisso, é o que muda o jogo

1. Commite o que está estável

Antes de soltar uma tarefa longa, deixa um commit com o projeto funcionando. Esse é o seu ponto zero, o "pior caso" pro qual você sempre pode voltar

O erro comum deste passo: começar a tarefa grande com um monte de coisa não commitada no working tree e depois não conseguir separar o que foi você do que foi a IA

2. Não quer commitar ainda? Usa o stash

O git stash grava o estado atual do diretório de trabalho e do index e te devolve um diretório limpo, guardando as modificações numa pilha pra você reaplicar depois, inclusive em outra branch:

git stash

O erro comum deste passo: esquecer dos arquivos não rastreados. O git stash padrão não leva os untracked junto, então quando quiser incluir eles:

git stash --include-untracked

3. Isole a tarefa em um worktree

O Claude Code tem suporte a git worktrees pra rodar sessões paralelas isoladas

Que worktree? É um diretório de trabalho próprio, com a sua própria branch, compartilhando o mesmo histórico e o mesmo remoto do repositório. Ou seja: a IA bagunçando lá não encosta no diretório onde você está trabalhando

git worktree add ../projeto-feature-a -b feature-a

O erro comum deste passo: achar que o worktree isola TUDO. Ele isola arquivos e branch, não isola permissão: quando você aprova um comando Bash com a opção de não perguntar de novo dentro de uma sessão em worktree, a regra é gravada no .claude/settings.local.json do checkout principal e passa a valer pro checkout principal e pra todos os worktrees do repositório

4. Rode a tarefa e revise pelo diff, não pela conversa

Com commit estável e worktree no lugar, você pode deixar rodar com muito mais sossego

E revisa olhando o diff. A conversa conta a história que a IA acha que aconteceu, o diff conta o que aconteceu mesmo 😛

Vale lembrar que sessão muito longa também piora a qualidade da revisão dele, e aí entra todo aquele papo de contexto cheio na sessão longa

Reverter tudo ou aproveitar parte? Como decidir

Nem todo estrago merece bola de demolição. Às vezes tem coisa MUITO boa no meio do que ele escreveu

A alteração inteira saiu pior:

Caso clássico: ele entendeu o pedido errado lá no começo e construiu tudo em cima disso

Aqui não tem o que aproveitar, nem no código nem no papo

Restaura código e conversa pro checkpoint antes do prompt problemático e reescreve o pedido com mais contexto. Recomeçar limpo custa menos que remendar uma base errada

O código está ruim, mas o raciocínio serve:

Acontece bastante: ele mapeou os arquivos certos, entendeu a arquitetura, explicou o plano direitinho… e implementou torto

Jogar a conversa fora aqui é desperdício puro

Restaura só o código e mantém o histórico da conversa. Você volta os arquivos pro estado bom e continua o papo com todo o contexto que ele já construiu, só corrigindo o rumo da implementação

Parte dos arquivos está boa:

O cenário mais comum de todos: três arquivos ficaram ótimos, um ficou péssimo

Não precisa reverter a sessão inteira por causa de um

Aqui o Git é mais cirúrgico que o rewind: git restore devolve só os caminhos que você listar, a partir do commit que você escolher, e o resto fica como está. Se o problema já virou commit, o git revert desfaz aquele commit criando histórico novo, mantendo o que veio antes

A regra mental é essa: rewind trabalha por turno da sessão, Git trabalha por arquivo e por commit. Quando o corte que você quer é fino, usa o Git

Conclusão

A rede de segurança boa é em camadas, e cada camada resolve um tipo de susto

O checkpoint com /rewind (ou Esc + Esc com o campo vazio) salva o momento dentro da sessão, com as três ações de restaurar código e conversa, só a conversa ou só o código

O Git segura o resto: o que veio de comando bash, o que você editou na mão, o checkpoint que já saiu dos 100 mais recentes ou expirou na retenção

E o worktree é a camada preventiva, dando à tarefa um diretório e uma branch só dela, sobre o mesmo repositório

Sem essas camadas montadas antes, tem estrago que simplesmente não tem de onde voltar, e é por isso que a prevenção pesa mais que o botão de desfazer

Próximo passo prático pra hoje: antes da sua próxima tarefa longa, cria um worktree, deixa um commit estável e abre o /rewind UMA vez só pra ver o menu com calma

Porque aprender onde fica o botão no meio do incêndio é péssimo, né? 😀

Até o próximo post!