Come fare pulizia dopo gli strumenti AI per programmare sul Mac

Un disco che era comodo per due anni può riempirsi nell'arco di pochi mesi usando agent di programmazione ogni giorno. Gli agent stessi sono piccoli. Ciò che è cambiato è quanto spesso la macchina compila, quanto spesso una CLI si sostituisce sul disco, e quanto del tuo stesso ragionamento ora vive nella tua home directory come testo. Quasi tutta la crescita rientra in tre categorie, e richiedono tre decisioni diverse, perché costano tre importi molto diversi da recuperare.

I pesi dei modelli sono il sospettato ovvio e di solito quello sbagliato per questo problema specifico. Ollama, LM Studio e Hugging Face mantengono store con indirizzamento per contenuto che solo i loro stessi strumenti possono potare in sicurezza, ed è coperto a parte in rimuovere i residui degli strumenti AI. Questo articolo riguarda cosa lasciano dietro di sé gli agent di programmazione AI mentre lavori.

Misura prima di cancellare qualsiasi cosa

Due comandi rispondono alla maggior parte della domanda. Il primo totalizza le home directory degli agent:

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

Il secondo trova l'output di build sparso in ogni progetto che hai mai aperto. Sostituisci le radici con dove tieni il codice:

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 impedisce a find di scendere dentro una directory già trovata, e qui conta: senza, find percorre ogni file dentro un target/ da 24 GB prima di proseguire. Sul Mac che ho misurato scrivendo questo, le prime due righe erano un target/ Rust da 24 GB e il target/ di un progetto Tauri da 9,8 GB, contro alberi node_modules che vanno da 134 MB a 1,5 GB. Il rapporto è il punto: la cosa che sembra il problema delle dipendenze era il due percento del numero reale.

Se preferisci vedere questo come una mappa invece che una lista, la vista Analyze di Mole disegna gli stessi volumi come un treemap e ti lascia esplorare il rettangolo più grande, il che è più veloce che indovinare quale radice passare a find.

Categoria uno: output di build, amplificato

Questa categoria non è nuova. Il volume lo è. Uno sviluppatore che lavora a mano compila poche volte al giorno. Un agent che lavora su un compito compila dopo quasi ogni modifica, esegue i test, prova un secondo approccio, e compila di nuovo. Le cache che una volta crescevano nell'arco di mesi ora crescono nell'arco di un pomeriggio, e le directory di build incrementale sono progettate per scambiare disco con velocità.

Rust è di solito il più grande di gran lunga. Una directory target/ contiene dipendenze compilate, stato di compilazione incrementale, e output degli script di build, tenuti separatamente per profilo, quindi debug e release sono due copie complete. cargo clean senza opzioni "will delete the entire target directory". Fai prima un'anteprima:

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

cargo clean -p <package> pulisce solo i pacchetti nominati, che è lo strumento giusto quando il problema è un solo membro del workspace.

JavaScript distribuisce l'output più sottilmente. Oltre a node_modules stesso c'è node_modules/.cache (usata da bundler e transpiler), .next per le build Next.js, e qualsiasi cosa scriva dist o build nella tua toolchain. Trova le cache specificamente:

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

Python lascia __pycache__ accanto a ogni pacchetto che importa. Individualmente minuscole, e ce ne sono migliaia. Contale prima di rimuoverle, perché la stessa forma di comando con rm -rf alla fine non perdona se una radice è sbagliata:

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

Le cache di bytecode si rigenerano al prossimo import senza alcun accesso di rete, quindi questa è la cosa più sicura da cancellare in tutto l'articolo.

Go mantiene una singola cache di build globale invece di directory per progetto. go env GOCACHE stampa la sua posizione e go clean -cache "causes clean to remove the entire go build cache". go clean -testcache fa scadere i risultati dei test in cache senza scartare i pacchetti compilati. Sulla mia macchina la cache di build era 183 MB contro una cache dei moduli di 38 MB, quindi vale la pena controllare il lato build anche quando i moduli scaricati sono piccoli.

Xcode richiede un trattamento a parte, perché DerivedData, archivi, supporto dispositivi e runtime del simulatore sono quattro tipi di cose con quattro costi di ripristino diversi. La cartella DerivedData su questo Mac misurava 9,3 GB. Fare pulizia dello storage di Xcode copre quali di questi puoi cancellare e quali tenere per la simbolizzazione. Gradle e Maven si dividono allo stesso modo tra directory build/ per progetto e uno store globale sotto ~/.gradle o ~/.m2, e il lato globale appartiene con gli altri registri in svuotare le cache di sviluppo.

Categoria due: versioni CLI superate

