Claude Code's Ressourcen-Schwarzes Loch: Von einer 11,3 MB Einzeldatei bis zu 1,2 TB Festplattenverschlingung

Claude Code’s Client ist eine Node.js‑Einzeldateianwendung ohne Ressourcen‑Lebenszyklus‑Management: Beim Start wird eine 11,3 MB‑Pack‑Datei geparst, zur Laufzeit werden unbegrenzt Daten auf die Festplatte geschrieben, und nach dem Schließen des Terminals bleibt der Prozess aktiv und verbraucht weiter Speicher, bis das System abstürzt. Basierend auf echten Nutzerberichten aus GitHub Issues und Community‑Reverse‑Engineering systematisiert dieser Artikel die Ressourcenverwaltungsdefizite von Claude Code in den Bereichen Speicher, CPU und Festplatte und deckt strukturelle Probleme in Pack‑Architektur, Speicherdesign und Prozesslebenszyklus‑Management auf. Diese Probleme sind keine Rand‑Cases, sondern seit August 2025 bis April 2026 kontinuierlich von der Community gemeldet worden und wurden von Stale‑Bots massenhaft geschlossen – ein systematischer Architektur‑Defekt.

Pack‑Architektur: Die Kosten einer 11,3 MB‑Einzeldatei

Der Kern von Claude Code ist ein einzelnes Bundle‑File namens cli.js mit einer Größe von etwa 11,3 MB. Community‑Mitglied paultendo hat in Issue #29481 eine ausführliche statische Analyse durchgeführt und mehrere schwerwiegende Architekturprobleme aufgedeckt.

V8‑Startzeit: 32 % der Zeit für das Parsen

CPU‑Profiling zeigt, dass compileSourceTextModule 31,7 % der Sampling‑Zeit der Startphase verbraucht. Die V8‑Engine benötigt etwa 300 ms, um diese 11,3 MB‑Einzeldatei zu parsen, während ein einfacher Node.js‑Skript nur 23 ms benötigt. Weitere 7,3 % entfallen auf spawnSync, 3,5 % auf Garbage‑Collection. Das bedeutet, dass vor jeder Benutzereingabe bereits über 40 % der Startzeit für reines Parsen verschwendet werden.

Vollständiges Laden: Nur 20 dynamische Imports

Das gesamte Bundle wird beim Start vollständig geparst und ausgeführt, mit nur 20 import()‑Ausdrücken. Jeder Nutzer zahlt den Preis für alle Funktionen, unabhängig davon, ob sie verwendet werden. Folgende Komponenten sollten on‑demand geladen werden, werden aber komplett gebündelt:

pie title Zusammensetzung der Bundle‑Datei (ca. 13,5 MB)
    "Kernlogik der Anwendung" : 7540
    "AWS Bedrock SDK" : 1100
    "highlight.js (182 Sprachen)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "Sonstiges (Ink, Zod, Ajv, Axios usw.)" : 1807

Ein Coding‑Assistent, der 182 Sprachen wie Brainfuck, MIPS‑Assembly, Flix, Zephir, Inform7, Lasso usw. hervorhebt, verdeutlicht die grobe Pack‑Strategie. Das Beibehalten von nur etwa 40 gängigen Sprachen könnte ca. 786 KB an Parsing‑Overhead einsparen.

Redundante Abhängigkeiten: Vier HTTP‑Clients, drei Validierungs‑Libraries

Verschiedene SDKs bringen jeweils eigene Abhängigkeiten mit, sodass das Bundle vier HTTP‑Clients (Axios, Undici, Got, native fetch) und drei Validierungs‑Libraries (Zod, Ajv, JSON Schema) enthält. In Node 18+ ist native fetch bereits vollständig verfügbar, sodass zusätzliche HTTP‑Clients überflüssig sind.

413 synchrone Dateisystem‑Aufrufe

Das Bundle enthält 196 existsSync, 109 statSync, 108 readFileSync, 58 mkdirSync usw., insgesamt 413 synchrone Dateisystem‑Aufrufe. Jeder blockiert den Event‑Loop. Viele Aufrufe folgen dem Muster existsSync(path) && readFileSync(path), das durch ein einzelnes try { await readFile(path) } catch {} ersetzt werden könnte.

1087 CJS/ESM‑Interoperabilitäts‑Wrapper

Jedes CommonJS‑Modul, das in ein ESM‑Bundle eingebettet wird, erzeugt __toESM/__commonJS/__require‑Kompatibilitäts‑Shims, insgesamt 1087 Stück. Diese Shims erhöhen das Parsing‑Gewicht und fügen jedem Modul einen kleinen Laufzeit‑Overhead hinzu.

Unnötige Node‑20‑Polyfills

