# So räumen Sie nach KI-Coding-Tools auf dem Mac auf > Coding-Agents vervielfachen Build-Ausgaben, behalten jede überholte CLI-Version und speichern monatelange Mitschnitte, die wie Logs aussehen. Messen Sie jeden einzelnen und sortieren Sie danach, was seine Wiederherstellung kostet, nicht nach der Größe. Published: 2026-08-21 | Updated: 2026-08-22 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](https://mole.fit/de/blog/how-to-remove-ai-tool-leftovers-mac). 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](https://mole.fit/) 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 ` 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](https://mole.fit/de/blog/how-to-clean-up-xcode-mac) 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](https://mole.fit/de/blog/how-to-clear-dev-caches-mac). ## 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/-/` ab, mit einem `current`-Symlink eine Ebene darüber, der auf das aktive Release zeigt. - **Claude Code** legt unter `~/.local/share/claude/versions/` 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--macos-` 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/-/` 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](https://github.com/openai/codex/issues/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.
Ein Launcher-Symlink im PATH löst über einen current-Zeiger in ein Release-Verzeichnis auf, während die danebenliegenden Geschwister-Release-Verzeichnisse unreferenziert und gefahrlos entfernbar sind.
Der Launcher, nicht der Zeitstempel, identifiziert das aktive Release. Ein festgepinntes Downgrade und ein halb fertiges Update machen beide das neueste Verzeichnis zur falschen Antwort.
## 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](https://code.claude.com/docs/en/claude-directory) 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](https://mole.fit/) 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.
Drei Stufen, nach Wiederherstellungskosten geordnet, mit target und node_modules als optisch identische Projektverzeichnisse, die in unterschiedlichen Stufen landen, weil das eine aus lokalem Quellcode neu baut und das andere eine Registry braucht.
Größe ordnet die Kandidaten in der falschen Reihenfolge. Zwei Verzeichnisse, die an der Projektwurzel gleich aussehen, können sich um einen ganzen Arbeitstag unterscheiden, was es kostet, sie wiederherzustellen.
## So macht das Mole Der manuelle Weg funktioniert und kostet nichts. Was [Mole](https://mole.fit/) 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](https://github.com/tw93/Mole) 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.
Moles Clean-Ansicht zeigt eine geprüfte Bereinigung mit jedem Kandidaten nach Pfad und Größe aufgelistet, und den nach der Operation tatsächlich zurückgewonnenen Speicherplatz.
Entdecken und Entfernen sind zwei getrennte Schritte. Der Abschlussbildschirm meldet, was tatsächlich zurückgewonnen wurde, nicht was vor dem Scan geschätzt worden war.
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](https://mole.fit/de/blog/how-to-clear-dev-caches-mac) 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](https://mole.fit/de/blog/how-to-remove-ai-tool-leftovers-mac). ## 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](https://mole.fit/de/blog/how-to-clear-dev-caches-mac) die werkzeugspezifischen Bereinigungsbefehle. War es Xcode, trennt [Xcode-Speicher aufräumen](https://mole.fit/de/blog/how-to-clean-up-xcode-mac) die neu aufbaubaren Ordner von den Archiven, die Sie behalten. War es ein Modellspeicher, erklärt [KI-Tool-Reste entfernen](https://mole.fit/de/blog/how-to-remove-ai-tool-leftovers-mac), warum das besitzende Werkzeug die Löschung übernehmen muss. --- Canonical HTML page: https://mole.fit/de/blog/how-to-clean-up-ai-coding-tools-mac Blog index for agents: https://mole.fit/de/blog/llms.txt Site index for agents: https://mole.fit/llms.txt