# AI Mac-opschoners: wat een model wel en niet mag beslissen

> Rangschikken en toeschrijven mogen probabilistisch zijn, de verwijderbeslissing niet. Hoe cc-cleaner, DevCleaner, agentskills en Mole die lijn trekken, en welke bij je schijf past.

Published: 2026-08-20 | Updated: 2026-10-18

"AI Mac-opschoner" wijst naar twee verschillende producten. Het ene is een opschoonapp met ergens een model
erin, verkocht op de intelligentie van de aanbevelingen. Het andere is een tool
om de schijf terug te winnen die Claude Code, Cursor, Ollama en hun caches het afgelopen
jaar stilletjes hebben ingenomen. Het tweede is wat de meeste mensen die die zin in 2026 typen willen.
Het eerste is het waard om eerst te beantwoorden, want het antwoord bepaalt hoeveel je alles
in de tweede groep vertrouwt.

## Deel één: wat het model echt beslist

Een opschoner die AI adverteert doet een bewering over één stap in een pijplijn die er minstens
vier heeft:

1. **Opsommen.** Loop de schijf door en meet die. Werk in de vorm van `du`, zonder oordeel.
2. **Toeschrijven.** Beslis welke app of toolchain eigenaar is van elk pad.
3. **Rangschikken en uitleggen.** Beslis welke twaalf van vierduizend kandidaten een blik verdienen,
   en zeg in één zin wat elk is.
4. **Beslissen en verwijderen.** Beslis wat veilig te verwijderen is, en verwijder het daarna.

Stappen 2 en 3 zijn echt vaag, en een model helpt daar echt. Stap 4 is een ander
soort probleem, en een model is het verkeerde instrument daarvoor. Bijna elk argument over AI-opschoners is eigenlijk een argument over welke stap de leverancier bedoelt.

### Waar een model zijn plek verdient

Toeschrijving is het eerlijke moeilijke geval. Stel dat je
`~/Library/Application Support/Foo Labs` vindt met 3 GB en geen app met de naam Foo Labs op de
schijf. Het bewijs is zwak en verspreid: fragmenten van bundle-identifiers in de eigen plists van de map,
een bijpassend voorvoegsel in `~/Library/HTTPStorages`, een bundel `.savedState` onder
`~/Library/Saved Application State`, een installatiebewijs in `/var/db/receipts`. Naam-gelijkheid faalt meteen, omdat de leverancier op de ene plek `Foo Labs` schrijft en
op de andere `com.foolabs.editor`, en een met de hand geschreven catalogus dekt de bovenste paar honderd
apps en valt daarna van een klif. Dit is precies de vorm waarin een model een regel verslaat: veel zwakke
signalen, geen beslissend signaal, een lange staart die niemand af zal catalogiseren.

Rangschikken heeft dezelfde vorm: een scan die 4.000 paden en 60 GB teruggeeft is een tweede probleem, geen
resultaat. Uitleg is nog makkelijker, want
`~/Library/Caches/com.apple.nsurlsessiond` omzetten in een gewone zin is vertaling. Een tool
die een model voor die drie taken gebruikt, en dat zegt, adverteert een echte functie.

### Waarom de laatste poort deterministisch moet zijn

De verwijderbeslissing heeft drie eigenschappen die een model niet kan leveren.

**Determinisme.** Dezelfde schijf, dezelfde versie, hetzelfde antwoord, elke keer. Temperatuur nul koopt
dit niet, want de prompt draagt de inhoud van jouw machine: installeer nog één app, de
bestandslijst schuift, en de tokens waar de beslissing aan hangt schuiven mee. Een veiligheidsregel die
op jouw Mac geldt maar niet op die van je collega is geen veiligheidsregel.

**Controleerbaarheid van tevoren.** Een beschermingslijst is een verzameling padvoorvoegsels, in
een minuut volledig te lezen en te diffen tussen twee releases. Gewichten plus een prompt zijn niet te lezen als
een lijst van wat geweigerd wordt, dus niets toont je de grens voordat je die overschrijdt.

**Controleerbaarheid achteraf.** Wanneer een deterministische regel het verkeerde verwijdert krijg je
een reproduceerbare bug: hier is het pad, hier is de regel die het toestond, hier is de test
die nu faalt. Doet een model het, dan is het artefact een transcript, de reparatie een prompt-bewerking, en het effect van die bewerking op elk ander geval is ongemeten.

