Claude Code द्वारा प्रोजेक्ट रिपॉज़िटरी में हर 10 मिनट पर Git reset --hard origin/main चलाने की समस्या

• macOS वातावरण में प्रोजेक्ट के बदलाव हर 10 मिनट में अपने-आप मिट जाने की घटना रिपोर्ट की गई
• जांच में पता चला कि कारण Claude Code नहीं, बल्कि उपयोगकर्ता द्वारा बनाया गया अलग लोकल ऑटोमेशन टूल था, जो GitPython के जरिए समय-समय पर git reset --hard origin/main चला रहा था
• एक ही working directory साझा होने के कारण Claude Code वजह जैसा दिखा, लेकिन वास्तव में रीसेट बाहरी स्क्रिप्ट कर रही थी
• Claude Code टीम ने स्पष्ट किया कि उसके आंतरिक कोड में यह कमांड चलाने का कोई लॉजिक नहीं है, और --dangerously-skip-permissions विकल्प इस्तेमाल होने पर ही ऐसा मिलता-जुलता व्यवहार संभव है
• अंततः निष्कर्ष निकला कि यह Claude Code का bug नहीं बल्कि उपयोगकर्ता के टूल की समस्या थी, और शीर्षक संशोधित कर issue बंद कर दिया गया

---

समस्या का लक्षण और वातावरण

• यह देखा गया कि Claude Code उपयोगकर्ता की प्रोजेक्ट रिपॉज़िटरी में हर 10 मिनट पर git fetch origin और git reset --hard origin/main चला रहा है
• इस व्यवहार से commit न किए गए tracked files के सभी बदलाव मिट जाते हैं, जबकि untracked files बनी रहती हैं
• Git worktree वातावरण में ऐसा रीसेट नहीं होता
• वातावरण की जानकारी
  • Claude Code संस्करण: 2.1.87 (Homebrew cask, Bun binary)
  • OS: macOS 15.4 (Darwin 25.3.0, arm64)
  • Shell: zsh

जांच की प्रक्रिया

• Git reflog में 10 मिनट के अंतराल पर reset: moving to origin/main लॉग 95 बार से अधिक दर्ज मिले
  • session के बीच offset अलग था, लेकिन हर session के भीतर यह ठीक 600 सेकंड के अंतराल पर दोहराया गया
• रियल-टाइम पुनरुत्पादन परीक्षण में tracked file (api.ts) रीसेट के समय मूल स्थिति में लौट गई, जबकि untracked file (.canary-test.txt) वैसी ही रही
• fswatch से .git/ डायरेक्टरी की निगरानी करने पर रीसेट के समय .git/refs और .git/logs/HEAD फाइलों में बदलाव का पैटर्न मिला
• lsof के अनुसार उस रिपॉज़िटरी की CWD इस्तेमाल करने वाली प्रक्रिया केवल Claude Code CLI थी
• बाहरी git process नहीं मिला, इसलिए अनुमान लगाया गया कि यह भीतर से libgit2 आदि के जरिए किया गया होगा
• worktree वातावरण में reflog में रीसेट का कोई रिकॉर्ड नहीं मिला

जिन कारणों को खारिज किया गया

• Git hooks, Claude Code user hooks, plugin update, macOS cloud sync, Cron/LaunchAgents, IDE, Time Machine, file monitoring tools आदि सभी को असंबंधित पाया गया
• हर बिंदु को वास्तविक config files और processes की जांच के जरिए खारिज किया गया

बाइनरी विश्लेषण (आंशिक)

• Claude Code binary के भीतर कुछ functions में ["fetch","origin"] कमांड चलाने वाला code fragment मिला
• git pull wrapper function और fileHistory state management logic मौजूद थे, लेकिन 10 मिनट के interval वाला timer नहीं मिला

प्रभाव

• commit न किए गए बदलाव हर 10 मिनट में अपने-आप मिट जाते थे, जिससे 2 घंटे के session में तीन बार से अधिक edits गायब हो गए
• जब सभी बदलाव commit कर दिए जाते थे, तब रीसेट का असर नहीं होता था, इसलिए समस्या कभी-कभी होने वाली लगती थी

Claude Code टीम की प्रतिक्रिया

• Jarred-Sumner ने साफ कहा, “Claude Code के भीतर git reset --hard origin/main चलाने वाला कोई code नहीं है”
• उन्होंने बताया कि --dangerously-skip-permissions विकल्प इस्तेमाल करने पर Claude बिना prompt के shell commands चला सकता है, और अगर /loop 10m <prompt> कमांड समय-समय पर “remote के साथ sync” करने को कहे, तो git fetch && git reset --hard origin/main चल सकता है
• जांच के तरीकों के रूप में:
  1. grep -r "reset --hard" ~/.claude/projects/ से session logs खोजें
  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 नहीं चलाता

