Claude Code'in Kaynak Kara Deliği: 11.3MB Tek Dosya Paketten 1.2TB Disk Yutkunmasına

GitHub Issues’taki gerçek kullanıcı raporları ve topluluk tersine mühendisliği analizi temelinde, Claude Code’un bellek, CPU ve disk üç boyutundaki kaynak yönetimi eksikliklerini sistematik olarak inceleyerek, paketleme mimarisi, depolama tasarımı ve süreç yaşam döngüsü yönetimindeki yapısal sorunları ortaya koyar.

Claude Code’un istemcisi, kaynak yaşam döngüsü yönetimi olmayan bir Node.js tek dosya uygulamasıdır: Başlatıldığında 11.3MB paket dosyasını ayrıştırır, çalışma sırasında diske sınırsız yazma yapar, terminal kapatıldıktan sonra süreç hâlâ hayatta kalır ve belleği tüketmeye devam eder, sistem çökene kadar. GitHub Issues’taki gerçek kullanıcı raporları ve topluluk tersine mühendisliği analizi temelinde, bu makale bellek, CPU ve disk üç boyutundaki kaynak yönetimi eksikliklerini sistematik olarak inceleyerek, paketleme mimarisi, depolama tasarımı ve süreç yaşam döngüsü yönetimindeki yapısal sorunları ortaya koyar. Bunlar kenar durumları değildir; 2025 Ağustos’tan 2026 Nisan’a kadar topluluk tarafından rapor edilen, ancak stale botları tarafından toplu olarak kapatılan sistematik mimari kusurlardır.

Paketleme Mimarisi: 11.3MB Tek Dosyanın Bedeli

Claude Code’un çekirdeği, cli.js adlı tek dosya paket ürünüdür ve yaklaşık 11.3MB büyüklüğündedir. Topluluk üyesi paultendo, Issue #29481 içinde kapsamlı bir statik analiz yaparak bir dizi ciddi mimari sorunu ortaya koymuştur.

V8 Başlatma Süresi: %32 Zaman Ayrıştırmaya Harcanıyor

CPU profili, compileSourceTextModule‘ün başlatma aşamasının %31.7’sini tükettiğini gösteriyor. V8 motoru bu 11.3MB tek dosyayı ayrıştırmak için yaklaşık 300ms harcıyor, oysa çıplak bir Node.js betiği yalnızca 23ms sürecek. Ek %7.3’lük tüketim spawnSync çağrısına, %3.5’lik tüketim çöp toplama işlemine gidiyor. Bu, kullanıcı herhangi bir komut girmeden önce %40’tan fazla başlatma süresinin yalnızca ayrıştırma maliyetine harcandığı anlamına geliyor.

Tam Yükleme: Sadece 20 Dinamik import

Tüm paket dosyası başlatıldığında tamamen ayrıştırılır ve yürütülür, sadece 20 import() ifadesi bulunur. Her kullanıcı, kullanıp kullanmadığına bakılmaksızın tüm işlevlerin maliyetini öder. Aşağıda talep üzerine yüklenmesi gereken ancak tamamen paketlenmiş bileşenler yer alıyor:

pie title Paket Dosyası Bileşenleri (≈ 13.5MB)
    "Uygulama Çekirdek Mantığı" : 7540
    "AWS Bedrock SDK" : 1100
    "highlight.js (182 Dil)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "Diğer (Ink, Zod, Ajv, Axios vb.)" : 1807

Bir kod yardımcısının Brainfuck, MIPS assembly, Flix, Zephir, Inform7, Lasso vb. 182 dili vurgulaması gerekir; bu, paketleme stratejisinin ne kadar kaba olduğunu gösterir. Yaklaşık 40 yaygın dili tutmak, yaklaşık 786KB ayrıştırma maliyetini tasarruf ettirebilir.

Bağımlılık Fazlalığı: Dört HTTP İstemcisi, Üç Doğrulama Kütüphanesi

