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가 안도하는 느낌이 들 정도임
  백업은 정말 생명줄임