OpenClaw Cron wird nicht zugestellt: Sessions, Delivery und Fehlersuche

Ein OpenClaw-Cron kann pünktlich starten, sauber durchlaufen und trotzdem nicht dort landen, wo du ihn erwartest. Dann ist der Fehler selten nur „der Cron geht nicht“. Meist hängen drei Dinge auseinander: der Zeitplan, die Session-Bindung und die Zustellung in den Chat.

Die CLI-Doku beschreibt openclaw cron als Gateway-Scheduler für Hintergrundjobs. Entscheidend ist dabei nicht nur, wann ein Job läuft, sondern in welcher Session er ausgeführt wird und welche Delivery-Route am Ende für die Antwort zuständig ist. Genau an dieser Trennung entstehen die typischen Fälle: keine Nachricht, falscher Chat, falscher Kontext oder ein Lauf, der intern als Fehler zählt, obwohl außen nur Stille ankommt.

Für die Grundlagen zu Zeitplänen, Heartbeats und wiederkehrenden Automationen passt weiterhin unser Tutorial zu Cron-Jobs, Heartbeats und Automationen. Dieser Artikel ist die Fehlersuche daneben: Was prüfst du, wenn die Automation zwar angelegt ist, aber nicht zuverlässig zugestellt wird?

Das Symptom: Cron läuft, aber niemand sieht das Ergebnis

Das wichtigste Muster ist die Trennung von Ausführung und Zustellung. Ein Job kann vom Scheduler akzeptiert werden, aber die finale Antwort erreicht den Chat nicht. Umgekehrt kann ein Job korrekt zugestellt werden, aber aus einem frischen isolierten Kontext heraus anders antworten als in der Unterhaltung, aus der du ihn erstellt hast.

Praktisch sieht das oft so aus:

• Ein Reminder oder Report wurde angelegt, aber im Chat erscheint nichts.
• openclaw cron list zeigt den Job, die erwartete Nachricht fehlt trotzdem.
• Ein isolierter Lauf reagiert nicht auf Gesprächskontext, den du implizit vorausgesetzt hast.
• Ein Mehrkanal-Ziel wirkt eindeutig, ist aber ohne Provider-Präfix nicht eindeutig genug.
• Ein Modell-, Auth- oder Setup-Problem zählt als Cron-Fehler, obwohl kein normaler Antworttext entsteht.

Die schlechte Diagnose wäre: „Cron kaputt.“ Die bessere Diagnose ist: Erst klären, ob der Job geplant ist, dann ob er gelaufen ist, dann ob Delivery aufgelöst werden kann.

Session ist nicht gleich Session

Die Doku nennt für --session vier Werte: main, isolated, current und session:<id> (laut OpenClaw-Doku, abgerufen am 26. Mai 2026). main bindet einen Cron an die Hauptsession des Agenten. isolated erzeugt für jeden Lauf ein frisches Transcript und eine neue Session-ID. current bindet den Job an die beim Anlegen aktive Session. session:<id> pinnt den Job an einen expliziten persistenten Session-Key.

Damit beschreibt OpenClaw vier Betriebsarten mit sehr unterschiedlichem Risikoprofil. main ist naheliegend, wenn ein Cron wirklich Teil des laufenden Agenten-Kontexts sein soll. isolated passt besser für Jobs, die reproduzierbar und möglichst frei von Gesprächsresten laufen müssen. current ist praktisch, hängt aber stärker am Moment der Job-Erstellung. session:<id> ist die explizite Variante für Setups, die eine bestimmte dauerhafte Session gezielt adressieren wollen.

Gerade isolated ist der interessante Fall. Die Doku sagt, dass isolierte Läufe den umgebenden Gesprächskontext zurücksetzen. Ebenfalls zurückgesetzt werden Channel- und Gruppenrouting, Send-/Queue-Policy, Elevation, Origin und die ACP-Runtime-Bindung. Sichere Präferenzen sowie explizit gewählte Modell- oder Auth-Overrides können dagegen über Läufe hinweg erhalten bleiben.

Für Agenten-Crons ist das eine sinnvolle Default-Denkweise: Ein automatischer Lauf sollte nicht versehentlich auf die Stimmung, den Auftrag oder die Zustellroute einer früheren Unterhaltung reagieren. Isolation kostet etwas Komfort, verhindert aber genau die Sorte Kontext-Leckage, die bei wiederkehrenden Jobs schwer zu debuggen ist.

Diagnose: erst Route, dann Run-Historie

