AI-codingtools op de Mac opruimen: caches, CLI's, transcripten

Een schijf die twee jaar comfortabel was kan binnen een paar maanden vollopen wanneer je elke dag coding-agents gebruikt. De agents zelf zijn klein. Wat veranderde is hoe vaak de machine compileert, hoe vaak een CLI zichzelf op schijf vervangt, en hoeveel van je eigen redenering nu in je thuismap als tekst staat. Bijna alle groei valt in drie categorieën, en die vragen drie verschillende beslissingen, omdat ze drie heel verschillende bedragen kosten om terug te krijgen.

Modelgewichten zijn de voor de hand liggende verdachte en meestal de verkeerde voor dit specifieke probleem. Ollama, LM Studio en Hugging Face houden content-addressed stores bij die alleen hun eigen tools veilig kunnen snoeien, en dat staat apart in resten van AI-tools verwijderen. Dit artikel gaat over wat AI-codingagents achterlaten terwijl je werkt.

Meet voordat je iets verwijdert

Twee opdrachten beantwoorden het grootste deel van de vraag. De eerste telt de thuismappen van de agents op:

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

De tweede vindt builduitvoer die verspreid staat over elk project dat je ooit hebt geopend. Vervang de wortels door waar jij code bewaart:

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 houdt find tegen om af te dalen in een map die al is gematcht, en dat telt hier: zonder die vlag loopt find elk bestand in een target/ van 24 GB door voordat die verdergaat. Op de Mac die ik mat terwijl ik dit schreef, waren de bovenste twee regels een Rust-target/ van 24 GB en een target/ van een Tauri-project van 9,8 GB, tegen node_modules-bomen van 134 MB tot 1,5 GB. In dit voorbeeld was de Rust-builduitvoer veel groter dan elk van de losse afhankelijkheidsmappen die werden genoemd.

Wil je dit liever als kaart dan als lijst zien, dan tekent de weergave Analyse van Mole dezelfde volumes als een treemap en kun je in de grootste rechthoek duiken, wat sneller is dan gokken welke wortel je aan find geeft.

Categorie één: builduitvoer, versterkt

Deze categorie is niet nieuw. Het volume wel. Een ontwikkelaar die met de hand werkt compileert een paar keer per dag. Een agent die een taak doorwerkt compileert na bijna elke bewerking, draait de tests, probeert een tweede aanpak, en compileert opnieuw. Caches die vroeger over maanden groeiden groeien nu over een middag, en mappen voor incrementele builds zijn ontworpen om schijf te ruilen voor snelheid.

Rust is meestal met ruime marge de grootste. Een map target/ bevat gecompileerde afhankelijkheden, staat van incrementele compilatie en uitvoer van buildscripts, apart bewaard per profiel, dus debug en release zijn twee volledige kopieën. cargo clean zonder opties "will delete the entire target directory". Bekijk het eerst:

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

cargo clean -p <package> ruimt alleen de genoemde pakketten op, en dat is het juiste gereedschap wanneer één lid van de workspace het probleem is.

JavaScript spreidt de uitvoer dunner. Naast node_modules zelf is er node_modules/.cache (gebruikt door bundlers en transpilers), .next voor Next.js-builds, en wat je toolchain ook als dist of build schrijft. Zoek specifiek de caches:

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

Python laat __pycache__ naast elk pakket dat het importeert. Stuk voor stuk klein, en er zijn er duizenden. Tel ze voordat je verwijdert, want dezelfde vorm van opdracht met rm -rf aan het eind is onverbiddelijk als een wortel verkeerd is:

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

Bytecode-caches worden bij de volgende import opnieuw gemaakt, helemaal zonder netwerk, dus dit is het veiligste om te verwijderen in het hele artikel.

Go houdt één globale buildcache bij in plaats van mappen per project. go env GOCACHE drukt de locatie af en go clean -cache "causes clean to remove the entire go build cache". go clean -testcache laat gecachte testresultaten verlopen zonder gecompileerde pakketten weg te gooien. Op mijn machine was de buildcache 183 MB tegen een modulecache van 38 MB, dus de buildkant is de moeite van het controleren waard ook wanneer de gedownloade modules klein zijn.

