Signal mit OpenClaw verbinden: Messenger-Setup ohne Bastelchaos

Signal passt gut zu Agenten-Betrieb: vertraute App, Direktnachrichten, Gruppen und mobile Zustellung. Laut OpenClaw-Dokumentation ist der Kanal aber keine eingebaute libsignal-Integration, sondern läuft über signal-cli.

Der wichtige Punkt ist die Architektur. OpenClaw spricht mit signal-cli über HTTP: entweder mit einem nativen Daemon über JSON-RPC und SSE oder über den Container bbernhard/signal-cli-rest-api mit REST und WebSocket. Damit ist Signal kein reines „Schalter umlegen“-Feature, sondern ein kleiner Betriebsbaustein neben dem Gateway.

Du brauchst dafür eine laufende OpenClaw-Installation auf einem Server, eine Signal-fähige Bot-Kennung und eine Entscheidung, ob signal-cli direkt auf dem Host oder im Container laufen soll. Die OpenClaw-Doku beschreibt den Linux-Pfad ausdrücklich als auf Ubuntu 24 getestet. Andere Umgebungen sind damit nicht ausgeschlossen, sollten aber wie ein eigenes Deployment behandelt werden.

Bot-Kennung sauber trennen

Nach Angaben der OpenClaw-Dokumentation empfiehlt sich für den Bot eine separate Signal-Kennung. Das ist betrieblich sinnvoll, weil ein Agent sonst schnell mit privater Messenger-Nutzung kollidiert. Die Doku nennt außerdem SMS-Verifikation und Browserzugriff auf signalcaptchas.org als Voraussetzungen für die Registrierung.

Praktisch gibt es zwei Wege. Der schnellere Testpfad ist das Verlinken über QR-Code: signal-cli link -n "OpenClaw", danach wird der Code mit Signal gescannt. Der zweite Pfad ist die Registrierung einer dedizierten Bot-Kennung per Captcha und SMS-Verifikation. Beide Varianten führen zum gleichen Ziel: OpenClaw bekommt ein Signal-Konto, das der Gateway später als Kanal nutzen kann.

Der Unterschied liegt im Betriebsrisiko. Ein verlinktes Konto hängt stärker an einem bestehenden Signal-Setup. Eine dedizierte Bot-Kennung ist sauberer für Automatisierung, Monitoring und spätere Übergaben. Für produktive Agenten-Kommunikation ist die getrennte Kennung meist die robustere Wahl. Für lokale Tests reicht der QR-Link oft aus.

Die Konfiguration bleibt klein, aber präzise

Die OpenClaw-Dokumentation zeigt eine minimale Konfiguration unter channels.signal. Darin stehen enabled, die Bot-Kennung als account, der Pfad zu signal-cli über cliPath, die DM-Policy dmPolicy und erlaubte Absender in allowFrom.

Wichtig ist die Schreibweise: account erwartet laut Feldreferenz einen E.164-Wert, etwa mit führendem Pluszeichen. cliPath zeigt entweder direkt auf signal-cli oder nutzt den Namen, wenn das Binary im PATH liegt.

dmPolicy ist der zentrale Sicherheitshebel. Die Doku empfiehlt pairing. Damit wird nicht jede Direktnachricht ungeprüft zum Agenten durchgereicht, sondern ein Pairing-Prozess vorgeschaltet. Zum Funktionstest gehört deshalb nicht nur eine Nachricht an den Bot, sondern auch die Freigabe mit openclaw pairing approve signal <CODE>.

allowFrom zieht die Grenze noch enger. Laut Feldreferenz akzeptiert die Liste E.164-Werte oder Einträge in der Form uuid:<id>. Für den Einstieg ist eine kleine Allowlist vernünftiger als ein offenes Setup. Signal wirkt privat, ist für den Agenten aber ein produktiver Eingabekanal. Alles, was dort ankommt, kann Arbeit auslösen.

Direktnachrichten und Gruppen getrennt testen

OpenClaw routet Antworten laut Dokumentation deterministisch zurück zu Signal. Das ist im Alltag wichtig: Wenn eine Anfrage über Signal kommt, soll die Antwort nicht plötzlich in einem anderen Frontend landen.

Für Direktnachrichten teilt Signal die Hauptsession des Agenten. Gruppen behandelt OpenClaw getrennt; die Doku beschreibt isolierte Gruppensessions im Muster agent:<agentId>:signal:group:<groupId>. Daraus folgt: DMs und Gruppen sollten nicht als identischer Kanal getestet werden.

Eine DM eignet sich für persönliche Agenten-Kommandos, Statusfragen oder kurze Übergaben. Eine Gruppe ist eher ein gemeinsamer Raum mit eigenem Kontext. Das ist nützlich, wenn ein Team denselben Agenten ansprechen soll, kann aber irritieren, wenn Gruppenkontext automatisch in der privaten Agentensession erwartet wird.

Der Funktionstest sollte klein bleiben: eine DM an den Bot, Pairing freigeben, Antwort prüfen. Danach eine Testgruppe mit klar erkennbarem Namen anlegen, kurze Nachricht senden und Antwort prüfen. Erst wenn beide Wege getrennt funktionieren, lohnt sich Feinschliff an Allowlist, Betriebsstart und Monitoring.

Wo das Setup typischerweise knirscht

Viele Stolperfallen liegen an den Rändern des Setups. signal-cli muss erreichbar sein, der Gateway muss mit dem gewählten HTTP-Modus sprechen können, die Bot-Kennung muss registriert oder verlinkt sein, und Captcha oder SMS-Verifikation dürfen nicht halb abgeschlossen bleiben.

Wenn der DM-Test scheitert, hilft eine feste Reihenfolge: läuft signal-cli, stimmt account, zeigt cliPath auf das richtige Binary, ist dmPolicy bewusst gesetzt, steht der Absender in allowFrom?

Bei Gruppen kommt laut OpenClaw-Dokumentation die Session-Trennung hinzu. Wenn ein Agent in der Gruppe weniger Kontext hat als per DM, ist das nicht zwingend ein Fehler. Es kann schlicht die isolierte Gruppensession sein. Für Teams ist diese Trennung oft sinnvoller als ein gemeinsam genutzter Privatkontext.

Signal lohnt sich für OpenClaw vor allem dann, wenn der Agent wirklich in den Kommunikationsfluss soll: kurze mobile Eingaben, Rückfragen unterwegs, Gruppenchats mit begrenztem Scope. Als produktiver Kanal braucht es eine getrennte Bot-Kennung, eine enge Allowlist und einen bewussten Pairing-Prozess. Dann wird aus Messenger-Nähe ein kontrollierter Eingang für Agentenarbeit.