Como anular alterações no Claude Code: /rewind e git

Encontra informação prática sobre a utilização do Ailoot na documentação.

O que é a anulação no Claude Code e porque não bastam três níveis?#

Ativei o /rewind na minha primeira semana de utilização do Claude Code, quando este estragou a lógica de autenticação do meu projeto em dois pedidos. Fiz rewind, respirei de alívio e continuei. Um mês depois, surgiu outra situação: estava a escrever uma migração de esquema, o Claude ajudou, fiz commit, mudei de branch e percebi que me tinha esquecido de um passo necessário. O /rewind não ajudou — a sessão já era outra. git checkout para o commit anterior resolveu. Um mês depois disso, disse acidentalmente ao agente: «faz rollback de tudo até ao último push», e ele executou git reset --hard, destruindo três horas de trabalho. O git reflog salvou-me — os hashes dos commits destruídos continuavam lá.

Estas três histórias representam três níveis de proteção que funcionam de maneiras diferentes, detetam erros diferentes e são todos necessários. Este guia explica cada nível, com os respetivos comandos, limitações e exemplos, e mostra também como configurar antecipadamente um projeto para que o Claude não o deite abaixo logo à primeira.

3 níveis de anulação — o quê e quando:

A seguir, vamos percorrer cada nível — o que fazer exatamente, as armadilhas a evitar e como configurar tudo para não haver nada a anular porque nada se estragou.

Como invocar /rewind: com um comando ou com Esc-Esc?#

Depois de cada resposta, o Claude cria automaticamente um instantâneo de todos os ficheiros que editou nessa sessão. Os instantâneos são guardados em ~/.claude/file-history/{sessionId}/ e conservados durante até 30 dias. São incrementais — guardam-se apenas as diferenças entre estados, não o ficheiro inteiro. Por predefinição, são guardados até 100 instantâneos por sessão. Isto significa que, na maioria dos projetos reais, tens a qualquer momento um histórico completo de todas as alterações do Claude ao longo do dia de trabalho.

Para abrir o menu de rewind, prime Esc duas vezes quando o campo de entrada está vazio:

[o campo de entrada está vazio]
> _

[prime Esc, Esc]

Rewind para que mensagem?
  1. Criar uma migração para a tabela User          (3 ficheiros alterados)
  2. Adicionar o campo lastLoginAt                  (1 ficheiro alterado)
  3. Reescrever a lógica de autorização             (5 ficheiros alterados)
  ...

Se houver texto no campo de entrada, o primeiro duplo toque em Esc apaga-o e guarda-o no histórico Up. Isto é útil quando já começaste a escrever e percebes que precisas de fazer rewind. Uma citação da documentação oficial da Anthropic:

O comando /rewind faz o mesmo — abre o menu. Existe um alias, /checkpoint, que leva ao mesmo sítio. O método mais cómodo depende do hábito. Eu uso Esc Esc — é mais rápido e não tiro as mãos do teclado.

6 modos no menu Rewind: qual deves escolher e quando?#

Escolhe um ponto da lista e vais parar ao menu de ações. Tem seis opções, cada uma com uma função diferente.

Tabela completa dos modos:

A funcionalidade Summarize up to here surgiu no Claude Code v2.1.139-v2.1.142, lançado entre 11 e 15 de maio de 2026, na semana 20:

A diferença entre Restore e Summarize é fundamental. Restore regressa a um estado anterior e anula tudo o que aconteceu depois do ponto selecionado. Summarize não anula nada; apenas comprime — as mensagens originais continuam no registo da sessão para consulta, mas só o resumo permanece no contexto ativo. Usa restore quando queres que seja «como se isto nunca tivesse acontecido». Usa summarize quando queres «manter isto, mas sem ocupar espaço no contexto».

Depois de Restore conversation ou Summarize from here, o texto original do pedido selecionado volta ao campo de entrada — podes editá-lo e enviá-lo novamente. Depois de Summarize up to here, o campo de entrada fica vazio e continuas no fim da conversa.

Que alterações é que /rewind NÃO anula?#

Esta é a principal limitação com que as pessoas se deparam: o /rewind mostra uma marca verde e diz «rewind concluído», mas o projeto continua avariado porque o Claude mexeu em mais do que ficheiros. Vejamos os três casos.

