Lubang Sumber Daya Claude Code: Dari Paket File Tunggal 11.3MB hingga Konsumsi 1.2TB Disk

Lubang sumber daya Claude Code adalah aplikasi Node.js tunggal tanpa manajemen siklus hidup sumber daya: saat diluncurkan, ia memecahkan file terbundel 11.3MB, menulis ke disk tanpa batas, dan setelah ditutup terminal, proses terus hidup dan terus menghabiskan memori hingga sistem crash. Berdasarkan laporan pengguna sebenarnya di GitHub Issues dan analisis komunitas yang terbalik secara sistematis, artikel ini menyusun defek manajemen sumber daya pada tiga dimensi memori, CPU, dan disk pada Claude Code, mengungkap masalah struktural dalam arsitektur pemetaan, desain penyimpanan, dan manajemen siklus hidup proses. Ini bukan kasus pinggiran, melainkan masalah arsitektur sistematis yang telah dilaporkan berulang kali oleh komunitas antara Agustus 2025 hingga April 2026, namun ditutup secara massal oleh bot stale.

Arsitektur Pemetaan: Biaya File Tunggal 11.3MB

Inti dari Claude Code adalah file terbundel tunggal bernama cli.js, dengan ukuran sekitar 11.3MB. Pengguna社区 paultendo melakukan analisis statis yang sangat rinci di Issue #29481, mengungkap beberapa masalah arsitektur yang serius.

Waktu Startup V8: 32% Waktu untuk Memecahkan

Profiling CPU menunjukkan bahwa compileSourceTextModule menghabiskan waktu 31.7% dari waktu sampling pada fase startup. V8 engine perlu sekitar 300ms untuk memecahkan file tunggal 11.3MB ini, sementara waktu pemecahan skrip Node.js biasa hanya 23ms. Waktu tambahan 7.3% dihabiskan pada panggilan spawnSync, dan 3.5% dihabiskan untuk garbage collection. Artinya sebelum pengguna memasukkan instruksi apa pun, lebih dari 40% waktu startup telah dihabiskan untuk overhead pemecahan murni.

Pemuatan Penuh: Hanya 20 Import Dinamis

File terbundel seluruhnya diproses dan dieksekusi pada startup, dengan hanya 20 ekspresi import(). Setiap pengguna membayar biaya untuk semua fitur, apa pun yang digunakan. Berikut adalah komponen yang seharusnya dimuat secara bertahap namun justru dikemas secara penuh:

pie title Komposisi File Terbundel (sekitar 13.5MB)
    "Logika Aplikasi Inti" : 7540
    "AWS Bedrock SDK" : 1100
    "highlight.js (182 bahasa)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "Lain (Ink, Zod, Ajv, Axios dll.)" : 1807

Sebuah asisten pengodean perlu menyoroti Brainfuck, MIPS assembly, Flix, Zephir, Inform7, Lasso dan 182 bahasa lainnya, yang sendiri sudah menggambarkan tingkat pemetaan yang gegabah. Hanya menyisihkan sekitar 40 bahasa yang paling sering digunakan saja sudah dapat menghemat sekitar 786KB dalam overhead pemecahan.

Redundansi Ketergantungan: Empat Klien HTTP, Tiga Library Validasi

Ketergantungan yang berbeda dari setiap SDK memperkenalkan dependensi independen, sehingga file terbundel memiliki empat klien HTTP (Axios, Undici, Got, fetch bawaan) dan tiga library validasi (Zod, Ajv, JSON Schema) secara bersamaan. Di lingkungan Node 18+, fetch bawaan sudah sepenuhnya tersedia, jadi tidak perlu klien HTTP tambahan.

413 Panggilan Sistem File Sinkron

File terbundel mencakup 196 panggilan existsSync, 109 panggilan statSync, 108 panggilan readFileSync, 58 panggilan mkdirSync, dll., total 413 panggilan sistem file sinkron. Setiap panggilan akan mengunci event loop. Banyak panggilan mengikuti pola existsSync(path) && readFileSync(path), yang dapat diganti dengan satu try { await readFile(path) } catch {}.

1087 Penyangga CJS/ESM Interop

Setiap modul CommonJS yang dikemas ke ESM menghasilkan penyangga __toESM/__commonJS/__require, total 1087 penyangga. Penyangga-penyangga ini menambah berat pemecahan serta membawa biaya runtime mikro per modul.

