OpenClaw plant konfigurierbaren Setup-Watchdog für isolierte Cron-Agenten

OpenClaw diskutierte im Juni 2026 mit Pull Request #88396 einen konfigurierbaren Setup-Watchdog für isolierte Cron-Agenten. Der Vorschlag traf genau die Stelle, an der Cron in der Praxis unangenehm wird: Nicht die Fachlogik eines Jobs scheitert, sondern schon der Startpfad davor. Im Alltag sieht das aus wie ein pünktlich geplanter Lauf, der intern nie sauber in die eigentliche Arbeit kommt.

Stand 24. August 2026: Der PR wurde am 28. Juni 2026 ohne Merge geschlossen. Die Konfigurationsoption cron.agentSetupWatchdogMs existiert nicht. Den Startpfad sichert OpenClaw heute anders ab — dazu unten mehr.

Warum das Thema größer ist als ein kleiner Timeout

In der OpenClaw-Doku gehört Cron fest zum Gateway. Jobs, Laufstatus und Historie liegen persistent in der gemeinsamen SQLite-Datenbank, und jeder Lauf wird als Background-Task erzeugt. Wer mehrere geplante Jobs über denselben Gateway-Knoten abwickelt, verlässt sich damit auf eine ganze Startkette: Scheduler, Persistenz, Kanal-Anbindung und isolierter Agentenlauf. Der Timer ist davon nur ein Glied.

Genau dort setzt der Watchdog an. Der PR behandelt das Setup isolierter Agenten, nicht die spätere Job-Logik. Wenn diese Phase hängen bleibt oder zu knapp budgetiert ist, sieht ein geplanter Lauf schnell wie ein sauber gestarteter Job aus, obwohl er operativ nie richtig in die Ausführung kommt. Im Betrieb ist das die unangenehme Fehlerklasse: Der Termin war da, aber die eigentliche Arbeit ist nicht verlässlich losgelaufen.

Was der Pull Request bereits klar signalisiert

Der Vorschlag ging über den PR-Titel hinaus: Er führte cron.agentSetupWatchdogMs als optionale Cron-Konfiguration ein. Blieb der Wert unset, sollte das bisherige Verhalten mit 60 Sekunden bestehen bleiben. Werte unterhalb einer Sicherheitsgrenze sollten auf mindestens 1.000 Millisekunden geklemmt werden. So hätte niemand den Watchdog versehentlich faktisch deaktiviert.

Das passt zur bestehenden Architektur. Die Doku beschreibt bereits, dass der Gateway beim Start überfällige isolierte Jobs nicht blind sofort nachschiebt, sondern sie aus dem Channel-Connect-Fenster heraus neu terminiert. OpenClaw behandelt den Startpfad also schon heute als empfindlichen Teil des Betriebsmodells. Ein konfigurierbarer Watchdog wäre die nächste logische Schraube an genau dieser Infrastrukturkante.

Wo die praktische Relevanz liegt

Ein fixer Setup-Timeout wirkt in kleinen Setups oft harmlos. In der Praxis unterscheiden sich Cron-Jobs aber deutlich. Ein leichter Reminder startet anders als ein isolierter Lauf, der erst Kanäle verbinden, Tools bereitstellen oder einen schwereren Agentenkontext hochziehen muss. Je dichter das Zeitfenster und je mehr Jobs am selben Morgen über einen Gateway-Knoten laufen, desto eher wird aus einer knappen Setup-Grenze ein operatives Problem statt eines theoretischen Details.

Deshalb ist die Konfigurierbarkeit hier mehr als Komfort. Sie verschiebt eine harte Annahme aus dem Code näher an die Umgebung, in der der Job wirklich läuft. Wer nur leichte Wakeups plant, kann weiter mit dem Default fahren. Wer schwerere isolierte Läufe bündelt, bekommt zumindest die Chance, das Setup-Fenster realistischer zu dimensionieren.

Wie der PR ausging

Die Review-Punkte gaben den Ausschlag. ClawSweeper monierte fehlenden realen Cron-Runtime-Proof und das Risiko übergroßer Timer-Werte. In Node kippen zu große setTimeout-Delays auf praktisch sofortige Ausführung. Dazu kam der Zuschnitt: Der PR zielte auf eine globale Cron-Konfiguration statt auf eine job-spezifische Stellschraube. Für gemischte Cron-Lasten bleibt eine einzelne globale Zahl grob.

Am 28. Juni 2026 wurde der PR ohne Merge geschlossen. cron.agentSetupWatchdogMs gibt es in der Cron-Konfiguration nicht.

Was OpenClaw stattdessen gebaut hat

Liegen geblieben ist das Problem trotzdem nicht. Die aktuelle Automations-Dokumentation beschreibt phasenspezifische Watchdogs auf dem Startpfad. Sie melden konkret, wo ein isolierter Lauf hängt — etwa cron: isolated agent setup timed out before runner start oder cron: isolated agent run stalled before execution start (last phase: context-engine).

Der entscheidende Unterschied liegt in der Kappung. Diese Watchdogs greifen auch bei CLI-gestützten Providern, bevor der externe Prozess überhaupt startet. Und sie sind unabhängig von langen timeoutSeconds-Werten gedeckelt. Ein Cold-Start-, Auth- oder Kontextfehler wird dadurch sichtbar, statt still in einem großzügigen Job-Budget zu versickern.

Für den Betrieb heißt das: Statt einer Zahl, die du selbst dimensionierst, bekommst du eine Fehlermeldung, die die Phase benennt. Das ist weniger Stellschraube und mehr Diagnose. Wer regelmäßig schwere isolierte Läufe bündelt, arbeitet damit im Zweifel schneller als mit einem selbst gesetzten Setup-Fenster.

Was der Fall über OpenClaw zeigt

Interessant ist hier der Reifegrad. OpenClaw behandelt Cron erkennbar als Laufzeitpfad für heterogene Agentenjobs. Ein simpler Termin-Trigger sieht anders aus. Der abgelehnte PR und die stattdessen gebauten Phasen-Watchdogs zeigen dieselbe Bewegung: Der Startpfad bekommt eine eigene Fehlerklasse.

Für einen abgelehnten Pull Request ist das ein ordentliches Ergebnis. Die Diagnose ist heute besser als vor dem Vorschlag, auch ohne die vorgeschlagene Konfigurationsoption.