OpenClaw kaputt? Ich repariere es mit Claude Code

Kurz gesagt: Ich betreibe einen Heimserver mit lokalen KI-Helfern (OpenClaw), die alltägliche Aufgaben erledigen. Wenn wirklich etwas kaputtgeht oder zu komplex für sie wird, hole ich mir auf derselben Maschine einen stärkeren Cloud-Assistenten (Claude Code) dazu, der das Problem behebt — und lasse ihn Anleitungen schreiben, damit die lokalen Helfer diese Situation künftig selbst meistern können.

Willst du das selbst umsetzen? Du musst diese Anleitung nicht von Hand durcharbeiten — ein LLM-Assistent (Claude, ChatGPT oder ein lokales Modell) kann denselben Aufbau auf deiner Maschine umsetzen. Erledige die wenigen Dinge, die nur du machen kannst, füge dann den Prompt unten ein und lass den Assistenten den Rest übernehmen. Neu bei LLM-Assistenten? So richtest du einen ein (Claude Code, Cowork, Terminex, DeepSeek).

Dein Teil — das kannst nur du erledigen

Eine Linux-Maschine, auf der bereits ein Agenten-Gateway wie OpenClaw mit lokalen Modellen läuft
Ein Claude-Konto oder API-Key für Claude Code (die kostenpflichtige, stärkere Stufe, zu der man greift, wenn es wirklich zählt)

Der Teil des Assistenten — das kannst du delegieren

Die tatsächliche Störung anhand von Logs und Konfiguration diagnostizieren, statt dass Sie raten müssen
Die dauerhafte Lösung umsetzen (nicht nur einen Neustart) und überprüfen, dass die Dienste wieder gesund laufen
Das Runbook bzw. die Konfiguration so schreiben, dass Ihre lokalen Agenten dieselbe Situation beim nächsten Mal selbst bewältigen

Diesen Prompt zum Start kopieren:

Rufe https://www.laserlloyd.com/de/projects/openclaw-broken-i-fix-it-with-claude-code/ ab und lies es — dort stehen die vollständige Anleitung, Einstellungen und Stolperfallen für dieses Projekt. Debugge das ausgefallene lokale Agenten-Gateway auf dieser Maschine — ich beschreibe dir die Symptome. Finde die eigentliche Ursache und setze eine dauerhafte Lösung um, nicht nur einen Neustart auf gut Glück. Verifiziere das, indem du die Dienste neu startest, einen gesunden Status-Output zeigst und eine erfolgreiche Testnachricht durch das Gateway schickst. Schreibe anschließend ein kurzes Runbook, damit meine Agenten das nächste Mal selbst reagieren können, und fasse Ursache und deine Änderungen zusammen.

Meine lokalen OpenClaw-Agenten betreiben diese Website, meine Chat-App und einen ganzen Haufen kleiner Automatisierungen. Sie erledigen diese Routinearbeit rund um die Uhr für 0 € — bis genau zu dem Moment, in dem die Maschine, auf der sie laufen, ausfällt. Dann bitte ich kein ertrinkendes System, sich selbst zu retten: Ich öffne Claude Code auf derselben Maschine und lasse ein stärkeres Modell die Sache reparieren.

tl;dr

Einfache, wiederkehrende Arbeit: lokale OpenClaw-Agenten. Kostenlose Tokens, immer aktiv.
Wirklich komplex oder kaputt: Claude Code, direkt auf der Maschine ausgeführt, auf der OpenClaw läuft.
Der wichtige Teil: Claude Code repariert nicht nur — es richtet alles so ein, dass OpenClaw es beim nächsten Mal selbst schafft (oder zumindest übersteht).

Die zweistufige Idee

Lokale Modelle reichen für eine ganze Menge: Beiträge entwerfen, Dienste überwachen, Chatnachrichten einspeisen, geplante Jobs ausführen. Aber sie haben eine Obergrenze — kleinerer Kontext, schwächerer Debugging-Instinkt und die Angewohnheit, selbstbewusst Dinge neu zu starten, die eigentlich eine echte Diagnose bräuchten.

Die Faustregel: Wenn die Lösung ein bekanntes Runbook ist, führt OpenClaw es aus. Wenn die Lösung erst herausgefunden werden muss, ist das Claude Codes Job.

