So räumen Sie nach KI-Coding-Tools auf dem Mac auf

Eine Festplatte, die zwei Jahre lang locker gereicht hat, kann sich innerhalb weniger Monate füllen, sobald Sie täglich mit Coding-Agenten arbeiten. Die Agenten selbst sind klein. Verändert hat sich, wie oft die Maschine kompiliert, wie oft sich eine CLI auf der Festplatte selbst ersetzt, und wie viel von Ihrem eigenen Denkprozess inzwischen als Text im Home-Verzeichnis liegt. Fast das gesamte Wachstum fällt in drei Kategorien, und die brauchen drei unterschiedliche Entscheidungen, weil sie drei sehr unterschiedliche Summen kosten, um sie wieder zurückzuholen.

Modellgewichte sind der naheliegende Verdächtige und meistens der falsche für dieses spezielle Problem. Ollama, LM Studio und Hugging Face führen inhaltsadressierte Speicher, die nur ihre eigenen Werkzeuge sicher bereinigen können; das behandelt gesondert KI-Tool-Reste entfernen. Hier geht es darum, was KI-Coding-Agenten während der Arbeit hinterlassen.

Erst messen, dann löschen

Zwei Befehle beantworten den größten Teil der Frage. Der erste summiert die Home-Verzeichnisse der Agenten:

du -sh ~/.codex ~/.claude ~/.local/share/claude ~/.grok ~/.cache 2>/dev/null | sort -h

Der zweite findet Build-Output, der über jedes Projekt verstreut ist, das Sie je geöffnet haben. Ersetzen Sie die Wurzelverzeichnisse durch die Orte, an denen Sie Ihren Code ablegen:

find ~/www ~/Projects -maxdepth 3 -type d \
  \( -name target -o -name node_modules -o -name .next -o -name dist -o -name build \) \
  -prune -exec du -sh {} + 2>/dev/null | sort -h | tail -20

-prune verhindert, dass find in ein Verzeichnis absteigt, das bereits getroffen hat, und das ist hier wichtig: ohne diese Option durchläuft find jede einzelne Datei innerhalb eines 24-GB-target/-Ordners, bevor es weitermacht. Auf dem Mac, den ich für diesen Artikel vermessen habe, standen ganz oben ein Rust-target/ mit 24 GB und das target/ eines Tauri-Projekts mit 9,8 GB, gegenüber node_modules-Bäumen zwischen 134 MB und 1,5 GB. Das Verhältnis ist der Punkt: Was wie das Abhängigkeitsproblem aussah, war zwei Prozent der tatsächlichen Zahl.

Wer das lieber als Karte statt als Liste sieht: Die Analyze-Ansicht von Mole zeichnet dieselben Volumen als Treemap und lässt Sie in das größte Rechteck hineinklicken, was schneller geht, als zu raten, welche Wurzel man find übergeben soll.

Kategorie eins: Build-Output, verstärkt

Diese Kategorie ist nicht neu. Das Volumen schon. Ein Entwickler, der von Hand arbeitet, kompiliert ein paar Mal am Tag. Ein Agent, der sich durch eine Aufgabe arbeitet, kompiliert nach fast jeder Änderung, lässt die Tests laufen, probiert einen zweiten Ansatz und kompiliert erneut. Caches, die früher über Monate wuchsen, wachsen jetzt an einem Nachmittag, und inkrementelle Build-Verzeichnisse sind bewusst so gebaut, dass sie Festplattenplatz gegen Geschwindigkeit eintauschen.

Rust liegt meistens mit großem Abstand vorn. Ein target/-Verzeichnis enthält kompilierte Abhängigkeiten, den Zustand der inkrementellen Kompilierung und die Ausgabe von Build-Skripten, getrennt nach Profil gespeichert, sodass Debug und Release zwei vollständige Kopien sind. cargo clean ohne Optionen „löscht das gesamte Target-Verzeichnis“. Erst eine Vorschau:

cargo clean --dry-run
cargo clean --release