Farklı SDK’lar bağımsız bağımlılıklar getiriyor; bu da paket dosyasında aynı anda dört HTTP istemcisi (Axios, Undici, Got, yerel fetch) ve üç doğrulama kütüphanesi (Zod, Ajv, JSON Schema) bulunmasına yol açıyor. Node 18+ ortamında yerel fetch tamamen kullanılabilir, ek bir HTTP istemcisine hiç gerek yoktur.

413 Senkron Dosya Sistemi Çağrısı

Paket dosyasında 196 existsSync, 109 statSync, 108 readFileSync, 58 mkdirSync vb. toplam 413 senkron dosya sistemi çağrısı bulunur. Her biri olay döngüsünü engeller. Birçok çağrı existsSync(path) && readFileSync(path) şeklinde bir model izler; iki sistem çağrısı bir try { await readFile(path) } catch {} ile değiştirilebilirdi.

1087 CJS/ESM Etkileşim Sarmalayıcısı

ESM içine paketlenen her CommonJS modülü __toESM/__commonJS/__require uyumluluk yastığı üretir; toplamda 1087 adet. Bu yastıklar ayrıştırma ağırlığını artırır ve her modül için küçük bir çalışma zamanı maliyeti ekler.

Gereksiz Node 20 Polyfill

Paket dosyasında 62 Promise yastığı (Node 0.12’den beri yerel), 57 Symbol yastığı (Node 4’ten beri yerel), 57 async dönüşüm yardımcı fonksiyonu (Node 8’den beri yerel) ve 3 AbortController polyfill (Node 15’ten beri yerel) bulunur. Bunlar eski Node veya tarayıcı ortamları için derlenen geçiş bağımlılıklarından gelir ve hedef çalışma zamanında tamamen gereksizdir.

ripgrep Tüm 6 Platform Binaries’ı Paketledi: 61MB

ripgrep’in 6 platform binary’sı tamamen paketlenmiştir; toplam 61MB. Buna karşılık sharp, optional dependencies kullanarak yalnızca mevcut platformun binary’sini kurar. Bu, her kurulumun yaklaşık 51MB disk alanı israf ettiği anlamına gelir.

Ink Render Performansı Konuşma Uzunluğuyla Bozulur

Terminal UI, Ink (React for Terminal) kullanır. Analiz, bileşen ağacında 6457 createElement çağrısı, 578 useState hook’u olduğunu, ancak yalnızca 11 React.memo() sarmalayıcısı olduğunu gösteriyor; oran sadece %1.9. Ink içinde her durum güncellemesi tam sanal DOM koordinasyonunu tetikler. Akış yanıtı sırasında her token durum güncellemesi yapar, memoize edilmemiş bileşenler gereksiz yere yeniden render olur. Konuşma uzadıkça render çıktısı artar; her yeniden render daha fazla terminal içeriği fark eder. Bu, Issue #22265 içinde rapor edilen “oturum ilerledikçe yavaşlama” olayıyla tutarlıdır.

Disk Yutkunması: GB’den TB’ye Sınırsız Büyüme

Disk sorunu, Claude Code’un en ciddi kaynak yönetimi eksikliği olup, en geniş etki alanına ve en ağır sonuçlara sahiptir.

Windows .node Yerel Modül Sızıntısı: Haftada 20GB

Issue #23095 bir aylarca çözülemeyen sorunu belgeledi: Claude Code’un Windows yerel ikili dosyası (claude.exe) her oturumda sistem geçici dizinine yerel Node.js eklenti dosyalarını çıkarıyor, ancak hiç temizlemiyor. Her dosya yaklaşık 6.6MB; kullanıcı SlothKing16 dört gün içinde 2813 dosya biriktirdi, toplam 18GB. Kullanıcı kolkov’un istatistikleri daha çarpıcı: haftada yaklaşık 20GB, yoğun kullanıcılar haftada 100GB’a kadar ulaşabiliyor. Bu sorun 2025 başından beri rapor edildi, botlar tarafından tekrar tekrar “duplicate” olarak işaretlenip kapatıldı.

