Kudu 2.6: quelloffener Systemcleaner mit JSON-Reinigungsregeln

Was Kudu 2.6 unter einer Oberfläche zusammenfasst

Der Anspruch des Projekts steht im README in einem einzigen Satz: Speicherplatz zurückholen, Malware entfernen, Privatsphäre zurückholen, alles in einer Anwendung. Die Repository-Metadaten weisen TypeScript als Hauptsprache aus, als Standardzweig dient main, und die jüngste erfasste Auslieferung trägt die Versionsnummer v2.6.0 vom 29. August 2026. Zwischen v2.4.0 am 23. August und v2.6.0 liegen sechs Tage, dazwischen liegt v2.5.0 vom 28. August. Zu den Inhalten der einzelnen Minor-Versionen macht das README keine Angaben.

Für wen das gedacht ist, verrät eher die Funktionsliste als der Werbesatz. Wer auf Windows Registry-Einträge, Startprogramme und Dienste zugreifen will, bekommt hier eine einzige Oberfläche statt verstreuter Bordmittel. Unter macOS und Linux fallen die Windows-spezifischen Teile weg, ohne dass das README beziffert, wie viel vom Umfang dort übrig bleibt. Diese Asymmetrie durchzieht das gesamte Dokument: Die Beschreibung ist sichtbar aus der Windows-Perspektive geschrieben.

Finanziert wird das Projekt über Sponsoren, die das README unter usekudu.com/sponsors anspricht, während die Desktop-Werkzeuge selbst kostenlos bleiben sollen. Wie viele Mittel darüber zusammenkommen und ob daraus eine feste Maintainerschaft entsteht, ist nicht angegeben.

Der Reinigungsteil: von Shader-Caches bis zum ARP-Cache

Die Funktionstabelle gliedert den Reinigungsteil in eine erste Spalte mit löschbarem Ballast. Der System Cleaner bearbeitet temporäre Dateien, Protokolle, Caches und Absturzabbilder. Der Browser Cleaner deckt Caches der gängigen Browser ab, ohne dass eine Liste der unterstützten Programme folgt. Der App Cleaner räumt Reste entfernter Anwendungen weg, und der Gaming Cleaner kümmert sich um Launcher- und Shader-Caches. Der Registry Cleaner sucht defekte oder verwaiste Einträge.

Spannender als diese Summe sind die Werkzeuge, die über das Löschen hinausgehen. Der Startup Manager liefert eine Analyse der Auswirkung auf den Bootvorgang. Die Network Cleanup entfernt DNS-Einträge, gespeicherte Wi-Fi-Profile und den ARP-Cache, was bei Netzwerkproblemen ein sinnvoller erster Handgriff sein kann. Der Disk Analyzer stellt die Belegung als interaktive Baumkarte dar. Debloater, Driver Manager, Program Uninstaller und Service Manager adressieren Windows-Bestandteile, die sich sonst nur umständlich erreichen lassen.

Der Software Updater zieht Aktualisierungen gebündelt über winget, Chocolatey, Scoop und npm. In welcher Reihenfolge diese Quellen angesprochen werden und ob sich einzelne abschalten lassen, steht nicht im README. Auch für den Registry Cleaner fehlt jeder Hinweis darauf, nach welchen Kriterien ein Eintrag als verwaist gilt.

Malware Scanner und Privacy Shield: was das README offenlässt

Der Malware Scanner kombiniert laut README drei Dinge: Signaturabgleich, heuristische Analyse und eine Anbindung an Defender. Wie die Signaturdatenbank gepflegt wird und in welchem Takt sie aktualisiert wird, bleibt offen. Die Dokumentation nennt keinen Anbieter, kein Update-Intervall und keine Information dazu, ob die heuristische Auswertung vollständig lokal läuft. Auch die Form der Defender-Integration wird nicht aufgelöst, ob also ein vorhandener Scanner nur abgefragt oder aktiv angestoßen wird.

Privacy Shield bündelt nach README-Angabe mehr als 30 Windows-Datenschutzeinstellungen, darunter Telemetrie, Werbe-ID, Cortana und Tracking. Welche Registry- oder Richtlinien-Schlüssel dahinterliegen, listet das README nicht auf, und es fehlt ein Hinweis darauf, ob sich jede Änderung einzeln zurücknehmen lässt oder nur als Ganzes. Secure Delete überschreibt Dateien vor dem Löschen mit Zufallsdaten. Die Zahl der Durchläufe und das Verfahren sind nicht angegeben.

Wer wissen will, ob diese drei Funktionen halten, was ihre Namen versprechen, kommt am Quelltext nicht vorbei. Das ist bei einem offenen Projekt kein Nachteil, aber es verschiebt den Prüfaufwand auf die lesende Person.

Performance Monitor, Wiederherstellungspunkte und die Datei CLI.md

Der Performance Monitor zeigt CPU-, Speicher-, Datenträger- und Netzwerkwerte in Echtzeit, ergänzt um Pro-Kern-Daten und S.M.A.R.T.-Informationen. Vor dem Reinigen lassen sich Systemwiederherstellungspunkte anlegen. Bei einem Werkzeug, das Dateien löscht, ist das die naheliegende Reihenfolge: zuerst der Punkt, dann der Löschlauf. Die Cleaning History protokolliert vergangene Sitzungen samt zurückgewonnenem Speicherplatz, und geplante Scans laufen täglich, wöchentlich oder monatlich.

One-Click Clean scannt und löscht in einem Durchgang. Genau diese Abkürzung ist der Punkt, an dem Vorsicht angebracht ist, denn wer den Zwischenschritt der Prüfung überspringt, verlässt sich darauf, dass die mitgelieferten Regeln nur treffen, was sie treffen sollen. Der Haftungsausschluss weiter unten im README formuliert es entsprechend: Die Verantwortung für die Auswahl liegt bei der Person, die die Anwendung bedient.

