技術 約6分で読めます

Claude Codeが10分ごとにgit reset --hardを実行するバグ報告と、その誤報までの顛末

Claude Code Anthropic Git Bug AIエージェント

2026年3月29日、「Claude Codeが10分ごとに git reset --hard origin/main を実行してプロジェクトの未コミット変更を破壊する」というGitHub issue（#40710）が投稿された。Hacker Newsで244ポイントを獲得し、Google Feedにも載り、各ニュースサイトが取り上げた。

そして約10時間後、報告者本人が原因を特定した。Claude Codeではなく、自分が作った別のツールが犯人だった。

報告された現象

報告者のJohn Mathewsが観測した現象は具体的で、一見して説得力があった。

git reflogに95件以上の reset: moving to origin/main エントリが記録されており、すべて正確に10分間隔だった。セッションごとにオフセット秒が異なるが、間隔は常に600秒。4セッション、約36時間にわたって再現していた。

e8ea2c9 HEAD@{2026-03-29 22:19:09 +0200}: reset: moving to origin/main
e8ea2c9 HEAD@{2026-03-29 22:09:09 +0200}: reset: moving to origin/main
e8ea2c9 HEAD@{2026-03-29 21:59:09 +0200}: reset: moving to origin/main
e8ea2c9 HEAD@{2026-03-29 21:49:09 +0200}: reset: moving to origin/main

追跡されたファイルへの変更は10分ごとに消え、untrackedファイルは残る。git worktreeは影響を受けない。この挙動は git fetch origin + git reset --hard origin/main のパターンに完全に一致していた。

調査の精度と、それでも間違えた理由

報告者の調査手法自体はかなり丁寧だった。

除外した原因調査方法
Git hooks.sampleのみ、husky/lint-staged なし
Claude Codeユーザーhooks音声通知のみ、git操作するhookなし
macOSクラウド同期iCloud, Dropbox, Syncthing, Synology, Google Driveすべて非該当
cron/LaunchAgentscrontab空、LaunchAgentにgit操作なし
IDE/エディタnvimは別リポジトリ
Time MachineローカルスナップショットはAPFS読み取り専用
ファイルウォッチャーfswatch/entr/watchman/guard 動作なし

さらに lsof で確認したところ、対象リポジトリにCWDを持つプロセスはClaude Code CLIだけだった。プロセスモニタリングでは外部の git バイナリの起動も検出されなかった。fswatch が .git/ 配下のロックファイル生成を捕捉しており、プログラム的なgit操作が行われていることも確認された。

コンパイル済みバイナリの逆アセンブルまで行い、hg1() 関数が ["fetch","origin"] を明示的なCWDなしで実行していること、io1() 関数がgit pullラッパーであることまで突き止めている。

問題は、真犯人が同じCWDで動いていたことだった。

真犯人は自作ツール

投稿から約10時間後、報告者が原因を特定したコメントを投稿した。

犯人はローカルで動かしていたテスト用の自作ツールだった。GitPythonでリポジトリを操作しており、設定がローカルの作業ディレクトリを指している状態ではポーリングサイクルごとにリモートに合わせてハードリセットを実行する仕様だった。

証拠がすべてClaude Codeを指していたのは、ツールの挙動がことごとく重なっていたからだ。

  • 10分間隔が一致したのは、ツールのポーリング間隔を600秒に設定していたから
  • セッションごとにオフセットが変わったのは、タイマーがツールの起動時刻に紐づいていたから
  • 外部gitバイナリが検出されなかったのは、ツールがGitPythonでプログラム的に操作していたから
  • lsof でClaude Codeだけが見えたのは、両者が同じプロジェクトディレクトリで動いていたから

報告者が作業していたプロジェクトのドキュメントを提供するためにこのツールを使っており、Claude Codeで作業していたディレクトリと完全に一致していた。Claude Code以外の候補が見つからないという結論は、候補の検索範囲に自作ツールが入っていなかったために起きた見落としだった。

Bun開発者の指摘

issueのコメントで、Bunの開発者であるJarred Sumnerが別の仮説を提示していた。--dangerously-skip-permissions フラグでClaude Codeを実行しているため、Claude Codeがシェルコマンドとして git fetch && git reset --hard を確認なしに実行している可能性を指摘し、「Claude Code自体にはgit reset —hardを実行するコードはない」と明言した。

セッション内のトランスクリプトに reset --hard が記録されているか確認することを提案していたが、結局この仮説も外れで、根本原因は自作ツールだった。

拡散の速度と修正の遅れ

このissueは典型的な「AIが暴走した」ストーリーのフォーマットに完璧にフィットしていた。具体的な証拠、再現手順、破壊的な影響。Google FeedやHacker Newsで急速に拡散し、コメント欄には「Googleに記事を送り込まれてここに来た」という反応が大量についた。

issue自体のリアクションも象徴的で、😂が55件と最多だった。真相判明後に笑いに転じた形だ。

コメント欄では「未確認の再現不能なバグがクリックベイトとしてニュースサイトに載ること」への懸念が複数上がっていた。報告者は誤報を認めた後、issueの冒頭に訂正を追記している。ただ、訂正がニュースとして同じ速度で広まることはない。

git reset --hard はClaude Codeの既知の問題ではある

今回のissue #40710は誤報だったが、Claude Codeと git reset --hard の組み合わせは過去にも問題になっている。

  • #7232 ではClaude Codeがユーザーの許可なく git reset --hard を実行してデータを破壊した事例が報告されている
  • #8072 ではコードの変更が繰り返し巻き戻される現象が報告された
  • #17190 では安全な git checkout で済む場面で破壊的な git reset --hard を選択した事例が報告されている

これらはいずれもClaude Codeのモデル側が git reset --hard を実行判断する問題で、今回のような10分間隔のタイマーによる自動実行とは性質が異なる。ただし、Claude Codeが破壊的なgitコマンドを使いがちだという前例があったからこそ、今回の誤報は即座に信じられた。以前取り上げたKiroの本番環境削除やClaude Codeのauto-compaction問題やCowork VMの無警告生成が積み重なり、「またか」という空気ができていた。

--dangerously-skip-permissions の実務的リスク

今回の報告者は claude --dangerously-skip-permissions でClaude Codeを実行していた。このフラグはすべてのBashコマンドをユーザー確認なしに実行する。仮にClaude Codeがセッション内で git reset --hard を実行判断したとしても、通常モードなら確認プロンプトが表示されて止まる。

flowchart LR
    A["Claude Codeが<br/>git reset --hard<br/>を実行判断"] --> B{"パーミッション<br/>モード"}
    B -->|"通常モード"| C["ユーザーに<br/>確認プロンプト表示"]
    C --> D["承認/拒否"]
    B -->|"--dangerously-skip-<br/>permissions"| E["即座に実行<br/>確認なし"]

このフラグの名前に dangerously が入っているのは伊達ではない。AIエージェントに対して「確認なしで何でも実行していい」と宣言することの意味は、今回のケースが仮にClaude Codeの問題だったとしても変わらない。