~/.claude Dizini: 3GB+ Yönetimsiz

Kullanıcı kolkov, Issue #5024 içinde 8 ay boyunca günlük kullandığı bir makineyi denetledi:

pie title ~/.claude Dizin Kullanımı (≈ 3.1GB)
    "projects/ (oturum kayıtları)" : 2500
    "debug/ (hata günlükleri)" : 303
    "file-history/ (dosya anlık görüntüleri)" : 232
    "history.jsonl (global geçmiş)" : 10
    "Diğer" : 55

Anahtar rakamlar: En büyük tek oturum JSONL dosyası 203MB, en büyük alt ajan JSONL dosyası 72MB, history.jsonl 37000+ giriş içeriyor. Tüm veriler döndürülmüyor, sıkıştırılmıyor, temizleme mekanizması yok. file-history/ içindeki dosya anlık görüntüleri tekrarlanmıyor; aynı dosya 10 kez düzenlendiğinde 10 tam kopya saklanıyor. debug/ dizinindeki hata günlükleri hiç temizlenmiyor.

Arka Plan Görev Çıktı Dosyaları: 1.2TB Kendine Referans Döngüsü

Issue #32282 inanılmaz bir tasarım kusurunu ortaya koyuyor. Claude Code birden fazla arka plan ajanı başlattığında ve otomatik olarak bir ilerleme kontrol bash komutu çalıştırdığında, bu komutun çıktı dosyası aynı glob ile eşleşen dizine yazılıyor ve kendine referans veren sonsuz geri besleme döngüsü oluşturuyor:

flowchart LR
    A["bash: for f in tasks/*.output; tail -5 $f"] --> B["çıktı tasks/task-A.output dosyasına yazılıyor"]
    B --> C["glob task-A.output dosyasını kendisiyle eşleşiyor"]
    C --> D["tail -5 kendisinin çıktısını okur"]
    D --> E["kendi dosyasına ek yazar"]
    E --> C

Birçok kullanıcı aynı sorunu rapor etti: 1.2TB, 460GB, 303GB, 235GB, 480GB, 36GB. Issue yorumcuları 70 ilgili açık issue’yi 15 gruba ayırdı; sadece ilk iki grup yaklaşık 9.5TB disk tüketimi rapor etti. Yazma hızı 425MB/s’ye ulaşabiliyor, 18 dakika sürebiliyor, disk tamamen dolana kadar devam ediyor.

Zincirleme Arıza: Disk Dolu Olduktan Sonra Geri Döndürülemez Çöküş

Issue #24207 disk dolduğunda meydana gelen felaket zincir reaksiyonunu tanımlıyor:

flowchart TD
    A["Disk Alanı = 0"] --> B[".claude.json yazılamıyor"]
    B --> C["Sıfır uzunlukta dosya oluşturuluyor"]
    C --> D["Geçersiz JSON olarak okunuyor"]
    D --> E["Tüm proje ayarları üzerine yazılıyor"]
    E --> F["OAuth/API token'ları bozuluyor"]
    F --> G["Yeniden kimlik doğrulama gerekiyor"]
    G --> H["Tüm çalışan ajan/oturum durduruluyor"]
    H --> I["Disk alanı serbest bırakılsa bile geri dönüş yok"]

Uyarı yok, nazik bir düşüş yok, kurtarma yolu yok. Kullanıcılar tüm süreçleri manuel olarak sonlandırmak, alanı serbest bırakmak, yapılandırmayı yeniden kurmak ve yeniden kimlik doğrulamak zorunda kalıyor.

Eşzamanlı Yazma: Kilit Yok, İşlem Yok, Koordinasyon Yok

