Claude Code's resource black hole: van een 11,3 MB enkelbestandspakket tot 1,2 TB schijfverbruik

Claude Code’s client is een Node.js‑enkelbestandstoepassing zonder resource‑levenscyclusbeheer: bij opstarten wordt een 11,3 MB‑pakketbestand geparseerd, tijdens uitvoering wordt onbeperkt naar schijf geschreven, en na het sluiten van de terminal blijft het proces bestaan en blijft geheugen verbruiken tot het systeem crasht. Gebaseerd op echte gebruikersrapporten in GitHub Issues en community‑reverse‑engineering, analyseert dit artikel systematisch de resource‑beheerdefecten op geheugen-, CPU- en schijfgebied, en onthult structurele problemen in de verpakkingsarchitectuur, opslagontwerp en proceslevenscyclusbeheer. Dit zijn geen randgevallen, maar systematische architectuurdefecten die van augustus 2025 tot april 2026 continu door de community werden gemeld, maar door een stale‑bot massaal werden gesloten.

Verpakkingsarchitectuur: de prijs van een 11,3 MB enkelbestand

Claude Code’s kern is een enkelbestandspakket cli.js van ongeveer 11,3 MB. Community‑gebruiker paultendo voerde een grondige statische analyse uit in Issue #29481 en onthulde meerdere ernstige architectuurproblemen.

V8‑opstarttijd: 32 % van de tijd besteed aan parsing

CPU‑profilering toont dat compileSourceTextModule 31,7 % van de samples tijdens de opstartfase verbruikte. De V8‑engine heeft ongeveer 300 ms nodig om dit 11,3 MB‑bestand te parseren, terwijl een kaal Node.js‑script slechts 23 ms nodig heeft. Extra 7,3 % wordt verbruikt door spawnSync, 3,5 % door garbage collection. Dit betekent dat meer dan 40 % van de opstarttijd wordt verspild aan pure parsing vóór enige gebruikersinvoer.

Volledige lading: slechts 20 dynamische imports

Het volledige pakket wordt bij opstarten volledig geparsed en uitgevoerd, met slechts 20 import()‑expressies. Elke gebruiker betaalt de prijs voor alle functionaliteit, ongeacht of ze die gebruiken. Hieronder staan componenten die onnodig volledig zijn verpakt in plaats van on‑demand geladen:

pie title Verpakkingsbestandssamenstelling (≈ 13,5 MB)
    "Applicatie‑kernlogica" : 7540
    "AWS Bedrock SDK" : 1100
    "highlight.js (182 talen)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "Overig (Ink, Zod, Ajv, Axios, enz.)" : 1807

Een code‑assistent die 182 talen zoals Brainfuck, MIPS‑assembly, Flix, Zephir, Inform7, Lasso, enz. moet highlighten, illustreert de ruwe aard van de verpakkingsstrategie. Het behouden van slechts ~40 veelgebruikte talen zou ongeveer 786 KB aan parsing‑overhead besparen.

Overbodige afhankelijkheden: vier HTTP‑clients, drie validatie‑libraries

Verschillende SDK’s introduceren elk hun eigen afhankelijkheden, waardoor het pakket vier HTTP‑clients (Axios, Undici, Got, native fetch) en drie validatie‑libraries (Zod, Ajv, JSON Schema) bevat. In Node 18+ is native fetch volledig beschikbaar, waardoor extra HTTP‑clients overbodig zijn.

413 synchronische besturingssysteem‑aanroepen

Het pakket bevat 196 existsSync, 109 statSync, 108 readFileSync, 58 mkdirSync enz., in totaal 413 synchronische besturingssysteem‑aanroepen. Elke aanroep blokkeert de event‑loop. Veel oproepen volgen het patroon existsSync(path) && readFileSync(path), wat met één asynchrone await readFile(path) vervangen kan worden.

1087 CJS/ESM‑interoperabiliteitswrappers

Voor elk CommonJS‑module dat in ESM is verpakt, wordt een __toESM/__commonJS/__require‑compatibiliteitspatch gegenereerd, in totaal 1087. Deze patches verhogen zowel de parse‑weight als de runtime‑overhead per module.