Für die Automatisierung verweist das README auf eine eigene Datei namens CLI.md und beschreibt sie als skriptfähig und ohne grafische Oberfläche nutzbar. Die Befehle selbst stehen nicht im README, sondern in dieser Datei. Wer Kudu in einem Wartungsablauf einsetzen will, muss sie also öffnen, bevor sich der Aufwand abschätzen lässt.

Reinigungsregeln als JSON-Dateien unter rules/RULES.md

Reinigungsregeln sind laut README einfache JSON-Dateien, für die kein Code nötig ist. Wer eine Anwendung ergänzen will, legt eine solche Datei an, statt TypeScript zu schreiben. Der Einstiegspunkt für Beitragende heißt rules/RULES.md, und unter usekudu.com/cleaners liegt ein Verzeichnis der bereits abgedeckten Anwendungen.

Das ist die interessanteste Stelle des Projekts. Eine Regeldatei bestimmt, welche Pfade und Dateimuster ein Cleaner anfasst, und damit auch, was versehentlich gelöscht werden kann. Wie das Schema aufgebaut ist, welche Felder Pflicht sind und ob Platzhalter in Pfaden erlaubt sind, erfährt man erst in rules/RULES.md. Das Schlagwort im README reicht dafür nicht, und eine Beispielregel ist dort nicht abgedruckt.

Dass die Regeln bewusst ohne Programmierkenntnisse erweiterbar sind, senkt die Hürde für Beiträge und verschiebt die Risikofrage: Eine falsch gesetzte Regel wirkt sich auf jede Instanz aus, die sie übernimmt. Ob es eine Prüfstrecke gibt, die eingereichte Regeln gegen echte Systeme laufen lässt, ist in der Dokumentation nicht angegeben.

Installationsformate je Plattform und die fehlenden Prüfsummen

Die Download-Tabelle im README nennt je Plattform ein Format: ein .exe-Installationsprogramm für Windows, ein .dmg für Intel und Apple Silicon unter macOS, unter Linux wahlweise ein .AppImage oder ein .deb-Paket. Alle Dateien liegen auf der Releases-Seite des Repositories. Eine Paketquelle für Homebrew oder einen Kanal für winget erwähnt das README nicht, obwohl Kudu selbst über winget aktualisieren kann.

Was fehlt, fällt auf. Es gibt keine Mindest-Windows-Version, keine macOS-Vorgabe, keine Angabe zu benötigten Rechten unter Linux und keine Prüfsummen oder Signaturen zum Abgleich. Bei einem Werkzeug, das typischerweise mit erhöhten Rechten läuft und Dateien löscht, wäre ein veröffentlichter SHA-256-Wert zum Gegenlesen kein Luxus. Mindestanforderungen an Arbeitsspeicher oder Plattenplatz sucht man ebenfalls vergebens.

Die Sprachauswahl ist dagegen üppig dokumentiert: Das README listet 30 Sprachen auf, darunter Deutsch, Schweizer Varianten sind nicht ausgewiesen. Ob Übersetzungsbeiträge demselben Weg folgen wie Codebeiträge, bleibt offen.

MIT, Haftungsausschluss und der Vergleich mit CCleaner

Das Repository steht unter MIT, Copyright bei Advent Development Inc. Die Lizenz erlaubt Nutzung, Kopie, Veränderung, Zusammenführung, Veröffentlichung, Verteilung, Unterlizenzierung und Verkauf, solange der Urheberrechts- und der Genehmigungsvermerk erhalten bleiben. Eine Gewährleistung gibt es nicht, die Software wird wie besehen bereitgestellt. Für jemanden, der Kudu in einer Organisation ausrollen will, heißt das vor allem: keine Zusage zu Support, keine Haftung, und der Haftungsausschluss im README bekräftigt das mit dem Satz, dass keine Verantwortung für Datenverlust oder Systeminstabilität übernommen wird.

Der Vergleichspartner ist im README selbst genannt: CCleaner. Der Unterschied liegt nach Darstellung des Projekts im offenen Quellcode, im Verzicht auf Werbung und gebündelte Zusatzsoftware sowie darin, dass Scans und Reinigung lokal bleiben. Optionale Kudu Cloud Funktionen sollen erst nach expliziter Aktivierung eine Verbindung aufnehmen. Dass solche Cloud-Funktionen überhaupt existieren, steht im README; welche Daten dabei übertragen und wo sie gespeichert werden, nicht. Wer die Cloud-Teile konsequent deaktiviert, erhält ein reines Lokalwerkzeug, verliert aber alles, was an diese Funktionen gebunden ist.

Der dritte Unterschied betrifft die Nachvollziehbarkeit. Bei CCleaner lässt sich nicht prüfen, was gelöscht wird. Bei Kudu liegt die Entscheidung in JSON-Dateien, die jede Person lesen kann. Das ist der belastbarste Vorteil, den das Projekt vorzuweisen hat.

Redaktionelles Fazit

Kudu passt zu Personen, die Windows-Rechner regelmäßig von Ballast befreien und dafür eine Oberfläche mit Wiederherstellungspunkt und Cleaning History wollen; die JSON-Regeln unter rules/RULES.md erlauben es, eigene Anwendungen ohne Code nachzuziehen. Weniger passt es für Umgebungen, in denen jede Löschung vorher geprüft sein muss, denn das README nennt weder Prüfsummen der Installationsdateien noch ein Schema der Regeldateien. Wer einsteigt, sollte zuerst rules/RULES.md lesen, einen Systemwiederherstellungspunkt anlegen und den ersten Durchlauf ohne One-Click Clean fahren.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes