Claude Code’un proje deposunda her 10 dakikada bir Git reset --hard origin/main çalıştırması sorunu

• macOS ortamında proje değişikliklerinin her 10 dakikada bir otomatik olarak silindiği bir durum raporlandı
• İnceleme sonucunda nedenin Claude Code değil, kullanıcının oluşturduğu ayrı bir yerel otomasyon aracı olduğu ve bu aracın GitPython üzerinden düzenli olarak git reset --hard origin/main çalıştırdığı doğrulandı
• Aynı çalışma dizini paylaşıldığı için sorumlu Claude Code gibi görünse de, gerçekte sıfırlamayı harici bir betik yapıyordu
• Claude Code ekibi, dahili kodda ilgili komutu çalıştıran bir mantık olmadığını açıkça belirtti; benzer davranışın yalnızca --dangerously-skip-permissions seçeneği kullanıldığında mümkün olabileceğini açıkladı
• Sonuç olarak sorun, Claude Code hatası değil kullanıcı aracının sorunu olarak değerlendirildi; başlık düzeltilerek konu kapatıldı

---

Sorunun belirtileri ve ortam

• Claude Code’un kullanıcının proje deposunda 10 dakikalık aralıklarla git fetch origin ve git reset --hard origin/main çalıştırdığı gözlemlendi
• Bu davranış, commit edilmemiş izlenen dosyalardaki tüm değişiklikleri siliyor; izlenmeyen dosyalar ise korunuyor
• Git worktree ortamında bu tür sıfırlamalar meydana gelmiyor
• Ortam bilgileri
  • Claude Code sürümü: 2.1.87 (Homebrew cask, Bun binary)
  • OS: macOS 15.4 (Darwin 25.3.0, arm64)
  • Shell: zsh

İnceleme süreci

• Git reflog içinde 10 dakikalık aralıklarla reset: moving to origin/main kaydının 95’ten fazla kez yazıldığı görüldü
  • Oturumlara göre başlangıç ofseti değişse de, her oturum içinde tam 600 saniyelik aralıklarla tekrar ediyordu
• Gerçek zamanlı yeniden üretim testinde, izlenen dosya (api.ts) sıfırlama anında eski haline dönerken, izlenmeyen dosya (.canary-test.txt) olduğu gibi kaldı
• .git/ dizini fswatch ile izlendiğinde, sıfırlama anında .git/refs ve .git/logs/HEAD dosyalarının değiştiği deseni yakalandı
• lsof sonucuna göre, ilgili deponun CWD’sini kullanan tek süreç Claude Code CLI idi
• Harici git süreçleri tespit edilmediği için, işlemin içeride libgit2 benzeri bir yöntemle yapıldığı tahmin edildi
• worktree ortamında reflog’da hiçbir sıfırlama kaydı bırakılmadı

Elenen nedenler

• Git hook’ları, Claude Code kullanıcı hook’ları, eklenti güncellemeleri, macOS bulut senkronizasyonu, Cron/LaunchAgents, IDE, Time Machine, dosya izleme araçları vb. etkenlerin tamamının ilgili olmadığı doğrulandı
• Her bir başlık, gerçek yapılandırma dosyaları ve süreç kontrolleri üzerinden elendi

İkili dosya analizi (kısmi)

• Claude Code binary’si içindeki bazı fonksiyonlarda ["fetch","origin"] komutunu çalıştıran kod parçaları bulundu
• git pull sarmalayıcı fonksiyonu ve fileHistory durum yönetimi mantığı mevcut, ancak 10 dakikalık periyodik zamanlayıcı tanımlanamadı

Etki

• Commit edilmemiş değişiklikler her 10 dakikada bir otomatik olarak silindiği için, 2 saatlik bir oturum boyunca değişiklikler en az üç kez kayboldu
• Tüm değişiklikler commit edilmiş durumdayken sıfırlama anlamsız kaldığından, sorun zaman zaman ortaya çıkıyormuş gibi görünüyordu

Claude Code ekibinin yanıtı

