Bir kodlama uyumsuzluğu, Claude Code batch script'inin 1.068 dosyayı silmesine izin verdi

Ne oldu

5 Eylül 2026'da Claude Code 2.1.224 (Opus) aleyhine açılan bir GitHub issue'su, araç tarafından oluşturulan bir Windows batch script'inin bir kullanıcının repository'sinden 1.068 dosyayı nasıl sildiğini belgeliyor. #92328 numaralı issue hakkındaki dev.to yazısına göre ortam, OEM kod sayfası 932 olarak ayarlanmış — yani Japonca yerel ayarlı — Windows 11'di ve hasar pervasız bir komuttan değil, bir noktalama işaretinden kaynaklandı.

Bir nokta yeni satırı nasıl yuttu

dev.to yazısına göre Claude Code'un Write aracı, yalnızca LF satır sonlarıyla UTF-8 olarak kodlanmış bir .cmd yardımcı script'i üretti; bu, mevcut bir dosyanın dönüştürülmesi değil, aracın varsayılan çıktı biçimiydi. Ancak cmd.exe batch dosyalarını UTF-8 olarak yorumlamıyor; onları sistemin OEM kod sayfasına göre okuyor.

CP932 altında, rem yorumundaki sondaki tam genişlikli Japonca noktanın — UTF-8'de E3 80 82 baytları — son baytı, çok baytlı bir karakterin lead byte'ı olarak değerlendiriliyor ve hemen ardından gelen yeni satır karakterini yutuyor. Bu, yorum satırını bir sonraki satırla, "WORK=C:\Temp\work.i64" satırıyla birleştirdi; atama hiç çalıştırılmadı ve WORK tanımsız kaldı.

Onun bir sonraki satırı olan del /F /Q "%WORK%", boş değişkeni del /F /Q "" olarak açtı. Bu komut hata vermek ya da hiçbir şey yapmamak yerine, geçerli çalışma dizinindeki tüm dosyaları siliyor. Çalışma dizini repository kökü olduğu için 1.068 dosya silindi. Alt dizinler, /S olmadan del özyinelemeli olmadığı için kurtuldu; ancak silinen dosyalardan 123'ü başka hiçbir yerde yoktu ve kurtarılamaz.

Raporun dayandığı kanıtlar

dev.to makalesi, rapor eden kişinin iddiasını, sorunlu satırın bir hex dökümüyle ve 1.068 FILE_DELETE kaydı ile eşleşen sıfır RENAME kaydı gösteren — bu da Recycle Bin'e taşınmayı dışlıyor — bir NTFS USN günlüğü alıntısıyla desteklediğini belirtiyor. Ayrıca deterministik bir yeniden üretim de var: Aynı dosyayı LF yerine CRLF satır sonlarıyla kaydetmek hatayı tetiklemiyor. Issue, "has repro" ve "high-priority" etiketlerini taşıyor ve StupidLLM'in külliyatı bunu bu gerekçelerle doğrulanmış ve yeniden üretilebilir olarak işaretliyor.

Raporun ortaya koymadığı şeyler

Bu, tek bir makine yapılandırması hakkında tek bir rapor. Arızanın gerçekleşmesi için üç koşulun bir araya gelmesi gerekiyor: UTF-8 olmayan bir OEM kod sayfası, oluşturulan bir yorumun sonunda çok baytlı bir karakter ve Write aracından gelen yalnızca LF'lik satır sonları. Issue, Claude'un ASCII olmayan yorumlar içeren batch dosyalarını ne sıklıkta ürettiği ya da UTF-8 olmayan OEM kod sayfalarının Claude Code'un Windows kullanıcıları arasında ne kadar yaygın olduğu konusunda bir şey söylemiyor. Yayın tarihi itibarıyla issue açıktı ve bir maintainer yanıtı yoktu; dolayısıyla ne bir düzeltme ne de kapsamı doğrulandı.

Neden önemli

Yıkıcı ajan olaylarının çoğu, bir modelin çok geniş ya da kapsamsız bir komut seçmesi nedeniyle yaşanıyor. Bu olay farklı: script'in mantığı baştan sona doğruydu ve ajan herhangi bir şeyi silmeye karar vermemişti. Arıza tamamen serileştirmede — dosyayı yazan araçla onu okuyan yorumlayıcı arasındaki bir metin kodlama uyumsuzluğunda yaşıyor; bu uyumsuzluk sessizce bir yeni satırı ve onunla birlikte bir değişken atamasını yuttu. İkinci sessiz adım ise %WORK%'ün hiçliğe açılması ve del /F /Q "" komutunun gürültülü biçimde başarısız olmak yerine her şeyi silmesiydi.

Ajanlı araçları Windows batch script'leri üreten herkes için çıkarım şu: bu script'lerin diskte hangi kodlama ve satır sonlarıyla yerleştiğini denetleyin — yalnızca içerdikleri komutları değil.