Wenn ein Cron nicht zugestellt wird, sind zwei CLI-Ansichten besonders wichtig. openclaw cron list und openclaw cron show <job-id> zeigen laut Doku eine Vorschau der aufgelösten Delivery-Route. Für channel: "last" wird sichtbar, ob die Route aus der Main- oder Current-Session stammt oder geschlossen fehlschlägt.

Das ist der wichtigste Prüfpunkt. Wenn die Delivery-Preview schon keine belastbare Route zeigt, ist der Scheduler nicht der eigentliche Verdächtige. Dann fehlt ein explizites Ziel, die letzte Chat-Route ist nicht mehr verfügbar oder last zeigt nicht auf den Ort, den du erwartest.

Der zweite Prüfpunkt ist die Run-Historie. Für manuelle Läufe beschreibt die Doku openclaw cron run <job-id> und danach openclaw cron runs --id <job-id> --run-id <run-id>. Mit --wait blockiert die CLI bis zu einem terminalen Status und beendet nur bei ok erfolgreich; error, skipped oder Timeout liefern einen Fehler. Das ist nützlich, wenn du nicht raten willst, ob ein Lauf wirklich fertig wurde.

Als Entscheidungsbaum reicht meistens:

1. Taucht der Job in openclaw cron list auf?
2. Zeigt openclaw cron show <job-id> eine plausible Delivery-Route?
3. Gibt es in openclaw cron runs einen Lauf mit ok, error oder skipped?
4. Wenn ok: Hat der Agent selbst direkt zugestellt oder sollte announce die finale Antwort liefern?
5. Wenn error oder skipped: Liegt der Fehler vor dem Modellstart, beim Provider, bei Auth, beim Prompt oder bei Delivery?

Diese Reihenfolge verhindert die klassische Sackgasse, sofort am Prompt zu schrauben, obwohl der Job schlicht keinen gültigen Zustellvertrag hat.

Zustellung ist ein eigener Vertrag

Die zweite wichtige Linie zieht OpenClaw bei Delivery. Provider-prefixed Targets können laut Doku unklare Announce-Ziele auflösen. Ein Ziel wie telegram:123 kann Telegram auswählen, wenn delivery.channel fehlt oder auf last steht. Ist der Channel explizit gesetzt, muss der Prefix dazu passen; channel: "whatsapp" zusammen mit to: "telegram:123" wird abgelehnt. Service-Prefixe wie imessage: und sms: bleiben channel-eigene Zielsyntax.

Damit verhindert OpenClaw eine typische Mehrkanal-Falle: Eine ID allein sagt nicht immer, welcher Provider gemeint ist. Der Prefix macht die Absicht sichtbar, ohne die Zuständigkeit eines explizit gesetzten Channels auszuhebeln.

Für neu angelegte isolierte Cron-Jobs nennt die Doku außerdem eine wichtige Default-Regel: Isolated cron add Jobs verwenden standardmäßig --announce Delivery. Wer die Ausgabe intern halten will, nutzt --no-deliver; --deliver bleibt als veralteter Alias für --announce erhalten.

Das ist pragmatisch. Isolation trennt den Lauf vom bisherigen Chat-Kontext, aber der Job soll trotzdem nicht automatisch in einem unsichtbaren Raum enden. --announce gibt dem Runner eine Zustellverantwortung. Gleichzeitig bleibt mit --no-deliver ein sauberer Weg für rein interne Automationen offen.

Failure Modes: warum ein Job still wirkt

OpenClaw unterscheidet inzwischen mehrere Fälle, die von außen ähnlich aussehen können. Die Doku nennt Failure-Zustellung über delivery.failureDestination, eine globale Cron-Failure-Destination oder das primäre Announce-Ziel. Isolierte Jobs akzeptieren Failure-Destinations in allen Modi; Main-Session-Jobs nur unter engeren Bedingungen, wenn primär Webhook-Delivery genutzt wird.

Wichtig ist auch: Isolierte Cron-Läufe behandeln agentenseitige Run-Level-Fehler als Jobfehler, selbst wenn kein Antwort-Payload entsteht. Modell- oder Providerfehler zählen also nicht einfach als leere Antwort, sondern können Fehlerzähler und Benachrichtigungen auslösen.

Für besonders tückische Fälle nennt die Doku phase-spezifische Fehler vor dem Modellaufruf, etwa wenn Setup, Session-Lookup, Auth, Hooks, Prompt-Aufbau oder CLI-Start hängen bleiben. Dann ist nicht der Inhalt des Cron-Prompts das Problem, sondern die Vorlaufphase. In solchen Fällen helfen Run-Historie und Failure-Notification mehr als ein Rewrite des Jobs.

