# Come fare pulizia dopo gli strumenti AI per programmare sul Mac > Gli strumenti AI per programmare possono lasciare file di compilazione, vecchie versioni CLI e cronologie delle conversazioni. Misura le cartelle e verifica quali dati puoi recuperare prima di eliminare. Published: 2026-08-21 | Updated: 2026-10-05 Un disco che aveva spazio sufficiente 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 ripulire in sicurezza, ed è coperto a parte in [rimuovere i residui degli strumenti AI](https://mole.fit/it/blog/how-to-remove-ai-tool-leftovers-mac). 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](https://mole.fit/) 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 ` 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](https://mole.fit/it/blog/how-to-clean-up-xcode-mac) 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](https://mole.fit/it/blog/how-to-clear-dev-caches-mac). ## 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/-/`, con un symlink `current` un livello sopra che punta a quella attiva. - **Claude Code** mantiene `~/.local/share/claude/versions/`, 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--macos-` come file, con `~/.grok/bin/grok` e `~/.grok/bin/agent` che puntano alla build corrente. - **Cursor Agent** mantiene `~/.local/share/cursor-agent/versions/-/`, con `~/.local/bin/cursor-agent` come launcher. - **Cursor**, l'app desktop, tiene anche una propria copia dell'agent in `~/Library/Application Support/Cursor/User/globalStorage/anysphere.cursor-agent-worker/agent-cli/.local/share/cursor-agent/versions/`, con `bin/cursor-agent` nella stessa cartella `.local` come launcher. Sul Mac misurato in seguito aveva accumulato sette release, 4,1 GB. - **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](https://github.com/openai/codex/issues/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 identifica una versione attiva, non prova che tutte le altre siano inutilizzate. Verifica che nessun processo, installazione o aggiornamento le usi ancora. Nel dubbio, conservale. Dopo averle spostate nel Cestino, prova la CLI prima di svuotarlo.
Il collegamento simbolico del launcher nel PATH passa per current e indica una versione attiva. Occorre verificare separatamente se le altre cartelle di versioni servono ancora a processi, installazioni o aggiornamenti.
Il launcher, non il timestamp, è ciò che identifica la release attiva. Sia un downgrade fissato sia un aggiornamento a metà rendono la directory più recente la risposta sbagliata.
## 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](https://code.claude.com/docs/en/claude-directory) 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 quando è ormai troppo tardi. La stessa pagina documenta `claude project purge` per il caso opposto, quando vuoi che lo stato di un progetto sparisca deliberatamente. La pulizia di [Mole](https://mole.fit/) 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. Le vecchie sessioni hanno una strada a parte, che percorri tu. La Luna lontana nella pagina Pulizia apre Pulizia e cura IA, che tiene un periodo di conservazione per ogni strumento ed elenca le sessioni Codex e Claude Code oltre quel periodo, più le sessioni Claude Code la cui cartella di progetto non c'è più, ognuna con titolo e data, e nulla viene eliminato finché non lo selezioni. Una sessione Codex viene prima copiata nel Cestino e poi eliminata con il comando di Codex, così il suo indice resta integro, e le immagini e le note che Codex ha generato per quella sessione finiscono nel Cestino insieme a lei. Una sessione usata nelle ultime 24 ore non compare mai nell'elenco, quindi puoi pulire anche con Codex e Claude Code aperti, e memorie, piani e skill non compaiono in nessuna lista neanche lì. ## 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 stai già lavorando, senza rete. Prima interrompi le build in corso e verifica che si tratti di output rigenerabili, non di file del progetto. **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.
Tre livelli classificati per costo di ripristino, con target e node_modules mostrati come directory di progetto visivamente identiche che finiscono in livelli diversi perché una si ricostruisce da codice sorgente locale e l'altra ha bisogno di un registro
La dimensione classifica i candidati nell'ordine sbagliato. Due directory che sembrano uguali alla radice di un progetto possono differire di un'intera giornata lavorativa in ciò che costa ripristinarle.
## Farlo dentro Mole La via manuale funziona e non costa nulla. Ciò che aggiunge [Mole](https://mole.fit/) è 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 cache vengono eliminate definitivamente per impostazione predefinita. Puoi scegliere il Cestino nelle impostazioni e ripristinare i file finché vi rimangono. Il risultato mostra anche gli elementi saltati e quelli non rimossi a causa di un errore. 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. La copia che Cursor tiene dentro l'app desktop è trattata allo stesso modo, e una vecchia release può andare anche con Cursor aperto, purché nessun processo la stia usando. Il [Mole CLI](https://github.com/tw93/Mole) è 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.
Schermata di revisione della pulizia di Mole: categorie di cache con la loro dimensione e una casella ciascuna, e in basso il pulsante per pulire definitivamente i 5,14 GB selezionati.
Scoperta e rimozione sono due passaggi separati. La revisione elenca per categoria ciò che la scansione ha trovato, e nulla viene rimosso finché non confermi.
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 include driver o estensioni di sistema. Non cancella mai da sé file di modelli, e la pulizia ordinaria non tocca mai la cronologia delle chat AI: le vecchie sessioni e i modelli Ollama inutilizzati da un mese se ne vanno solo da Pulizia e cura IA, una casella alla volta, e il comando di Ollama rimuove i modelli. Gli altri modelli 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. **Lascia la pulizia periodica degli archivi globali ai loro strumenti.** 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](https://mole.fit/it/blog/how-to-clear-dev-caches-mac) 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? Solo se nessun processo, installazione o aggiornamento le usa ancora. Esegui `readlink -f "$(command -v claude)"` o l'equivalente per la tua CLI, conserva il percorso indicato e verifica le altre versioni una per una. 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. La pulizia ordinaria di 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. La pagina separata Pulizia e cura IA può proporre sessioni Codex e Claude Code oltre il periodo scelto per ogni strumento, più le sessioni Claude Code il cui progetto non esiste più, non selezionate e da verificare singolarmente. ### 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 completa per progetto. Interrompi le build in corso e verifica che gli output siano rigenerabili in locale prima di eliminarli. Una cartella `node_modules` che richiede un nuovo download dal registro dei pacchetti non rientra in questa categoria. ### 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](https://mole.fit/it/blog/how-to-remove-ai-tool-leftovers-mac). I modelli Ollama sono l’unica eccezione che Mole gestisce: Pulizia e cura IA elenca quelli inutilizzati da un mese e rimuove quelli selezionati con il comando `ollama rm` di Ollama, così i blob che un altro modello usa ancora restano. ## 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](https://mole.fit/it/blog/how-to-clear-dev-caches-mac) ha i comandi di pulizia per strumento. Se era Xcode, [fare pulizia dello storage di Xcode](https://mole.fit/it/blog/how-to-clean-up-xcode-mac) separa le cartelle ricostruibili dagli archivi che tieni. Se era uno store di modelli, [rimuovere i residui degli strumenti AI](https://mole.fit/it/blog/how-to-remove-ai-tool-leftovers-mac) spiega perché deve essere lo strumento proprietario a fare la cancellazione. --- Canonical HTML page: https://mole.fit/it/blog/how-to-clean-up-ai-coding-tools-mac Blog index for agents: https://mole.fit/it/blog/llms.txt Site index for agents: https://mole.fit/llms.txt