OpenClaw auf X: Öffentliche Replies mit Allowlist absichern

Jede Antwort, die ein OpenClaw-Agent auf X gibt, steht öffentlich unter dem Post, der ihn erwähnt hat. Das in OpenClaw enthaltene X-Plugin (Paket @openclaw/x) macht aus Erwähnungen eines Bot-Kontos Gespräche mit dem Agenten und veröffentlicht dessen Antwort als Reply. Bevor der Kanal live geht, sollten zwei Fragen geklärt sein: Wer darf eine Antwort auslösen? Und was steht anschließend öffentlich unter dem eigenen Account?

Was der Agent sieht und was er darf

Jede X-Konversation läuft als eigener Gruppen-Thread, zugeordnet über die conversation_id. Der Agent bekommt die auslösende Erwähnung, verfügbare Vorgängerposts, weitere Beiträge der Konversation und zitierte Posts. Standardmäßig fließen bis zu 50 Posts in diesen Kontext. Die Suche reicht sieben Tage zurück, gelöschte oder nicht verfügbare Posts fehlen.

Der Funktionsumfang ist schmal. Direktnachrichten, eigene Posts, Likes, Follows und Medienuploads unterstützt der Kanal nicht. Wer auf eine komplette X-Automation gehofft hat, bekommt einen Reply-Kanal. Mehr nicht.

Neue Erwähnungen holt das Plugin auf zwei Wegen ab. Über die Activity API schickt X Ereignisse direkt an das Plugin, beim Polling fragt das Plugin regelmäßig selbst nach. Für den Stream braucht es ein separates App-Bearer-Token. Fehlt es, fallen die Modi auto und stream auf Polling zurück. Kann der Stream nicht starten, nennt die Statusmeldung des Kanals den betroffenen Endpunkt und den HTTP-Status, während das Polling weiterläuft.

Allowlist statt offener Tür

Standardmäßig können nur freigegebene Autoren einen Reply auslösen. Alle anderen werden stillschweigend verworfen, solange der Gastmodus (guests.enabled) nicht aktiv ist. Einen Pairing-Hinweis bekommen sie nicht. In allowFrom gehört deshalb mindestens die numerische X-ID einer verantwortlichen Person. Handles haben dort nichts zu suchen.

Diese Voreinstellung ist richtig. Ein Bot, der auf jede beliebige Erwähnung öffentlich antwortet, lädt alle auf X dazu ein, dem Agenten Worte in den Mund zu legen.

Gepflegt wird die Liste in der Control UI, der Weboberfläche des Gateways, auf der Seite „X replies“. Administratoren fügen dort Nutzernamen hinzu, die das Plugin in stabile numerische IDs auflöst. Einträge aus der Konfiguration sind dort nur lesbar. Dieselbe Seite zeigt die geschätzten X-API-Kosten für den aktuellen Tag und den laufenden Abrechnungszeitraum. Optional speist sich die Liste zusätzlich aus einem GitHub-Repository: Wer dort Schreibrechte hat und im GitHub-Profil einen X-Account angibt, bekommt dieselben Rechte wie Maintainer aus der Konfiguration. Jede dabei aufgelöste X-ID kostet 0,01 US-Dollar, ein Cache verhindert wiederholte Abfragen. Ich würde diesen Abgleich nur für Repositories einschalten, deren Schreibberechtigte man tatsächlich kennt, denn jede Person mit Push-Rechten kann dann öffentliche Antworten des Bots auslösen.

Wie die Antwort auf X aussieht

Das Plugin zerlegt lange Antworten in eine Kette eigener Replies mit höchstens 280 gewichteten Zeichen pro Post, wobei jede URL als 23 Zeichen zählt. Der letzte Teil trägt standardmäßig die Signatur „🤖 automated reply“. Ein leerer Wert für replySignature schaltet sie ab. Sinnvoll ist das selten, denn die Kennzeichnung zeigt Mitlesenden, dass hier kein Mensch schreibt.

Startet eine Anfrage aus dem Maintainer-Kreis eine sichtbare Arbeitssitzung, hängt das Plugin deren Link an den Reply. Öffentlich lesbar ist dieser Link nur, wenn die Veröffentlichung bestätigt wurde. Sonst steht dort „Work session (sign-in required)“.

Vor dem Start bleiben damit drei Entscheidungen: wer auf der Allowlist steht, ob GitHub-Rechte dort mitbestimmen dürfen und ob die Bot-Signatur sichtbar bleibt. Alle drei wirken öffentlich. Fühlt sich niemand für die Liste zuständig, sollte der Agent auf X gar nicht antworten.