1. Os comandos Bash não são acompanhados. Se o Claude executar rm file.txt ou mv old.txt new.txt num turno, essas alterações não são incluídas no checkpoint. A documentação da Anthropic afirma-o explicitamente:

Isto significa que, se o Claude apagar, mover ou copiar um ficheiro por iniciativa própria através da ferramenta Bash, o /rewind não restaura tudo. git checkout ou o restauro a partir de uma cópia de segurança podem ajudar, mas exigem mais do que premir duas teclas.

2. As edições externas não são detetadas. Se abrires manualmente um ficheiro no VS Code e alterares alguma coisa, ou se uma segunda sessão do Claude alterar os mesmos ficheiros em paralelo, a primeira sessão não consegue ver essas alterações. O instantâneo do checkpoint é criado quando o Claude termina um turno na sessão atual. O que acontece entre turnos fica fora da sua responsabilidade.

3. As operações fora dos ficheiros não são abrangidas. Uma migração do Prisma aplicada através de npx prisma migrate dev alterou o esquema da base de dados — o /rewind não a anula porque a base de dados está fora do sistema de ficheiros do projeto. Um force-push para origin/main é igual: o commit foi para o servidor remoto e o checkpoint não o traz de volta. Uma chamada a uma API remota que cobrou dinheiro ou apagou um registo só pode ser anulada através dos mecanismos da própria API.

Regra: Se uma tarefa afetar algo fora dos ficheiros do projeto — migrações de bases de dados, git push ou APIs remotas — prepara uma estratégia de rollback separada para cada efeito externo. O /rewind é apenas o histórico local dos ficheiros da sessão atual.

/rewind e git: em que diferem e porque precisas dos dois?#

A documentação da Anthropic descreve diretamente esta combinação:

As diferenças numa tabela:

A combinação é simples: sempre que chegares a um estado em que «isto está a funcionar e não quero perdê-lo», faz um git commit. Entre commits, usa /rewind — é imediato, não exige uma mensagem de commit e não enche o histórico do git com estados intermédios. Quando o trabalho estiver concluído, faz commit — de preferência um commit significativo e atómico.

Porque é que um único /rewind não abrange a tarefa toda?#

A anulação é um dos casos de gestão de contexto. Se gerires o contexto da sessão (quando fazer commit, quando premir /rewind, que regras colocar no CLAUDE.md), terás um Claude previsível que não destrói o projeto nem perde trabalho.

Porque é que git reset --hard é perigoso quando pedes ao Claude para «voltar atrás»?#

Um pedido para «guardar o estado atual e voltar ao último push» pode levar a estes comandos:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # saved uncommitted changes
git reset --hard 35eb731                                                # destroyed commits d63695e..882e618

O primeiro comando estava correto — guardou as alterações não commitadas no stash. O segundo foi destrutivo: reescreveu o branch para o commit 35eb731 e todos os commits entre este e 882e618 ficaram órfãos. Por predefinição, os commits órfãos permanecem em .git/objects/ até ser executado git gc, o que normalmente acontece de forma automática no prazo de duas semanas. Mas, se não souberes o que fazer naquele momento, o tempo já está a correr contra ti.

A lógica é simples: em linguagem natural, «voltar atrás», «regressar», «restaurar», «reverter» e «anular» significam «consultar o histórico» ou «regressar a um local seguro». Não significam «destruir o histórico». O comando git reset --hard destrói-o — reescreve o branch e remove commits daqueles que podem ser alcançados através de HEAD. Uma alternativa segura é git checkout <commit>, que cria um HEAD desanexado e permite ver o estado antigo sem tocar nos branches.

A principal lição prática é fazer git commit do estado atual antes de qualquer tarefa substancial, sobretudo antes de refatorizar vários ficheiros. Um commit transforma qualquer asneira do Claude num único comando git checkout ., sem perder trabalho.

Como é que o git reflog te salva depois de um reset destrutivo?#

Depois de um reset destrutivo, executa git reflog imediatamente:

git reflog

O resultado é semelhante a este:

35eb731 HEAD@{0}: reset: moving to 35eb731
882e618 HEAD@{1}: commit: middleware refactoring complete
d63695e HEAD@{2}: commit: leaveRemove method finalized
1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled
35eb731 HEAD@{4}: pull origin main

