Problema en el que Claude Code ejecuta `git reset --hard origin/main` en el repositorio del proyecto cada 10 minutos

• Se reportó un fenómeno en macOS donde los cambios del proyecto se borraban automáticamente cada 10 minutos.
• Tras la investigación, se confirmó que la causa no era Claude Code sino otra herramienta local de automatización creada por el usuario, que ejecutaba periódicamente git reset --hard origin/main mediante GitPython.
• Como ambos compartían el mismo directorio de trabajo, parecía que Claude Code era el causante, pero en realidad el reinicio lo estaba haciendo un script externo.
• El equipo de Claude Code aclaró que no existe lógica en su código interno para ejecutar ese comando, y explicó que un comportamiento similar solo sería posible al usar la opción --dangerously-skip-permissions.
• Finalmente, se concluyó que el issue no era un bug de Claude Code sino un problema de una herramienta del usuario, y el título fue corregido antes de cerrarse.

---

Síntomas del problema y entorno

• Se observó que Claude Code ejecutaba git fetch origin y git reset --hard origin/main cada 10 minutos en el repositorio del proyecto del usuario.
• Este comportamiento elimina todos los cambios en archivos rastreados que no hayan sido confirmados, mientras que los archivos no rastreados se conservan.
• En un entorno con Git worktree, este reinicio no ocurría.
• Información del entorno
  • Versión de Claude Code: 2.1.87 (Homebrew cask, binario de Bun)
  • OS: macOS 15.4 (Darwin 25.3.0, arm64)
  • Shell: zsh

Proceso de investigación

• En el Git reflog se registró más de 95 veces el log reset: moving to origin/main a intervalos de 10 minutos.
  • Aunque el desfase variaba entre sesiones, dentro de cada sesión se repetía exactamente cada 600 segundos.
• En una prueba de reproducción en tiempo real, el archivo rastreado (api.ts) volvía a su estado original al momento del reset, mientras que el archivo no rastreado (.canary-test.txt) permanecía intacto.
• Al monitorear el directorio .git/ con fswatch, se detectó un patrón en el que los archivos .git/refs y .git/logs/HEAD se modificaban en el momento del reset.
• Según lsof, el único proceso que usaba ese repositorio como CWD era el CLI de Claude Code.
• Como no se detectaron procesos git externos, se supuso que se estaba realizando internamente con libgit2 o algo similar.
• En el entorno de worktree, no quedaba ningún registro de reset en el reflog.

Causas descartadas

• Se confirmó que no estaban relacionados Git hooks, hooks de usuario de Claude Code, actualizaciones de plugins, sincronización en la nube de macOS, Cron/LaunchAgents, IDEs, Time Machine ni herramientas de vigilancia de archivos.
• Cada elemento fue descartado revisando directamente los archivos de configuración y los procesos reales.

Análisis del binario (parcial)

• Parte de las funciones dentro del binario de Claude Code incluían fragmentos de código que ejecutaban el comando ["fetch","origin"].
• Existían una función wrapper para git pull y lógica de gestión de estado de fileHistory, pero no se identificó ningún temporizador de 10 minutos.

Impacto

• Los cambios no confirmados se eliminaban automáticamente cada 10 minutos, y durante una sesión de 2 horas los cambios desaparecieron al menos tres veces.
• Como el reset no tiene efecto cuando todos los cambios ya están committeados, el problema podía parecer intermitente.

Respuesta del equipo de Claude Code

• Jarred-Sumner afirmó claramente: “Claude Code en sí no tiene código que ejecute git reset --hard origin/main”.
• Explicó que, si se usa la opción --dangerously-skip-permissions, Claude puede ejecutar comandos de shell sin pedir confirmación, y que si el comando /loop 10m <prompt> solicita periódicamente “sincronizar con el remoto”, podría ejecutarse git fetch && git reset --hard origin/main.
• Como formas de verificación, propuso:
  1. Buscar en los logs de sesión con grep -r "reset --hard" ~/.claude/projects/
  2. Ejecutar claude --debug-file /tmp/debug.txt --dangerously-skip-permissions, esperar 10 minutos y luego buscar con grep -i bash /tmp/debug.txt | grep reset
• La función fileHistory de Claude Code no está relacionada con git y no llama internamente a git reset.

Conclusión final

• En la actualización del 30 de marzo de 2026, se confirmó que la causa raíz del problema no era Claude Code sino otra herramienta local del usuario.
• Esa herramienta usaba GitPython para hacer un hard reset cada 10 minutos y estaba monitoreando el mismo directorio que Claude Code.
• El issue se cerró con estado "not planned", y el título fue cambiado de “Claude Code ejecuta reset” a “Mi herramienta de automatización ejecuta reset”.

Soluciones temporales

• Al usar git worktree, no hay impacto del reset.
• Se pueden proteger los cambios haciendo commits frecuentes.

Issues relacionados

• #8072 — problema en el que los cambios de código se revierten repetidamente
• #7232 — pérdida de datos por ejecución de git reset --hard sin aprobación
• #32793 — problema donde el comando claude install cambia incorrectamente la URL del remote de git (caso similar pero distinto)

[GN⁺]

Comentarios en Hacker News