Das Bundle enthält 62 Promise‑Shims (seit Node 0.12 nativ), 57 Symbol‑Shims (seit Node 4 nativ), 57 async‑Transform‑Hilfsfunktionen (seit Node 8 nativ) und 3 AbortController‑Polyfills (seit Node 15 nativ). Diese stammen aus Transitive‑Abhängigkeiten, die für alte Node‑ oder Browser‑Umgebungen kompiliert wurden und sind im Ziel‑Runtime völlig überflüssig.

ripgrep‑Bundle aller 6 Plattform‑Binaries: 61 MB

Alle 6 Plattform‑Binaries von ripgrep werden gebündelt, insgesamt 61 MB. Im Gegensatz dazu nutzt sharp optionale Abhängigkeiten und installiert nur das Binary der aktuellen Plattform. Das bedeutet, dass jede Installation etwa 51 MB Festplattenspeicher verschwendet.

Ink‑Render‑Leistung verschlechtert sich mit Dialoglänge

Das Terminal‑UI verwendet Ink (React for Terminal). Analysen zeigen 6457 createElement‑Aufrufe, 578 useState‑Hooks, aber nur 11 React.memo()‑Wrapper (1,9 %). In Ink löst jeder State‑Update eine vollständige virtuelle DOM‑Koordination aus. Während des Streamings wird bei jedem eingehenden Token ein State‑Update ausgelöst, sodass nicht memo‑isierte Komponenten unnötig neu gerendert werden. Mit wachsendem Dialog steigt die Render‑Ausgabe, und jedes erneute Rendern muss mehr Terminal‑Inhalt diffen. Das entspricht dem in Issue #22265 beschriebenen Phänomen „Die Sitzung wird immer langsamer“.

Festplatten‑Verschlingung: Unbegrenztes Wachstum von GB zu TB

Das Festplatten‑Problem ist das gravierendste Ressourcen‑Management‑Defizit von Claude Code und hat die breiteste Auswirkung.

Windows‑.node‑Native‑Modul‑Leak: 20 GB pro Woche

Issue #23095 dokumentiert ein seit Monaten ungelöstes Problem: Das Windows‑Native‑Binary (claude.exe) extrahiert bei jeder Sitzung native Node.js‑Plugin‑Dateien in das temporäre Verzeichnis, löscht sie jedoch nie. Jede Datei ist ca. 6,6 MB; Nutzer SlothKing16 sammelte in 4 Tagen 2813 Dateien (≈ 18 GB). Nutzer kolkov meldete sogar ~20 GB/Woche, bei intensiven Nutzern bis zu 100 GB/Woche. Dieses Problem wird seit Anfang 2025 gemeldet, aber von Bots wiederholt als Duplikat markiert und geschlossen.

~/.claude‑Verzeichnis: 3 GB+ ohne Verwaltung

Nutzer kolkov auditierte in Issue #5024 eine Maschine, die 8 Monate täglich genutzt wurde:

pie title Speicherverbrauch von ~/.claude (ca. 3,1 GB)
    "projects/ (Sitzungsprotokolle)" : 2500
    "debug/ (Debug‑Logs)" : 303
    "file-history/ (Dateisnapshots)" : 232
    "history.jsonl (globale Historie)" : 10
    "Sonstiges" : 55

Wichtige Zahlen: größte einzelne JSONL‑Sitzungsdatei 203 MB, größte Unter‑Agent‑JSONL‑Datei 72 MB, history.jsonl enthält über 37 000 Einträge. Alle Daten werden nicht rotiert, komprimiert oder bereinigt. Snapshots in file-history/ werden nicht dedupliziert – dieselbe Datei, 10‑mal bearbeitet, erzeugt 10 vollständige Kopien. debug/‑Logs werden nie gelöscht.

Hintergrund‑Task‑Ausgabedatei: 1,2 TB Selbst‑Referenz‑Endlosschleife

Issue #32282 enthüllt ein unglaubliches Design‑Defizit. Wenn Claude Code mehrere Hintergrund‑Agenten startet und automatisch einen Bash‑Befehl zur Fortschrittsprüfung ausführt, wird die Ausgabedatei in dasselbe Verzeichnis geschrieben, das vom Glob‑Pattern erfasst wird, wodurch eine selbst‑referenzierende Endlosschleife entsteht:

flowchart LR
    A["bash: for f in tasks/*.output; tail -5 $f"] --> B["Ausgabe wird in tasks/task-A.output geschrieben"]
    B --> C["Glob erfasst task-A.output selbst"]
    C --> D["tail -5 liest die eigene Ausgabe"]
    D --> E["Anhang schreibt wieder in dieselbe Datei"]
    E --> C