cargo clean -p <package> bereinigt nur die genannten Pakete, das richtige Werkzeug, wenn ein einzelnes Workspace-Mitglied das Problem ist.

JavaScript verteilt seinen Output dünner. Neben node_modules selbst gibt es node_modules/.cache (von Bundlern und Transpilern genutzt), .next für Next.js-Builds und was auch immer Ihre Toolchain unter dist oder build schreibt. Die Caches gezielt finden:

find ~/www -maxdepth 4 -type d -path '*/node_modules/.cache' -prune -exec du -sh {} + \
  2>/dev/null | sort -h | tail

Python legt __pycache__ neben jedes importierte Paket. Einzeln winzig, aber es gibt Tausende davon. Erst zählen, bevor Sie löschen, denn dieselbe Befehlsform mit angehängtem rm -rf verzeiht keinen falsch gewählten Wurzelpfad:

find ~/www -type d -name __pycache__ -prune -print | wc -l

Bytecode-Caches bauen sich beim nächsten Import ohne jeden Netzwerkzugriff neu auf, das ist damit die ungefährlichste Löschung im ganzen Artikel.

Go führt einen einzigen globalen Build-Cache statt Verzeichnisse pro Projekt. go env GOCACHE gibt dessen Pfad aus, und go clean -cache „lässt clean den gesamten Go-Build-Cache entfernen“. go clean -testcache verwirft gecachte Testergebnisse, ohne kompilierte Pakete zu löschen. Auf meiner Maschine lag der Build-Cache bei 183 MB gegenüber einem 38-MB-Modul-Cache, es lohnt sich also, die Build-Seite zu prüfen, selbst wenn die heruntergeladenen Module klein sind.

Xcode braucht eine eigene Betrachtung, denn DerivedData, Archive, Device Support und Simulator-Runtimes sind vier verschiedene Dinge mit vier verschiedenen Wiederherstellungskosten. Der DerivedData-Ordner auf diesem Mac maß 9,3 GB. Xcode-Speicher aufräumen erklärt, was davon Sie löschen können und was Sie für die Symbolisierung behalten. Gradle und Maven teilen sich genauso zwischen projektspezifischen build/-Verzeichnissen und einem globalen Speicher unter ~/.gradle oder ~/.m2, und die globale Seite gehört zu den anderen Registries in Entwickler-Caches leeren.

Kategorie zwei: überholte CLI-Versionen

Das ist die Kategorie, nach der fast niemand sucht, und auf einer Maschine, die mehrere Agenten laufen lässt, ist sie oft größer als alle Caches zusammen.

Agent-CLIs aktualisieren sich selbst, indem sie ein komplettes neues, versioniertes Release herunterladen und einen Launcher darauf zeigen lassen. Jedes Release ist in sich abgeschlossen und teilt daher keine Dateien mit dem vorherigen. Der Zeiger wandert weiter. Das alte Release bleibt liegen. Nichts räumt es auf, also wächst die Anzahl bei jedem Update um eins, für immer.

Die Ablagestruktur folgt überall demselben Muster, nur kosmetisch verschieden:

• Codex legt unter ~/.codex/packages/standalone/releases/<version>-<arch>/ ab, mit einem current-Symlink eine Ebene darüber, der auf das aktive Release zeigt.
• Claude Code legt unter ~/.local/share/claude/versions/<version> ab, wobei jeder Eintrag eine einzelne ausführbare Datei statt eines Verzeichnisses ist, und ~/.local/bin/claude ist ein Symlink auf die aktive Version.
• Grok legt ~/.grok/downloads/grok-<version>-macos-<arch> als Dateien ab, wobei ~/.grok/bin/grok und ~/.grok/bin/agent auf den aktuellen Build zeigen.
• Cursor Agent legt unter ~/.local/share/cursor-agent/versions/<date>-<sha>/ ab, mit ~/.local/bin/cursor-agent als Launcher.
• GitHub Copilot CLI, über npm installiert, ersetzt sich an Ort und Stelle, aber sein Installationsskript schreibt ein versioniertes Paket unter einen Präfix, der bei einem Nicht-Root-Nutzer standardmäßig $HOME/.local ist. Mole prüft ~/.copilot/pkg/universal auf dieselbe Struktur.