Xcode vraagt een eigen behandeling, want DerivedData, archieven, apparaatondersteuning en simulatorruntimes zijn vier soorten dingen met vier verschillende herstelkosten. De map DerivedData op deze Mac mat 9,3 GB. Xcode-opslag opruimen behandelt welke daarvan je kunt verwijderen en welke je bewaart voor symbolisatie. Gradle en Maven splitsen op dezelfde manier tussen mappen build/ per project en een globale store onder ~/.gradle of ~/.m2, en de globale kant hoort bij de andere registers in ontwikkelaarscaches wissen.

Categorie twee: vervangen CLI-versies

Dit is de categorie waar bijna niemand naar zoekt, en op een machine die meerdere agents draait is die vaak groter dan alle caches samen.

Agent-CLI's werken zichzelf bij door een complete nieuwe versie-release te downloaden en een launcher ernaar te laten wijzen. Elke release is zelfstandig, dus die deelt geen bestanden met de release ervoor. De pointer verschuift. De oude release blijft. Niets veegt die weg, dus het aantal groeit met één bij elke update, voor altijd.

De indelingen volgen één patroon met cosmetische verschillen:

• Codex bewaart ~/.codex/packages/standalone/releases/<version>-<arch>/, met een symlink current één niveau hoger die naar de live versie wijst.
• Claude Code bewaart ~/.local/share/claude/versions/<version>, waarbij elke vermelding een enkel uitvoerbaar bestand is in plaats van een map, en ~/.local/bin/claude een symlink is naar de live versie.
• Grok bewaart ~/.grok/downloads/grok-<version>-macos-<arch> als bestanden, met ~/.grok/bin/grok en ~/.grok/bin/agent die naar de huidige build wijzen.
• Cursor Agent bewaart ~/.local/share/cursor-agent/versions/<date>-<sha>/, met ~/.local/bin/cursor-agent als launcher.
• Cursor, de desktopapp, bewaart ook een eigen kopie van de agent in ~/Library/Application Support/Cursor/User/globalStorage/anysphere.cursor-agent-worker/agent-cli/.local/share/cursor-agent/versions/, met bin/cursor-agent in dezelfde map .local als launcher. Op de Mac die later werd gemeten had die zeven releases bewaard, 4,1 GB.
• GitHub Copilot CLI, geïnstalleerd via npm, vervangt zichzelf ter plekke, maar het installatie-script schrijft een versiepakket onder een prefix die standaard $HOME/.local is voor een gebruiker die geen root is. Mole controleert ~/.copilot/pkg/universal op dezelfde vorm.

Meet ze allemaal tegelijk:

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

