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

> Clean Markdown view of GeekNews topic #28020. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28020](https://news.hada.io/topic?id=28020)
- GeekNews Markdown: [https://news.hada.io/topic/28020.md](https://news.hada.io/topic/28020.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-31T05:33:26+09:00
- Updated: 2026-03-31T05:33:26+09:00
- Original source: [github.com/anthropics](https://github.com/anthropics/claude-code/issues/40710)
- Points: 3
- Comments: 1

## Topic Body

- 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을 잘못 변경하는 문제 (유사하지만 별개 사례)

## Comments



### Comment 54165

- Author: neo
- Created: 2026-03-31T05:33:26+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47567969) 
- 작성자가 직접 올린 **업데이트**임  
  [이슈 링크](https://github.com/anthropics/claude-code/issues/40710#issue...)에 따르면, 문제의 근본 원인은 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가 자기 꼬리를 쫓는 상황 같음. 디버깅에 실패하자 스스로 버그 리포트를 만들려는 듯함  
    심지어 사용자의 입력 없이 “에이전트적으로” 제출했을 수도 있음 (순전히 추측임)  
    [이슈 링크](https://github.com/anthropics/claude-code/issues/40701#issue...)  
  - 이런 경우에는 **eBPF**가 유용함. 예를 들어 [bpftrace](https://bpftrace.org)의 [execsnoop](https://github.com/bpftrace/bpftrace/blob/master/tools/execsnoop.bt) 스크립트를 쓰면 시스템에서 실행되는 모든 프로세스를 추적할 수 있음

- 이 글은 특정 개인의 문제를 전체 시스템 문제로 **오해**하게 만들 수 있음  
  아마 일부 **컨텍스트 손상**이 있었던 것 같음  
  - 나도 비슷한 일을 몇 번 겪었음. 한 번은 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 문서](https://code.claude.com/docs/en/permissions)를 보면 권한이 실제로 어떻게 강제되는지 불분명함.  
    프롬프트 인젝션으로 우회할 수도 있다는 해석도 가능함  
  - 실시간 리포에서 권한 없이 돌리는 건 **데이터 삭제 사고**를 자초하는 일임  
    하드 리셋을 막지 못하는 규칙은 그냥 보여주기식임  
  - 지금의 규칙과 권한은 프로그램 플래그가 아니라, 단순히 에이전트가 “지켜야 한다고 믿는” **텍스트**에 불과함

- 작성자가 직접 밝히길, 원인은 Claude Code가 아니라 자신이 만든 로컬 테스트 도구의 버그였음  
  - 즉, **잘못된 신고**였음  
    [이슈 링크](https://github.com/anthropics/claude-code/issues/40710#issue...)  
  - “내가 만든 도구”라는 표현이 좀 애매함. 아마도 급하게 만든 **vibe-coded 툴**일 가능성이 큼  
  - 사실 이 티켓 자체가 Claude Code의 **분석 결과(즉, 환각)** 로 생성된 것일 수도 있음

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

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