▲

Claude Code가 프로젝트 저장소에 10분마다 Git reset --hard origin/main을 실행하는 문제

 (github.com/anthropics)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • macOS 환경에서 프로젝트 변경사항이 10분마다 자동으로 삭제되는 현상이 보고됨
  • 조사 결과, 원인은 Claude Code가 아니라 사용자가 만든 별도 로컬 자동화 도구가 GitPython을 통해 주기적으로 git reset --hard origin/main을 실행한 것으로 확인됨
  • 동일한 작업 디렉터리를 공유한 탓에 Claude Code가 원인처럼 보였으나, 실제로는 외부 스크립트가 리셋을 수행하고 있었음
  • Claude Code 팀은 내부 코드에 해당 명령 실행 로직이 없음을 명확히 밝혔으며, --dangerously-skip-permissions 옵션 사용 시만 유사 동작이 가능함을 설명함
  • 최종적으로 이슈는 Claude Code 버그가 아닌 사용자 도구의 문제로 결론 나고, 제목이 수정되어 종료됨

문제 현상 및 환경

  • Claude Code가 사용자의 프로젝트 저장소에서 10분 간격으로 git fetch origin과 git reset --hard origin/main 을 수행하는 것으로 관찰됨
  • 이 동작은 커밋되지 않은 추적 파일의 변경사항을 모두 삭제하며, 추적되지 않은 파일은 유지됨
  • Git worktree 환경에서는 이러한 리셋이 발생하지 않음
  • 환경 정보
    • Claude Code 버전: 2.1.87 (Homebrew cask, Bun 바이너리)
    • OS: macOS 15.4 (Darwin 25.3.0, arm64)
    • Shell: zsh

조사 과정

  • Git reflog 에서 10분 간격으로 reset: moving to origin/main 로그가 95회 이상 기록됨
    • 세션별로 오프셋은 다르지만, 각 세션 내에서는 정확히 600초 간격으로 반복됨
  • 실시간 재현 테스트에서 추적 파일(api.ts)은 리셋 시점에 원상복구되고, 비추적 파일(.canary-test.txt)은 그대로 유지됨
  • fswatch 로 .git/ 디렉터리를 감시한 결과, 리셋 시점에 .git/refs 및 .git/logs/HEAD 파일이 수정되는 패턴이 포착됨
  • lsof 결과, 해당 저장소의 CWD를 사용하는 프로세스는 Claude Code CLI 하나뿐이었음
  • 외부 git 프로세스는 감지되지 않아, 내부적으로 libgit2 등으로 수행된 것으로 추정됨
  • worktree 환경에서는 reflog에 리셋 기록이 전혀 남지 않음

배제된 원인

  • Git hooks, Claude Code 사용자 훅, 플러그인 업데이트, macOS 클라우드 동기화, Cron/LaunchAgents, IDE, Time Machine, 파일 감시 도구 등은 모두 무관으로 확인됨
  • 각 항목은 실제 설정 파일 및 프로세스 점검을 통해 배제됨

바이너리 분석 (부분)

  • Claude Code 바이너리 내 함수 일부가 ["fetch","origin"] 명령을 수행하는 코드 조각을 포함
  • git pull 래퍼 함수와 fileHistory 상태 관리 로직이 존재하지만, 10분 주기 타이머는 식별되지 않음

영향

  • 커밋되지 않은 변경사항이 10분마다 자동으로 삭제되어, 2시간 세션 동안 세 차례 이상 수정사항이 사라짐
  • 모든 변경을 커밋한 상태에서는 리셋이 무의미하므로, 문제는 간헐적으로 보이는 특성이 있었음

Claude Code 팀의 응답

  • Jarred-Sumner 는 “Claude Code 자체에는 git reset --hard origin/main을 실행하는 코드가 없다”고 명확히 언급
  • --dangerously-skip-permissions 옵션을 사용하면 Claude가 프롬프트 없이 쉘 명령을 실행할 수 있으며, /loop 10m <prompt> 명령이 주기적으로 “원격과 동기화”를 요청할 경우 git fetch && git reset --hard origin/main이 실행될 수 있다고 설명
  • 확인 방법으로는
    1. grep -r "reset --hard" ~/.claude/projects/ 로 세션 로그 검색
    2. claude --debug-file /tmp/debug.txt --dangerously-skip-permissions 실행 후 10분 대기, grep -i bash /tmp/debug.txt | grep reset 검색
  • Claude Code의 fileHistory 기능은 git과 무관하며, 내부적으로 git reset을 호출하지 않음

최종 결론

  • 2026년 3월 30일 업데이트에서 문제의 근본 원인은 Claude Code가 아닌 사용자의 별도 로컬 도구로 확인됨
  • 해당 도구가 GitPython을 사용해 10분마다 하드 리셋을 수행했으며, Claude Code와 동일한 디렉터리를 감시하고 있었음
  • 이슈는 “not planned” 상태로 종료되었고, 제목이 “Claude Code가 리셋을 실행한다”에서 “내 자동화 도구가 리셋을 실행한다”로 수정됨

임시 해결책

  • git worktree 사용 시 리셋 영향 없음
  • 자주 커밋하여 변경사항을 보호 가능