Polyfill Node 20 Tidak Perlu

File terbundel mencakup 62 polyfill Promise (Node 0.12 sudah mendukung secara bawaan), 57 polyfill Symbol (Node 4 sudah mendukung), 57 fungsi bantuan konversi async (Node 8 sudah mendukung), serta 3 polyfill AbortController (Node 15 sudah mendukung). Semuanya berasal dari dependensi transitif yang dikompilasi untuk versi lama Node atau lingkungan browser, tidak perlu di lingkungan target sama sekali.

Ripgrep Mengemas Semua 6 Platform Binari: 61MB

Enam binari platform dari ripgrep seluruhnya dikemas, total 61MB. Dibandingkan dengan itu, sharp menggunakan dependensi optional, hanya menginstal binari platform saat ini. Artinya setiap instalasi menghabiskan ruang disk sekitar 51MB secara tidak perlu.

Ink Performa Render Menurun dengan Panjang Percakapan

Antarmuka terminal menggunakan Ink (React for Terminal). Analisis menunjukkan bahwa ada 6457 panggilan createElement di pohon komponen, 578 hook useState, namun hanya 11 wrapper React.memo(), rasio 1.9%. Di Ink, setiap pembaruan status akan memicu koordinasi virtual DOM lengkap. Selama respons streaming, setiap token yang diterima akan memicu pembaruan status, sehingga komponen yang tidak di-memo secara tidak perlu dirender ulang. Dengan bertambahnya percakapan, output render bertambah, setiap re-render perlu membandingkan lebih banyak konten terminal. Ini konsisten dengan fenomena “semakin lambat selama percakapan berlangsung” yang dilaporkan di Issue #22265.

Konsumsi Disk: Pertumbuhan Tanpa Batas dari GB ke TB

Masalah konsumsi disk merupakan defek manajemen sumber daya paling serius pada Claude Code, dengan dampak paling luas dan konsekuensi paling parah.

Windows Modul Asli .node Meleleh: 20GB per Minggu

Issue #23095 merekam masalah yang belum terselesaikan selama berbulan-bulan: file asli biner Windows (claude.exe) Claude Code mengekstrak file plugin Node.js asli setiap kali sesi, namun tidak pernah membersihkannya. Setiap file sekitar 6.6MB, pengguna SlothKing16 dalam 4 hari mengumpulkan 2813 file, total 18GB. Statistik pengguna kolkov jauh lebih mencengangkan: sekitar 20GB per minggu, pengguna berat bisa mencapai 100GB per minggu. Masalah ini dilaporkan sejak awal 2025 hingga hari ini, dan selama periode tersebut ditandai berulang kali oleh bot dan berusaha ditutup.

Direktori ~/.claude: 3GB+ Tanpa Manajemen

Pengguna kolkov melakukan audit pada sebuah mesin yang digunakan sehari-hari selama 8 bulan di Issue #5024:

pie title Penggunaan Direktori ~/.claude (sekitar 3.1GB)
    "projects/ (Rekaman Sesi)" : 2500
    "debug/ (Log Debug)" : 303
    "file-history/ (Snapshot File)" : 232
    "history.jsonl (Rekaman Global)" : 10
    "Lain" : 55

Angka kunci: file JSONL sesi tunggal terbesar 203MB, file JSONL sub-agent terbesar 72MB, history.jsonl mencakup 37.000+ entri. Semua data tidak ada rotasi, tidak ada kompresi, tidak ada mekanisme pembersihan. File snapshot di file-history/ tidak dideduplikasi, file yang diedit 10 kali disimpan 10 salinan lengkap. Log debug di debug/ tidak pernah dibersihkan.

File Output Tugas Latar Belakang: 1.2TB Referensi Ganda Mati Ulang Sendiri

Issue #32282 mengungkap sebuah desain yang luar biasa. Ketika Claude Code memulai beberapa agen latar belakang dan secara otomatis menjalankan perintah bash untuk memeriksa kemajuan, output file perintah tersebut ditulis ke direktori yang sama dengan glob yang cocok, membentuk referensi ganda tak terbatas:

flowchart LR
    A["bash: untuk f dalam tasks/*.output; tail -5 $f"] --> B["Output ditulis ke tasks/task-A.output"]
    B --> C["Glob cocok dengan task-A.output sendiri"]
    C --> D["tail -5 membaca output sendiri"]
    D --> E["Menambahkan tulisan sendiri"]
    E --> C

