OpenClaw-Crons brauchen klare Sessions und Zustellung

OpenClaw behandelt Cron-Jobs nicht nur als Zeitplan für Prompts. Die aktuelle CLI-Doku beschreibt openclaw cron als Kommando zur Verwaltung von Jobs im Gateway-Scheduler und macht dabei eine Trennung explizit, die bei Agenten-Automation schnell über Stabilität oder Chaos entscheidet: In welcher Session läuft der Job, und wer liefert das Ergebnis in den Chat?

Das klingt nach Implementierungsdetail. Ist es aber nicht. Sobald ein Agent regelmäßig Recherche, Reports oder Wartungsaufgaben ausführt, reicht ein Timer allein nicht mehr. Der Lauf braucht berechenbaren Kontext, eine nachvollziehbare Ausgaberoute und eine saubere Grenze zwischen interner Ausführung und externer Benachrichtigung. Genau diese Grenze ist auch in anderen OpenClaw-Workflows entscheidend, etwa wenn Automationen nicht versehentlich in alte Gesprächsrouten oder falsche Zustellkanäle zurückfallen sollen.

Session ist nicht gleich Session

Die Doku nennt für --session vier Werte: main, isolated, current und session:<id> (laut OpenClaw-Doku, abgerufen am 9. 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.

Zustellung ist ein eigener Vertrag

Die zweite wichtige Linie zieht OpenClaw bei Delivery. openclaw cron list und openclaw cron show <job-id> zeigen laut Doku eine Vorschau der aufgelösten Zustellroute. Für channel: "last" wird sichtbar, ob die Route aus der Main- oder Current-Session stammt oder geschlossen fehlschlägt.

Das ist operativ wertvoll. Ein Cron kann technisch erfolgreich laufen und trotzdem an der Zustellung scheitern. Wenn die Route vorab sichtbar ist, wird Delivery prüfbar statt magisch. Gerade bei Chat-Agenten ist das wichtig, weil ein Ergebnis nicht nur berechnet, sondern auch am richtigen Ort landen muss.

Die Doku beschreibt außerdem provider-prefixed targets. 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 laut Doku 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 des explizit gesetzten Channels auszuhebeln.

Isolierte Jobs sollen nicht still verschwinden

Für neu angelegte isolierte Cron-Jobs nennt die Doku noch 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 eine pragmatische Entscheidung. 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.

Die Doku formuliert Delivery Ownership als geteilte Verantwortung zwischen Agent und Runner. Der Agent kann direkt mit dem message-Tool senden, wenn eine Chat-Route verfügbar ist. announce dient als Fallback für die finale Antwort des Laufs. Auch hier steckt die eigentliche Relevanz in der Trennung: Der Agent darf aktiv zustellen, aber der Runner kann den Abschluss absichern.

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 man sich auf Benachrichtigungen verlässt. Drittens: Bei isolierten Jobs entscheiden, ob --announce gewünscht ist oder ob der Lauf ausdrücklich intern bleiben soll.

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 tiefer in diese Linie einsteigen will, findet sie auch in unserem OpenClaw-Schwerpunkt wieder.

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. Die Doku liefert dafür keine große Architekturtheorie, sondern konkrete Schalter. Das ist in diesem Fall die bessere Form von Produktreife.