De faalwijzen zijn ook asymmetrisch. Een slechte rangschikking kost een scroll. Een slechte verwijdering van
`~/.claude/projects` kost elk transcript dat je hebt. Het kader is dus niet "AI goed, AI
slecht". Het is een splitsing midden door de pijplijn: probabilistisch waar ernaast zitten
aandacht kost, deterministisch waar ernaast zitten gegevens kost.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/cleaner-decision-halves.webp" width="1360" height="454" loading="lazy" alt="Een opruimpijplijn in tweeën gesplitst: opsommen, toeschrijven, rangschikken en uitleggen aan de probabilistische kant waar een fout antwoord aandacht kost, en de beschermingslijst plus de verwijderbeslissing aan de deterministische kant waar een fout antwoord gegevens kost.">
  <figcaption>De splitsing is niet tussen slimme en domme tools. Die is tussen de helft van de pijplijn waar ernaast zitten een scroll verspilt en de helft waar ernaast zitten een bestand verliest.</figcaption>
</figure>

### Aan welke kant Mole staat

[Mole](https://mole.fit/) levert geen model en draait geen inferentie. Bij gewoon Opschonen wordt of een pad een verwijder-kandidaat kan worden beslist door een vaste reeks geblokkeerde relatieve voorvoegsels die in de app is gecompileerd,
met vermeldingen als `.ollama/models`, `.lmstudio/models`, `.cache/huggingface`,
`.cache/torch`, `.claude/projects`, `.codex/sessions`, `.grok/sessions` en
`Library/Caches/com.apple.e5rt.e5bundlecache`. De helft die jij kunt bewerken is een gewoon tekstbestand
dat je kunt lezen met `cat ~/.config/mole/whitelist`. De gratis
[Mole CLI](https://github.com/tw93/Mole) is open source onder GPL-3.0. Die deelt de
door de gebruiker bewerkbare whitelist met de app maar heeft eigen ingebouwde controles, die je kunt inspecteren.

Die laatste vermelding is het argument in het klein. `com.apple.e5rt.e5bundlecache` staat in
`~/Library/Caches` en het woord in de naam is "cache", dus elke heuristiek ter wereld
deelt die in als wegwerpbaar. Die bevat gecompileerde modellen van de Apple Neural Engine, en die wissen
terwijl een app modellen geladen heeft breekt herkenningsaanroepen tot de machine herstart. Die is
beschermd omdat iemand die fout raakte en de regel schreef.

De praktische test voor elke tool hier is dus één vraag: welke van de vier stappen voert het
model uit? Opsommen, toeschrijven, rangschikken en uitleggen zijn geloofwaardige antwoorden. "Het
beslist wat veilig te verwijderen is" is een antwoord om op te volgen door de lijst te vragen, en als
er geen lijst is, is er niets te controleren.

De meeste van deze grenzen zijn niet op een whiteboard bedacht. Iemand liep erop
op de eigen Mac, en de regel kwam later. Toen dit artikel werd geschreven had de
[GitHub-repository van Mole CLI](https://github.com/tw93/Mole) 145 bijdragers en 987
issues, waarvan 984 gesloten en 3 nog open. Dat gesloten aantal is alleen de volgstaat van GitHub,
geen bewering dat 984 bugs zijn gerepareerd, maar het laat een lang spoor achter van waar het probleem vandaan
kwam, waarom de regel veranderde en wat hetzelfde geval de volgende keer moet blokkeren.

Die getallen bewijzen niet dat elke Mac is getest. macOS en de apps blijven veranderen hoe
ze gegevens opslaan, en geen enkele machine kan voor elke andere machine staan. Wat ze laten zien is
dat de opruimgrens van Mole voortdurend wordt uitgedaagd op echte computers, verfijnd en terug
in tests gezet, in plaats van te rusten op een belofte om "voorzichtig te zijn".

Mole CLI en Mole voor Mac zijn niet hetzelfde verwijderprogramma. Het opdrachtregelgereedschap is gratis
en open source, voor mensen die een `--dry-run` willen lezen en de scope zelf
willen beslissen. De Mac-app heeft een eigen scanner en verwijderketen, met een kandidatenset die
hetzelfde of smaller is. Mappen als `node_modules`, `Pods` en `venv` hebben een netwerk-verbinding en de juiste afhankelijkheden nodig om opnieuw te bouwen. Ze zijn beschikbaar voor een terminalgebruiker om
te inspecteren, maar Mole voor Mac zet ze niet in een gewone opruimlijst.

De regels beginnen te werken voordat een kandidatenlijst het scherm bereikt. Systeemmappen,
sleutelhangers, Mail, Berichten, foto's, inhoud van cloudschijven, privacyrechten, inlogonderdelen en
achtergrondtaken worden geen kandidaten omdat ze groot zijn of toevallig onder een
map met de naam Cache staan. Bij gewoon Opschonen geldt hetzelfde voor transcripten van Claude, Codex en andere AI-tools,
plannen, herinneringen en lokale modellen. Mole wijst alleen beoordeelde cachebladeren aan, niet een hele
map voor applicatieondersteuning. Kan die niet uitleggen wat een map bevat, dan is de standaard
die met rust laten.

De laatste stap is waar het verschil telt. Een pad dat tijdens een scan veilig leek kan
minuten later onveilig zijn: een app kan zijn gestart, een build kan zijn begonnen, of een symbolische
koppeling kan ergens anders naartoe hebben geleid. Vóór verwijdering controleert Mole het oorspronkelijke pad, beschermde
locaties, de gebruikerswhitelist en de identiteit van het object opnieuw. Die controleert ook dat de
app of buildtool die eigenaar is die niet gebruikt. Onzekerheid levert een overslaan op, geen groter getal voor "opgeschoond".

Je kunt het gevolg van elke keuze nog zien. De controlelijst draagt een pad, een eigenaar en een
grootte. Een onzeker item kan ongeselecteerd blijven of worden gemarkeerd als Schoon dit nooit op. App-verwijderingen gaan naar de
prullenmand. Caches verwijderen standaard direct om ruimte terug te winnen, maar kunnen zo worden ingesteld dat ze naar de
prullenmand gaan. Het resultaat scheidt opgeschoonde, in de prullenmand gezette, overgeslagen en mislukte items, en een lokaal log
legt vast wat er echt gebeurde.

AI kan een map omzetten in een uitleg in gewone taal en helpen een onbekende
toolchain te traceren. Mole doet de andere helft: die aanwijzingen omzetten in een verwijderregel die niet
verdwijnt omdat één antwoord, één dubbelzinnige mapnaam of één andere Mac verandert.
Die probeert niet alles te verwijderen wat wegwerpbaar zou kunnen zijn. Die probeert elke
verwijdering uitlegbaar te maken, en het item te houden wanneer die niet zeker kan zijn.

## Deel twee: tools om op te ruimen na AI-tools

Voor opruimen na AI-tools splitst de voetafdruk in vier soorten gegevens met vier
verschillende regels, en die door elkaar halen is waar ongelukken gebeuren:

- **Toolcaches en logs.** `~/Library/Caches/claude-cli-nodejs`, Electron-caches van Cursor,
  telemetrie en debugmappen onder `~/.claude`. Opnieuw te maken en saai.
- **Transcripten en projectstaat.** `~/.claude/projects`, `~/.codex/sessions`,
  `~/.grok/sessions`. Vaak de grootste verrassing in een scan, en onvervangbaar.
- **Oude CLI-versies.** Agent-CLI's die zichzelf bijwerken kunnen eerdere releases achterlaten. Als
  voorbeeld, als elke kopie ongeveer 300 MB inneemt en je bevestigt dat maar één van de vijf nog nodig is,
  dan zijn de andere vier ongeveer 1,2 GB. Controleer launchers, draaiende processen en vastgezette
  versies voordat je beslist welke kopieën weggaan.
- **Modelgewichten.** `~/.ollama/models`, `~/.cache/huggingface/hub`, de modelmap van
  LM Studio. Veruit de grootste, in eigendom van de tool die ze downloadde.

Meet voordat je een tool kiest:

```
du -sh ~/.claude ~/.codex ~/.ollama/models ~/.cache/huggingface 2>/dev/null | sort -h
```

### Mole, voor een beoordeelde veeg die deze paden al kent

Het gereedschap Opschonen scant eerst en toont een resultaat dat je bekijkt voordat er iets beweegt. Elke
kandidatenrij draagt het exacte pad, de eigenaar en de grootte, en alles waar de scanner niet
zeker over is komt uitgevinkt binnen zodat de standaardklik de kleinere actie is. App-verwijderingen
gaan naar de prullenmand. Caches verwijderen standaard direct om ruimte terug te winnen, maar kunnen zo worden ingesteld dat ze naar de
prullenmand gaan. Opruimacties worden lokaal vastgelegd in `~/Library/Logs/mole/operations.log`. Het
log onderscheidt verplaatsingen naar de prullenmand van definitieve verwijdering.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/mole-clean-review.webp" width="2584" height="1741" loading="lazy" alt="De controle van Opschonen in Mole met cachecategorieën en hun groottes, elk met een selectievakje, en een knop Definitief opschonen voor de geselecteerde 5,14 GB.">
  <figcaption>De scan is klaar voordat het controlescherm verschijnt, dus je kiest nooit items uit een half opgebouwde lijst.</figcaption>
</figure>

Twee gedragingen tellen specifiek voor AI-tooling. Oude versiemappen van agent-CLI's worden
aangeboden na controle van het launcherdoel, niet alleen door versienummers te vergelijken. Dat doel
wijst één actief pad aan. Controleer vóór het verwijderen van andere kopieën op draaiende processen,
updates en vastgezette installaties die ze nog nodig hebben. Bewaar alles wat onzeker is. Verwijderen
controleert eigendom in plaats van alleen op namen te matchen, zodat
het verwijderen van één app van een leverancier niet de gedeelde bovenliggende map `Application Support` aanbiedt die een
nog geïnstalleerde zusterapp bezit.

Om de taak te draaien: open Opschonen, laat de scan afmaken, vouw de groepen open die groot lijken, vink
uit wat je wilt houden, schoon daarna op en controleer de vrijgekomen ruimte. Scannen is gratis en elk
betaald gereedschap draait twee keer gratis, dus de hele controle is te verifiëren voordat je beslist of
$19 het waard is.

### De Mole CLI, wanneer je liever in de terminal blijft

Een apart gratis product, open source onder GPL-3.0, geïnstalleerd met `brew install mole`.
Bekijk eerst, altijd:

```
mo clean --dry-run
mo purge --dry-run
```

`mo clean` behandelt caches en logs, `mo purge` richt zich op oude buildartefacten van projecten, en
clean, uninstall en optimize ondersteunen `--dry-run` zodat je hun acties kunt bekijken. Die deelt
de gebruikerswhitelist en de locatie van het bewerkingslog met de Mac-app. Eén verschil voordat je de
vlag weglaat: cache opruimen via de CLI verwijdert bestanden definitief, terwijl verwijderen en het wegnemen van resten
nog naar de prullenmand gaan.

### cc-cleaner, de open source terminaloptie die voor dit probleem is gebouwd

[cc-cleaner](https://github.com/elexingyu/cc-cleaner) heeft een MIT-licentie, Python 3.10 en
later, te installeren met `pipx install cc-cleaner`. Die levert 22 opschoners inclusief Claude
Code, npm, uv, cargo, Docker, Playwright, browsercaches, en een groep AI/ML-modellen die
Hugging Face, PyTorch, Whisper en Ollama dekt. `cc-cleaner status` drukt een groottetabel af,
`cc-cleaner clean` opent een interactieve kiezer, `-n` is een dry run.

Het risicomodel is expliciet: Safe-items worden standaard opgeschoond terwijl Moderate- en Dangerous-items
`--force` vragen, en de README zet "conversation transcripts, shared stores" in de
laag Moderate. De bron vertelt de rest. De Ollama-opschoner verwijdert het geheel van
`~/.ollama/models` als één map, de Hugging Face-opschoner doet hetzelfde met
`~/.cache/huggingface/hub` en `datasets`, en de Claude-opschoner biedt de transcripten `*.jsonl`
onder `~/.claude/projects` aan. Verwijderen is `shutil.rmtree` en `Path.unlink`, dus
niets komt in de prullenmand. De veiligheidslaag is een bevroren set verboden systeempaden plus
de eis dat elk doel onder je thuismap staat: een deterministische lijst die een mens
schreef, precies zoals het hoort. Het verschil is waar de lijn ligt, niet de strengheid.
cc-cleaner zet modelstores en transcripten achter een vlag. Gewoon Opschonen in Mole weigert ze.

### DevCleaner, als je een menubalkapp wilt voor hetzelfde terrein

[DevCleaner](https://devcleaner.app) is een menubalkhulpprogramma voor macOS 14 en nieuwer, nu 1.9.0,
dat 23 ecosystemen dekt van Xcode DerivedData en Gradle tot npm en Docker, met eigen
scanners voor Claude, ChatGPT, Cursor, Ollama en LM Studio. Safe-items worden standaard
verwijderd, Warning-items zijn "jouw keuze", Danger-items zijn nooit vooraf geselecteerd, en die houdt een
harde weigerlijst voor inloggegevens en sessiebestanden plus een waarschuwing voordat die de caches van een draaiende
app aanraakt. De kernopschoning is gratis en Pro wordt verkocht als eenmalige aankoop of een jaarlijks
abonnement. Controleer de huidige getallen op de pagina van de leverancier. De site zegt niet of
verwijderingen naar de prullenmand gaan, en dat is wat je vóór een eerste run wilt vragen.

MacPaw levert ook een CleanMyMac CLI als publieke bèta, via een Homebrew-cask, gericht op dezelfde
artefacten. Die is propriëtair, de repository is een issuetracker in plaats van bron, en het
gedrag verandert expliciet nog, dus lees wat de bevestigingsstap je toont in plaats van
een gepubliceerde beschrijving.

### Een agent op je eigen schijf richten

De laatste route is opruimtools overslaan en Claude Code of een vergelijkbare agent vragen de
schijf direct op te schonen, eventueel via een van de gepubliceerde opruimskills. Het voordeel is
echt en niets anders hier heeft het: een agent kan redeneren over een indeling die niemand heeft
gecatalogiseerd, of dat nu een framework is dat vorige maand uitkwam, een privé-toolchain, of een thuis-map die alleen jij zo indeelt.

De beoordeling moet even rechttoe zijn. De shellopdrachten worden gegenereerd op het moment van inferentie
tegen je echte bestandssysteem, dus wat draait is door niemand beoordeeld voordat het draaide.
Er is geen dry run tenzij je die eist. De explosieradius is je thuismap, en
`rm -rf` samengesteld uit een variabele die leeg bleek is een faalwijze met een lange
geschiedenis. Deel één geldt met het vangnet weg: de beslissing is probabilistisch en
rechtstreeks aan de laatste poort gekoppeld.

Vier vangrails kosten bijna niets:

- **Laat die een tool met een voorbeeldsvlag aansturen in plaats van zelf verwijderingen samen te stellen.** Eén
  publieke skill voor Claude Code wikkelt de CLI `mo` en maakt `mo clean --dry-run` verplicht
  vóór `mo clean`, drukt de volledige dry-run-uitvoer af, en vraagt een getypte bevestiging. De
  agent kiest het doel, een deterministische tool voert de verwijdering uit.
- **Keur `rm` nooit vooraf goed in je rechteninstellingen.** Keur elke verwijderopdracht
  apart goed, en lees het pad in plaats van de samenvatting ervan.
- **Maak de prullenmand de standaard.** Gebruik de Finder of een tool die de prullenmand kent, zoals `trash` van Homebrew.
  Bestanden die nog in de prullenmand staan zijn meestal terug te zetten, maar dit is geen back-up.
  Een gewone `mv` naar `~/.Trash` is niet gelijkwaardig: naambotsingen kunnen bestanden overschrijven.
- **Begrens de werkset.** Wijs die op één map, en vraag `du -sh` ervoor en
  `df -h` erna zodat de geclaimde teruggave wordt gemeten in plaats van geschat.

### Modelstores horen bij de tool die ze downloadde

Geen algemene opschoner hoort hier je instrument te zijn, ook de bovenstaande niet. Ollama en
Hugging Face houden allebei content-addressed stores bij waarin modellen blobs delen, dus alleen de tool die eigenaar is
weet welke blob nog wordt gebruikt. Gebruik `ollama ls` en `ollama rm <model>`, en
`hf cache ls` met `hf cache rm model/<repo> --dry-run`. Waarom blobbestanden met de hand verwijderen
een model wees maakt staat in
[resten van AI-tools verwijderen](https://mole.fit/nl/blog/how-to-remove-ai-tool-leftovers-mac).

## Hoe ze zich verhouden

| Tool | Beslist deterministisch | Toont paden vooraf | Terug te halen | Beschermt modelstores en chatgeschiedenis | Kosten |
|---|---|---|---|---|---|
| Mole voor Mac | Vaste lijst van geblokkeerde voorvoegsels plus gebruikerswhitelist | Ja, pad, eigenaar en grootte per rij | App-verwijderingen gaan naar de prullenmand; caches verwijderen standaard, instelbaar naar de prullenmand | Ja, nooit kandidaten | $19 eenmalig, twee Macs, gratis updates |
| Mole CLI | Ingebouwde controles plus de gedeelde gebruikerswhitelist | Ja, `--dry-run` voor clean, uninstall en optimize | Verwijderen naar de prullenmand, cache opruimen definitief | Ingebouwde uitsluitingen plus de gebruikerswhitelist | Gratis, GPL-3.0 |
| cc-cleaner | Bevroren set verboden paden, begrensd tot de thuismap | Ja, dry run met `-n` en een interactieve kiezer | Nee, `shutil.rmtree` en `unlink` | Bereikbaar achter `--force`, niet geweigerd | Gratis, MIT |
| DevCleaner | Drie risicolagen plus een weigerlijst voor inloggegevens | Groottes per scanner, Danger nooit vooraf geselecteerd | Niet gedocumenteerd, vraag het vóór het draaien | Modelgewichten apart benoemd als klasse | Gratis kern, Pro eenmalig of jaarlijks |
| CleanMyMac CLI | Niet gepubliceerd, repository is een issuetracker | Ja, bevestiging vóór verwijdering | Niet gedocumenteerd | Niet gedocumenteerd | Publieke bèta, controleer de voorwaarden van de leverancier |
| Agent met shelltoegang | Niets, beslist op het moment van inferentie | Alleen als je het eist | Alleen als je de prullenmand afdwingt | Alleen als je het in de prompt zegt | Je agentabonnement |
| `ollama rm`, `hf cache rm` | Referentietelling binnen de store | `hf cache rm --dry-run` | Nee, maar opnieuw te downloaden | Dit is de bescherming | Gratis |

## De grens, rechttoe

Mole is geen reactie op malware, geen back-up, en geen vervanging voor een uninstaller van de leverancier
bij software die stuurprogramma's, VPN-onderdelen of systeemextensies meelevert. Die
verwijdert geen modelgewichten, en AI-chatgeschiedenis vertrekt alleen via AI-opschoning en -onderhoud, één
aangevinkte sessie tegelijk, dus als je probleem van 200 GB helemaal een modelbibliotheek is, toont
Analyse je de vorm van die bibliotheek en geeft de taak aan Ollama of LM Studio.
Ollama-modellen die een maand ongebruikt zijn, zijn de uitzondering: AI-opschoning en -onderhoud toont ze en
verwijdert de modellen die je aanvinkt met `ollama rm`. Dat is een bewuste grens, geen gat om
later te dichten.

## Er één kiezen

**200 GB aan builduitvoer en een dozijn toolchains.** Het volume zit in caches, oude
`node_modules`, DerivedData en Docker, niet in iets dat specifiek voor AI is. Begin met een beoordeelde
veeg of `mo clean --dry-run`, en werk daarna door
[ontwikkelaarscaches wissen](https://mole.fit/nl/blog/how-to-clear-dev-caches-mac) voor de stores die hun
eigen snoeiopdracht nodig hebben. cc-cleaner is een goede tweede ronde als je eerst de risicolagen leest.

**Een grote lokale modelbibliotheek.** Sla algemene opschoners voor de gewichten helemaal over. `ollama ls`,
`hf cache ls` en de weergave My Models van LM Studio zijn de enige tools die een gedeelde blob
veilig kunnen vrijmaken. Gebruik een schijfkaart om de store te vinden en de tool die eigenaar is om die te wijzigen.

**Je merkte net dat Cursor of Claude Code schijf opeet.** Begin met wegwerpbare
caches en logs te scheiden van transcripten en projectstaat. Oudere CLI-versies zijn alleen kandidaten
na controle van launchers, draaiende processen, updates en vastgezette versies. Bewaar transcripten
en alles wat je niet kunt aanwijzen. De stap-voor-stapcontrole staat in
[opruimen na AI-codingtools](https://mole.fit/nl/blog/how-to-clean-up-ai-coding-tools-mac).

## Veelgestelde vragen

### Verwijdert een Mac-opschoner met AI veiliger dan een gewone?

Niet op het beschikbare bewijs. Een model kan een regel verslaan bij het beslissen welke app eigenaar is van een
weesmap en bij het rangschikken van wat aandacht verdient, omdat dat vage problemen zijn
met veel zwakke signalen. Beslissen of een pad veilig te verwijderen is vraagt determinisme en een
controleerbare lijst, en een model levert geen van beide. Vraag een leverancier welke pijplijnstap hun
model draait, en behandel "het beslist wat veilig te verwijderen is" als een aanleiding om de lijst te zien.

### Is het veilig om Claude Code mijn Mac te laten opschonen?

Het is de meest flexibele optie en de minst begrensde. De opdrachten worden gegenereerd op het
moment van inferentie en draaien tegen je thuismap, zonder voorbeeld tenzij je erom vraagt.
Doe je het, laat de agent dan een tool aansturen die een dry-run-vlag heeft in plaats van zelf
`rm -rf` samen te stellen, keur `rm` nooit vooraf goed in je rechteninstellingen, stuur verwijderingen naar de
prullenmand, en beperk die tot één map tegelijk.

### Verwijdert een Mac-opschoner mijn Ollama-modellen of mijn Claude Code-geschiedenis?

Het hangt helemaal van de tool af, en daarom is dit de vraag om eerst te stellen. Gewoon Opschonen van Mole blokkeert
`~/.ollama/models`, `~/.lmstudio/models`, `~/.cache/huggingface`, `~/.claude/projects`,
`~/.codex/sessions` en `~/.grok/sessions` bij de verwijderpoort op elke leeftijd, dus ze worden nooit
kandidaten. cc-cleaner deelt modelmappen en transcripten van Claude Code in als
matig risico en verwijdert ze als je `--force` meegeeft. Lees de risicolagen van een tool vóór de
eerste run en niet erna. De ene bewuste uitzondering is de pagina AI-opschoning en -onderhoud van Mole,
die Codex-sessies voorbij een venster dat je kiest kan tonen en Claude Code-sessies waarvan het
project weg is, uitgevinkt, zodat je ze één voor één bevestigt.

### Wat neemt de ruimte echt in na een jaar AI-codingtools?

Controleer oude CLI-versies en transcripten naast caches. Bijvoorbeeld, als elke versie
ongeveer 300 MB is en maar één van de vijf nog nodig is, zijn de andere vier samen ongeveer 1,2 GB. Dat is
een illustratie, geen meting van jouw Mac. Transcripten onder `~/.claude/projects` kunnen
ook in de tijd groeien, maar anders dan caches kunnen ze onvervangbaar werk bevatten, dus sluit ze
uit van een opruimveeg.

## Verder lezen

- [Ollama- en LM Studio-modellen op de Mac opruimen](https://mole.fit/nl/blog/how-to-remove-ai-tool-leftovers-mac)
  voor de werking van content-addressed modelstores.
- [Ontwikkelaarscaches wissen zonder builds te breken](https://mole.fit/nl/blog/how-to-clear-dev-caches-mac) voor
  stores van pakketbeheerders en verspreide `node_modules`.
- [Opruimen na AI-codingtools](https://mole.fit/nl/blog/how-to-clean-up-ai-coding-tools-mac) voor de
  versie stap voor stap, pad voor pad.

---

Canonical HTML page: https://mole.fit/nl/blog/ai-mac-cleaner-tools
Blog index for agents: https://mole.fit/nl/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
