3 ポイント 投稿者 GN⁺ 2026-03-31 | 1件のコメント | WhatsAppで共有
  • macOS環境で、プロジェクトの変更内容が10分ごとに自動で削除される現象が報告された
  • 調査の結果、原因はClaude Codeではなく、ユーザーが作成した別のローカル自動化ツールがGitPython経由で定期的に git reset --hard origin/main を実行していたことが判明した
  • 同じ作業ディレクトリを共有していたためClaude Codeが原因のように見えたが、実際には外部スクリプトがリセットを実行していた
  • Claude Codeチームは、内部コードに該当コマンドを実行するロジックはないことを明確にし、--dangerously-skip-permissions オプションを使った場合にのみ類似の動作が起こりうると説明した
  • 最終的に、この問題はClaude Codeのバグではなくユーザーツールの問題と結論づけられ、タイトルが修正されて終了した

問題の現象と環境

  • Claude Codeがユーザーのプロジェクトリポジトリで、10分間隔で git fetch origingit 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時間のセッション中に3回以上修正内容が消えた
  • すべての変更をコミットした状態ではリセットに意味がないため、問題は断続的に見える特性があった

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と同じディレクトリを監視していた
  • このIssueは「not planned」状態で終了し、タイトルも「Claude Codeがリセットを実行する」から「自分の自動化ツールがリセットを実行する」へ修正された

一時的な回避策

  • git worktreeの使用 ではリセットの影響を受けない
  • 頻繁にコミットすることで変更内容を保護できる

関連Issue

  • #8072 — コード修正が繰り返し元に戻される問題
  • #7232 — 承認なしで git reset --hard が実行され、データ損失が発生する問題
  • #32793claude install コマンドがgit remote URLを誤って変更する問題(似ているが別件)

1件のコメント

 
GN⁺ 2026-03-31
Hacker Newsのコメント
  • 投稿者本人によるアップデート
    イシューへのリンクによると、問題の根本原因はClaude Codeではなく、投稿者がローカルテスト用に作ったツールのバグだった
    そのツールがローカルの作業ディレクトリをリモートと同期しようとして、各周期ごとにハードリセットを実行し、コミットされていない変更をすべて削除していた

    • あれだけ「調査」したと言いながら、10分間Claudeを止めてみることすら思いつかなかったのは笑える
      タイトルを「開発者が10分おきにgitリポジトリをリセットするスクリプトを作っていたのを忘れてClaude Codeのせいにした」くらいに変えるならフラグを外すよ
  • 本当の問題は、タイトルの二重ハイフンがHNで自動的にen dashに変換されたことだ

    • LaTeXでは二重ハイフンはen dash、三重ハイフンはem dashとして使われる
    • 自分も本来は二重ハイフンをそのままにしておくべきだと思うが、LaTeXやTypstの慣習を見るとen dashのほうが適切だ
    • プロ向けのコツ: HNのタイトルをそのままコピーしてコマンドラインに貼り付けるのは危険
    • 本来は「--hard」のようにハイフン2つで書くべき
    • 2つはen dash、3つはem dashという規則がある
  • 自分でもこの問題を直接調べたが、Claude Code自体にはgit reset --hard origin/mainを実行するコードはない
    おそらく開発者が/loop 10mのようなコマンドを走らせていたか、10分ごとにgitをリセットするcronジョブを作っていた可能性が高い

    • たぶん「サーバーと定期的に同期する」ような無害な機能だと勘違いしていたのかもしれない
  • 0.1秒間隔でプロセスを監視したのにgitプロセスがなかったというのは信用しづらい
    gitコマンドは速すぎて、その間隔では捕まらない
    代わりに$PATH上のgitをラップして、すべての実行をログに残す方法のほうがよい

    • これはClaude Codeが自分の尻尾を追いかけている状況に見える。デバッグに失敗して、自分でバグレポートを作ろうとしているようだ
      しかもユーザー入力なしに「エージェント的に」送信した可能性すらある(完全な推測)
      イシューへのリンク
    • こういう場合はeBPFが役に立つ。たとえばbpftraceexecsnoopスクリプトを使えば、システム上で実行されるすべてのプロセスを追跡できる
  • この投稿は、特定個人の問題をシステム全体の問題だと誤解させかねない
    おそらくある程度のコンテキスト破損があったのだろう

    • 自分も似たようなことを何度か経験した。一度はGitHubにforce pushまでされてしまった
      Claudeがstashsed置換 → 競合 → reset --hardの順で壊したことがある
      だからCLAUDE.mdの先頭に次の警告を書いてある
      sedによる大量置換禁止、git push --forcegit reset --hardなどの破壊的なgitコマンドは絶対禁止
      それ以降はかなりましになった
    • あなたの言うことが正しいのかもしれない。だがコンテキストが0.1%壊れるだけでも、1000件の作業のうち1件でデータを失う可能性がある
    • 実際のところ、こうした問題は技術的な防御策で完全に防げる。
      特定の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がほっとしているように感じるくらいだ
    バックアップは本当に命綱