Ein reales Beispiel: das crash-loopende Gateway

Eines Morgens crash-loopte das OpenClaw-Gateway und hinterließ nichts als:

agents.list.5: Invalid input

Kein Agent wurde in der Fehlermeldung genannt. Neustarts halfen nicht — die Konfiguration wurde genauso schnell wieder kaputtgemacht, wie sie repariert wurde. Ein lokales Modell hätte es endlos in einer Schleife neu gestartet.

Claude Code, direkt auf der Maschine ausgeführt, spürte die Ursache auf: OpenClaws Identity-Reconcile-Schritt las bei jedem Start eine veraltete Workspace-Datei ein, die von einer früheren Aufräumaktion übrig geblieben war, und injizierte dabei eine ungültige Agenten-Definition erneut in die Live-Konfiguration. Die dauerhafte Lösung bestand aus drei Teilen:

Die veraltete Quelldatei korrigieren (die eigentliche Ursache),
Die saubere Gateway-Konfiguration wiederherstellen,
Durch einen vollständigen Start-und-Neustart-Zyklus verifizieren, bis jede Unit stabil oben blieb.

Das ist das Muster: Der sichtbare Fehler steckte in der Konfiguration, aber die Ursache war eine Datei, die seit Wochen niemand mehr angesehen hatte. Diagnose statt Neustarts.

„Repariere es so, dass OpenClaw es beim nächsten Mal selbst kann”

Die zweite Hälfte jeder Claude-Code-Sitzung ist der Teil, den die meisten Leute überspringen: Nach der Reparatur lasse ich das Wissen zurück in das lokale System einfließen, damit dieselbe Problemklasse nie wieder das teure Modell braucht. In der Praxis bedeutet das:

Runbooks, denen die lokalen Agenten folgen können. Schritt-für-Schritt-Anleitungen, geschrieben für ein kleineres Modell — überprüfbare Schritte, exakte Befehle, feste Regeln. Mein wöchentlicher Site-Refresh-Job läuft genau nach einer solchen Datei.
Leitplanken statt Wachsamkeit. Nach einem Vorfall hat Claude Code eine fail-closed-Prüfung vor jeder Veröffentlichung in den Build dieser Site eingebaut (Secret-Scan + Content-Regeln), damit kein Agent — lokal oder Cloud — etwas Peinliches veröffentlichen kann.
Watchdogs für die bekannten Fehlerbilder. Timeouts, abgestimmt auf langsame lokale Modelle, sich selbst löschende Follow-up-Timer für delegierte Arbeit, Health-Checks, die sich in meiner Chat-App melden, statt still zu versagen.

Wenn dasselbe das nächste Mal wackelt, übernimmt OpenClaw das mit kostenlosen Tokens, und Claude Code wird nur noch für wirklich neue Probleme gerufen.

Warum Claude Code auf der OpenClaw-Maschine ausführen?

Auf derselben Maschine ausgeführt, liest es die echten Logs, die echte Konfiguration, die echten Dienst-Zustände — und verifiziert die Lösung end-to-end, statt aus meiner Beschreibung zu raten. Eine durch mich gefilterte Beschreibung ist genau der Weg zu plausibel klingenden, aber falschen Lösungen.

Stolperfallen

Lokale Agenten sich nicht mitten im Vorfall selbst reparieren lassen. Ein Agent, dessen eigenes Gateway kaputt ist, macht die Sache nur schlimmer. Von außen reparieren (Claude Code), dann die Kontrolle zurückgeben.
Auf der dauerhaften Lösung bestehen. „Einfach neu starten” ist nur ein Symptom-Pflaster. Explizit nach der Ursache fragen und den Assistenten beweisen lassen, dass die Lösung einen Neustart-Zyklus übersteht.
Das Runbook schreiben lassen, solange der Kontext noch frisch ist. Die beste Dokumentation eines Vorfalls schreibt genau das, was ihn gerade repariert hat — Minuten nach der Reparatur.
Secrets aus dem Kreislauf heraushalten. Runbooks und Briefings, die die Agenten lesen, sollten frei von Secrets sein; Schlüssel gehören in die Umgebung, nicht in den Fließtext.