# Mole CLI oder Mole for Mac

> Zwischen der kostenlosen Terminal-CLI und der kostenpflichtigen nativen App anhand von Workflow, gemeinsamen Schutzdateien und Aufgaben wählen, die nur eines von beiden erledigen kann.

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

Mole gibt es als zwei Programme. `mo` ist ein kostenloses Open-Source-Kommandozeilenwerkzeug, das Sie mit Homebrew installieren und das unter der GPL-3.0 lizenziert ist. Mole for Mac ist eine kostenpflichtige native App mit fünf Tabs und einer Menüleisten-Präsenz. Das sind keine Test- und Pro-Edition desselben Produkts. Es sind getrennte Implementierungen mit überlappenden Aufgaben und einer kleinen gemeinsamen Schicht auf der Festplatte. Wer eines wählt, sperrt sich nicht vom anderen aus. Dieser Leitfaden hilft Ihnen, das Werkzeug zu wählen, das zu Ihrer Arbeitsweise passt, und erklärt, was passiert, wenn Sie beide behalten.

## Was die beiden teilen

Fünf CLI-Befehle entsprechen direkt den fünf Tabs der App: `mo clean`,
`mo uninstall`, `mo optimize`, `mo analyze` und `mo status` entsprechen Clean,
Software, Optimize, Analyze und Status. Die Kategorien sind auf beiden Seiten erkennbar:
überlappende Cache-Familien für Nutzer, Entwickler, Browser und System, App-Inventar und
Remnant-Erkennung, Festplattenanalyse und Gesundheitsmetriken. Die Implementierungen und die
genauen Kandidatenmengen sind nicht identisch.

Scannen ist in beiden kostenlos. Die App berechnet nur den destruktiven Teil, und jedes
destruktive Werkzeug funktioniert zweimal, bevor eine Lizenz nötig wird. So können Sie den Scan
der App mit dem der CLI auf demselben Mac vergleichen, ohne etwas zu bezahlen.

Die interessantere Überlappung liegt auf der Festplatte. Beide schreiben in `~/.config/mole/whitelist` und
`~/.config/mole/whitelist_optimize`, und beide hängen an
`~/Library/Logs/mole/operations.log` an. Ein Cache, den Sie in einer Oberfläche schützen, ist
auch in der anderen geschützt, und eine Löschung in einer der beiden hinterlässt einen Eintrag in derselben Datei. Die beiden
Programme kennen einander zur Laufzeit nicht, sind aber auch nicht unabhängig.

## Was nur das Terminal kann

Drei größere CLI-Abläufe haben kein Pendant in der App. Unterstützende Befehle wie
`mo history`, `mo update`, `mo completion` und `mo remove` gehören zur Terminal-Verwaltung
und sind keine zusätzlichen Wartungsflächen.

### `mo purge`

Durchsucht Ihre Projektverzeichnisse und bietet an, schwere Build-Artefakte zu entfernen. Die Zielliste
ist breit: `target`, `build`, `dist`, `.next`, `DerivedData`, `__pycache__`,
`coverage` und rund dreißig weitere, einschließlich Abhängigkeitsverzeichnisse, die ein Paketmanager
erneut herunterladen müsste. Purge löscht endgültig, statt in den
Papierkorb zu verschieben, und markiert Projekte, die in den letzten sieben Tagen berührt wurden, als aktuell und lässt sie
unausgewählt. Das ist ein direkter Weg, auf einer Entwicklermaschine Dutzende Gigabyte freizugeben,
und zugleich der Befehl, der am ehesten zuerst ein `--dry-run` verdient.

### `mo installer`

Räumt DMG-, PKG- und Archiv-Installer aus Downloads, Desktop, Homebrew-Caches,
iCloud und Mail und kennzeichnet jeden nach seiner Herkunft.

### `mo touchid`

Richtet Touch ID für `sudo` ein, also eine Shell-Konfigurationsaufgabe und keine
Bereinigungsaufgabe.