अंतिम निष्कर्ष

• 30 मार्च 2026 के अपडेट में पुष्टि हुई कि समस्या का मूल कारण Claude Code नहीं, बल्कि उपयोगकर्ता का अलग लोकल टूल था
• वह टूल GitPython का उपयोग करके हर 10 मिनट पर hard reset कर रहा था, और Claude Code की ही डायरेक्टरी को मॉनिटर कर रहा था
• issue को “not planned” स्थिति में बंद किया गया, और शीर्षक “Claude Code रीसेट चलाता है” से बदलकर “मेरा ऑटोमेशन टूल रीसेट चलाता है” कर दिया गया

अस्थायी समाधान

• git worktree का उपयोग करने पर रीसेट का प्रभाव नहीं पड़ता
• बार-बार commit करके बदलावों को सुरक्षित रखा जा सकता है

संबंधित issues

• #8072 — code edits बार-बार revert हो जाने की समस्या
• #7232 — approval के बिना git reset --hard चलने से data loss होने की घटना
• #32793 — claude install कमांड द्वारा git remote URL गलत बदलने की समस्या (मिलता-जुलता लेकिन अलग मामला)

[GN⁺]

Hacker News की राय

• यह लेखक द्वारा पोस्ट किया गया अपडेट है
  issue link के अनुसार, समस्या की मूल वजह Claude Code नहीं थी, बल्कि लेखक के लोकल टेस्टिंग के लिए बनाए गए एक टूल में बग था
  वह टूल लोकल working directory को remote के साथ sync करने की कोशिश में हर चक्र पर hard reset कर रहा था, और इस तरह सभी uncommitted बदलाव मिटा रहा था

  • मज़ेदार बात यह है कि लेखक ने इतना “जांच-पड़ताल” किया, लेकिन 10 मिनट के लिए Claude बंद करके देखने का खयाल नहीं आया
    अगर शीर्षक को “डेवलपर ने हर 10 मिनट में git repo reset करने वाली script बनाकर भूल गया और Claude Code को दोष दे दिया” जैसा बदल दिया जाए, तो मैं flag हटा दूँगा

• असली समस्या यह है कि शीर्षक में मौजूद double hyphen को HN ने अपने-आप en dash में बदल दिया

  • LaTeX में double hyphen en dash और triple hyphen em dash के लिए इस्तेमाल होता है
  • मुझे भी मूल रूप से लगता है कि double hyphen को वैसे ही छोड़ना सही है, लेकिन LaTeX और Typst की परंपरा देखें तो en dash ज़्यादा उपयुक्त है
  • प्रो टिप: HN के शीर्षक को ज्यों का त्यों copy करके command line में paste करना ख़तरनाक है
  • मूल रूप से इसे “--hard” की तरह दो hyphen के साथ लिखा जाना चाहिए
  • नियम यह है कि दो en dash होते हैं, तीन em dash

• मैंने भी इस समस्या की सीधे जांच की, और Claude Code में खुद git reset --hard origin/main चलाने वाला कोई code नहीं है
  ज़्यादा संभावना यह है कि डेवलपर ने /loop 10m जैसी कोई command चलाई हो, या हर 10 मिनट में git reset करने वाला कोई cron job बनाया हो

  • शायद उसने इसे “server के साथ समय-समय पर sync” जैसी किसी harmless feature के रूप में समझ लिया हो

• 0.1 सेकंड के अंतराल पर process monitor किया गया और git process नहीं मिला — इस पर भरोसा करना मुश्किल है
  git command इतनी तेज़ होती है कि उस अंतराल पर पकड़ी नहीं जाएगी
  इसके बजाय $PATH में git को wrap करके हर execution को log करने का तरीका बेहतर है

  • यह कुछ ऐसा लगता है जैसे Claude Code अपनी ही पूँछ का पीछा कर रहा हो। debugging में असफल होकर खुद bug report बनाना चाह रहा हो
    शायद उसने user input के बिना “agentic” तरीके से submit भी किया हो (यह सिर्फ अटकल है)
    issue link
  • ऐसे मामलों में eBPF उपयोगी होता है। उदाहरण के लिए bpftrace की execsnoop script इस्तेमाल करें तो system पर चलने वाली सभी processes को trace किया जा सकता है