Questa è quella che quasi nessuno cerca, e su una macchina che fa girare diversi agent è spesso più grande di tutte le cache messe insieme.

Le CLI degli agent si aggiornano da sole scaricando una release completa con nuova versione e puntando un launcher su di essa. Ogni release è autosufficiente, quindi non condivide file con la release precedente. Il puntatore si sposta. La vecchia release resta. Niente la spazza via, quindi il conteggio cresce di uno a ogni aggiornamento, per sempre.

I layout seguono uno schema con differenze cosmetiche:

• Codex mantiene ~/.codex/packages/standalone/releases/<version>-<arch>/, con un symlink current un livello sopra che punta a quella attiva.
• Claude Code mantiene ~/.local/share/claude/versions/<version>, dove ogni voce è un singolo file eseguibile invece di una directory, e ~/.local/bin/claude è un symlink verso quella attiva.
• Grok mantiene ~/.grok/downloads/grok-<version>-macos-<arch> come file, con ~/.grok/bin/grok e ~/.grok/bin/agent che puntano alla build corrente.
• Cursor Agent mantiene ~/.local/share/cursor-agent/versions/<date>-<sha>/, con ~/.local/bin/cursor-agent come launcher.
• GitHub Copilot CLI installato tramite npm si sostituisce sul posto, ma il suo script di installazione scrive un pacchetto con versione sotto un prefisso che ha come default $HOME/.local per un utente non root. Mole controlla ~/.copilot/pkg/universal per la stessa struttura.

Misurale tutte in una volta:

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