Alle auf einmal messen:

du -sh ~/.codex/packages/standalone/releases/* \
       ~/.local/share/claude/versions/* \
       ~/.grok/downloads/* \
       ~/.local/share/cursor-agent/versions/* 2>/dev/null

Auf dem Mac, den ich für diesen Artikel benutzt habe, kamen dabei fünf Codex-Releases zwischen 262 MB und 310 MB heraus, fünf Claude-Code-Binärdateien zwischen 293 MB und 306 MB, zwei Grok-Builds und zwei Cursor-Agent-Versionen. Insgesamt rund 3,5 GB, davon etwa 920 MB aktiv genutzt. Alles andere war eine Binärdatei, die bereits ersetzt worden war. Codex' eigener Issue-Tracker hat dazu eine offene Anfrage, in der der Melder das Wachstum auf etwa 250 MB pro Update beziffert (openai/codex#22293).

Den Launcher auflösen, bevor Sie auch nur ein Verzeichnis löschen

Die verlockende Abkürzung ist, nach Datum zu sortieren und die neueste Version zu behalten. Lassen Sie es. Zwei ganz gewöhnliche Situationen machen das kaputt: Sie haben nach einer Regression absichtlich eine ältere Version festgepinnt, oder ein Update hat das neue Verzeichnis bereits vorbereitet, bevor es den Zeiger umgestellt hat. Löschen Sie das aktive Release, bleibt ein Launcher zurück, der ins Leere zeigt.

Fragen Sie stattdessen den Launcher selbst. Er ist ein Symlink, also aufgelöst:

readlink -f "$(command -v codex)"
readlink -f "$(command -v claude)"
readlink -f "$(command -v grok)"

Das gibt das echte Ziel aus, zum Beispiel ~/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin/bin/codex, während ls -l "$(command -v codex)" jede einzelne Zwischenstation statt der Endantwort zeigt. Was dabei herauskommt, ist aktiv. Jedes Geschwisterverzeichnis, das nicht auf diesem Pfad liegt, ist überholt, und es in den Papierkorb zu legen ist sicher. Danach die CLI einmal ausführen, um zu bestätigen, dass der Launcher noch auflöst, bevor Sie den Papierkorb leeren.

Kategorie drei: Arbeitszustand des Agenten, kein Datenmüll

Die dritte Kategorie ist die, bei der ein Cleaner echten Schaden anrichten kann, weil sie genauso aussieht wie die ersten beiden.

Sitzungsmitschnitte, Memories, Pläne und generierte Anhänge liegen unter ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects und ~/.grok/sessions. Es sind JSONL-Dateien, benannt nach Sitzungs-ID, mit Zeitstempel, nur anfügend, und sie hören nie auf zu wachsen. Jede Heuristik, die ein generischer Cleaner verwendet, sagt: Logdatei. Auf dem Mac, den ich vermessen habe, war ~/.codex/sessions 9,8 GB groß, ~/.claude/projects kam auf 2,7 GB über 2.362 Mitschnittdateien, und ~/.grok/sessions lag bei 1,3 GB: eine große, verlockende Zahl, die an Dateien hängt, die entbehrlich wirken.

Es sind keine Logs. Ein Mitschnitt ist das Protokoll davon, wie eine Änderung zustande kam: die probierten und verworfenen Ansätze, die Einschränkung, die einen davon ausschied, der Grund, warum die endgültige Form so ist, wie sie ist. Diese Überlegung existiert sonst nirgendwo. Die Commit-Nachricht hält fest, was sich geändert hat, der Code hält die überlebende Option fest und nicht die vier verworfenen. Monate davon sammeln sich still an, und den Wert entdecken Sie erst, wenn Sie zum ersten Mal zurückgehen und fragen, warum etwas so gebaut wurde.

Das größere Risiko ist gar nicht ein Cleaner von Drittanbietern. Claude Code liefert seine eigene Aufbewahrungsbereinigung mit: cleanupPeriodDays steht standardmäßig auf 30 Tage, und beim Start löscht es Mitschnitte unter projects/, Plandateien, Snapshots vor Änderungen in file-history/ sowie sitzungsbezogene Aufgabenlisten, die älter sind. Die .claude-Verzeichnisreferenz dokumentiert genau, welche Pfade bereinigt werden und welche unbegrenzt erhalten bleiben. Wer ein Jahr an Mitschnitten will, sollte diese Zahl jetzt erhöhen, statt den Standardwert im Nachhinein zu entdecken. Dieselbe Seite dokumentiert claude project purge für den umgekehrten Fall, wenn Sie den Zustand eines Projekts gezielt loswerden möchten.

Mole fasst nichts davon an. Diese fünf Pfade, dazu ~/.claude/file-history, ~/.claude/plans, ~/.claude/tasks, ~/.codex/attachments und ~/.codex/generated_images, stehen unabhängig vom Alter auf der Schutzliste. Es gibt keine Altersgrenze, keine Ausnahme für „älter als 90 Tage“, keine Einstellung, die eine solche einschalten würde. Eine altersabhängige Ausnahme für diese Pfade wurde einmal gebaut und noch am selben Tag zurückgenommen, denn ein alter Mitschnitt ist kein veralteter Mitschnitt.

Unter der Haube: nach Wiederherstellungskosten sortieren, nicht nach Größe

Das ist die Regel, die alle drei Kategorien entscheidbar macht, und das Einzige in diesem Artikel, das man sich wirklich merken sollte. Ordnen Sie jeden Kandidaten danach ein, was es kostet, ihn zurückzuholen, nicht danach, wie viele Gigabyte er anzeigt.

Lokal neu erzeugbar. Build-Output, Zustand der inkrementellen Kompilierung, Bytecode-Caches, DerivedData. Die Kosten, das zu löschen, sind CPU-Minuten auf einer Maschine, an der Sie ohnehin schon sitzen, ganz ohne Netzwerk. Frei löschen, und die größten Brocken ohne viel Nachdenken.

Teuer neu aufzubauen. Paket-Registries, node_modules, CocoaPods, Python-Virtual-Environments, vendor-Verzeichnisse, Modellgewichte, iOS-DeviceSupport. Jedes davon braucht ein Netzwerk, eine Registry, die noch genau die Versionen liefert, die Ihre Lockfile nennt, und manchmal eine native Toolchain. Die eigentlichen Kosten sind nicht Minuten bei guter Verbindung, sondern die Frage, ob Sie im Zug überhaupt arbeiten können. Diese einzeln durchgehen.

Unersetzlich. Chat-Mitschnitte, Agent-Memories, Plandateien, Projektzustand, lokale Fine-Tunes. Keine Menge an CPU oder Bandbreite holt das zurück. Sie gehören nie in eine Stapellöschung und sollten sich nicht versehentlich mit auswählen lassen.

Die Falle ist, dass Stufe eins und Stufe zwei identisch aussehen. target/ und node_modules/ sind beide große Verzeichnisse an der Projektwurzel, beide voller Abhängigkeits-Artefakte, beide in der .gitignore gelistet, beide durch einen einzigen Befehl neu erzeugbar. Nach Größe sortiert stehen sie direkt nebeneinander. Aber cargo build baut target/ aus Quellcode wieder auf, den Sie ohnehin schon auf der Festplatte haben, während npm ci braucht, dass die Registry noch läuft und die Lockfile noch auflöst. Das eine ist eine Kaffeepause. Das andere ist ein blockierter Nachmittag oder ein zurückgezogenes Paket, das sich nicht neu installieren lässt. Diese beiden zu verwechseln ist der mit Abstand häufigste Fehler in dieser Kategorie, und deshalb ist „die größten Ordner löschen“ ein schlechter Rat, selbst wenn er den meisten Platz freigibt.

So macht das Mole

Der manuelle Weg funktioniert und kostet nichts. Was Mole dazugibt: Alle drei Kategorien landen in einer geprüften Liste, in der die Stufengrenze bereits angewendet ist, sodass Sie sich nicht merken müssen, welches Punkt-Verzeichnis die Mitschnitte enthält.

Öffnen Sie das Clean-Werkzeug und starten Sie einen Scan. Scannen ist kostenlos und braucht keine Lizenz. Jeder Kandidat kommt mit seinem exakten Pfad, seinem Eigentümer und seiner gemessenen Größe an, und nichts bewegt sich, bis Sie die Liste bestätigen. Alles mit geringer Konfidenz kommt unmarkiert an, die Standardaktion ist also immer die kleinere. Entfernungen wandern in den Papierkorb statt unlinked zu werden, ein Fehler ist also ein Zurückziehen statt eine Wiederherstellung aus dem Backup, und eine Stapeloperation meldet, was übersprungen und was fehlgeschlagen ist, nicht nur, was entfernt wurde.

Speziell für die überholten CLI-Versionen erledigt Mole die oben beschriebene Launcher-Auflösung für Sie. Es liest den Launcher-Symlink jeder Agent-CLI, löst ihn zum aktiven Release auf und schließt dieses Release aus der Kandidatenmenge aus, sodass ein bewusstes Downgrade unangetastet bleibt, statt als alte Version behandelt zu werden. Der gemessene Fall hinter diesem Verhalten ist Codex: fünf Releases mit 1,2 GB, von denen nur eines aktiv war.

Die Mole CLI ist kostenlos, quelloffen und erledigt denselben Job aus der Shell mit mo clean; jeder destruktive Befehl akzeptiert --dry-run, sodass Sie die vollständige Pfadliste lesen können, bevor sich irgendetwas bewegt. Beide teilen sich eine Schutzliste unter ~/.config/mole/whitelist und ein Operations-Log unter ~/Library/Logs/mole/operations.log, und alles läuft lokal, ohne Upload und ohne Telemetrie.

Der Klarheit halber: Mole ist kein Backup, keine Malware-Reaktion und kein Ersatz für einen Hersteller-Uninstaller bei Software, die Treiber oder Systemerweiterungen mitbringt. Es löscht keine Modellgewichte und keinen KI-Chat-Verlauf und wird das auch nicht anbieten. Die bleiben bei den Werkzeugen, denen sie gehören.

Damit es nicht wiederkommt

Drei Konfigurationsänderungen decken den größten Teil des Nachwachsens ab.

Rust auf ein einziges Build-Verzeichnis lenken. CARGO_TARGET_DIR legt den „Ort fest, an dem alle erzeugten Artefakte abgelegt werden“, sodass jedes Projekt in einen Baum schreibt, den Sie an einer einzigen Stelle messen und bereinigen können. Der Kompromiss ist real: Cargo sperrt das Build-Verzeichnis, zwei Projekte, die sich ein Target-Verzeichnis teilen, bauen also nacheinander statt parallel. Wer regelmäßig parallel baut, sollte sie getrennt halten und stattdessen einen regelmäßigen Aufräumdurchgang einplanen.

Die globalen Speicher nach Plan bereinigen, nicht von Hand. Modernes Cargo entfernt bereits ungenutzte Einträge aus seinem globalen Cache während normaler Build- und Fetch-Befehle, und npm beschreibt seinen Cache als selbstheilend mit npm cache verify als Wartungsbefehl. Lassen Sie diese eingebauten Mechanismen laufen, statt Punkt-Ordner im Home-Verzeichnis rundheraus zu löschen. Entwickler-Caches leeren hat die werkzeugspezifischen Befehle.

Prüfen, ob Ihre Agent-CLI ihre eigenen Releases bereinigt, und im Zweifel davon ausgehen, dass sie es nicht tut. Zum Zeitpunkt dieses Artikels konnte ich weder in Codex noch in Claude Code eine dokumentierte Option oder Konfigurationseinstellung finden, die überholte Release-Binärdateien bereinigt, und die Anfrage bei Codex ist noch offen. Claude Codes cleanupPeriodDays bereinigt Sitzungsdaten, keine Versions-Binärdateien, hilft hier also nicht. Solange sich das nicht ändert, ist das eine wiederkehrende Aufgabe, und sie ist der wertvollste Punkt auf der Liste, weil sie im Takt zurückkommt, in dem Ihre Agenten Updates ausliefern.

Häufige Fragen

Wie viel Speicherplatz belegen KI-Coding-Tools tatsächlich?

Die Binärdateien selbst sind jeweils ein paar hundert Megabyte groß, aber entscheidend ist die Anhäufung. Auf der für diesen Artikel vermessenen Maschine hielten vier Agent-CLIs rund 3,5 GB in ihren Versionsverzeichnissen, davon nur 920 MB aktiv, die Sitzungsmitschnitte kamen auf etwa 14 GB, und ein einzelnes Rust-target/-Verzeichnis war 24 GB groß. Ihre Zahlen werden sich eher nach Sprache als nach Agent unterscheiden, führen Sie also lieber die beiden du-Befehle am Anfang dieses Artikels aus, als irgendeiner Zahl zu vertrauen, auch dieser hier nicht.

Ist es sicher, alte Claude-Code- oder Codex-Versionen zu löschen?

Ja, solange Sie zuerst den Launcher auflösen. Führen Sie readlink -f "$(command -v claude)" oder das Äquivalent für Ihre CLI aus, behalten Sie den ausgegebenen Pfad, und legen Sie die Geschwisterverzeichnisse in den Papierkorb. Sortieren Sie nicht nach Datum und behalten Sie nicht einfach das neueste, denn ein festgepinntes Downgrade und ein halb fertiges Update machen beide das neueste Verzeichnis zur falschen Wahl. Führen Sie die CLI nach dem Löschen und vor dem Leeren des Papierkorbs einmal aus.

Löscht ein Mac-Cleaner meinen Agent-Chat-Verlauf?

Manche schon, weil diese Dateien genau wie Logs aussehen. Das ist das spezifische Risiko in dieser Kategorie. Mole fasst ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects oder ~/.grok/sessions unabhängig vom Alter nie an. Bevor Sie irgendeinen Cleaner laufen lassen, prüfen Sie, ob diese Pfade in seiner Kandidatenliste auftauchen; zeigt Ihnen das Werkzeug die Liste nicht, bevor es handelt, ist das bereits die Antwort.

Verlangsamt das Leeren von Build-Caches irgendetwas?

Den nächsten Build, einmal, und danach nicht mehr. Der Zustand der inkrementellen Kompilierung existiert dafür, den zweiten Build schneller zu machen als den ersten, das Löschen kostet Sie also genau einen Kaltstart-Build pro Projekt. Das ist der ganze Nachteil, und deshalb gehört Build-Output in die Stufe „frei löschen“, während ein node_modules-Baum, der eine Registry-Anfrage braucht, dort nicht hingehört.

Was ist mit Ollama-Modellen und Hugging-Face-Caches?

Bewusst außerhalb des Rahmens hier. Diese Werkzeuge nutzen inhaltsadressierte Speicher, in denen sich zwei Modelle denselben Blob teilen können; von Hand gelöschte Dateien können daher ein Modell verwaisen lassen, das noch darauf verweist. Nutzen Sie den eigenen Entfernen-Befehl des jeweiligen Werkzeugs, das behandelt KI-Tool-Reste entfernen.

Wie es weitergeht

Nach Wiederherstellungskosten sortieren, den Launcher auflösen, bevor Sie ein Release löschen, die Mitschnitte in Ruhe lassen. War die größte Zeile in Ihrer Messung ein Paketspeicher, hat Entwickler-Caches leeren die werkzeugspezifischen Bereinigungsbefehle. War es Xcode, trennt Xcode-Speicher aufräumen die neu aufbaubaren Ordner von den Archiven, die Sie behalten. War es ein Modellspeicher, erklärt KI-Tool-Reste entfernen, warum das besitzende Werkzeug die Löschung übernehmen muss.