# Mole CLI o Mole for Mac

> Scegli tra la CLI gratuita da terminale e l’app nativa a pagamento in base al flusso di lavoro, ai file di protezione che condividono su disco e ai compiti che solo una delle due può fare.

Published: 2026-07-25 | Updated: 2026-08-08

Mole si presenta in due programmi. `mo` è uno strumento da riga di comando gratuito e open source, installato con Homebrew e con licenza GPL-3.0. Mole for Mac è un’app nativa a pagamento, con cinque schede e una presenza nella barra dei menu. Non sono una versione di prova e una Pro. Sono implementazioni distinte, con compiti che si sovrappongono e un piccolo strato condiviso sul disco: sceglierne una non ti esclude dall’altra. Questa è una guida per capire quale combacia con il modo in cui lavori già, e cosa succede se le tieni entrambe.

## Cosa condividono le due

Cinque comandi della CLI corrispondono direttamente alle cinque schede dell’app: `mo clean`, `mo uninstall`, `mo optimize`, `mo analyze` e `mo status` mappano su Clean, Software, Optimize, Analyze e Status. Le categorie sono riconoscibili in entrambe: famiglie di cache utente, di sviluppo, del browser e di sistema che si sovrappongono, inventario delle app e scoperta dei residui, analisi del disco e metriche di salute. Le implementazioni e gli elenchi precisi dei candidati non sono identici.

La scansione è gratuita in entrambi. L’app addebita solo la metà distruttiva, e ogni strumento distruttivo funziona due volte prima che sia richiesta una licenza: così puoi confrontare la scansione dell’app con quella della CLI sullo stesso Mac senza pagare nulla.

La sovrapposizione più interessante è sul disco. Entrambe scrivono in `~/.config/mole/whitelist` e `~/.config/mole/whitelist_optimize`, e entrambe aggiungono a `~/Library/Logs/mole/operations.log`. Una cache che proteggi da un frontend è protetta anche dall’altro, e una cancellazione fatta da uno o dall’altro lascia un record nello stesso file. I due programmi non si conoscono a runtime, ma non sono nemmeno indipendenti.

## Cosa può fare solo il terminale

Tre flussi di lavoro più ampi della CLI non hanno un equivalente nell’app. Comandi di supporto come `mo history`, `mo update`, `mo completion` e `mo remove` sono amministrazione da terminale, non superfici di manutenzione aggiuntive.

### `mo purge`

Scansiona le directory dei tuoi progetti e propone di rimuovere artefatti di build pesanti. L’elenco dei target è ampio: `target`, `build`, `dist`, `.next`, `DerivedData`, `__pycache__`, `coverage` e circa altre trenta voci, comprese directory di dipendenze che un package manager dovrebbe scaricare di nuovo. Purge elimina in modo permanente invece di spostare nel Cestino, e contrassegna come recenti i progetti toccati negli ultimi sette giorni lasciandoli deselezionati. È un modo diretto per recuperare decine di gigabyte da una macchina da sviluppatore, ed è anche il comando che merita di più un `--dry-run` prima.

### `mo installer`

Ripulisce installatori DMG, PKG e archivi da Download, Scrivania, cache di Homebrew, iCloud e Mail, etichettando ciascuno in base alla provenienza.

### `mo touchid`

Configura Touch ID per `sudo`: un compito di configurazione della shell più che di pulizia.

Oltre ai comandi, il terminale ti dà tre cose che una finestra non può. Ogni comando distruttivo accetta `--dry-run`, che stampa esattamente cosa verrebbe rimosso e non rimuove nulla. `mo analyze`, `mo status` e `mo history` accettano `--json`, e `mo status` passa da solo a JSON quando l’output viene reindirizzato in pipe, così un controllo di salute può alimentare uno script. I percorsi di sola lettura e di output strutturato funzionano anche via ssh, su un Mac headless o dentro script. La cancellazione programmata richiede comunque una policy non interattiva esplicita: la schermata di conferma interattiva non diventa sicura solo perché l’ha lanciata cron.

## Cosa può fare solo l’app

Le aggiunte dell’app si concentrano su due cose in cui il terminale è debole: visualizzazione continua e controllo di sistema privilegiato.

Per la visualizzazione, Analyze disegna una treemap in cui puoi scendere di livello, Status mostra un dashboard bento in tempo reale con sparkline e processi fissabili, e un HUD nella barra dei menu tiene CPU, memoria e rete visibili mentre lavori altrove. Uninstall presenta un piano di revisione con percorsi, proprietari e dimensioni prima che qualcosa si muova, e le rimozioni vanno nel Cestino invece di essere eliminate del tutto.

Per il controllo di sistema, l’app installa un helper root a scope ristretto tramite SMJobBless per le scritture su ventole e batteria supportate. La gestione degli elementi di avvio segue un confine separato: i job launchd validati e gli elementi Service Management supportati si possono attivare e disattivare, mentre gli elementi in background non abbinati aprono Impostazioni di Sistema invece di essere indovinati. L’app porta anche superfici che hanno senso solo come app residente: Privacy Check, che segnala l’uso in tempo reale di fotocamera e microfono; Battery Care, che tiene la carica intorno al 75–80 percento sui Mac supportati; Keep Screen On; Clean Screen per pulire la tastiera; e un Doctor in sola lettura che assembla un report diagnostico da incollare in una issue.

La superficie più ampia solo dell’app è l’aggiornamento delle altre app. Rileva diversi canali di update e ha percorsi in-app per Sparkle, cask e formula Homebrew, Mac App Store e feed Electron. GitHub Releases e i metadati dei siti possono identificare altre versioni; quando Mole non può verificare e sostituire un bundle in sicurezza, apre l’app o la pagina del vendor invece di inventare un altro installatore. La licenza è un acquisto una tantum che copre due Mac con aggiornamenti a vita, rimborso entro 14 giorni e macOS 14 o successivo. Nessuno dei due programmi invia telemetria.

## Dietro le quinte: come un modello di sicurezza serve due frontend

L’app non è un wrapper che invoca `mo` dalla shell. È una reimplementazione in Swift, e i due codebase condividono percorsi e decisioni di sicurezza, non processi. Analyze attinge alla tassonomia dei percorsi della CLI e alle lezioni sul dimensionamento in parallelo, ma ha il proprio scanner, i propri timeout, gli stati di risultato parziale, la cache e i comportamenti di fallback. Un totale da un frontend è quindi un utile controllo incrociato, non una promessa di parità byte per byte.

Il principio registrato nel repository per tenerle allineate è che la parity con la CLI significa uguale o più sicuro, non la stessa ampiezza di cancellazione. Ogni candidato che l’app mostra è classificato prima di arrivarti: selezionabile di default, solo revisione e deselezionato di default, oppure bloccato del tutto e rifiutato anche se qualcosa lo chiede. Quando il comportamento della CLI e quella classificazione non coincidono, l’app prende la posizione più stretta.

`mo purge` è l’esempio più chiaro. La porta Mac di quella scansione esclude di proposito ogni directory di dipendenze scaricate che la CLI rimuove, inclusi `node_modules`, `Pods`, `venv` e `vendor`. Il motivo è la recuperabilità: una directory `target` compilata torna da una build locale, mentre un albero di dipendenze richiede la rete e può risolvere qualcosa di diverso da quanto installato. L’app offre solo ciò che la compilazione puramente locale può ricostruire, e lo presenta come righe di sola revisione invece che preselezionate. La stessa asimmetria compare altrove. L’app mette le scansioni dei dati app dietro Full Disk Access, rivalida ogni percorso al momento della cancellazione e non solo alla scansione, e instrada le rimozioni ordinarie attraverso il Cestino.

Quindi le due non sono altrettanto aggressive, e la differenza va in una direzione coerente. La CLI recupera di più perché presume un utente che legge l’elenco. L’app recupera di meno perché presume un utente che vuole l’elenco già sicuro.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/two-front-ends.webp" width="1360" height="454" loading="lazy" alt="Due front end, uno strumento da Terminale e un'app Mac, che eseguono le stesse cinque operazioni separatamente ma leggono e scrivono lo stesso file whitelist e lo stesso log delle operazioni su disco">
  <figcaption>I due programmi non si parlano mai mentre sono in esecuzione, ma condividono un elenco di protezioni e un log: una cache protetta in uno è protetta in entrambi.</figcaption>
</figure>

## Usarle entrambe

Non si rompe nulla se installi entrambe, e i file condivisi rendono la combinazione coerente. Proteggi una cache dalle Impostazioni dell’app e anche `mo clean` la salterà. Aggiungi un percorso con `mo clean --whitelist` e l’app lo rispetta. Entrambe lasciano le cancellazioni nello stesso log.

Due avvertenze da conoscere. I programmi non si coordinano mentre girano, quindi non avviare una clean in entrambe allo stesso tempo. E poiché l’app è deliberatamente più stretta, vedere in `mo clean` una categoria che l’app non offre mai è comportamento atteso, non una funzione mancante.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/same-or-safer.webp" width="1360" height="454" loading="lazy" alt="L'insieme di ciò che la CLI rimuoverà disegnato intorno all'insieme più piccolo che l'app Mac rimuoverà, con la differenza tra i due costituita da directory di dipendenze scaricate come node_modules, Pods, venv e vendor">
  <figcaption>Uguale o più sicuro, mai più ampio. Le directory che spazza solo la CLI sono quelle che per tornare hanno bisogno della rete.</figcaption>
</figure>

## Come scegliere

Installa la CLI se vivi nel terminale, vuoi l’anteprima con `--dry-run`, ti serve `--json` per uno script, vuoi le scansioni degli artefatti di progetto e degli installatori, o semplicemente non vuoi spendere. Su una macchina da sviluppatore è spesso tutto ciò che serve, ed è gratis proprio perché possa esserlo.

Compra l’app se vuoi la mappa del disco e il dashboard live, se il controllo ventole, la gestione dell’avvio o gli aggiornamenti di app di terze parti sono il motivo reale per cui sei qui, o se la stai installando per qualcuno che non aprirà mai il Terminale. Quest’ultimo caso era il motivo originale per cui l’app esiste, una storia raccontata in
[la storia di Mole](https://mole.fit/it/blog/the-story-of-mole).

Se ancora non sai, installa prima la CLI e lancia `mo clean --dry-run`. Non costa nulla, non cancella nulla, e leggere il suo output è il modo più rapido per capire se il Mac ha un problema che valga uno strumento, una domanda
[da porsi prima di installare qualsiasi cleaner](https://mole.fit/it/blog/do-you-need-a-mac-cleaner).

---

Canonical HTML page: https://mole.fit/it/blog/mole-cli-vs-mac-app
Blog index for agents: https://mole.fit/it/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