Es gibt außerdem zwei bewusst stille Fälle: Isolierte Cron-Läufe unterdrücken rein veraltete Zwischenbestätigungen und prompten einmal nach einem echten Ergebnis. Und wenn ein Lauf nur das Silent-Token NO_REPLY oder no_reply zurückgibt, werden direkte Zustellung und Fallback-Zusammenfassung unterdrückt. Das ist kein Delivery-Bug, sondern ein ausdrückliches Schweigen.

Recovery: was du konkret änderst

Wenn die Delivery-Preview falsch oder leer ist, korrigierst du zuerst die Zustellung, nicht den Zeitplan. Die Doku zeigt dafür Bearbeitungen wie openclaw cron edit <job-id> --announce --channel telegram --to "123456789" oder für Slack --channel slack --to "channel:C1234567890". Für rein interne Jobs ist openclaw cron edit <job-id> --no-deliver die klare Variante.

Wenn ein Job aus der falschen Session lebt, ist die Recovery heikler. current ist beim Anlegen bequem, kann später aber schwerer zu erklären sein. Für wiederkehrende Automationen ist isolated oft besser, solange du alle benötigten Informationen in den Prompt schreibst und Delivery explizit setzt. Für dauerhaft gebundene Arbeitskontexte ist session:<id> klarer als ein implizites „der Chat von damals“.

Wenn die Run-Historie Fehler vor dem Modellstart zeigt, prüfst du nicht zuerst den Artikeltext, sondern Gateway-, Auth-, Provider- und Hook-Kontext. Die Doku beschreibt unter anderem lokale Provider-Preflights: Unerreichbare lokale Modellendpunkte können bei isolierten Jobs als skipped landen und später erneut versucht werden. Das ist ein anderer Fehler als „Prompt erzeugt keine Antwort“.

Wenn alte Jobs nach Format- oder Delivery-Änderungen merkwürdig aussehen, verweist die Doku auf openclaw doctor --fix. Das normalisiert ältere Cron-Felder und migriert bestimmte Legacy-Delivery-Angaben. Das ist kein Allheilmittel, aber der richtige Startpunkt, wenn alte Jobs noch aus einer früheren Cron-Struktur stammen.

Reality Check

• Getestet: Die Diagnosepunkte in diesem Artikel stützen sich auf die aktuelle OpenClaw-CLI-Doku zu openclaw cron, insbesondere Sessions, Delivery, Failure-Delivery, Run-Historie und Migration älterer Jobs.
• Nicht getestet: Dieser Artikel behauptet nicht, dass jedes Plugin-Ziel in jeder Installation gleich heißt. Provider-Ziele, Chat-IDs und Failure-Destinations hängen von deiner geladenen Messenger-Integration ab.
• Grenze: Ein erfolgreicher Cron-Lauf ist nicht automatisch eine erfolgreiche Chat-Nachricht. Zustellung bleibt ein eigener Vertrag.
• Sicherheitsgrenze: In Gruppen- oder Teamkanälen solltest du Zustellung explizit setzen. last ist praktisch, aber als dauerhafte Ops-Konfiguration schlechter prüfbar als ein klarer Channel mit Ziel.

Der praktische Effekt

Für robuste Agenten-Crons entsteht daraus ein klares Muster. Erstens: Den Session-Modus bewusst wählen, statt Cron-Jobs einfach an die aktuelle Unterhaltung zu hängen. Zweitens: Die Delivery-Route mit cron list oder cron show prüfen, bevor du dich auf Benachrichtigungen verlässt. Drittens: Bei isolierten Jobs entscheiden, ob --announce gewünscht ist oder ob der Lauf ausdrücklich intern bleiben soll. Viertens: Run-Historie und Failure-Destination ernst nehmen, wenn ein Lauf still bleibt.

Das passt zu einem Grundmotiv vieler OpenClaw-Themen auf agentenlog.de: Agenten werden nicht dadurch verlässlich, dass sie mehr Autonomie bekommen, sondern dadurch, dass Kontext, Ausführung und Zustellung sauber getrennt sind. Wer OpenClaw produktiv betreibt, sollte Cron deshalb nicht als Timer behandeln, sondern als kleinen Betriebsvertrag: Session, Modell, Prompt, Zustellung, Fehlerpfad.

OpenClaw-Crons werden dadurch nicht spektakulärer, aber verlässlicher. Und genau das zählt bei Automationen: Ein Agenten-Job ist erst dann gut gebaut, wenn Fehler sichtbar werden, bevor sie als falsche Nachricht, fehlende Nachricht oder schief gelaufener Kontext im Chat landen.