# Come fare pulizia dopo gli strumenti AI per programmare sul Mac > Gli agent di programmazione moltiplicano l'output di build, mantengono ogni release CLI superata e accumulano mesi di trascrizioni che sembrano log. Misura ciascuno, poi ordina per costo di ripristino invece che per dimensione. Published: 2026-08-21 | Updated: 2026-08-22 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](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. - **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 è 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.
Un symlink di launcher nel PATH che si risolve attraverso un puntatore current in una directory di release, mentre le directory di release sorelle accanto ad essa non sono referenziate ed è sicuro rimuoverle
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 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](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. ## 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.
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 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](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.
La vista Clean di Mole che mostra una pulizia revisionata con ogni candidato elencato per percorso e dimensione, e lo spazio effettivamente recuperato riportato dopo l'operazione
Scoperta e rimozione sono due passaggi separati. La schermata di completamento riporta cosa è stato effettivamente recuperato invece di cosa era stato stimato prima della scansione.
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](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? 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](https://mole.fit/it/blog/how-to-remove-ai-tool-leftovers-mac). ## 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