Mehrere Nutzer berichteten das gleiche Problem: 1,2 TB, 460 GB, 303 GB, 235 GB, 480 GB, 36 GB. Der Issue‑Kommentator zählte 70 verwandte offene Issues, aufgeteilt in 15 Gruppen; allein die ersten beiden Gruppen verursachten ca. 9,5 TB Festplattenverbrauch. Schreibgeschwindigkeiten von bis zu 425 MB/s über 18 Minuten bis zur Erschöpfung des Speicherplatzes.

Kaskadierende Fehlfunktion: Irreversible Abstürze nach voller Festplatte

Issue #24207 beschreibt die katastrophale Kettenreaktion, wenn die Festplatte voll ist:

flowchart TD
    A["Festplattenspeicher = 0"] --> B["Schreiben von .claude.json schlägt fehl"]
    B --> C["Erzeugt Null‑Längen‑Datei"]
    C --> D["Wird als ungültiges JSON gelesen"]
    D --> E["Überschreibt alle Projekteinstellungen"]
    E --> F["OAuth/API‑Token werden beschädigt"]
    F --> G["Neuauthentifizierung erforderlich"]
    G --> H["Alle laufenden Agenten/Sitzungen stoppen"]
    H --> I["Selbst nach Freigabe von Speicherplatz keine Wiederherstellung möglich"]

Keine Vorwarnung, kein graceful Degradation, kein Wiederherstellungsweg. Nutzer müssen alle Prozesse manuell beenden, Speicherplatz freigeben, Konfigurationen manuell wiederherstellen und neu authentifizieren.

Konkurrenz‑Schreibzugriffe: Keine Locks, keine Transaktionen, keine Koordination

Im ~/.claude/‑Verzeichnis gibt es nur die Lock‑Datei .update.lock (5 Byte). Alle anderen Dateien werden ohne Schutz geschrieben. Wenn mehrere Claude‑Code‑Prozesse gleichzeitig laufen (Agent + Sub‑Agent ist ein normales Nutzungsszenario), gibt es keinerlei Koordination beim Schreiben gemeinsamer Dateien:

Unter Windows ist es noch schlimmer: Der Workaround für atomare Writes (erst .tmp schreiben, dann rename()) schlägt fehl, weil rename() EPERM zurückgibt, wenn die Zieldatei von einem anderen Prozess gehalten wird, wodurch die Atomizität komplett zerstört wird.

Speicher‑ und CPU‑Verbrauch: Von 13 GB RSS bis zum Kernel‑Panic

Extrem‑Speicherverbrauch unter Windows

Issue #24840 dokumentiert einen extremen Fall unter Windows: RSS 13,21 GB, virtueller Speicher‑Commit 47,17 GB, bei einem Gesamtspeicher von nur 42,56 GB. 3,75 M Page‑Faults, was auf ständige Festplatten‑I/O hinweist. In 347 s Laufzeit wurden nur 35 s CPU‑Zeit im Userspace verbraucht – etwa 90 % der Zeit wurden mit Warten auf I/O und Swapping verbracht, wodurch andere Anwendungen (z. B. Opera) völlig unresponsive wurden.

macOS‑Kernel‑Panic

Issue #39253 berichtet schwerwiegendere Folgen: Auf einem MacBook Pro M3 Pro (18 GB RAM) führen mehrere Claude‑Code‑Instanzen zu macOS‑Kernel‑Panics. Zwei unterschiedliche Panic‑Typen wurden beobachtet: Jetsam OOM‑Kill (Speicher‑Pressure tötet den kritischen watchdogd‑Prozess) und Watchdog‑Timeout (watchdogd meldet nach > 90 s Ressourcen‑Hungern keinen Heartbeat). Das System startet ohne Warnung neu, ohne Fehlermeldung und ohne Möglichkeit, ungespeicherte Arbeit zu retten.

Orphan‑Prozesse: Weiterleben nach Schließen des Terminals

Issue #44507 (April 2026, nur wenige Tage alt) meldet einen grundlegenden Lifecycle‑Mangel: Nach dem Schließen des Terminal‑Fensters bleibt der Claude‑Code‑Prozess aktiv. Ein isolierter Prozess verbrauchte in 21 Tagen 35,4 GB RSS und 95,5 % CPU. Ursache ist das Fehlen eines process.stdin.on("end")‑Handlers im Haupt‑CLI‑Entry‑Point, während über 55 setInterval‑Timer (Polling, Telemetry, Status‑Bar‑Refresh usw.) die Node‑Event‑Loop dauerhaft am Leben halten. Der V8‑Heap wächst unbegrenzt, es gibt keinen GC‑Druck, keine --max-old-space-size‑Begrenzung und keinen Selbst‑Terminierungs‑Watchdog.