Overbodige Node 20‑polyfills

Het pakket bevat 62 Promise‑polyfills (native sinds Node 0.12), 57 Symbol‑polyfills (native sinds Node 4), 57 async‑helper‑functies (native sinds Node 8) en 3 AbortController‑polyfills (native sinds Node 15). Deze komen voort uit transitieve afhankelijkheden die voor oudere Node‑ of browser‑omgevingen zijn gecompileerd en zijn volledig overbodig in de doel‑runtime.

ripgrep‑bundeling van alle 6 platform‑binaries: 61 MB

Alle 6 platform‑binaries van ripgrep worden verpakt, in totaal 61 MB. In contrast gebruikt sharp optional dependencies en installeert alleen de binary voor het huidige platform. Dit betekent dat elke installatie ~51 MB schijfruimte verspilt.

Ink‑renderprestaties degraderen met gesprekslengte

De terminal‑UI gebruikt Ink (React for Terminal). Analyse toont 6457 createElement‑aanroepen, 578 useState‑hooks, maar slechts 11 React.memo()‑wrappers (1,9 %). In Ink triggert elke statusupdate een volledige virtuele DOM‑reconciliation. Tijdens streaming‑respons triggert elk binnenkomend token een statusupdate, waardoor niet‑gememoiseerde componenten onnodig opnieuw renderen. Naarmate het gesprek groeit, neemt de renderoutput toe en elke her-render vereist meer diff‑werk voor de terminal. Dit komt overeen met de “langzaam wordende sessie” die wordt gemeld in Issue #22265.

Schijfgroei: van GB tot TB onbeperkte expansie

Schijfgroei is het ernstigste resource‑beheerprobleem van Claude Code en heeft de breedste impact.

Windows .node‑native‑module‑lekkage: 20 GB per week

Issue #23095 documenteert een maandenlange onopgeloste kwestie: Claude Code’s Windows‑native binary (claude.exe) extraheert bij elke sessie native Node.js‑plugin‑bestanden naar de systeem‑tempmap, maar verwijdert ze nooit. Elk bestand is ~6,6 MB; gebruiker SlothKing16 verzamelde in 4 dagen 2813 bestanden (≈18 GB). Gebruiker kolkov rapporteerde nog erger: ≈20 GB/week, met zware gebruikers tot 100 GB/week. Deze kwestie werd sinds begin 2025 gemeld, maar door een bot als duplicate gemarkeerd en gesloten.

~/.claude‑directory: >3 GB zonder beheer

Gebruiker kolkov auditte een machine die 8 maanden dagelijks werd gebruikt (Issue #5024):

pie title ~/.claude‑directorygebruik (≈ 3,1 GB)
    "projects/ (sessie‑logboeken)" : 2500
    "debug/ (debug‑logboeken)" : 303
    "file-history/ (bestandssnapshots)" : 232
    "history.jsonl (globale geschiedenis)" : 10
    "Overig" : 55

Kerncijfers: grootste enkele sessie‑JSONL‑bestand 203 MB, grootste sub‑agent‑JSONL‑bestand 72 MB, history.jsonl bevat >37 000 items. Geen rotatie, compressie of opruimmechanisme. file-history/ bevat ongededupliceerde snapshots; dezelfde file bewerkt 10 keer resulteert in 10 volledige kopieën. debug/‑logboeken worden nooit opgeschoond.

Achtergrondtaak‑outputbestanden: 1,2 TB zelf‑refererende lus

Issue #32282 onthult een ongelooflijk ontwerpfout. Wanneer Claude Code meerdere achtergrond‑agents start en automatisch een bash‑commando uitvoert om voortgang te controleren, schrijft het output‑bestand naar dezelfde directory die door de glob‑patroon wordt gematcht, waardoor een zelf‑refererende oneindige feedback‑lus ontstaat:

flowchart LR
    A["bash: for f in tasks/*.output; tail -5 $f"] --> B["output geschreven naar tasks/task-A.output"]
    B --> C["glob matcht task-A.output zelf"]
    C --> D["tail -5 leest eigen output"]
    D --> E["append schrijft opnieuw naar zichzelf"]
    E --> C

Meerdere gebruikers meldden hetzelfde probleem: 1,2 TB, 460 GB, 303 GB, 235 GB, 480 GB, 36 GB. De issue‑commentator telde 70 gerelateerde open issues, verdeeld over 15 groepen; alleen de eerste twee groepen rapporteerden ≈9,5 TB schijfverbruik. Schrijfsnelheden bereikten 425 MB/s gedurende 18 minuten, tot de schijf vol was.

Cascading‑failure: onomkeerbare crash bij volle schijf

Issue #24207 beschrijft de catastrofale kettingreactie wanneer de schijf vol raakt:

flowchart TD
    A["schijfruimte = 0"] --> B["schrijven naar .claude.json mislukt"]
    B --> C["leeg bestand aangemaakt"]
    C --> D["lezen als ongeldige JSON"]
    D --> E["overschrijven van alle projectinstellingen"]
    E --> F["OAuth/API‑tokens beschadigd"]
    F --> G["herauthenticatie vereist"]
    G --> H["alle actieve agents/sessies gestopt"]
    H --> I["herstel onmogelijk, zelfs na vrijmaken van schijfruimte"]

Geen waarschuwing, geen elegante degradatie, geen herstelpad. Gebruikers moeten handmatig alle processen beëindigen, schijfruimte vrijmaken, configuraties herstellen, opnieuw authenticeren en alle instellingen opnieuw configureren.

Concurrerende schrijfacties: geen lock, geen transactie, geen coördinatie

In de ~/.claude/‑directory is het enige lock‑bestand .update.lock (5 bytes). Alle andere bestanden worden zonder enige bescherming geschreven. Wanneer meerdere Claude Code‑processen tegelijk draaien (agents + sub‑agents zijn normaal), is er geen coördinatie:

Op Windows is het nog erger: de gebruikelijke atomic‑write‑workaround (schrijf eerst .tmp en rename()) faalt omdat rename() EPERM retourneert wanneer het doelbestand door een ander proces wordt vastgehouden, waardoor atomair gedrag volledig wordt ondermijnd.

Geheugen‑ en CPU‑impact: van 13 GB RSS tot kernel‑panic

Extreem geheugenverbruik op Windows

Issue #24840 registreerde een extreem geval op Windows: RSS 13,21 GB, virtueel geheugen 47,17 GB, terwijl het systeem slechts 42,56 GB RAM had. 3,75 miljoen page‑faults duiden op constant disk‑I/O. In 347 s runtime was CPU‑tijd in gebruikersmodus slechts 35 s; ≈90 % van de tijd werd besteed aan wachten op I/O en swap, waardoor andere apps (bijv. Opera) volledig onresponsief werden.

macOS kernel‑panic

Issue #39253 rapporteerde ernstigere gevolgen: op een MacBook Pro M3 Pro (18 GB RAM) veroorzaakten meerdere Claude Code‑instanties een macOS kernel‑panic. Twee verschillende panic‑types werden waargenomen: Jetsam OOM‑kill (macOS doodde kritieke watchdogd‑processen door geheugen‑druk) en watchdog‑timeout (watchdogd miste >90 s check‑ins door resource‑uitputting). Het systeem herstartte zonder waarschuwing, zonder foutdialoog, zonder mogelijkheid om werk op te slaan.

Orphan‑processen: blijven actief na sluiten van terminal

Issue #44507 (april 2026, enkele dagen geleden) meldde een fundamenteel levenscyclus‑beheerprobleem: na het sluiten van het terminalvenster blijft het Claude Code‑proces draaien. Een geïsoleerd proces verbruikte in 21 dagen 35,4 GB RSS en 95,5 % CPU. De oorzaak is dat de hoofd‑CLI‑ingang geen process.stdin.on("end")‑handler heeft, terwijl >55 setInterval‑timers (polling, telemetry, status‑balk‑refresh, enz.) de Node.js‑event‑loop levend houden. De V8‑heap groeit onbeperkt, zonder idle‑GC‑druk, zonder --max-old-space-size‑limiet, zonder zelf‑terminerende watchdog.

100 % CPU‑freeze

Issue #27415 meldde een 100 % CPU‑freeze veroorzaakt door TaskStop, met als oorzaak een out‑of‑control loop in posix_spawn binnen de Bun‑runtime. Issue #26224 rapporteerde dat Claude Code bij verwerking van grote prompts 5‑20 minuten kan vastlopen.

Systemisch falen van de platte‑bestand‑architectuur

Toewijzen zonder opruimen: een terugkerend patroon in alle issues

Community‑lid kolkov benadrukte in meerdere issues dat de onderliggende oorzaak hetzelfde is:

Deze .node‑lekkage is geen geïsoleerde bug – het is een symptoom van een terugkerend architectuurpatroon waarbij Claude Code resources toewijst maar niet opruimt.

Van 2025 tot 2026 evolueerde het probleem van een enkele .claude.json‑file naar verspreide JSONL‑bestanden, maar de fundamentele architectuur bleef onveranderd: platte bestanden, geen lock, geen transactie, geen opruiming, geen compressie.

SQLite en een lokale daemon: community‑alternatieven

De community heeft herhaaldelijk voorgesteld SQLite te gebruiken in plaats van platte‑bestandopslag. Een SQLite‑database kan alle problemen tegelijk oplossen: WAL‑modus biedt atomische concurrent‑read + single‑write, transacties garanderen “all‑or‑nothing” voor sessies, ingebouwde compressie, TTL‑opruiming, deduplicatie en platform‑consistentie.

Een andere suggestie is een lokale daemon (vergelijkbaar met een LSP‑server of Docker‑architectuur) waarbij alle Claude Code‑processen via IPC communiceren, coördinatie bieden zonder de opslagbackend te wijzigen.

Community‑reverse‑engineering versus stale‑bot

Community‑lid gebeer vat de situatie treffend samen:

Bedankt voor je grondige analyse. Dit had de maintainers al lang moeten doen.

kolkov voegde toe:

Ironisch is dat de community feitelijk debuggen voor hen doet – reverse‑engineert verwarrende code, traceert foutpaden, levert patches met code‑snippets – terwijl de reactie een stale‑bot is die alle inhoud 60 dagen later sluit.

Vergelijking met resource‑beheer van soortgelijke tools

GitHub Copilot draait als VS Code‑extensie en valt onder de geheugen‑ en levenscyclus‑beperkingen van de host; Cursor, een fork van VS Code, erft hetzelfde resource‑beheer. Beide gebruiken SQLite of vergelijkbare databases, die native concurrency en transacties ondersteunen. Claude Code koos voor een onafhankelijk proces + platte‑bestandbenadering, maar implementeerde geen resource‑beheerverantwoordelijkheden – geen geheugen‑limiet, geen schijf‑quota, geen proces‑watchdog, geen elegante shutdown. Het gedrag lijkt meer op een prototype‑demo dan op een productie‑gereed hulpmiddel.

Paradox tussen modelcapaciteit en engineeringkwaliteit

Een 11,3 MB‑enkelbestandspakket, 413 synchronische besturingssysteem‑aanroepen, 1087 CJS/ESM‑interoperabiliteitswrappers, geen resource‑cleanup, geen concurrency‑control, geen schijfruimtemonitoring – dit zijn geen randgevallen, maar systemische architectuurdefecten. Van Issue #5024 (augustus 2025) tot Issue #44507 (april 2026) rapporteert de community consistent dezelfde categorie problemen, biedt gedetailleerde analyses en reparatie‑suggesties, terwijl veel issues als “not planned” worden gemarkeerd of automatisch door een stale‑bot worden gesloten. Een AI‑code‑tool waarvan de eigen code‑kwaliteit afhankelijk is van community‑audit en -reparatie, vormt een intrigerende paradox.

Als je Claude Code gebruikt, controleer dan regelmatig de grootte van de ~/.claude‑directory, maak tijdelijke .node‑bestanden op tijd op, en zorg ervoor dat je bij het afsluiten van de terminal correct afsluit met Ctrl+C. Als je schijfruimte plotseling verdwijnt, weet je nu waar je moet zoeken.

• ←Vorige
• Volgende→