~/.claude/ dizinindeki tek kilit dosyası .update.lock (5 bayt). Diğer tüm dosya yazmaları korumasız. Birden fazla Claude Code süreci aynı anda çalıştığında (ajan + alt ajan normal kullanım senaryosu), paylaşılan dosyalara yazma hiç koordine edilmez:

DosyaYazıcıKilit MekanizmasıBilinen Sonuç
sessions-index.jsonHer oturumYokYarış durumu
{uuid}.jsonlAna oturum + sıkıştırmaYokKayıp girişler
.claude.jsonHer süreçYokKonfigürasyon bozulması (8 kez rapor)
file-history/*Her Edit/YazmaYokSınırsız büyüme

Windows’ta durum daha kötüdür: atomik yazma geçici dosya (.tmp) ardından rename() yöntemiyle yapılır, ancak hedef dosya başka bir süreç tarafından tutulduğunda rename() EPERM döndürür ve atomikliği tamamen bozar.

Bellek ve CPU: 13GB RSS’den Çekirdek Panic’ine

Windows Aşırı Bellek Tüketimi

Issue #24840 Windows’ta aşırı bir vakayı belgeledi: RSS 13.21GB, sanal bellek tahsisi 47.17GB, makinenin toplam belleği sadece 42.56GB. 3.75 milyon sayfa hatası, sürekli disk I/O’yu gösteriyor. 347 saniye çalışma süresinde kullanıcı modu CPU süresi sadece 35 saniye, %90’ı I/O ve takas beklemede harcanıyor. Bu, diğer uygulamaların (ör. Opera) tamamen yanıt veremez hale gelmesine yol açıyor.

macOS Çekirdek Panic’i

Issue #39253 daha ciddi bir sonucu rapor etti: MacBook Pro M3 Pro (18GB RAM) üzerinde birden fazla Claude Code örneği çalıştırmak macOS çekirdek panic’ine neden oluyor. İki farklı panic türü gözlemlendi: Jetsam OOM kill (bellek baskısı nedeniyle macOS kritik watchdogd sürecini öldürür) ve watchdog timeout (watchdogd sistem kaynakları açığa çıkınca 90+ saniye içinde ping atamaz). Sistem uyarı vermeden yeniden başlatır, hata iletişim kutusu göstermez, kaydedilmiş çalışma verisi kaybolur.

Süreç Yetimliği: Terminal Kapatıldığında Hayatta Kalır

Issue #44507 (2026 Nisan, birkaç gün önce) temel bir yaşam döngüsü yönetimi eksikliğini rapor etti: Terminal penceresi kapatıldığında Claude Code süreci hâlâ çalışır. İzole bir süreç 21 gün içinde 35.4GB RSS ve %95.5 CPU kullanımı tüketti. Temel neden, ana CLI giriş noktasının process.stdin.on("end") işleyicisinin olmaması ve 55+ setInterval zamanlayıcısının (polling, telemetry, status bar yenileme vb.) Node.js olay döngüsünü sonsuz canlı tutması. V8 yığını sınırsız büyür, boş GC baskısı yok, --max-old-space-size sınırlaması yok, kendini sonlandıran watchdog eksik.

%100 CPU Donması

Issue #27415 TaskStop tetiklediğinde %100 CPU donmasını rapor etti; temel neden Bun çalışma zamanındaki posix_spawn döngüsünün kontrolden çıkması. Issue #26224 ise Claude Code’un büyük prompt’lar işlediğinde 5‑20 dakika takılma sorununu rapor etti.

Düz Dosya Mimarisi Sistematik Başarısızlık

Dağıt ve Temizleme Yok: Tüm issue’larda Tekrarlanan Mimari Model

Topluluk üyesi kolkov, birçok issue’da aynı temel sorunun tekrarlanan mimari modelden kaynaklandığını vurguladı:

Bu .node sızıntısı izole bir bug değil — tekrarlanan bir mimari modelin semptomudur; Claude Code kaynakları tahsis eder ama temizlemez.

2025’ten 2026’ya kadar sorun .claude.json tek dosyasının şişmesinden JSONL dosyalarının dağınık şişmesine evrildi, ancak temel mimari değişmedi: düz dosyalar, kilit yok, işlem yok, temizlik yok, sıkıştırma yok.

SQLite ve Yerel Daemon: Topluluğun Alternatif Çözümü

Topluluk, düz dosya depolamayı SQLite ile değiştirme önerisini defalarca dile getirdi. Bir SQLite veritabanı tüm sorunları aynı anda çözebilir: WAL modu eşzamanlı okuma + tek yazma atomikliğini sağlar, işlemler tam ya da hiç yazma garantisi verir, yerleşik sıkıştırma, TTL temizlik, içerik deduplikasyonu ve çapraz platform tutarlılığı sunar.

Bir diğer öneri, yerel bir daemon (LSP sunucusu, Docker mimarisi gibi) eklemek; tüm Claude Code süreçleri IPC üzerinden iletişim kurar, depolama arka ucunu değiştirmeden koordinasyon sağlar.

Topluluk Tersine Mühendisliği ve Stale Bot Karşılaştırması

Topluluk üyesi gebeer’in yorumu mevcut durumu özetliyor:

Ayrıntılı analiziniz için teşekkürler. Bu, bakımcıların uzun zaman önce yapması gereken bir şeydi.

kolkov ekledi:

Ironik bir şekilde, topluluk aslında onların yerine hata ayıklama yapıyor — tersine mühendislik, kod karışıklığını izleme, kod parçacıklı düzeltme önerileri sunma — ama yanıt bir 60 gün sonra tüm içeriği kapatan stale-issue botu.

Benzer Araçların Kaynak Yönetimi Karşılaştırması

GitHub Copilot, VS Code uzantısı olarak çalışır ve uzantı hostunun bellek sınırlamaları ve yaşam döngüsü yönetimi kısıtlamalarına tabidir; Cursor, VS Code’un bir fork’u olarak aynı kaynak yönetim çerçevesini miras alır; her ikisinin de depolaması SQLite veya benzeri bir veritabanı kullanır, doğal olarak eşzamanlılık ve işlem desteği sağlar. Claude Code ise bağımsız süreç + düz dosya yaklaşımını seçmiş, ancak bağımsız sürecin sahip olması gereken kaynak yönetimi sorumluluklarını (bellek sınırı, disk kotası, süreç watchdog, nazik çıkış) yerine getirmemiştir — bir prototip gösterimi gibi davranır, üretim ortamı aracı gibi değil.

Model Kapasitesi ve Mühendislik Kalitesi Paradoksu

11.3MB tek dosya paketleme, 413 senkron dosya sistemi çağrısı, 1087 CJS/ESM etkileşim sarmalayıcısı, kaynak temizliği yok, eşzamanlı kontrol yok, disk alan izleme yok — bunlar kenar durumları değil, sistematik mimari eksikliklerdir. 2025 Ağustos’taki Issue #5024 tarihinden 2026 Nisan’daki Issue #44507 tarihine kadar topluluk aynı kategori sorunları raporladı, ayrıntılı analiz ve düzeltme önerileri sundu, ancak birçok issue “not planned” olarak işaretlendi veya stale botu tarafından otomatik kapatıldı. Bir AI kodlama aracı, kendi kod kalitesi için topluluğun denetim ve düzeltme yapmasını gerektiriyor; bu da derinlemesine düşünülmesi gereken bir paradoks.

Eğer Claude Code kullanıyorsanız, ~/.claude dizini boyutunu düzenli olarak kontrol etmenizi, geçici dizindeki .node dosyalarını temizlemenizi ve terminali kapatmadan önce Ctrl+C ile düzgün çıkış yaptığınızdan emin olmanızı öneririz. Disk alanı aniden kaybolduğunda, artık nedenini nerede aramanız gerektiğini biliyorsunuz.