• Jarred-Sumner, “Claude Code’un kendisinde git reset --hard origin/main çalıştıran bir kod yok” diyerek bunu açıkça ifade etti
• --dangerously-skip-permissions seçeneği kullanıldığında Claude’un prompt olmadan shell komutları çalıştırabildiğini, /loop 10m <prompt> komutunun periyodik olarak “uzak depo ile senkronize et” isteği vermesi halinde git fetch && git reset --hard origin/main çalıştırılabileceğini açıkladı
• Doğrulama yöntemi olarak
  1. grep -r "reset --hard" ~/.claude/projects/ ile oturum günlüklerinde arama yapılması
  2. claude --debug-file /tmp/debug.txt --dangerously-skip-permissions çalıştırılıp 10 dakika beklendikten sonra grep -i bash /tmp/debug.txt | grep reset ile kontrol edilmesi önerildi
• Claude Code’un fileHistory özelliği git ile ilgili değil ve dahili olarak git reset çağırmıyor

Nihai sonuç

• 30 Mart 2026 güncellemesinde, sorunun kök nedeninin Claude Code değil kullanıcının ayrı bir yerel aracı olduğu doğrulandı
• Bu aracın GitPython kullanarak her 10 dakikada bir hard reset yaptığı ve Claude Code ile aynı dizini izlediği belirlendi
• Konu “not planned” durumuyla kapatıldı; başlık da “Claude Code sıfırlama çalıştırıyor” ifadesinden “Benim otomasyon aracım sıfırlama çalıştırıyor” şeklinde değiştirildi

Geçici çözüm yolları

• git worktree kullanıldığında sıfırlamanın etkisi görülmüyor
• Sık commit atarak değişiklikler korunabiliyor

İlgili konular

• #8072 — kod değişikliklerinin tekrar tekrar geri alınması sorunu
• #7232 — onay olmadan git reset --hard çalıştırılması nedeniyle veri kaybı
• #32793 — claude install komutunun git remote URL’sini yanlış değiştirmesi sorunu (benzer ama ayrı bir vaka)

[GN⁺]

Hacker News görüşleri

• Bu, gönderiyi yazan kişinin doğrudan paylaştığı bir güncelleme
  Sorun bağlantısı uyarınca, sorunun asıl nedeni Claude Code değil, yazarın yerel test için yaptığı bir aracın hatasıymış
  Bu araç, yerel çalışma dizinini uzaktakiyle eşitlemeye çalışırken her döngüde bir hard reset yapıyor ve commit edilmemiş tüm değişiklikleri siliyormuş

  • Bunca “araştırma” yaptığını söyleyip Claude’u 10 dakikalığına kapatmayı hiç düşünmemesi komik
    Başlığı “Geliştirici, her 10 dakikada bir git reposunu sıfırlayan bir script yazıp bunu unuttuktan sonra Claude Code’u suçladı” gibi bir şeye çevirirse flag’i kaldırırım

• Asıl sorun, başlıktaki çift tire işaretinin HN’de otomatik olarak en dash’e çevrilmiş olması

  • LaTeX’te çift tire en dash, üçlü tire ise em dash olarak kullanılır
  • Ben de aslında çift tireyi olduğu gibi bırakmanın doğru olduğunu düşünürdüm ama LaTeX ve Typst geleneğine bakınca en dash daha uygun
  • Uzman ipucu: HN başlığını olduğu gibi kopyalayıp komut satırına yapıştırmak risklidir
  • Aslında “--hard” gibi iki tireyle yazılması gerekir
  • Kural olarak iki tane en dash, üç tane em dash’tir

• Ben de bu meseleyi bizzat inceledim ve Claude Code’un kendisinde git reset --hard origin/main çalıştıran bir kod yok
  Muhtemelen geliştirici /loop 10m gibi bir komut çalıştırdı ya da her 10 dakikada bir git reset yapan bir cron işi oluşturdu

  • Belki de bunu “sunucuyla periyodik senkronizasyon” gibi zararsız bir özellik sanmış olabilir

• Süreçleri 0,1 saniye aralıklarla izleyip git süreci görmediğini söylemek pek güvenilir değil
  git komutları o kadar hızlı ki bu aralıkla yakalanmayabilir
  Bunun yerine $PATH içindeki git’i sarıp tüm çalıştırmaları log’a yazdırmak daha iyi

  • Bu, Claude Code’un kendi kuyruğunu kovalaması gibi duruyor. Debug edemeyince kendi kendine bug report oluşturmaya çalışıyor sanki
    Hatta kullanıcının girdisi olmadan bunu “ajanvari” şekilde göndermiş bile olabilir (tamamen tahmin)
    Sorun bağlantısı
  • Böyle durumlarda eBPF faydalıdır. Örneğin bpftrace içindeki execsnoop script’iyle sistemde çalıştırılan tüm süreçleri izleyebilirsiniz