Beberapa pengguna melaporkan masalah yang sama: 1.2TB, 460GB, 303GB, 235GB, 480GB, 36GB. Penyunting di issue tersebut menghitung 70 masalah open yang terkait, dibagi menjadi 15 kelompok, dan hanya dua kelompok pertama yang melaporkan konsumsi disk mencapai sekitar 9.5TB. Kecepatan tulis mencapai 425MB/s, berlangsung 18 menit, sampai disk habis.

Kegagalan Kaskade: Crash Tak Teratur Setelah Disk Penuh

Issue #24207 menggambarkan rangkaian bencana ketika disk diisi penuh:

flowchart TD
    A["Kapasitas Disk = 0"] --> B["Penulisan .claude.json gagal"]
    B --> C["Menghasilkan file kosong"]
    C --> D["Dibaca sebagai JSON tidak valid"]
    D --> E["Menutupi semua pengaturan proyek"]
    E --> F["OAuth/API Token rusak"]
    F --> G["Perlu otentikasi ulang"]
    G --> H["Semua agen/sesi yang berjalan berhenti"]
    H --> I["Bahkan setelah melepaskan kapasitas disk pun tidak dapat dipulihkan"]

Tidak adaperingatan, tidak ada degradasi elegan, tidak ada jalur pemulihan. Pengguna harus secara manual memutus semua proses, melepaskan ruang, memulihkan konfigurasi, otentikasi ulang, dan mengatur kembali semua pengaturan.

Tulis Bersamaan: Tidak Ada Kunci, Tidak Ada Transaksi, Tidak Ada Koordinasi

Satu-satunya file kunci di direktori ~/.claude/ adalah .update.lock (5 byte). Seluruh file lain ditulis tanpa perlindungan. Ketika beberapa proses Claude Code berjalan bersamaan (agennya + sub-agen adalah skenario penggunaan normal), mereka melakukan tulis tanpa koordinasi pada file bersama:

Di Windows kondisinya lebih buruk lagi: solusi penulisan atomik (tulis .tmp lalu rename()) gagal di Windows karena ketika target file dimiliki oleh proses lain, rename() mengembalikan EPERM, sepenuhnya merusak atomisitas.

Memori dan CPU: Dari 13GB RSS hingga Panik Inti

Konsumsi Memori Ekstrim Windows

Issue #24840 merekam kasus ekstrim di Windows: RSS 13.21GB, commit virtual 47.17GB, sementara mesin total memori hanya 42.56GB. Kesalahan halaman 3.75 juta kali, menunjukkan disk I/O berkelanjutan. Selama 347 detik berjalan, waktu CPU pengguna hanya 35 detik, sekitar 90% waktu dihabiskan untuk menunggu I/O dan swap. Hal ini menyebabkan aplikasi lain (seperti Opera browser) sama sekali tidak merespons.

Panik Inti macOS

Issue #39253 melaporkan konsekuensi yang lebih parah: di MacBook Pro M3 Pro (18GB RAM), menjalankan beberapa instance Claude Code menyebabkan macOS kernel panic. Dua jenis panic berbeda diamati: Jetsam OOM kill (macOS mematikan proses watchdogd penting karena tekanan memori) dan watchdog timeout (watchdog gagal menandatangani dalam 90+ detik karena kelaparan sumber daya sistem). Sistem restart langsung tanpa peringatan, tanpa dialog kesalahan, tanpa kesempatan menyimpan kerja.

Proses Orphan: Tetap Hidup Setelah Terminal Ditutup

Issue #44507 (April 2026, baru beberapa hari lalu) melaporkan defek manajemen siklus hidup dasar: setelah menutup jendela terminal, proses Claude Code terus hidup. Sebuah proses yang tidak terikat menghabiskan 35.4GB RSS dalam 21 hari, penggunaan CPU 95.5%. Akar masalahnya adalah titik masuk utama CLI tidak memiliki handler process.stdin.on("end"), sementara 55+ timer setInterval (untuk polling, pelacakan, refresh bar status, dll.) menjaga event loop Node.js tetap hidup tanpa batas. Tumpukan V8 tumbuh tanpa batas, tanpa tekanan GC idle, tanpa batas --max-old-space-size, tanpa watchdog self-termination.

100% CPU Freeze