Sul Mac che ho usato per questo articolo questo ha stampato cinque release di Codex tra 262 MB e 310 MB, cinque binari di Claude Code tra 293 MB e 306 MB, due build di Grok, e due versioni di Cursor Agent. Circa 3,5 GB in totale, di cui circa 920 MB attivi. Tutto il resto era un binario già sostituito. L'issue tracker di Codex stesso ha una richiesta aperta per questo, dove chi l'ha segnalata misura la crescita a circa 250 MB per aggiornamento (openai/codex#22293).

Risolvi il launcher prima di cancellare una sola directory

La scorciatoia allettante è ordinare per data e tenere la più recente. Non farlo. Due situazioni ordinarie la rompono: hai fissato una versione più vecchia deliberatamente dopo una regressione, o un aggiornamento ha messo in staging la nuova directory prima di spostare il puntatore. Cancellare la release attiva ti lascia con un launcher che punta al nulla.

Chiedi al launcher invece. È un symlink, quindi risolvilo:

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

Questo stampa il target reale, per esempio ~/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin/bin/codex, e ls -l "$(command -v codex)" mostra ogni salto invece della risposta finale. Quello che torna è attivo. Ogni sibling non su quel percorso è superato, e cestinarlo è sicuro. Esegui la CLI una volta dopo per confermare che il launcher si risolve ancora prima di svuotare il Cestino.

Categoria tre: stato di lavoro dell'agent, che non è spazzatura

La terza categoria è quella in cui un cleaner può fare danni reali, perché assomiglia esattamente alle prime due.

Trascrizioni di sessione, memorie, piani e allegati generati vivono sotto ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects, e ~/.grok/sessions. Sono file JSONL nominati per id di sessione, con timestamp, append-only, e non smettono mai di crescere. Ogni euristica che un cleaner generico usa dice file di log. Sul Mac che ho misurato, ~/.codex/sessions era 9,8 GB, ~/.claude/projects era 2,7 GB su 2.362 file di trascrizione, e ~/.grok/sessions era 1,3 GB: un numero grande e allettante attaccato a file che sembrano eliminabili.

Non sono log. Una trascrizione è il registro di come si è arrivati a una modifica: gli approcci provati e scartati, il vincolo che ne ha escluso uno, la ragione per cui la forma finale è quella che è. Quel ragionamento non esiste da nessun'altra parte. Il messaggio di commit registra cosa è cambiato, il codice registra l'opzione sopravvissuta e non le quattro scartate. Mesi di questo si accumulano silenziosamente, e scopri il valore la prima volta che torni indietro a chiederti perché qualcosa è stato costruito in quel modo.

Il rischio più grande non è un cleaner di terze parti. Claude Code spedisce una propria pulizia di retention: cleanupPeriodDays ha come default 30 giorni, e all'avvio cancella le trascrizioni sotto projects/, i file di piano, gli snapshot pre-modifica in file-history/, e le liste di task per sessione più vecchie di quel limite. Il suo riferimento della directory .claude documenta esattamente quali percorsi vengono spazzati via e quali restano indefinitamente. Se vuoi un anno di trascrizioni, alza quel numero adesso piuttosto che scoprire il default dopo il fatto. La stessa pagina documenta claude project purge per il caso opposto, quando vuoi che lo stato di un progetto sparisca deliberatamente.

Mole non tocca mai nulla di tutto questo. Quei cinque percorsi, più ~/.claude/file-history, ~/.claude/plans, ~/.claude/tasks, ~/.codex/attachments, e ~/.codex/generated_images, sono nella sua lista di protezione a qualsiasi età. Non c'è soglia d'età, nessuna eccezione "più vecchio di 90 giorni", nessuna impostazione per abilitarne una. Un'eccezione con soglia d'età è stata costruita per questi percorsi una volta ed è stata annullata lo stesso giorno, perché una trascrizione vecchia non è una trascrizione obsoleta.

Sotto il cofano: ordina per costo di ripristino, non per dimensione

Questa è la regola che rende decidibili tutte e tre le categorie, ed è l'unica cosa in questo articolo che vale la pena memorizzare. Classifica ogni candidato in base a cosa costa recuperarlo, non a quanti gigabyte mostra.

Rigenerabile localmente. Output di build, stato di compilazione incrementale, cache di bytecode, DerivedData. Il costo di cancellarli sono minuti di CPU su una macchina su cui sei già seduto, senza alcuna rete coinvolta. Cancella liberamente, e cancella i più grandi senza troppi pensieri.

Costoso da ricostruire. Registri dei package, node_modules, CocoaPods, ambienti virtuali Python, directory vendor, pesi dei modelli, DeviceSupport iOS. Ognuno richiede una rete, un registro che serva ancora esattamente le versioni nominate dal tuo lockfile, e a volte una toolchain nativa. Il costo reale non sono minuti su una buona connessione, è se puoi lavorare del tutto su un treno. Rivedi questi uno alla volta.

Insostituibile. Trascrizioni di chat, memorie dell'agent, file di piano, stato del progetto, fine-tune locali. Nessuna quantità di CPU o banda li riporta indietro. Non appartengono mai a una cancellazione batch, e non dovrebbero essere il tipo di cosa che puoi selezionare per sbaglio.

La trappola è che il livello uno e il livello due sembrano identici. target/ e node_modules/ sono entrambe directory grandi alla radice di un progetto, entrambe piene di artefatti di dipendenze, entrambe elencate in .gitignore, entrambe rigenerate da un singolo comando. Ordinate per dimensione stanno una accanto all'altra. Ma cargo build ricostruisce target/ dal codice sorgente che hai già sul disco, mentre npm ci ha bisogno che il registro sia ancora attivo e il lockfile si risolva ancora. Uno è una pausa caffè. L'altro è un pomeriggio bloccato o un pacchetto ritirato che non puoi reinstallare. Confonderli è l'errore più comune in questa categoria, ed è per questo che "cancella le cartelle più grandi" è un cattivo consiglio anche quando libera più spazio.

Farlo dentro Mole

La via manuale funziona e non costa nulla. Ciò che aggiunge Mole è che tutte e tre le categorie arrivano in un'unica lista revisionata con il confine tra livelli già applicato, così non sei tu a dover ricordare quale directory nascosta contiene le trascrizioni.

Apri lo strumento Clean ed esegui una scansione. La scansione è gratuita e non richiede licenza. Ogni candidato arriva con il suo percorso esatto, il suo proprietario, e la sua dimensione misurata, e niente si muove finché non approvi la lista. Qualsiasi cosa a bassa confidenza arriva deselezionata, quindi l'azione predefinita è sempre quella più piccola. Le rimozioni vanno nel Cestino invece di essere scollegate, quindi un errore è un trascinamento fuori piuttosto che un ripristino da backup, e un'operazione batch riporta cosa ha saltato e cosa è fallito invece di solo cosa ha rimosso.

Per le versioni CLI superate specificamente, Mole fa per te la risoluzione del launcher descritta sopra. Legge il symlink del launcher per ogni CLI di agent, lo risolve alla release attiva, ed esclude quella release dall'insieme di candidati, così un downgrade deliberato resta intatto invece di essere trattato come una vecchia versione. Il caso misurato dietro quel comportamento è Codex: cinque release a 1,2 GB con una sola attiva.

Il Mole CLI è gratuito, open source, e copre lo stesso lavoro da una shell con mo clean; ogni comando distruttivo accetta --dry-run, così puoi leggere l'intera lista dei percorsi prima che qualsiasi cosa si muova. Entrambi condividono una lista di protezione in ~/.config/mole/whitelist e un log delle operazioni in ~/Library/Logs/mole/operations.log, e tutto gira in locale senza upload e senza telemetria.

Vale la pena dirlo chiaramente: Mole non è un backup, non è una risposta al malware, e non è un sostituto di un uninstaller del fornitore per software che spedisce driver o estensioni di sistema. Non cancella pesi di modelli o cronologia delle chat AI, e non si offrirà di farlo. Quelli restano con gli strumenti che li possiedono.

Impedire che torni

Tre modifiche di configurazione coprono la maggior parte della ricrescita.

Punta Rust su un'unica directory di build. CARGO_TARGET_DIR imposta la "location of where to place all generated artifacts", così ogni progetto scrive in un unico albero che puoi misurare e pulire in un solo posto. Il compromesso è reale: Cargo blocca la directory di build, quindi due progetti che condividono un unico target dir compilano uno alla volta invece che in parallelo. Se esegui build concorrenti di routine, tienile separate e programma una pulizia invece.

Pota gli store globali su un programma, non a mano. Il Cargo moderno rimuove già le voci inutilizzate dalla sua cache globale durante i normali comandi di build e fetch, e npm descrive la sua cache come autoriparante con npm cache verify come comando di manutenzione. Lascia che quelle policy girino invece di cancellare interamente le cartelle nascoste della home directory. Svuotare le cache di sviluppo ha i comandi per strumento.

Controlla se la tua CLI di agent pota le proprie release, e assumi che non lo faccia. Al momento della stesura non ho trovato un flag documentato o una chiave di configurazione né in Codex né in Claude Code che poti i binari di release superati, e la richiesta di Codex è ancora aperta. cleanupPeriodDays di Claude Code spazza i dati di sessione, non i binari di versione, quindi non aiuta qui. Finché questo non cambia è un lavoro ricorrente, ed è l'elemento a più alto valore nella lista perché torna al ritmo con cui i tuoi agent spediscono aggiornamenti.

Domande frequenti

Quanto disco usano davvero gli strumenti AI per programmare?

I binari sono poche centinaia di megabyte ciascuno, ma è l'accumulo che conta. Sulla macchina misurata per questo articolo, quattro CLI di agent tenevano circa 3,5 GB nelle loro directory di versione con solo 920 MB attivi, le trascrizioni di sessione arrivavano a circa 14 GB, e una singola directory target/ Rust era 24 GB. I tuoi numeri differiranno più per linguaggio che per agent, quindi esegui i due comandi du all'inizio di questo articolo invece di fidarti della cifra di chiunque, inclusa questa.

È sicuro cancellare vecchie versioni di Claude Code o Codex?

Sì, finché risolvi prima il launcher. Esegui readlink -f "$(command -v claude)" o l'equivalente per la tua CLI, tieni qualsiasi percorso stampi, e cestina i sibling. Non ordinare per data e tenere la più recente, perché sia un downgrade fissato sia un aggiornamento a metà rendono entrambi la directory più recente quella sbagliata. Esegui la CLI una volta dopo aver cancellato e prima di svuotare il Cestino.

Un Mac cleaner cancellerà la cronologia chat del mio agent?

Alcuni lo faranno, perché quei file sembrano esattamente log. È il rischio specifico in questa categoria. Mole non tocca mai ~/.codex/sessions, ~/.codex/archived_sessions, ~/.codex/memories, ~/.claude/projects, o ~/.grok/sessions a nessuna età. Prima di eseguire qualsiasi cleaner, controlla se quei percorsi appaiono nella sua lista di candidati, e se lo strumento non ti mostra la lista prima di agire, quella è la tua risposta.

Svuotare le cache di build rallenta qualcosa?

La prossima build, una volta, e poi no. Lo stato di compilazione incrementale esiste per rendere la seconda build più veloce della prima, quindi cancellarlo ti costa esattamente una build a freddo per progetto. È l'intero svantaggio, ed è per questo che l'output di build appartiene al livello cancella liberamente mentre un albero node_modules che ha bisogno di un round trip col registro no.

E i modelli Ollama e le cache Hugging Face?

Fuori ambito qui, e deliberatamente. Quegli strumenti usano store con indirizzamento per contenuto dove due modelli possono condividere lo stesso blob, quindi cancellare file a mano può orfanizzare un modello che ancora li referenzia. Usa il comando di rimozione proprio di ogni strumento, coperto in rimuovere i residui degli strumenti AI.

Dove andare dopo

Ordina per costo di ripristino, risolvi il launcher prima di cancellare una release, lascia stare le trascrizioni. Se la riga più grande nella tua misurazione era uno store di package, svuotare le cache di sviluppo ha i comandi di pulizia per strumento. Se era Xcode, fare pulizia dello storage di Xcode separa le cartelle ricostruibili dagli archivi che tieni. Se era uno store di modelli, rimuovere i residui degli strumenti AI spiega perché deve essere lo strumento proprietario a fare la cancellazione.