In meinem Lab läuft ein KI-Agent mit, der die Cluster im Auge behält, mir auf Matrix Bescheid gibt und Reparaturen nicht selbst durchdrückt, sondern als Patch vorschlägt. Er heißt ZeroClaw — im Chat nur Claw — und ist der schlankere, vorsichtigere Nachfolger meines früheren Agenten OpenClaw. Dieser Beitrag zeigt, wie er integriert ist, über welche Kanäle er kommuniziert und wie der Weg von einer Idee bis zum gemergten Patch aussieht.
Von OpenClaw zu ZeroClaw
OpenClaw, der Vorgänger, tat durchaus seinen Dienst, geriet mir über die Zeit aber zu schwergewichtig und in seinen Berechtigungen zu großzügig dimensioniert — ein Agent mit eingebautem Browser, breitem Tool-Zugriff und einem nur grob umrissenen Blast-Radius. ZeroClaw ist die bewusste Verschlankung: kleinere Images, weniger eingebaute Fähigkeiten und eine spürbar engere Sicherheitsgrenze. Die wichtigsten Unterschiede:
| OpenClaw | ZeroClaw |
|---|---|
openclaw/-Baum | zeroclaw/ |
| nur SourceHut-Patches | Radicle-Patches (SourceHut nur noch für Flux/CI) |
openclaw.json Matrix-Config | [channels.matrix] in zeroclaw.toml |
| MCP-Plugin im Agenten | Scrapling-MCP als Sidecar |
Der rote Faden dabei: möglichst wenig Logik im Agenten selbst, dafür klar abgegrenzte Sidecars für Netz, Forge und Tailnet — und alles Steuernde nach Git ausgelagert. Diese Aufteilung verkleinert nicht nur die Angriffsfläche, sondern macht das Verhalten des Agenten auch nachvollziehbar: Jede Fähigkeit hat einen sichtbaren Ort, statt in einem monolithischen Binary zu verschwinden.
Wie er integriert ist
ZeroClaw ist ein einzelner Pod auf hydra im Namespace zeroclaw. Statt eines Monolithen sind die Aufgaben auf den Agenten und ein paar Sidecars verteilt:
Die Cluster-API erreicht er ausschließlich über das Tailnet — denselben Pfad, den das tailnet-gateway bereitstellt. Sein kubeconfig zeigt auf https://<cluster>-gateway.tif.internal:6443, die Talos-Zugangsdaten sind read-only, und der Tailscale-Sidecar läuft mit tag:bot und TS_ACCEPT_DNS=false, damit die Pod-DNS-Auflösung beim kube-system-CoreDNS bleibt.
web_fetch- und Browser-Tools sind in zeroclaw.toml deaktiviert; jeglicher ausgehende HTTP-Verkehr läuft über den MCP-Sidecar Scrapling auf Loopback. Der Egress des Agenten ist damit auf eine einzige, klar auditierbare Schnittstelle reduziert, statt einen vollwertigen Headless-Browser samt dessen Angriffsfläche im selben Pod laufen zu lassen.Wie er mit mir spricht
Primärer Kanal ist
Matrix
: eine Synapse-Instanz auf hydra, Ende-zu-Ende-verschlüsselt. Der E2EE-State (Geräte-Identität, Schlüssel) liegt auf dem PVC unter state/matrix und überlebt damit Neustarts — das ist der empfindlichste Teil des ganzen Setups und hat eine eigene Recovery-Prozedur, falls der Krypto-Store je verloren geht. Optional ist Claw zusätzlich über meinen internen InspIRCd erreichbar.
Wichtig ist mir dabei eine Regel, die in seinem Workspace festgeschrieben steht: Jede Antwort im Kanal muss mindestens einen menschenlesbaren Satz enthalten — keine nackten Tool-Aufrufe, kein rohes JSON. Ein Agent, der nur Werkzeug-Output ausspuckt, ist als Gegenüber wertlos.
Der Workflow: Vom Symptom zum Merge
Das wichtigste Designprinzip: Claw ändert den Cluster nie direkt. Er liest den Zustand, erklärt ihn und schlägt Korrekturen als
Radicle
-Patch vor; eingespielt werden sie erst durch Flux, nachdem ich den Patch nach main gemergt habe.
Die geschützten Branches main und next darf der Bot grundsätzlich nicht beschreiben — er reicht ausschließlich Patches und Issues ein. Solange das Repo noch nicht öffentlich ist, zieht Flux den kanonischen main weiterhin über SourceHut; Claws Beitrag ist der Vorschlag, nie der Merge.
Workspace-Updates
Claws „Gehirn“ — seine Betriebsanleitung, Skills und Notizen — lebt nicht im Container-Image, sondern in einem versionierten Workspace unter zeroclaw/workspaces/main/ (AGENTS.md, TOOLS.md, CLUSTERS.md, skills/). Der Update-Weg ist sauber von der Laufzeit getrennt:
Ändere ich etwas am Workspace, baut die CI ein neues Workspace-Image, das beim nächsten Pod-Start per rsync in den PVC gespielt wird. Der austauschbare Teil (Anleitung, Skills) wird so frisch gezogen, während der wertvolle State (Matrix-Schlüssel, Memory) auf dem PVC liegen bleibt. Dasselbe gilt für den Agenten selbst: Sein Image wird über die signierte Pipeline gebaut.
Software-Updates mit Renovate
Dependency-Updates erledigt
Renovate
— self-hosted im Agenten-Image mit --platform=local. Es läuft sowohl interaktiv (über die renovate-ops-Fähigkeit, wenn ich ihn darum bitte) als auch geplant per Cron. Das Ergebnis ist nie ein direkter Push, sondern wieder ein Radicle-Patch, den ich in Ruhe reviewen kann. Damit schließt sich der Kreis: Auch das Hochziehen von Versionsständen folgt demselben „vorschlagen statt durchdrücken“-Prinzip wie jede andere Änderung.
Daneben arbeitet Claw eine Reihe geplanter Audits ab — Flux-Health alle sechs Stunden, ein Backup-Check, ein Ceph-Deep-Dive, eine wöchentliche Memory-Distillation. Im Normalfall bleibt er dabei still und meldet sich nur, wenn wirklich etwas zu tun ist.
Sicherheit
Die Verschlankung gegenüber OpenClaw ist vor allem eine Sicherheitsentscheidung. Der Agent läuft in einer Landlock -Sandbox, seine Secrets sind read-only und liegen nicht auf dem PVC, der Web-Zugriff ist auf Scrapling begrenzt, und die wirksame Cluster-Macht ergibt sich allein aus dem gemounteten kubeconfig — das ich bewusst Richtung read-only schnüren kann. Selbst bei voller Autonomie im Sinne der Konfiguration bleibt die harte Grenze dieselbe wie für mich: Was in den Cluster soll, geht durch Git und durch ein Review.
Fazit
ZeroClaw ist kein Autopilot, sondern ein sehr aufmerksamer Kollege mit Tunnelblick fürs Wesentliche: Er sieht den Cluster, erklärt mir Probleme in verständlichen Sätzen und legt mir Lösungen als Patch auf den Tisch. Den Knopf drücke ich. Genau diese Arbeitsteilung — Maschine schlägt vor, Mensch entscheidet, Flux führt aus — macht ihn zu einem Werkzeug, dem ich Zugriff auf mein Lab anvertraue.