Issue #27415 melaporkan freeze 100% CPU yang disebabkan oleh loop tak terkendali posix_spawn di runtime Bun. Issue #26224 melaporkan Claude Code tertinggal 5-20 menit saat menangani banyak prompt.

Kegagalan Arsitektur File Flat secara Sistematis

Alokasi tanpa Pembersihan: Pola Arsitektur yang Berulang di Semua Issue

Anggota komunitas kolkov menunjukkan dalam beberapa issue bahwa semua masalah ini memiliki akar yang sama:

Leak .node ini bukan masalah isolasi – ini adalah gejala pola arsitektur yang berulang, yaitu Claude Code mengalokasikan sumber daya tanpa membersihkan.

Antara 2025 dan 2026, masalah berkembang dari ekspansi tunggal file .claude.json menjadi ekspansi tersebar file JSONL, namun arsitektur fundamental tidak berubah: file flat, tanpa kunci, tanpa transaksi, tanpa pembersihan, tanpa kompresi.

SQLite vs Local Daemon: Alternatif Komunitas

Komunitas beberapa kali menyarankan menggunakan SQLite sebagai ganti penyimpanan file flat. Sebuah database SQLite dapat menyelesaikan semua masalah secara bersamaan: mode WAL memberikan pembacaan concurrent + atomicitas tunggal tulisan, transaksi menjamin tulisan sesi secara lengkap atau tidak sama sekali, kompresi bawaan, TTL pembersihan, deduplikasi konten, konsistensi lintas platform.

Saran lain adalah memperkenalkan daemon lokal (mirip server LSP, arsitektur Docker), semua proses Claude Code berkomunikasi melalui IPC, memberikan koordinasi tanpa mengubah backend penyimpanan.

Perbandingan Antara Reverse Engineering Komunitas dan Bot Stale

Komentar anggota komunitas gebeer secara tepat menggambarkan situasi saat ini:

Terima kasih atas analisis yang teliti. Itu seharusnya dilakukan oleh pemelihara bertahun-tahun yang lalu.

kolkov lebih lanjut menunjukkan:

Ironisnya, komunitas benar-benar melakukan debugging bagi mereka – reverse engineering kode yang membingungkan, menelusuri jalur kesalahan, mengusulkan solusi dengan potongan kode – sementara responsnya adalah bot issue stale yang menutup semua konten setelah 60 hari.

Perbandingan Manajemen Sumber Daya Antara alat Sejenis

GitHub Copilot berjalan sebagai ekstensi VS Code, dibatasi oleh memori dan manajemen siklus hidup host ekstensi; Cursor didasarkan pada fork VS Code, mewarisi kerangka manajemen sumber daya yang sama; penyimpanannya menggunakan SQLite atau database serupa, secara alami mendukung concurrent dan transaksi. Claude Code memilih solusi independent process + file flat, namun tidak menerapkan tanggung jawab manajemen sumber daya yang seharusnya dimiliki independent process – tidak ada batas memori, tidak ada kuota disk, tidak ada watchdog process, tidak ada keluar elegan. Perilakunya lebih mirip prototipe demo daripada alat untuk lingkungan produksi.

Paradoks Kemampuan Model dan Kualitas Engineering

File tunggal 11.3MB, 413 panggilan sistem file sinkron, 1087 penyangga interop CJS/ESM, tanpa pembersihan sumber daya, tanpa kontrol concurrent, tanpa monitoring disk – ini bukan kasus pinggiran, melainkan defek arsitektur sistematis. Antara Issue #5024 pada Agustus 2025 hingga Issue #44507 pada April 2026, komunitas terus melaporkan masalah yang sama klasifikasinya, menyediakan analisis dan solusi rinci, sementara banyak issue ditandai “not planned” atau ditutup otomatis oleh bot stale. Sebuah alat pengodean AI, kualitas kode sendiri yang perlu diaudit dan diperbaiki oleh komunitas, ini sendiri merupakan paradox yang layak direnungkan.

Jika Anda menggunakan Claude Code, disarankan untuk secara rutin memeriksa ukuran direktori ~/.claude, membersihkan file .node di direktori sementara, dan memastikan keluar yang benar menggunakan Ctrl+C sebelum menutup terminal. Jika kapasitas disk tiba-tiba menghilang, Anda setidaknya tahu di mana mencari penyebabnya.

• ←Sebelumnya
• Berikutnya→