Über die Befehle hinaus gibt Ihnen das Terminal drei Dinge, die ein Fenster nicht kann. Jeder destruktive
Befehl akzeptiert `--dry-run`, das genau zeigt, was entfernt würde, und entfernt
nichts. `mo analyze`, `mo status` und `mo history` akzeptieren `--json`, und `mo status`
wechselt von selbst zu JSON, wenn die Ausgabe in eine Pipe geht, sodass ein Gesundheitscheck ein
Skript speisen kann. Die reinen Lese- und strukturierten Ausgabepfade laufen auch über SSH, auf einem headless Mac
oder in Skripten. Geplante Löschungen brauchen weiterhin eine explizite nicht-interaktive Policy;
der interaktive Bestätigungsbildschirm wird nicht allein dadurch sicher, dass cron ihn
gestartet hat.

## Was nur die App kann

Die Zusätze der App gruppieren sich um zwei Dinge, bei denen das Terminal schwach ist: kontinuierliche
Anzeige und privilegierte Systemsteuerung.

Zur Anzeige zeichnet Analyze eine Treemap, in die Sie hineinbohren können, Status rendert ein Live-Bento-Dashboard
mit Sparklines und anheftbaren Prozessen, und ein Menüleisten-HUD hält CPU, Arbeitsspeicher
und Netzwerk sichtbar, während Sie in etwas anderem arbeiten. Uninstall zeigt vor jeder Bewegung einen Prüfplan
mit Pfaden, Besitzern und Größen, und Entfernungen gehen in den Papierkorb statt
endgültig gelöscht zu werden.

Zur Systemsteuerung installiert die App über SMJobBless einen eng begrenzten Root-Helper
für Fan- und unterstützte Batterieschreibvorgänge. Die Startobjekt-Verwaltung folgt einer eigenen Grenze:
geprüfte launchd-Jobs und unterstützte Service-Management-Einträge lassen sich umschalten, während
nicht gematchte Hintergrundobjekte die Systemeinstellungen öffnen, statt geraten zu werden. Die App
trägt außerdem Flächen, die nur als resident App Sinn ergeben: Privacy Check, der
die Live-Nutzung von Kamera und Mikrofon meldet, Battery Care, der den Ladezustand auf unterstützten Macs bei etwa 75 bis
80 Prozent hält, Keep Screen On, Clean Screen zum Abwischen der Tastatur und
ein schreibgeschützter Doctor, der einen Diagnosebericht zusammenstellt, den Sie in ein Issue einfügen können.

Die größte App-only-Fläche ist das Aktualisieren anderer Apps. Sie erkennt mehrere Update-Kanäle
und hat In-App-Pfade für Sparkle, Homebrew Casks und Formulae, den Mac App Store und
Electron-Feeds. GitHub Releases und Website-Metadaten können weitere Versionen identifizieren;
wenn Mole ein Bundle nicht sicher verifizieren und ersetzen kann, öffnet es die App oder die Herstellerseite,
statt einen weiteren Installer zu erfinden. Die Lizenz ist ein einmaliger Kauf für zwei
Macs mit lebenslangen Updates, 14-tägiger Rückerstattung und macOS 14 oder neuer. Keines der beiden Programme
sendet Telemetrie.

## Unter der Haube: wie ein Sicherheitsmodell zwei Frontends bedient

Die App ist kein Wrapper, der `mo` per Shell aufruft. Sie ist eine Swift-Neuimplementierung, und
die beiden Codebasen teilen Pfade und Sicherheitsentscheidungen, nicht Prozesse. Analyze baut
auf der Pfad-Taxonomie und den Parallel-Sizing-Lehren der CLI auf, hat aber eigenen Scanner,
Timeouts, Partial-Result-Zustände, Cache und Fallback-Verhalten. Eine Summe aus einem Frontend
ist daher ein nützlicher Gegencheck, kein Byte-für-Byte-Paritätsversprechen.

Das im Repository festgehaltene Prinzip, um sie im Gleichschritt zu halten, lautet: CLI-Parity
bedeutet same-or-safer, nicht identische Löschbreite. Jeder Kandidat, den die App anzeigt,
wird klassifiziert, bevor er Sie erreicht: standardmäßig auswählbar, nur zur Prüfung und standardmäßig
unausgewählt, oder komplett blockiert und abgelehnt, selbst wenn etwas danach fragt. Wenn das
Verhalten der CLI und diese Klassifikation auseinanderlaufen, nimmt die App die engere Position.

