Problema em que o Claude Code executa `git reset --hard origin/main` no repositório do projeto a cada 10 minutos

• Foi relatado, em ambiente macOS, um fenômeno em que as alterações do projeto eram apagadas automaticamente a cada 10 minutos
• Após a investigação, confirmou-se que a causa não era o Claude Code, mas sim uma ferramenta local de automação separada criada pelo usuário, que executava periodicamente git reset --hard origin/main via GitPython
• Como ambos compartilhavam o mesmo diretório de trabalho, parecia que o Claude Code era o responsável, mas na prática o reset estava sendo feito por um script externo
• A equipe do Claude Code declarou claramente que não existe lógica interna que execute esse comando, e explicou que um comportamento semelhante só seria possível ao usar a opção --dangerously-skip-permissions
• Por fim, concluiu-se que o problema não era um bug do Claude Code, mas da ferramenta do usuário, e o título foi corrigido antes do encerramento

---

Sintomas do problema e ambiente

• Foi observado que o Claude Code executava git fetch origin e git reset --hard origin/main em intervalos de 10 minutos no repositório do projeto do usuário
• Esse comportamento apagava todas as alterações não commitadas em arquivos rastreados, enquanto arquivos não rastreados eram mantidos
• Em ambiente com Git worktree, esse reset não ocorria
• Informações do ambiente
  • Versão do Claude Code: 2.1.87 (Homebrew cask, binário Bun)
  • OS: macOS 15.4 (Darwin 25.3.0, arm64)
  • Shell: zsh

Processo de investigação

• No Git reflog, foram registrados mais de 95 logs de reset: moving to origin/main em intervalos de 10 minutos
  • O deslocamento variava entre sessões, mas dentro de cada sessão a repetição ocorria exatamente a cada 600 segundos
• Em um teste de reprodução em tempo real, o arquivo rastreado (api.ts) voltava ao estado original no momento do reset, enquanto o arquivo não rastreado (.canary-test.txt) permanecia intacto
• Ao monitorar o diretório .git/ com fswatch, foi detectado um padrão em que os arquivos .git/refs e .git/logs/HEAD eram modificados no momento do reset
• Segundo o lsof, o único processo usando esse repositório como CWD era o próprio CLI do Claude Code
• Como nenhum processo git externo foi detectado, levantou-se a hipótese de execução interna via libgit2 ou similar
• Em ambiente com worktree, nenhum registro de reset aparecia no reflog

Causas descartadas

• Git hooks, hooks de usuário do Claude Code, atualização de plugins, sincronização em nuvem do macOS, Cron/LaunchAgents, IDE, Time Machine e ferramentas de monitoramento de arquivos foram todos confirmados como não relacionados
• Cada item foi descartado por meio da verificação real de arquivos de configuração e processos

Análise do binário (parcial)

• Parte das funções dentro do binário do Claude Code incluía trechos de código que executavam o comando ["fetch","origin"]
• Havia uma função wrapper para git pull e lógica de gerenciamento de estado de fileHistory, mas nenhum timer de 10 minutos foi identificado

Impacto

• Alterações não commitadas eram apagadas automaticamente a cada 10 minutos, fazendo com que modificações desaparecessem mais de três vezes durante uma sessão de 2 horas
• Quando todas as mudanças estavam commitadas, o reset não tinha efeito prático, o que fazia o problema parecer intermitente

Resposta da equipe do Claude Code

• Jarred-Sumner afirmou claramente: “o próprio Claude Code não tem código que execute git reset --hard origin/main”
• Ele explicou que, ao usar a opção --dangerously-skip-permissions, o Claude pode executar comandos de shell sem prompt, e que, se o comando /loop 10m <prompt> solicitar periodicamente “sincronizar com o remoto”, poderá acabar executando git fetch && git reset --hard origin/main
• Como formas de verificação, foram sugeridos:
  1. grep -r "reset --hard" ~/.claude/projects/ para buscar nos logs de sessão
  2. Executar claude --debug-file /tmp/debug.txt --dangerously-skip-permissions, esperar 10 minutos e então buscar com grep -i bash /tmp/debug.txt | grep reset
• O recurso fileHistory do Claude Code não tem relação com git e não chama git reset internamente

Conclusão final

• Na atualização de 30 de março de 2026, confirmou-se que a causa raiz do problema não era o Claude Code, mas uma ferramenta local separada do usuário
• Essa ferramenta usava GitPython para executar hard reset a cada 10 minutos e monitorava o mesmo diretório do Claude Code
• A issue foi encerrada com status not planned, e o título foi alterado de “o Claude Code executa resets” para “minha ferramenta de automação executa resets”

Soluções temporárias

• Ao usar git worktree, não há impacto do reset
• É possível proteger as alterações fazendo commits frequentes

Issues relacionadas

• #8072 — problema em que modificações de código são revertidas repetidamente
• #7232 — perda de dados causada pela execução de git reset --hard sem aprovação
• #32793 — problema em que o comando claude install altera incorretamente a URL do git remote (caso semelhante, mas distinto)

[GN⁺]

Comentários do Hacker News

• É uma atualização postada pelo próprio autor
  Segundo o link da issue, a causa raiz do problema não era o Claude Code, e sim um bug em uma ferramenta que o autor criou para testes locais
  Essa ferramenta fazia um hard reset a cada ciclo ao tentar sincronizar o diretório de trabalho local com o remoto, apagando todas as alterações não commitadas

  • É engraçado que o autor disse ter feito tanta “investigação”, mas nem pensou em desligar o Claude por 10 minutos
    Eu removeria a flag se o título fosse algo como “Desenvolvedor cria um script que reseta o repo git a cada 10 minutos, esquece disso e culpa o Claude Code”

• O verdadeiro problema é que o hífen duplo no título foi automaticamente convertido em en dash no HN

  • No LaTeX, hífen duplo vira en dash e hífen triplo vira em dash
  • Eu também achava que o certo era manter o hífen duplo como está, mas pela tradição do LaTeX e do Typst, o en dash parece mais apropriado
  • Dica de especialista: é perigoso copiar um título do HN e colar direto na linha de comando
  • O correto originalmente seria escrever com dois hífens, como em --hard
  • A regra é dois para en dash, três para em dash

• Eu também investiguei isso diretamente, e o próprio Claude Code não tem código que execute git reset --hard origin/main
  O mais provável é que o desenvolvedor tenha executado um comando como /loop 10m ou criado um cron job para resetar o git a cada 10 minutos

  • Talvez ele tenha confundido isso com alguma função inofensiva, como “sincronizar periodicamente com o servidor”

• É difícil confiar na alegação de que monitoraram processos em intervalos de 0,1 segundo e não apareceu nenhum processo git
  Comandos git são rápidos demais para serem pegos nesse intervalo
  Em vez disso, é melhor encapsular o git do $PATH para registrar em log todas as execuções

  • Isso parece uma situação em que o Claude Code está correndo atrás do próprio rabo. Como falhou ao depurar, parece que tentou criar ele mesmo um bug report
    Talvez até tenha enviado isso “agencialmente”, sem input do usuário (pura especulação)
    Link da issue
  • Nesses casos, eBPF é útil. Por exemplo, com o script execsnoop do bpftrace, dá para rastrear todos os processos executados no sistema

• Este post pode levar a uma interpretação equivocada de que um problema individual é um problema do sistema como um todo
  Parece que houve algum tipo de corrupção de contexto

  • Já passei por algo parecido algumas vezes. Em uma delas, acabou rolando até force push no GitHub
    O Claude já bagunçou tudo numa sequência stash → substituição com sed → conflito → reset --hard
    Por isso, deixei o seguinte aviso no topo do CLAUDE.md
    “Proibido fazer substituições em massa com sed; git push --force, git reset --hard e outros comandos destrutivos do git são absolutamente proibidos”
    Depois disso, ficou bem melhor
  • Você pode estar certo. Mas, se o contexto se corromper só 0,1%, uma entre 1000 tarefas pode apagar dados
  • Na verdade, esse tipo de problema pode ser totalmente evitado com defesas técnicas.
    Se você colocar um hook para bloquear certos comandos git, o sistema continua seguro independentemente da incerteza preditiva do modelo
    Vendo isso, dá a impressão de que muita gente esqueceu um princípio básico da engenharia de antigamente — processos determinísticos e reproduzíveis
  • No fim das contas, LLMs às vezes fazem coisas realmente estúpidas. Só isso

• Eu também tive um problema parecido
  Normalmente executo o claude-code dentro de um sandbox (bwrap, srt), mas quando rodo fora dele, ele chama gh sempre que apago um /command ou fecho o menu
  Como uso o KeepassXC como gerenciador de segredos, aparece um pop-up de aprovação toda vez, então isso fica óbvio na hora
  Quando perguntei ao Claude, ele disse que a causa era o recurso de contexto git.
  Como o KeepassXC não permite autorização por sessão, no fim ele exige autenticação todas as vezes

• Imagino que isso não deveria ser bloqueado pelas configurações de permissão
  Mas como o usuário executou com a opção --dangerously-skip-permissions, ele tem que aceitar comportamentos imprevisíveis

  • Ainda assim, com um hook pretooluse, dá para impedir isso mesmo com essa opção ativada
  • Pela documentação de permissions da Anthropic, não fica claro como as permissões são realmente aplicadas.
    Dá até para interpretar que isso poderia ser burlado por prompt injection
  • Rodar isso em um repositório real sem permissões é praticamente pedir um incidente de perda de dados
    Regras que não conseguem bloquear hard reset servem só para inglês ver
  • As regras e permissões atuais não são flags de programa; no fim, são só texto que o agente “acredita que deve seguir”

• O próprio autor esclareceu que a causa não era o Claude Code, e sim um bug na ferramenta local de teste que ele criou

  • Ou seja, foi uma denúncia equivocada
    Link da issue
  • A expressão “ferramenta que eu criei” é um pouco vaga. Provavelmente era uma ferramenta vibe-coded feita às pressas
  • Na verdade, há até a possibilidade de que esse ticket tenha sido gerado pela própria análise do Claude Code (ou seja, uma alucinação)

• Não é surpresa que usar uma ferramenta de desenvolvimento SaaS em blob binário possa gerar problemas assim, difíceis de depurar

• No fim, foi o próprio usuário que descobriu a causa, e a culpada era a ferramenta dele
  Isso já aconteceu antes e continua acontecendo.
  Eu mesmo já causei estragos suficientes com as próprias mãos, sem ajuda de LLM nenhuma
  Por isso, eu sempre desenvolvo com o Time Machine do Mac.
  Quando o Claude apaga um arquivo e aparece “restaurar?”, quase dá a sensação de que o Claude fica aliviado
  Backup é realmente uma linha de vida