# AI-codingtools op de Mac opruimen: caches, CLI's, transcripten > Meet builduitvoer, oude CLI-installaties en chattranscripten apart, en bekijk daarna wat nog in gebruik is voordat je verwijdert. Published: 2026-08-21 | Updated: 2026-10-18 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](https://mole.fit/nl/blog/how-to-remove-ai-tool-leftovers-mac). 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](https://mole.fit/) 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 ` 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](https://mole.fit/nl/blog/how-to-clean-up-xcode-mac) 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](https://mole.fit/nl/blog/how-to-clear-dev-caches-mac). ## 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/-/`, met een symlink `current` één niveau hoger die naar de live versie wijst. - **Claude Code** bewaart `~/.local/share/claude/versions/`, 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--macos-` als bestanden, met `~/.grok/bin/grok` en `~/.grok/bin/agent` die naar de huidige build wijzen. - **Cursor Agent** bewaart `~/.local/share/cursor-agent/versions/-/`, 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](https://github.com/openai/codex/issues/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.
Een launchersymlink op het PATH die via een current-pointer uitkomt in één releasemap. Andere releasemappen vragen aparte controles op actief gebruik voordat ze weggaan.
De launcher, niet het tijdstip, wijst de live release aan. Een vastgezette downgrade of een half afgeronde update maken de nieuwste map allebei het verkeerde antwoord.
## 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](https://code.claude.com/docs/en/claude-directory) 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](https://mole.fit/) 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.
Drie lagen gerangschikt op herstelkosten, met target en node_modules getoond als visueel identieke projectmappen die in verschillende lagen landen omdat de ene opnieuw bouwt vanuit lokale bron en de andere een register nodig heeft.
Grootte rangschikt de kandidaten in de verkeerde volgorde. Twee mappen die er hetzelfde uitzien in een projectwortel kunnen een hele werkdag schelen in wat het kost om ze terug te zetten.
## Dit doen in Mole De handmatige route werkt en kost niets. Wat [Mole](https://mole.fit/) 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](https://github.com/tw93/Mole) 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.
De controle van Opschonen in Mole met cachecategorieën en hun groottes, elk met een selectievakje, en een knop om de geselecteerde 5,14 GB definitief op te schonen.
Ontdekken en verwijderen zijn twee aparte stappen. De controle toont wat de scan per categorie vond, en er gaat niets weg tot je het bevestigt.
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](https://mole.fit/nl/blog/how-to-clear-dev-caches-mac) 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](https://mole.fit/nl/blog/how-to-remove-ai-tool-leftovers-mac). 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](https://mole.fit/nl/blog/how-to-clear-dev-caches-mac) de snoei-opdrachten per tool. Was het Xcode, dan scheidt [Xcode-opslag opruimen](https://mole.fit/nl/blog/how-to-clean-up-xcode-mac) de opnieuw op te bouwen mappen van de archieven die je bewaart. Was het een modelstore, dan legt [resten van AI-tools verwijderen](https://mole.fit/nl/blog/how-to-remove-ai-tool-leftovers-mac) uit waarom de tool die eigenaar is het verwijderen moet doen. Verwijder je een desktopapp helemaal, dan houden de gidsen om [Claude te verwijderen](https://mole.fit/tested-apps/claude) en [Cursor te verwijderen](https://mole.fit/tested-apps/cursor) de `~/.claude` van Claude Code en de Cursor Agent CLI, die apart installeert, buiten de verwijdering. --- Canonical HTML page: https://mole.fit/nl/blog/how-to-clean-up-ai-coding-tools-mac Blog index for agents: https://mole.fit/nl/blog/llms.txt Site index for agents: https://mole.fit/llms.txt