HEAD@{1} a HEAD@{3} são precisamente aqueles commits «destruídos». Não desapareceram do armazenamento local de objetos do git; simplesmente deixaram de estar acessíveis através do branch. Para os restaurar:

# cria um branch a partir do último commit «destruído»
git branch recovered-work 882e618

# ou muda diretamente para ele
git reset --hard 882e618

Depois disso, o branch volta a conter todo o histórico até à catástrofe.

Limitações do reflog:

1. Apenas local. O reflog é guardado em .git/logs/HEAD; não está no repositório remoto. Se fizeres force-push e depois apagares a cópia local do repositório, o reflog desaparece com a pasta.
2. 90 dias por predefinição. O git gc pode remover entradas mais antigas. Podes configurar este prazo com git config gc.reflogExpire 200.days.ago.
3. Não abrange o que nunca esteve em HEAD. Se um commit só estava no stash e o stash foi destruído, o reflog só mostrará o estado mais recente do stash, não o histórico interno.

Regra para a equipa: nunca executes git gc --aggressive logo após uma catástrofe. Primeiro investiga com o reflog e recupera; faz o resto depois. E nunca apagues o clone local do repositório até teres a certeza de que tudo o que precisas foi enviado.

Como proteger um projeto de comandos git destrutivos através do CLAUDE.md?#

A vulnerabilidade é o facto de o Claude não ter contexto de proteção por predefinição. Interpreta «voltar atrás» como git reset --hard porque, tecnicamente, é um método válido. Coloca a proteção no CLAUDE.md — o ficheiro de prompt de sistema do projeto.

Regra mínima (insere-a no teu CLAUDE.md):

## Protocolo de segurança do Git

- NUNCA executes comandos git destrutivos (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), a menos que eu peça explicitamente essas ações. Tomar ações destrutivas sem autorização não é útil e pode resultar em perda de trabalho.
- Quando eu disser «voltar atrás», «regressar», «restaurar», «reverter» ou «anular», interpreta como pedidos de CONSULTA: usa `git log`, `git diff`, `git checkout <commit>` (cria um HEAD desanexado) ou `git stash` (preserva as alterações).
- Pede SEMPRE confirmação antes de QUALQUER comando que:
  - Altere a posição de HEAD para outro commit num branch
  - Modifique o histórico de commits
  - Possa causar a perda de trabalho não commitado
  - Inclua as opções --hard, --force ou --aggressive
- Antes de qualquer comando destrutivo, apresenta uma comparação numerada:
  - SEGURO: usar `git checkout <commit>` para ver temporariamente
  - DESTRUTIVO: usar `git reset --hard` para destruir permanentemente
- Aguarda a minha escolha explícita antes de executar.

Regra alargada para a equipa (adiciona-a ao CLAUDE.md na raiz do repositório):

## Regras de fluxo de trabalho do Git

- Faz commit em cada marco funcional. Antes de um commit WIP, executa `git status` e `git diff`, prepara só os ficheiros nomeados e explicitamente revistos com `git add -- path/to/file` e inspeciona o diff preparado antes de fazer commit. Um temporizador lembra-te de rever; não autoriza preparar toda a árvore de trabalho.
- Nunca uses `git add .` nem `git add -A` para commits feitos pelo Claude. Indica apenas os nomes dos ficheiros, depois de `git status` + `git diff`.
- Antes de `git push --force` para main, para e pergunta-me. Em branches de funcionalidades, faz force-push com cautela e só se tiveres a certeza de que aceito perder a versão anterior.
- Ao resolver conflitos de merge, nunca escolhas «ours» ou «theirs» imediatamente — mostra-me primeiro ambas as versões e depois decidirei.
- O `.gitignore` tem de conter `.env*`, `.claude/personal/`, `node_modules/` e `dist/`. Se faltarem, acrescenta-os.

Depois de adicionares estes blocos, a frase «volta ao último push» levaria à seguinte resposta:

Vejo 3 ficheiros não commitados e 4 commits desde o último push. Tens duas opções:

1. SEGURO: criar um branch view-last-push através de git checkout <last-push-hash> — preservo todo o trabalho, mas mostro temporariamente o estado do push.
2. DESTRUTIVO: git reset --hard <last-push-hash> — destruo permanentemente 4 commits e as alterações não commitadas. Só podem ser recuperadas através do git reflog durante 90 dias. Qual escolhes?

São trinta segundos de conversa em vez de quatro horas de trabalho perdido.

Quais são as 5 formas de anular alterações no Claude Code e como escolher a certa?#

O cenário «o Claude estragou isto, preciso de o restaurar urgentemente» percorre esta escala de baixo para cima. Começa sempre no nível 1.

Nível 1. /rewind — anulação imediata durante uma sessão.

Prime Esc Esc ou escreve /rewind. Escolhe o ponto anterior à falha. Escolhe um modo (normalmente Restore code and conversation). Um segundo depois, estás de volta ao passado e podes recomeçar. Abrange 80% dos casos em que «o Claude fez a coisa errada».

Nível 2. git checkout . — anular todas as alterações não commitadas.

git diff                    # vê primeiro o que realmente mudou
git checkout .              # anula todas as alterações não commitadas em todos os ficheiros
# ou apenas um ficheiro:
git checkout -- path/to/file.ts   # apenas um ficheiro

É útil quando o /rewind não funcionou (por exemplo, o Claude alterou ficheiros através de Bash) ou quando precisas de anular alterações fora do histórico da sessão. Todas as alterações que não foram commitadas desaparecem permanentemente. Se puderes vir a arrepender-te, executa primeiro git stash (consulta o nível 2.5).

Nível 2.5. git stash — pôr as alterações na prateleira.

git stash save "might still need this"
# regressar a um estado limpo (sem alterações)
# ...
# se mudares de ideias, restaura a partir do stash:
git stash pop

Um bom compromisso entre «perder para sempre» e «deixar como está». O stash permanece local até ser explicitamente limpo.

Nível 3. git checkout <commit> — regressar a um commit antigo sem perder o histórico.

git log --oneline               # encontra o hash do commit certo, por exemplo abc1234
git checkout abc1234            # HEAD desanexado — vê sem alterar nada
# gostas deste estado? cria um branch a partir dele:
git checkout -b recovery abc1234
# regressar:
git checkout main

É um «regresso temporário» seguro. Um HEAD desanexado não altera o branch; o teu trabalho atual em main (ou no branch em que estavas) permanece intacto. Se quiseres trabalhar neste estado, cria um branch.

Nível 4. git reset --hard <commit> — recuar o branch até um ponto.

⚠️ Destrutivo. Os commits posteriores ao hash especificado ficam órfãos.

git reflog                                  # anota o hash do estado atual
git reset --hard abc1234                    # reescreve o branch
# encontraste um erro? regressa através do reflog:
git reset --hard HEAD@{1}                   # regressa a onde estavas antes do reset

Usa apenas se tiveres a certeza de que não precisas dos commits posteriores. E verifica sempre o git reflog ANTES do reset, para saberes onde regressar se mudares de ideias.

Nível 5. git reflog + recuperação — cenário catastrófico.

Alguém (o Claude, tu ou um colega) já executou git reset --hard ou force-push e eliminou o trabalho. O que fazer?

git reflog                                          # procura o último hash antes da catástrofe
git branch recovered HEAD@{N}                       # cria um branch a partir dele
git checkout recovered                              # muda para esse branch
git diff main                                       # compara com o estado atual
git checkout main && git merge recovered            # restaura no main, se tiveres a certeza

Se o reflog já tiver sido limpo (ao fim de 90 dias por predefinição), o último recurso é git fsck --lost-found, que mostrará commits pendentes em .git/objects/. É quase arqueologia, mas às vezes funciona.

Regra para escolher um nível:

Como proteger um projeto para não haver nada a anular?#

Regra 1. Faz commit de 30 em 30 minutos.

Não esperes até «a tarefa estar concluída». Faz commit de qualquer passo intermédio que funcione. As mensagens de commit podem ser quaisquer; o mais importante é que o Claude (ou tu) possa regressar a um estado funcional com um único comando git checkout.

