OpenClaw auf Main trennt Update-Ergebnismeldungen von freiwilligen Funktionsstatistiken

Wenn du OpenClaw aktualisierst, erfährt das Projekt künftig, ob das Update geklappt hat. Deine Installation schickt nach jedem Update eine kurze Meldung an die Entwickler: alte Version, neue Version, gelungen, gescheitert oder zurückgerollt. Das ist neu, und es ist standardmäßig eingeschaltet.

Der Grund ist einfach. OpenClaw fragt schon heute einmal am Tag nach, ob es eine neuere Version gibt. Daraus sehen die Entwickler zwar, wie viele Installationen es gibt, aber nicht, ob ihre Updates bei den Nutzern funktionieren. Geht ein Update auf vielen Rechnern schief, merken sie es erst, wenn sich jemand beschwert. Genau diese Lücke schließt Pull Request #154067, der inzwischen in den Hauptzweig gemergt ist.

Wichtig für dich: Diese Ergebnismeldung ist etwas anderes als die anonymen Nutzungsstatistiken, die OpenClaw ebenfalls anbietet. Die Statistiken bleiben aus, solange du sie nicht ausdrücklich einschaltest. Die Ergebnismeldung läuft dagegen mit, es sei denn, du schaltest den täglichen Versionscheck ab. Der Rest dieses Artikels erklärt, was genau in einer Meldung steht, mit welchem Schalter du sie stoppst und in welchen Fällen OpenClaw von sich aus nichts sendet.

Ergebnismeldung und Funktionsstatistik sind getrennte Schalter

Für die Ergebnismeldungen musst du keine Funktionsstatistiken freigeben; diese bleiben weiter standardmäßig aus. Die Telemetrie-Dokumentation beschreibt dasselbe Verhältnis: Abgeschlossene Updates senden standardmäßig einen begrenzten Bericht, der denselben Opt-outs für automatische Anfragen unterliegt. Anonyme Funktionsstatistiken sind dort ausdrücklich Opt-in.

Zuständig sind laut Dokumentation die Regeln für automatische Update-Anfragen, nicht der Statistik-Schalter. update.checkOnStart: false oder OPENCLAW_NO_AUTO_UPDATE=1 stoppen tägliche Checks und Ergebnismeldungen gemeinsam. openclaw telemetry off, telemetry.enabled: false und DO_NOT_TRACK schalten dagegen Funktionsstatistiken und die Installationszählung ab, aber weder den täglichen Check noch die Ergebnismeldungen. Mit update.checkOnStart: false entfällt außerdem der Update-Hinweis, selbst bei aktivierten automatischen Updates; explizite Update-Befehle bleiben verfügbar. Ganz abschalten heißt also: kein Hinweis auf neue Versionen.

In Nix- und CI-Umgebungen unterdrückt OpenClaw die Ergebnismeldungen laut PR ebenfalls, auch wenn in CI ein eigener Endpunkt gesetzt ist. Ist die aktuelle Konfiguration ungültig oder nicht lesbar, wird nichts gesendet.

Was in einer Meldung steht

Laut PR liest OpenClaw das Ergebnis aus seiner bestehenden Update-Buchführung und überträgt daraus nur eine fest abgegrenzte Auswahl. Sie enthält die Version vor dem Update, die Zielversion, die resultierende und die laufende Version, dazu feste Kategorien für Plattform, Installationsart, Kanal und Ergebnis, eine grobe Dauer, die beobachtete Verifikation, Rollback-Angaben und Fehlercodes aus einer Allowlist. Insgesamt sind es genau 18 Felder, ohne Lauf-, Installations- oder Nutzerkennungen, ohne rohen Diagnosetext, Logs, Pfade oder Konfiguration.

Auch bei den Versionsnummern bleibt der Spielraum klein. Private Versionslabels, Metadaten und führende Nullen werden auf unknown abgebildet.

openclaw telemetry show zeigt laut Dokumentation, ob Funktionsstatistiken aktiv sind und warum, welchen Endpunkt die Anfragen nutzen und wann der letzte erfolgreiche Check lief. Sind alle automatischen Anfragen abgeschaltet, erscheint dort Request: none samt Begründung. So lässt sich ein Opt-out prüfen. Eine Vorschau der Ergebnismeldung bietet der Befehl nicht.

Erst HEAD, dann POST