100 % CPU‑Freeze

Issue #27415 meldet einen 100 % CPU‑Freeze, ausgelöst durch TaskStop, verursacht durch eine unkontrollierte Schleife im posix_spawn‑Teil der Bun‑Runtime. Issue #26224 berichtet, dass Claude Code bei der Verarbeitung großer Prompt‑Mengen für 5‑20 Minuten hängen bleibt.

Systematisches Versagen einer flachen Dateistruktur

Allokieren ohne Aufräumen: Ein architektonisches Muster in allen Issues

Community‑Mitglied kolkov weist in mehreren Issues wiederholt darauf hin, dass die Grundursache überall gleich ist:

Dieses .node‑Leak ist kein isolierter Bug – es ist ein Symptom eines wiederkehrenden Architektur‑Musters, bei dem Claude Code Ressourcen allokiert, aber nicht aufräumt.

Von 2025 bis 2026 entwickelte sich das Problem von einer einzelnen .claude.json‑Datei zu einer verteilten JSONL‑Explosion, aber das Grund‑Design blieb unverändert: flache Dateien, keine Locks, keine Transaktionen, kein Aufräumen, keine Kompression.

SQLite und lokaler Daemon: Community‑Vorschläge

Die Community schlägt mehrfach vor, SQLite anstelle flacher Dateien zu verwenden. Eine SQLite‑Datenbank könnte alle Probleme lösen: WAL‑Modus bietet atomare Concurrency (viele Leser, ein Schreiber), Transaktionen garantieren „all‑or‑nothing“ bei Sitzungs‑Writes, eingebaute Kompression, TTL‑Bereinigung, Deduplizierung und plattformübergreifende Konsistenz.

Ein weiterer Vorschlag ist ein lokaler Daemon (ähnlich einem LSP‑Server oder Docker‑Architektur), über den alle Claude‑Code‑Prozesse per IPC kommunizieren, um Koordination zu ermöglichen, ohne das Speicher‑Backend zu ändern.

Community‑Reverse‑Engineering vs. Stale‑Bot

Community‑Mitglied gebeer fasst den Zustand prägnant zusammen:

Danke für deine gründliche Analyse. Das hätte die Maintainer schon vor langer Zeit erledigen sollen.

kolkov fügt hinzu:

Ironisch ist, dass die Community im Grunde für sie debuggt – Reverse‑Engineering, Fehlersuche, Patch‑Vorschläge mit Code – während ein Stale‑Issue‑Bot nach 60 Tagen alles schließt.

Vergleich mit anderen Tools hinsichtlich Ressourcen‑Management

GitHub Copilot läuft als VS Code‑Extension und unterliegt den Speicher‑ und Lifecycle‑Beschränkungen des Host‑Editors; Cursor, ein Fork von VS Code, übernimmt das gleiche Ressourcen‑Management‑Framework; beide speichern Daten in SQLite oder ähnlichen Datenbanken, die von Haus aus Concurrency und Transaktionen unterstützen. Claude Code wählte ein eigenständiges Prozess‑+‑flaches‑Datei‑Modell, implementierte jedoch weder Speicher‑Limits, noch Festplatten‑Quotas, noch Prozess‑Watchdogs, noch graceful Shutdowns. Sein Verhalten ähnelt eher einem Prototyp‑Demo als einem produktionsreifen Tool.

Paradoxon zwischen Modell‑Fähigkeit und Engineering‑Qualität

Eine 11,3 MB‑Einzeldatei, 413 synchrone Dateisystem‑Aufrufe, 1087 CJS/ESM‑Wrapper, kein Ressourcen‑Aufräumen, keine Concurrency‑Kontrolle, keine Festplatten‑Überwachung – das sind keine Rand‑Cases, sondern systemische Architektur‑Defizite. Von August 2025 (Issue #5024) bis April 2026 (Issue #44507) meldete die Community kontinuierlich dieselben Probleme, lieferte detaillierte Analysen und Lösungsvorschläge, während viele Issues als „not planned“ markiert oder von Stale‑Bots automatisch geschlossen wurden. Ein KI‑Coding‑Tool, dessen eigene Code‑Qualität von der Community auditieren und reparieren muss, stellt ein nachdenkliches Paradoxon dar.

Wenn du Claude Code nutzt, prüfe regelmäßig die Größe des ~/.claude‑Verzeichnisses, bereinige .node‑Dateien im temporären Ordner und stelle sicher, dass du vor dem Schließen des Terminals mit Ctrl + C korrekt beendest. Wenn plötzlich Festplattenspeicher verschwindet, weißt du jetzt, wo du nach der Ursache suchen musst.

• ←Zurück
• Weiter→