# no início de uma tarefa
git status                        # inspeciona todos os caminhos preparados e por preparar
git diff                          # revê as alterações
# Substitui este caminho pelo ficheiro real que reveste.
git add -- path/to/file.ts
git diff --cached                 # verifica exatamente o que entrará no commit
git commit -m "wip: starting User schema migration"

# passados 30 minutos (ou depois da primeira iteração funcional)
git status
git diff
git add -- path/to/file.ts         # caminho real revisto, não um padrão de diretório
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# no fim da tarefa — um commit significativo
git reset --soft HEAD~2           # combina os três commits wip num só
git commit -m "feat(auth): add lastLoginAt field to User table"

Se adicionares um lembrete PostToolUse, mantém a mesma regra de revisão e preparação de caminhos explícitos. Não transformes um temporizador num commit automático sem verificação: podem entrar alterações alheias à tarefa ou ficheiros já preparados.

Regra 2. .gitignore mínimo.

Estas linhas são obrigatórias na raiz do projeto:

# segredos
.env
.env.local
.env.*.local

# definições locais do Claude Code (não são enviadas para o repositório da equipa)
.claude/personal/
.claude/sessions/
.claude/file-history/

# dependências e compilação
node_modules/
dist/
.next/
build/

Mantenho a pasta .claude/personal/ para as minhas experiências e notas pessoais, que não devem ser incluídas no repositório partilhado. As pastas .claude/sessions/ e .claude/file-history/ são o armazenamento local do Claude Code; não pertencem ao repositório, ocupam muito espaço e estão associadas a um computador específico.

Regra 3. Faz experiências num branch separado.

Se a tarefa for grande (refatorizar 10+ ficheiros, migrar para uma nova base de dados, reescrever um módulo), não a faças no branch principal:

git checkout -b experiment/auth-rewrite
# trabalha e faz commit de 30 em 30 minutos
# se funcionar:
git checkout main
git merge experiment/auth-rewrite
# se não funcionar:
git checkout main
git branch -D experiment/auth-rewrite     # elimina o branch
# é tudo, o branch principal está intacto

Este hábito simples transforma «o Claude destruiu o projeto» em «o Claude destruiu um branch, apaguei-o e podemos recomeçar».

Regra 4. Antes de operações perigosas, usa git tag.

Antes de uma migração da base de dados, de uma refatorização grande ou de uma atualização de dependências, cria uma tag:

git tag pre-prisma-migration-v2
# trabalha
# algo correu mal:
git reset --hard pre-prisma-migration-v2
# ou limita-te a ver:
git checkout pre-prisma-migration-v2

Uma tag é um ponteiro com nome para um commit, que não perdes mesmo depois de limpar o reflog.

E agora: como se integra a anulação na gestão de contexto?#

Estes três níveis de anulação constituem a infraestrutura de uma competência: saber como restaurar um estado quando algo falha. Por si só, essa competência é limitada. Mas, combinada com outras ferramentas de gestão de contexto, transforma-se em algo mais.

O Plan Mode não te permite escrever código imediatamente — primeiro vem o plano, depois a confirmação e, por fim, a execução. É uma anulação preventiva: não escreves algo que mais tarde terias de anular porque o plano foi revisto antecipadamente. Lê mais no guia sobre o Plan Mode no Claude Code.

O ficheiro CLAUDE.md define regras que o Claude respeita por predefinição, incluindo o Protocolo de segurança do Git que abordámos acima. É uma proteção preventiva contra comandos destrutivos.

O Second Brain dá ao Claude memória sobre o projeto entre sessões — sabe que código tens, qual é a lógica de negócio e que acordos foram feitos anteriormente. Quanto mais memória, menor a probabilidade de fazer algo errado.

Skills e subagentes são a tua metodologia em código. Se o fluxo de trabalho correto do git estiver integrado numa Skill, nenhum subagente executará git reset --hard sem confirmação.

E tudo isto em conjunto é Context Engineering. Gere o contexto antes do prompt, não durante. Lê mais em o que é context engineering.

A anulação é a última linha de defesa. Plan Mode + CLAUDE.md + Second Brain + Skills são as primeiras quatro. Quando estão configuradas, a anulação é rara e rápida. Quando não estão, torna-se um ritual diário.

A anulação começa onde o planeamento termina.

Abrir o Ailoot.