• Bu yazı, belirli bir kişinin sorununu tüm sistemin sorunuymuş gibi yanlış anlamaya yol açabilir
  Muhtemelen bir miktar context bozulması yaşanmış

  • Ben de buna benzer şeyleri birkaç kez yaşadım. Bir keresinde GitHub’a force push bile oldu
    Claude’un stash → sed değişimi → çakışma → reset --hard sırasıyla işleri bozduğu olmuştu
    Bu yüzden CLAUDE.md dosyasının en üstüne şu uyarıyı yazdım
    “sed ile toplu değiştirme yok; git push --force, git reset --hard gibi yıkıcı git komutları kesinlikle yasak”
    Ondan sonra durum epey düzeldi
  • Söylediğin doğru olabilir. Ama context %0,1 bile bozulsa 1000 işten biri veriyi silebilir
  • Aslında bu tür sorunlar teknik önlemlerle tamamen engellenebilir.
    Belirli git komutlarını engelleyen bir hook eklerseniz, modelin tahmin belirsizliğinden bağımsız olarak güvenli çalışır
    Buna bakınca eski mühendisliğin temel ilkeleri — deterministik ve tekrarlanabilir süreçler — unutulmuş gibi geliyor
  • Sonuçta LLM’ler bazen gerçekten aptalca şeyler yapıyor. Hepsi bu

• Ben de buna benzer bir sorun yaşadım
  Normalde claude-code’u bir sandbox (bwrap, srt) içinde çalıştırıyorum ama dışarıda çalıştırınca /command silerken ya da menüyü her kapattığımda gh çağırıyor
  KeepassXC’yi gizli bilgi yöneticisi olarak kullandığım için her seferinde onay penceresi çıkıyor ve bunu hemen fark ediyorum
  Claude’a sorduğumda nedenin git context özelliği olduğunu söyledi.
  KeepassXC oturum bazlı izne izin vermediği için sonunda her seferinde kimlik doğrulama istiyor

• İzin ayarları varsa bunun engellenmesi gerekmez mi diye düşünüyor insan
  Ama kullanıcı bunu --dangerously-skip-permissions seçeneğiyle çalıştırmış, dolayısıyla öngörülemez davranışları göze almış sayılır

  • Yine de pretooluse hook kullanılırsa bu seçenek açıkken bile önlenebilir
  • Anthropic’in permissions dokümantasyonuna bakınca izinlerin pratikte nasıl zorlandığı belirsiz görünüyor.
    Hatta prompt injection ile aşılabileceği şeklinde de yorumlanabilir
  • Bunu gerçek bir repoda izinsiz çalıştırmak, veri silinmesi olayına davetiye çıkarmaktır
    Hard reset’i engelleyemeyen kurallar sadece göstermelik kalır
  • Mevcut kurallar ve izinler, programatik bayraklar değil; sadece ajanın “uyması gerektiğine inandığı” bir metin

• Yazarın kendisinin açıkladığına göre, neden Claude Code değil, kendi yaptığı yerel test aracındaki bir bug’mış

  • Yani bu, yanlış bir ihbarmış
    Sorun bağlantısı
  • “Benim yaptığım araç” ifadesi biraz muğlak. Muhtemelen aceleyle yapılmış bir vibe-coded araç olabilir
  • Hatta bu ticket’ın kendisi bile Claude Code’un analiz sonucu (yani halüsinasyonu) olarak oluşturulmuş olabilir

• SaaS tabanlı binary blob geliştirme araçları kullanıldığında, debug etmesi zor bu tür sorunların ortaya çıkması şaşırtıcı değil

• Sonunda kullanıcı sebebi kendisi buldu ve sorunun kaynağı kendi aracıydı
  Böyle şeyler eskiden de oluyordu, şimdi de oluyor.
  Ben de LLM yardımı olmadan kendi ellerimle yeterince çok şeyi bozdum
  Bu yüzden geliştirme yaparken her zaman Mac’in Time Machine özelliğini kullanıyorum.
  Claude bir dosyayı sildiğinde “geri yüklensin mi?” sorusu çıkınca, sanki Claude rahatlamış gibi hissediyorum
  Yedekler gerçekten bir can simidi