OpenClaw 2026.9.2: message send kann Multi-Agent-Alerts stummschalten

Ein erfolgreicher Backup-Job kann seine Warnung verlieren, ohne selbst fehlzuschlagen. Ein am 8. September 2026 gemeldeter OpenClaw-Fehler betrifft openclaw message send in Multi-Agent-Flotten mit expliziter Eigentümerzuordnung und ohne gesetzten System-Agent; der Bericht in Issue #141835 ordnet das Verhalten als Regression ein.

Die Folge ist heikel: Skripte und Cron-Jobs nutzen den Befehl für Benachrichtigungen, doch der Versand bricht für alle Kanäle mit einem AgentSelectionRequiredError ab. Die Warnung verschwindet. Fängt ein Skript den Fehler mit || true ab, läuft seine eigentliche Aufgabe weiter und wirkt erfolgreich, obwohl die Meldung ausbleibt.

Der vorgeschlagene Ausweg existiert am Befehl nicht

Die Fehlermeldung fordert dazu auf, einen Agenten per --agent <id> auszuwählen, wie Issue #141835 zeigt. openclaw message send registriert diese Option jedoch weder am Unterbefehl noch am übergeordneten message-Befehl oder global. Der naheliegende Reparaturversuch endet bei einer unbekannten Option.

Der Vertragsbruch betrifft auch openclaw directory: Laut Issue #124679 scheitern die Verzeichnisbefehle in einer Installation mit mehreren Agenten, während --agent ebenfalls abgewiesen wird. Vorhandene Routing-Bindings lösen den Eigentümer auf diesem CLI-Pfad nicht auf.

Das Risiko liegt damit in der gemeinsamen Owner-Auflösung. Zwei getrennte CLI-Oberflächen liefern eine Handlungsanweisung, die sie selbst nicht umsetzen. Automationen haben keinen Selektor, mit dem sie den zuständigen Agenten pro Aufruf festlegen können.

Was Betreiber jetzt prüfen sollten

Der Test gehört an den tatsächlichen Versandpfad. openclaw message send sollte mit dem produktiv genutzten Kanal und Ziel ausgeführt werden, zunächst wenn möglich als Dry-Run. Erscheint AgentSelectionRequiredError, muss der Exit-Code sichtbar in Logs und Monitoring landen; ein pauschales Unterdrücken verschleiert genau den Ausfall, den die Benachrichtigung melden sollte.

Als vorläufige Abhilfe nennt Issue #141835 einen festen Umgebungs-Owner über agents.defaults.systemAgent.agentId. Beim Reporter griff die Änderung ohne Neustart des Gateway.

Vor der Übernahme sollte das Betriebsteam die bestehenden Channel-Routing-Bindings prüfen und festlegen, welcher Agent systemweite Aufrufe besitzen darf. Die Einstellung entscheidet nicht bloß über eine einzelne Nachricht, sondern über die Zuordnung von Diensten, die ohne ausdrücklichen Agentenkontext im Hintergrund laufen.

Die Mindestregel ist einfach: Erfolg des Jobs und Erfolg seiner Benachrichtigung getrennt überwachen. Solange der CLI-Vertrag keinen funktionierenden Selektor anbietet, muss ein Test nach jedem OpenClaw-Update belegen, dass mindestens eine echte Cron-Meldung ihr Ziel erreicht.

Reality Check

• Getestet mit: laut Fehlerbericht OpenClaw 2026.9.2 in einer expliziten Multi-Agent-Flotte; nicht selbst getestet
• Funktioniert gut für: reproduzierbare Prüfung von Skript- und Cron-Benachrichtigungen
• Bricht wahrscheinlich bei: mehreren Agenten ohne gesetzten agents.defaults.systemAgent.agentId
• Nicht getestet: weitere CLI-Oberflächen neben message send und directory
• Sicherheitsrisiko: mittel
• Betriebsaufwand: niedrig
• Recovery: ja, über einen festgelegten System-Agent; ein CLI-Fix ist in den Quellen nicht bestätigt