• यह पोस्ट किसी एक व्यक्ति की समस्या को पूरे system की समस्या के रूप में गलत समझे जाने का कारण बन सकती है
  लगता है कुछ context corruption हुआ था

  • मेरे साथ भी ऐसा कुछ बार हुआ है। एक बार तो GitHub पर force push तक हो गया था
    Claude ने stash → sed replacement → conflict → reset --hard के क्रम में चीज़ें बिगाड़ दी थीं
    इसलिए मैंने CLAUDE.md के सबसे ऊपर यह चेतावनी लिख रखी है
    “sed से bulk replacement नहीं, git push --force, git reset --hard जैसे destructive git commands बिल्कुल नहीं”
    उसके बाद से स्थिति काफ़ी बेहतर हुई
  • हो सकता है तुम सही हो। लेकिन अगर context सिर्फ 0.1% भी corrupt हो जाए, तो 1000 कामों में से एक में data उड़ सकता है
  • दरअसल ऐसी समस्याओं को technical guardrails से पूरी तरह रोका जा सकता है।
    अगर कुछ खास git commands को block करने वाला hook लगा दिया जाए, तो मॉडल की prediction uncertainty से अलग सुरक्षित व्यवहार सुनिश्चित किया जा सकता है
    यह देखकर लगता है कि बहुत से लोग engineering के पुराने मूल सिद्धांत — deterministic और repeatable process — भूल चुके हैं
  • आखिरकार LLM कभी-कभी सचमुच बेवकूफ़ी भरा व्यवहार करते हैं। बस यही बात है

• मुझे भी इसी तरह की समस्या हुई थी
  आम तौर पर मैं claude-code को sandbox(bwrap, srt) के अंदर चलाता हूँ, लेकिन बाहर चलाने पर /command मिटाने या menu बंद करने के हर मौके पर यह gh को call करता है
  क्योंकि मैं KeepassXC को secret manager की तरह इस्तेमाल करता हूँ, हर बार approval popup आता है और बात तुरंत दिख जाती है
  Claude से पूछने पर उसने बताया कि वजह git context feature थी।
  KeepassXC session-level allow नहीं देता, इसलिए अंत में हर बार authentication माँगा जाता है

• अगर permissions settings हैं, तो क्या ऐसी चीज़ें रुक नहीं जानी चाहिए?
  लेकिन user ने इसे --dangerously-skip-permissions option के साथ चलाया था, इसलिए unpredictable behavior का जोखिम मानकर चलना चाहिए

  • फिर भी pretooluse hook इस्तेमाल किया जाए तो यह option ऑन होने पर भी रोका जा सकता है
  • Anthropic के permissions docs देखने पर साफ़ नहीं होता कि permissions वास्तव में कैसे enforce होती हैं।
    इसकी ऐसी व्याख्या भी हो सकती है कि prompt injection से इसे bypass किया जा सके
  • live repo में permissions के बिना चलाना data deletion incident को न्योता देना है
    जो नियम hard reset को नहीं रोक सकता, वह सिर्फ दिखावे का नियम है
  • मौजूदा rules और permissions program flags नहीं हैं, बल्कि बस text हैं जिनके बारे में agent “मानता है कि इन्हें मानना चाहिए”

• लेखक ने खुद स्पष्ट किया कि वजह Claude Code नहीं, बल्कि उसके अपने बनाए लोकल टेस्ट टूल में बग था

  • यानी यह गलत रिपोर्ट थी
    issue link
  • “मेरे बनाए टूल” जैसी अभिव्यक्ति थोड़ी अस्पष्ट है। संभव है यह जल्दी-जल्दी बनाया गया कोई vibe-coded tool हो
  • सच कहें तो यह टिकट खुद Claude Code के analysis result (यानी hallucination) से भी बना हो सकता है

• अगर आप SaaS-आधारित binary blob development tools इस्तेमाल करते हैं, तो इस तरह की मुश्किल से debug होने वाली समस्याएँ आना चौंकाने वाली बात नहीं है

• आखिर में user ने खुद वजह ढूँढ निकाली, और उसका अपना टूल ही समस्या की जड़ निकला
  ऐसा पहले भी होता रहा है और अब भी होता है।
  मैंने भी LLM की मदद के बिना अपने हाथों से चीज़ें काफ़ी बिगाड़ी हैं
  इसलिए मैं हमेशा Mac की Time Machine के साथ development करता हूँ।
  जब Claude कोई file मिटा देता है और “restore करूँ?” पूछा जाता है, तो लगता है जैसे Claude खुद राहत महसूस कर रहा हो
  backup सचमुच जीवनरेखा है