Op de Mac die ik voor dit artikel gebruikte drukte dat vijf Codex-releases af tussen 262 MB en 310 MB, vijf binaire bestanden van Claude Code tussen 293 MB en 306 MB, twee Grok-builds, en twee versies van Cursor Agent. Ongeveer 3,5 GB in totaal, waarvan ongeveer 920 MB live was. Al het andere was een binair bestand dat al was vervangen. De eigen issuetracker van Codex heeft een open verzoek hiervoor, waarin de melder de groei meet op ongeveer 250 MB per update (openai/codex#22293).

Los de launcher op voordat je één map verwijdert

De verleidelijke kortere weg is sorteren op datum en de nieuwste houden. Doe dat niet. Twee gewone situaties breken die aanpak: je hebt bewust een oudere versie vastgezet na een regressie, of een update heeft de nieuwe map klaargezet voordat de pointer omsloeg. De live release verwijderen laat je achter met een launcher die naar niets wijst.

Vraag het de launcher. Die is een symlink, dus los die op:

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

Dat drukt het echte doel af, bijvoorbeeld ~/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin/bin/codex, en ls -l "$(command -v codex)" toont elke sprong in plaats van het eindantwoord. Wat terugkomt identificeert de versie van die launcher. Controleer voordat je een zuster in de prullenmand zet dat geen ander proces, geen update en geen installatie die gebruikt. Bewaar onzekere items en test de CLI voordat je de prullenmand leegt.

Categorie drie: werkstaat van de agent, en dat is geen rommel

De derde categorie is de categorie waarin een opschoner echte schade kan doen, omdat die er precies uitziet als de eerste twee.

Sessietranscripten, herinneringen, plannen en gegenereerde bijlagen staan onder ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects en ~/.grok/sessions. Het zijn JSONL-bestanden met een sessie-id als naam, met een tijdstempel, alleen-toevoegend, en ze stoppen nooit met groeien. Elke heuristiek die een algemene opschoner gebruikt zegt logbestand. Op de Mac die ik mat was ~/.codex/sessions 9,8 GB, ~/.claude/projects 2,7 GB over 2.362 transcriptbestanden, en ~/.grok/sessions 1,3 GB: een groot, verleidelijk getal aan bestanden die wegwerpbaar lijken.

Het zijn geen logs. Een transcript is het verslag van hoe een wijziging tot stand kwam: de aanpakken die zijn geprobeerd en verworpen, de beperking die er één uitsloot, de reden dat de uiteindelijke vorm is wat die is. Die redenering bestaat nergens anders. Het commitbericht legt vast wat veranderde, de code legt de overgebleven optie vast en niet de vier verworpen opties. Maanden stapelen zich stilletjes op, en je ontdekt de waarde de eerste keer dat je teruggaat om te vragen waarom iets zo is gebouwd.

Het grotere risico is geen opschoner van een derde partij. Claude Code levert een eigen bewaarveeg: cleanupPeriodDays staat standaard op 30 dagen, en bij het opstarten verwijdert die transcripten onder projects/, planbestanden, snapshots van vóór een bewerking in file-history/, en takenlijsten per sessie die ouder zijn dan dat. De referentie van de map .claude documenteert precies welke paden worden geveegd en welke voor onbepaalde tijd blijven. Wil je een jaar aan transcripten, verhoog dat getal dan nu in plaats van de standaard achteraf te ontdekken. Dezelfde pagina documenteert claude project purge voor het omgekeerde geval, wanneer je de staat van één project bewust weg wilt.

De scan van Opschonen in Mole raakt niets daarvan aan. Die vijf paden, plus ~/.claude/file-history, ~/.claude/plans, ~/.claude/tasks, ~/.codex/attachments en ~/.codex/generated_images, staan op de beschermingslijst op elke leeftijd. Er is geen leeftijdsgrens, geen uitzondering "ouder dan 90 dagen", geen instelling om er één aan te zetten. Een uitzondering op leeftijd was ooit voor deze paden gebouwd en dezelfde dag teruggedraaid, omdat een oud transcript geen verouderd transcript is.

Oude sessies krijgen wel een apart pad, een pad dat je zelf loopt. De verre maan op de pagina Opschonen opent AI-opschoning en -onderhoud, dat een bewaarvenster per tool houdt en de Codex- en Claude Code-sessies toont die daar voorbij zijn, plus Claude Code-sessies waarvan de projectmap weg is, elk met titel en datum, en er gaat niets weg tot je het aanvinkt. Een Codex-sessie wordt eerst naar de prullenmand gekopieerd en daarna verwijderd via de eigen opdracht van Codex, zodat de index heel blijft, en de afbeeldingen en notities die Codex ervoor maakte gaan mee naar de prullenmand. Een sessie die in de laatste 24 uur is gebruikt verschijnt nooit op de lijst, dus je kunt opruimen terwijl Codex en Claude Code openstaan, en herinneringen, plannen en skills staan daar ook op geen enkele lijst.

Onder de motorkap: sorteer op herstelkosten, niet op grootte

Dit is de regel die alle drie de categorieën beslisbaar maakt, en het is het enige in dit artikel dat het onthouden waard is. Rangschik elke kandidaat op wat het kost om terug te krijgen, niet op hoeveel gigabytes die toont.

Lokaal opnieuw te maken. Builduitvoer, staat van incrementele compilatie, bytecode-caches, DerivedData. De kosten van deze verwijderen zijn CPU-minuten op een machine waar je al bij zit, zonder netwerk wanneer de vereiste bronnen en afhankelijkheden blijven. Stop actieve builds en controleer dat de gekozen uitvoer opnieuw te maken is voordat je die verwijdert.

Duur om opnieuw op te bouwen. Pakketregisters, node_modules, CocoaPods, virtuele Python-omgevingen, mappen vendor, modelgewichten, iOS DeviceSupport. Deze opnieuw maken kan netwerktoegang vragen, de oorspronkelijke downloads of pakketversies, en een compatibele toolchain. De echte kosten zijn niet alleen minuten op een goede verbinding, het is of je überhaupt kunt werken in de trein. Bekijk deze één voor één.

Onvervangbaar. Chattranscripten, herinneringen van de agent, planbestanden, projectstaat, lokale fine-tunes. Geen hoeveelheid CPU of bandbreedte brengt deze terug. Ze horen nooit in een batch-verwijdering, en het horen geen dingen te zijn die je per ongeluk kunt selecteren.

De val is dat laag één en laag twee er identiek uitzien. target/ en node_modules/ zijn allebei grote mappen in een projectwortel, allebei vol afhankelijkheidsartefacten, allebei genoemd in .gitignore, allebei opnieuw gemaakt door één opdracht. Gesorteerd op grootte staan ze naast elkaar. cargo build kan target/ lokaal opnieuw maken wanneer de vereiste bronnen, afhankelijkheden en toolchain beschikbaar zijn. npm ci kan downloads uit het register nodig hebben en ook een geldig lockbestand. Elk van beide kan flink tijd kosten, afhankelijk van het project. Een niet-beschikbare afhankelijkheid kan de herbouw helemaal stoppen. Hun herstelkosten als identiek behandelen is een fout, en dat is waarom "verwijder de grootste mappen" slecht advies is, ook wanneer het de meeste ruimte vrijmaakt.

Dit doen in Mole

De handmatige route werkt en kost niets. Wat Mole toevoegt is dat alle drie de categorieën in één beoordeelde lijst aankomen met de laaggrens al toegepast, zodat jij niet degene bent die onthoudt welke puntmap de transcripten bevat.

Open het gereedschap Opschonen en start een scan. Scannen is gratis en heeft geen licentie nodig. Elke kandidaat komt binnen met het exacte pad, de eigenaar en de gemeten grootte, en er beweegt niets tot je de lijst goedkeurt. Alles met weinig zekerheid komt uitgevinkt binnen, zodat de standaardactie altijd de kleinere is. Caches worden standaard definitief verwijderd. Je kunt in Instellingen voor de prullenmand kiezen en bestanden terugzetten zolang ze daar liggen. Batchresultaten melden ook overgeslagen en mislukte items.

Voor de vervangen CLI-versies specifiek doet Mole de launcherresolutie die hierboven staat voor je. Die leest de launchersymlink van elke agent-CLI, lost die op naar de live release, en sluit die release uit van de kandidatenset, zodat een bewuste downgrade intact blijft in plaats van als oude versie te worden behandeld. Het gemeten geval achter dat gedrag is Codex: vijf releases van 1,2 GB met maar één live. De eigen kopie van Cursor in de desktopapp wordt op dezelfde manier behandeld, en een oude release kan weg terwijl Cursor openstaat, zolang geen proces die open heeft.

De Mole CLI is gratis, open source, en dekt dezelfde taak vanuit een shell met mo clean. Opdrachten zoals clean, uninstall en optimize ondersteunen --dry-run om hun acties te bekijken. Beide delen de door de gebruiker bewerkbare uitsluitingslijst op ~/.config/mole/whitelist en één bewerkingslog op ~/Library/Logs/mole/operations.log, en alles draait lokaal, zonder upload en zonder telemetrie.

Het is de moeite waard om het rechttoe te zeggen: Mole is geen back-up, geen reactie op malware, en geen vervanging voor een uninstaller van de leverancier bij software die stuurprogramma's of systeemextensies meelevert. Die verwijdert zelf nooit modelbestanden, en gewoon Opschonen raakt nooit AI-chatgeschiedenis aan: oude sessies en Ollama-modellen die een maand ongebruikt zijn vertrekken alleen via AI-opschoning en -onderhoud, één selectievakje tegelijk, en de eigen opdracht van Ollama verwijdert de modellen. Andere modellen blijven bij de tools die eigenaar zijn.

Voorkomen dat het terugkomt

Drie configuratiewijzigingen dekken het grootste deel van de hergroei.

Laat Rust naar één buildmap wijzen. CARGO_TARGET_DIR zet de "location of where to place all generated artifacts", zodat elk project in één boom schrijft die je op één plek kunt meten en opruimen. De afweging is echt: Cargo vergrendelt de buildmap, dus twee projecten die één targetmap delen bouwen om de beurt in plaats van parallel. Draai je routinematig gelijktijdige builds, houd ze dan apart en plan een veeg in plaats daarvan.

Snoei de globale stores op een schema, niet met de hand. Modern Cargo verwijdert al ongebruikte vermeldingen uit de globale cache tijdens gewone build- en fetch-opdrachten, en npm beschrijft de cache als zelfherstellend met npm cache verify als onderhoudsopdracht. Laat die beleidsregels lopen in plaats van puntmappen in de thuismap ronduit te verwijderen. Ontwikkelaarscaches wissen heeft de opdrachten per tool.

Controleer of je agent-CLI de eigen releases snoeit, en neem aan van niet. Op het moment van schrijven kon ik geen gedocumenteerde vlag of configuratiesleutel vinden in Codex of Claude Code die vervangen releasebinaries snoeit, en het verzoek van Codex staat nog open. cleanupPeriodDays van Claude Code veegt sessiegegevens, geen versiebinaries, dus dat helpt hier niet. Tot dat verandert is dit een terugkerende taak, en het is het item met de hoogste waarde op de lijst omdat het terugkomt in het tempo waarin je agents updates uitbrengen.

Veelgestelde vragen

Hoeveel schijf gebruiken AI-codingtools echt?

De binaries zijn elk een paar honderd megabyte, maar de ophoping is wat telt. Op de machine die voor dit artikel is gemeten hielden vier agent-CLI's ongeveer 3,5 GB vast in hun versiemappen waarvan maar 920 MB live was, sessietranscripten kwamen op ongeveer 14 GB, en één map target/ van Rust was 24 GB. Jouw getallen verschillen meer per taal dan per agent, dus draai de twee du-opdrachten bovenaan dit artikel in plaats van iemands getal te vertrouwen, inclusief dit getal.

Is het veilig om oude versies van Claude Code of Codex te verwijderen?

Ja, zolang je eerst de launcher oplost. Draai readlink -f "$(command -v claude)" of het equivalent voor jouw CLI, en bewaar het afgedrukte doel. Controleer dat geen ander proces, geen update en geen installatie een zuster nodig heeft voordat je die in de prullenmand zet. Sorteren op datum is onbetrouwbaar: een vastgezette downgrade of een niet-afgeronde update kan de nieuwste map de verkeerde maken. Draai de CLI één keer na het verwijderen en voordat je de prullenmand leegt.

Verwijdert een Mac-opschoner mijn chatgeschiedenis van de agent?

Sommige wel, omdat die bestanden er precies uitzien als logs. Dat is het specifieke risico in deze categorie. Gewoon Opschonen van Mole raakt ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects en ~/.grok/sessions op geen enkele leeftijd aan. Controleer voordat je een opschoner draait of die paden in de kandidatenlijst staan, en als de tool je de lijst niet toont voordat die handelt, is dat je antwoord. De aparte pagina AI-opschoning en -onderhoud kan Codex- en Claude Code-sessies tonen die voorbij het bewaarvenster van elke tool zijn, plus Claude Code-sessies waarvan het project weg is, uitgevinkt voor individuele controle.

Vertraagt het wissen van buildcaches iets?

Verwacht een tragere eerste build terwijl de cache opnieuw wordt opgebouwd. Incrementele compilatie helpt de volgende build sneller te maken, maar de hersteltijd hangt af van de toolchain en het project. Stop actieve builds en houd de bronnen en afhankelijkheden die nodig zijn om de uitvoer opnieuw te maken voordat je die verwijdert. node_modules opnieuw maken kan ook toegang tot het pakketregister vragen.

En Ollama-modellen en Hugging Face-caches?

Buiten de scope hier, en bewust zo. Die tools gebruiken content-addressed stores waarin twee modellen dezelfde blob kunnen delen, dus bestanden met de hand verwijderen kan een model wees maken dat er nog naar verwijst. Gebruik de eigen verwijderopdracht van elke tool, wat staat in resten van AI-tools verwijderen. Ollama-modellen zijn de enige uitzondering die Mole afhandelt: AI-opschoning en -onderhoud toont de modellen die een maand ongebruikt zijn en verwijdert de modellen die je aanvinkt met de eigen ollama rm van Ollama, zodat blobs die een ander model nog gebruikt blijven.

Waar je daarna heen gaat

Sorteer op herstelkosten, los de launcher op voordat je een release verwijdert, laat de transcripten met rust. Was de grootste regel in je meting een pakketstore, dan heeft ontwikkelaarscaches wissen de snoei-opdrachten per tool. Was het Xcode, dan scheidt Xcode-opslag opruimen de opnieuw op te bouwen mappen van de archieven die je bewaart. Was het een modelstore, dan legt resten van AI-tools verwijderen uit waarom de tool die eigenaar is het verwijderen moet doen. Verwijder je een desktopapp helemaal, dan houden de gidsen om Claude te verwijderen en Cursor te verwijderen de ~/.claude van Claude Code en de Cursor Agent CLI, die apart installeert, buiten de verwijdering.