`mo purge` ist das klarste Beispiel. Der Mac-Port dieses Sweeps streicht bewusst jedes
heruntergeladene Abhängigkeitsverzeichnis, das die CLI entfernt, einschließlich `node_modules`, `Pods`,
`venv` und `vendor`. Der Grund ist Wiederherstellbarkeit: ein kompiliertes `target`-Verzeichnis
kommt aus einem lokalen Build zurück, während ein Abhängigkeitsbaum das Netz braucht und sich
anders auflösen kann als das Installierte. Die App bietet nur an, was reine
lokale Kompilierung neu bauen kann, und zeigt das als review-only-Zeilen statt
vorausgewählter. Dieselbe Asymmetrie zeigt sich woanders. Die App steuert App-Daten-Scans
hinter Full Disk Access, validiert jeden Pfad im Moment der Löschung erneut und nicht
zur Scan-Zeit und leitet gewöhnliche Entfernungen über den Papierkorb.

Die beiden sind also nicht gleich aggressiv, und der Unterschied verläuft in eine konsistente
Richtung. Die CLI gibt mehr frei, weil sie von jemandem ausgeht, der die Liste liest. Die App
gibt weniger frei, weil sie von jemandem ausgeht, der die Liste schon sicher vorfinden will.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/two-front-ends.webp" width="1360" height="454" loading="lazy" alt="Zwei Frontends, ein Terminal-Werkzeug und eine Mac-App, führen dieselben fünf Operationen getrennt aus, lesen und schreiben aber dieselbe Whitelist-Datei und dasselbe Operationsprotokoll auf der Festplatte">
  <figcaption>Die beiden Programme sprechen im Betrieb nie miteinander, teilen aber eine Schutzliste und ein Log, sodass ein in einem Frontend geschützter Cache in beiden geschützt ist.</figcaption>
</figure>

## Beide laufen lassen

Nichts geht kaputt, wenn Sie beide installieren, und die gemeinsamen Dateien machen die Kombination
stimmig. Schützen Sie einen Cache in den Einstellungen der App, und `mo clean` überspringt ihn ebenfalls. Fügen Sie
einen Pfad mit `mo clean --whitelist` hinzu, und die App beachtet ihn. Beide hinterlassen ihre Löschungen im
selben Log.

Zwei Hinweise lohnen sich. Die Programme koordinieren sich im Betrieb nicht, starten Sie also keinen
Clean in beiden gleichzeitig. Und weil die App bewusst enger ist, ist es erwartetes Verhalten und kein fehlendes
Feature, wenn `mo clean` eine Kategorie anbietet, die die App nie zeigt.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/same-or-safer.webp" width="1360" height="454" loading="lazy" alt="Die Menge dessen, was die CLI entfernen wird, umschließt die kleinere Menge, die die Mac-App entfernt; der Unterschied sind heruntergeladene Abhängigkeitsverzeichnisse wie node_modules, Pods, venv und vendor">
  <figcaption>Same or safer, nie breiter. Die Abhängigkeiten, die nur die CLI wegfegt, sind genau die, die das Netz brauchen, um zurückzukommen.</figcaption>
</figure>

## Die Wahl

Installieren Sie die CLI, wenn Sie im Terminal leben, mit `--dry-run` vorschauen wollen, `--json`
für ein Skript brauchen, die Project-Artifact- und Installer-Sweeps wollen oder schlicht kein
Geld ausgeben möchten. Für eine Entwicklermaschine reicht das oft, und es ist
genau deshalb kostenlos.

Kaufen Sie die App, wenn Sie die Festplattenkarte und das Live-Dashboard wollen, wenn Fan-Steuerung, Startobjekt-Verwaltung
oder Drittanbieter-App-Updates der eigentliche Grund sind, weshalb Sie hier sind, oder wenn Sie
das für jemanden installieren, der Terminal nie öffnen wird. Dieser letzte Fall war der
ursprüngliche Grund für die App; die Geschichte steht in
[der Geschichte von Mole](https://mole.fit/de/blog/the-story-of-mole).

Wenn Sie noch nicht wissen, installieren Sie zuerst die CLI und führen Sie `mo clean --dry-run` aus. Es kostet
nichts, löscht nichts, und das Lesen der Ausgabe ist der schnellste Weg zu erfahren, ob
Ihr Mac überhaupt ein Problem hat, das ein Werkzeug wert ist, eine Frage, die
[es sich lohnt, vor der Installation eines Cleaners zu stellen](https://mole.fit/de/blog/do-you-need-a-mac-cleaner).

---

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