• Esta es una actualización publicada por el propio autor
  Según el enlace del issue, la causa raíz del problema no era Claude Code sino un bug en una herramienta que el autor había hecho para pruebas locales
  Esa herramienta intentaba sincronizar el directorio de trabajo local con el remoto y hacía un hard reset en cada ciclo, borrando todos los cambios sin commit

  • Da risa que, después de decir que hizo tanta “investigación”, no se le ocurriera simplemente apagar Claude durante 10 minutos
    Si cambiara el título a algo como “Un desarrollador crea un script que resetea el repo git cada 10 minutos, se olvida de eso y luego culpa a Claude Code”, le quitaría la marca

• El verdadero problema es que el doble guion del título fue convertido automáticamente en un en dash por HN

  • En LaTeX, el doble guion se usa para en dash y el triple guion para em dash
  • Yo también pensaba originalmente que lo correcto era dejar el doble guion tal cual, pero viendo la tradición de LaTeX y Typst, el en dash parece más apropiado
  • Consejo de experto: es peligroso copiar un título de HN tal cual y pegarlo en la línea de comandos
  • Originalmente debería escribirse con dos guiones, como en “--hard”
  • Existe la regla de que dos son en dash y tres son em dash

• Yo también investigué este problema directamente, y Claude Code en sí no tiene código que ejecute git reset --hard origin/main
  Lo más probable es que el desarrollador haya corrido un comando como /loop 10m, o creado un trabajo de cron que resetea git cada 10 minutos

  • Tal vez lo confundió con alguna función inocente como “sincronizar periódicamente con el servidor”

• Cuesta creer que haya monitoreado procesos cada 0.1 segundos y no apareciera ningún proceso de git
  Los comandos de git son demasiado rápidos como para atraparlos con ese intervalo
  En cambio, es mejor envolver el git de $PATH y dejar registro en logs de cada ejecución

  • Esto suena a que Claude Code está persiguiendo su propia cola. Como si, al fallar en depurar el problema, hubiera intentado crear por sí mismo un bug report
    Incluso podría haberlo enviado de forma “agéntica” sin entrada del usuario (mera especulación)
    Enlace del issue
  • En casos así, eBPF sirve bastante. Por ejemplo, con el script execsnoop de bpftrace puedes rastrear todos los procesos que se ejecutan en el sistema

• Esta publicación puede hacer que se malinterprete un problema individual como si fuera un problema del sistema completo
  Probablemente hubo algo de corrupción de contexto

  • A mí me han pasado cosas parecidas varias veces. Una vez incluso terminó en un force push a GitHub
    Claude la arruinó siguiendo la secuencia stash → reemplazo con sed → conflicto → reset --hard
    Por eso dejé esta advertencia al principio de CLAUDE.md
    “Prohibido hacer reemplazos masivos con sed, git push --force, git reset --hard y otros comandos destructivos de git”
    Desde entonces ha mejorado bastante
  • Puede que tengas razón. Pero si el contexto se corrompe aunque sea un 0.1%, una de cada 1000 tareas puede terminar borrando datos
  • En realidad, este tipo de problema sí puede bloquearse por completo con defensas técnicas.
    Si pones un hook que bloquee ciertos comandos de git, se comportará de forma segura sin importar la incertidumbre predictiva del modelo
    Viendo esto, da la impresión de que mucha gente olvidó los principios básicos de la ingeniería de antes: procesos deterministas y repetibles
  • Al final, los LLM a veces hacen cosas realmente estúpidas. Eso es todo

• A mí me pasó algo parecido
  Normalmente ejecuto claude-code dentro de un sandbox (bwrap, srt), pero cuando lo corro fuera, llama a gh cada vez que borro un /command o cierro un menú
  Como uso KeepassXC como administrador de secretos, cada vez aparece un popup de aprobación y por eso se nota enseguida
  Cuando le pregunté a Claude, me dijo que la causa era la función de git context.
  Como KeepassXC no permite autorizaciones por sesión, al final termina pidiendo autenticación cada vez

• Uno pensaría que esto se evitaría si hay una configuración de permisos
  Pero como el usuario lo ejecutó con la opción --dangerously-skip-permissions, tuvo que aceptar comportamiento impredecible

  • Aun así, con un pretooluse hook se puede evitar incluso con esa opción activada
  • Si lees la documentación de permisos de Anthropic, no queda claro cómo se hacen cumplir realmente esos permisos.
    Incluso podría interpretarse que se pueden eludir mediante prompt injection
  • Ejecutarlo sin permisos en un repo en vivo es prácticamente buscarse un incidente de borrado de datos
    Una regla que no puede impedir un hard reset es puro adorno
  • Las reglas y permisos actuales no son flags del programa, sino solo texto que el agente “cree que debe obedecer”

• Según explicó el propio autor, la causa no era Claude Code sino un bug en una herramienta local de pruebas que él mismo había hecho

  • O sea, fue un reporte equivocado
    Enlace del issue
  • La expresión “una herramienta que hice yo” es un poco ambigua. Probablemente era una herramienta vibe-coded armada a las apuradas
  • De hecho, este ticket mismo podría haber sido generado por el análisis de Claude Code (o sea, una alucinación)

• No sorprende que usar herramientas de desarrollo tipo binary blob basadas en SaaS pueda provocar este tipo de problemas difíciles de depurar

• Al final el usuario descubrió por sí mismo la causa, y su propia herramienta era el origen del problema
  Estas cosas ya pasaban antes y siguen pasando ahora.
  Yo también me he arruinado suficiente por mi cuenta sin ayuda de ningún LLM
  Por eso siempre desarrollo con Time Machine de Mac.
  Cuando Claude borra archivos y sale “¿Restaurar?”, casi se siente como si Claude respirara aliviado
  Los respaldos de verdad son una línea de vida