Der PR beschreibt einen zweistufigen Ablauf. Bevor überhaupt ein Meldungsinhalt rausgeht, schickt der Client eine HEAD-Anfrage ohne Inhalt an exakt den konfigurierten Endpunkt und fragt so ab, ob der Empfänger Ergebnismeldungen annimmt. Nur eine Antwort mit HTTP 204 und dem Header OpenClaw-Update-Results: 2 erlaubt den POST; ein 405 von älteren Empfängern oder ein 503 bei unkonfigurierten unterdrückt ihn. Ohne angekündigte Fähigkeit des Empfängers sendet der Client keinen Outcome-POST.

Kein passender Empfänger, keine Meldung.

Beide Anfragen teilen sich eine Frist von drei Sekunden, folgen keinen Weiterleitungen und nutzen den festen User-Agent openclaw-update-result/1. Die Richtlinie prüft OpenClaw unmittelbar vor dem HEAD und noch einmal vor dem POST. Endpunkte mit Zugangsdaten in der URL oder einem Nicht-HTTP-Schema bekommen gar nichts.

Weiterlesen: Backoff und Jitter: Wiederholungen für Agenten begrenzen.

Was bewusst nicht passiert

Laut PR wird der Versuch lokal verbucht, bevor die Anfrage ins Netz geht. Pro Stunde ist höchstens ein Versuch erlaubt, historische Läufe werden nicht nachgemeldet, und eine dauerhafte Wiederholungswarteschlange oder eine Garantie für genau eine Zustellung gibt es nicht. Ein Nachholen beim Start ist laut Dokumentation ebenfalls nicht vorgesehen, und Antworten oder Nutzdaten werden nicht protokolliert.

Dazu kommen einige Sonderfälle. Das erste Upgrade von einem älteren Updater meldet nichts, weil diesem Lauf die Zulassungsmarke fehlt. Wird die Richtlinie zwischendurch widerrufen, geht nichts raus; verbraucht wird nur der lokale Versuch dieser Stunde. Abgelehnte Chat-Anfragen, die nie zu einem Versuch geführt haben, etwa mit owner_required, meldet OpenClaw nicht und zählt sie auch nicht gegen das Stundenlimit.

Brichst du openclaw update vor der Aktivierung mit Ctrl-C ab, schließt OpenClaw den Lauf laut Dokumentation als fehlgeschlagen ab, und dieses Ergebnis ist meldefähig. Gesendet wird es trotzdem nur, wenn Richtlinie, Stundenlimit und Empfänger es zulassen. Solange eine Meldung unterwegs ist, kann sich das Beenden der CLI um bis zu drei Sekunden verzögern. Wenn du Updates per Skript anstößt und auf das Prozessende wartest, plane diese kurze Verzögerung ein.

Update und eigener Empfänger bleiben unabhängig

Laut PR kann das Melden ein Update weder scheitern lassen noch zurückrollen. Schlägt ein Schreibvorgang der Buchführung fehl, wird nur die Buchführung zurückgerollt. Die Meldung geht erst raus, nachdem der abschließende Schreibvorgang des Updates gespeichert ist.

Weiterlesen: Rollback mit klarer Grenze.

Für Tests oder Self-Hosting nennt die Dokumentation die Variable OPENCLAW_TELEMETRY_ENDPOINT, die die vollständige Ersatz-URL aufnimmt. Eigene Endpunkte fallen dabei nie auf den Foundation-Endpunkt zurück. Antwortet dein Empfänger auf den HEAD nicht mit 204 und dem passenden Header, folgt kein POST.

Main-Stand, keine zugesicherte Zustellung

Belegt ist der Merge in main. Ob und in welcher veröffentlichten Version die Funktion ankommt, geht aus dem PR nicht hervor. Auch die Empfängerseite bleibt dort offen: Inbetriebnahme und Zustellungsnachweis des kompatiblen Empfängers und des getrennten Ergebnis-Datensatzes gelten laut PR als separat freigegebene Arbeit und sind nicht nachgewiesen. Solange ein Empfänger die Fähigkeit nicht ankündigt, sendet der Client keinen Meldungsinhalt.

Die Meldung selbst enthält laut Dokumentation keine Kennungen, keine exakten Client-Zeitstempel und keine Geodaten. Eine Verbindung hat trotzdem eine IP-Adresse: Die Infrastruktur kann sie vorübergehend verarbeiten, die Ergebniszeilen speichern weder sie noch Geodaten. Die ungefähre Standortangabe gehört zu den aufgezeichneten täglichen Update-Checks, nicht zu den Ergebnismeldungen. Ersatz-Endpunkte haben eigene Verarbeitungsregeln.