관련 이슈

  • #8072 — 코드 수정이 반복적으로 되돌려지는 문제
  • #7232 — 승인 없이 git reset --hard 실행으로 데이터 손실 발생
  • #32793 — claude install 명령이 git remote URL을 잘못 변경하는 문제 (유사하지만 별개 사례)
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • 작성자가 직접 올린 업데이트임
    이슈 링크에 따르면, 문제의 근본 원인은 Claude Code가 아니라 작성자가 로컬 테스트용으로 만든 도구의 버그였음
    해당 도구가 로컬 작업 디렉토리를 원격과 동기화하려고 매 주기마다 하드 리셋을 수행하면서 커밋되지 않은 변경사항을 모두 삭제했던 것임

    • 작성자가 그렇게 많은 “조사”를 했다면서도 10분만 Claude를 꺼보는 생각은 안 했다는 게 웃김
      제목을 “개발자가 10분마다 git 리포를 리셋하는 스크립트를 만들어놓고 잊은 채 Claude Code를 탓함” 정도로 바꾸면 플래그를 해제하겠음

  • 진짜 문제는 제목의 이중 하이픈이 HN에서 자동으로 en dash로 바뀌었다는 점임

    • LaTeX에서는 이중 하이픈이 en dash, 삼중 하이픈이 em dash로 쓰임
    • 나도 원래는 이중 하이픈을 그대로 두는 게 맞다고 생각하지만, LaTeX과 Typst의 전통을 보면 en dash가 더 적절함
    • 전문가 팁: HN 제목을 그대로 복사해 커맨드라인에 붙여넣는 건 위험함
    • 원래는 “--hard”처럼 두 개의 하이픈으로 써야 함
    • 두 개는 en dash, 세 개는 em dash라는 규칙이 있음

  • 나도 이 문제를 직접 조사했는데, Claude Code 자체에는 git reset --hard origin/main을 실행하는 코드가 없음
    아마도 개발자가 /loop 10m 같은 명령을 돌리거나, 10분마다 git을 리셋하는 cron 작업을 만들었을 가능성이 높음

    • 아마 “서버와 주기적으로 동기화” 같은 무해한 기능으로 착각했을 수도 있음

  • 0.1초 간격으로 프로세스를 모니터링했는데 git 프로세스가 없었다는 건 신뢰하기 어려움
    git 명령은 너무 빨라서 그 간격으로는 잡히지 않음
    대신 $PATH의 git을 래핑해서 모든 실행을 로그로 남기는 방법이 더 나음

    • 이건 Claude Code가 자기 꼬리를 쫓는 상황 같음. 디버깅에 실패하자 스스로 버그 리포트를 만들려는 듯함
      심지어 사용자의 입력 없이 “에이전트적으로” 제출했을 수도 있음 (순전히 추측임)
      이슈 링크
    • 이런 경우에는 eBPF가 유용함. 예를 들어 bpftrace의 execsnoop 스크립트를 쓰면 시스템에서 실행되는 모든 프로세스를 추적할 수 있음

  • 이 글은 특정 개인의 문제를 전체 시스템 문제로 오해하게 만들 수 있음
    아마 일부 컨텍스트 손상이 있었던 것 같음

    • 나도 비슷한 일을 몇 번 겪었음. 한 번은 GitHub에 force push까지 되어버렸음
      Claude가 stash → sed 대체 → 충돌 → reset --hard 순으로 망가뜨린 적이 있음
      그래서 CLAUDE.md 맨 위에 다음 경고를 써둠
      “sed로 대량 치환 금지, git push --force, git reset --hard 등 파괴적 git 명령 절대 금지”
      그 이후로는 훨씬 나아졌음
    • 네 말이 맞을 수도 있음. 하지만 컨텍스트가 0.1%만 손상돼도 1000개의 작업 중 하나는 데이터를 날릴 수 있음
    • 사실 이런 문제는 기술적 방어로 완전히 막을 수 있음.
      특정 git 명령을 차단하는 hook을 걸면 모델의 예측 불확실성과 상관없이 안전하게 동작함
      이런 걸 보면 예전 엔지니어링의 기본 원칙 — 결정적이고 반복 가능한 프로세스 — 을 잊은 사람이 많다는 생각이 듦
    • 결국 LLM은 가끔 정말 멍청한 행동을 함. 그게 전부임

  • 나도 비슷한 문제를 겪었음
    평소엔 claude-code를 sandbox(bwrap, srt) 안에서 돌리는데, 밖에서 실행하면 /command를 지우거나 메뉴를 닫을 때마다 gh를 호출함
    KeepassXC를 비밀 관리자로 쓰기 때문에 매번 승인 팝업이 떠서 바로 눈에 띔
    Claude에게 물어보니 원인은 git context 기능 때문이었음.
    KeepassXC는 세션 단위 허용이 안 되기 때문에, 결국 매번 인증을 요구하게 됨

  • 권한 설정이 있다면 이런 일이 막히지 않나 싶음
    하지만 사용자가 --dangerously-skip-permissions 옵션으로 실행했으니 예측 불가능한 행동을 감수해야 함

    • 그래도 pretooluse hook을 쓰면 이 옵션을 켜도 방지할 수 있음
    • Anthropic의 permissions 문서를 보면 권한이 실제로 어떻게 강제되는지 불분명함.
      프롬프트 인젝션으로 우회할 수도 있다는 해석도 가능함
    • 실시간 리포에서 권한 없이 돌리는 건 데이터 삭제 사고를 자초하는 일임
      하드 리셋을 막지 못하는 규칙은 그냥 보여주기식임
    • 지금의 규칙과 권한은 프로그램 플래그가 아니라, 단순히 에이전트가 “지켜야 한다고 믿는” 텍스트에 불과함

  • 작성자가 직접 밝히길, 원인은 Claude Code가 아니라 자신이 만든 로컬 테스트 도구의 버그였음

    • 즉, 잘못된 신고였음
      이슈 링크
    • “내가 만든 도구”라는 표현이 좀 애매함. 아마도 급하게 만든 vibe-coded 툴일 가능성이 큼
    • 사실 이 티켓 자체가 Claude Code의 분석 결과(즉, 환각) 로 생성된 것일 수도 있음

  • SaaS 기반의 바이너리 블롭 개발 도구를 쓰면 이런 디버깅 어려운 문제가 생길 수 있다는 건 놀랍지 않음

  • 결국 사용자가 직접 원인을 밝혀냈고, 자신의 도구가 문제의 원인이었음
    이런 일은 예전에도 있었고, 지금도 있음.
    나도 LLM 도움 없이 내 손으로 충분히 망가뜨린 적이 많음
    그래서 나는 항상 Mac의 Time Machine으로 개발함.
    Claude가 파일을 지웠을 때도 “복원할까?” 하면 Claude가 안도하는 느낌이 들 정도임
    백업은 정말 생명줄임

답변달기