OpenClaw mit Matrix verbinden: Räume, Push-Regeln und sichere Replies ohne Zustellchaos

Wenn OpenClaw in Matrix nicht antwortet, prüfe zuerst die Invite-Regeln und die Ziel-IDs. Genau dort spielt Matrix anders als Discord, Slack oder Signal. Der Kanal ist offen und für selbst gehostete Setups attraktiv, verlangt aber saubere Routing- und Push-Entscheidungen.

Die gute Nachricht: Die offiziellen OpenClaw-Dokumente decken die kritischen Punkte inzwischen sauber ab. Wenn du systematisch prüfst, ob der Bot wirklich beigetreten ist, welche stabilen Ziele in deinen Allowlists stehen und ob Quiet-Streaming überhaupt eine funktionierende Push-Infrastruktur vorfindet, lässt sich ein stiller Matrix-Kanal meist ohne langes Rätselraten wieder einfangen.

Was Matrix in OpenClaw wirklich kann

Das offizielle @openclaw/matrix-Plugin nutzt laut Dokumentation die matrix-js-sdk. Es unterstützt DMs und Räume, inklusive Threads, Medien und Ende-zu-Ende-Verschlüsselung. Installiert wird es mit:

openclaw plugins install @openclaw/matrix

Für die Praxis wichtiger als die Featureliste: plugins install registriert und aktiviert das Plugin direkt. Wenn danach nichts ankommt, prüfe channels.matrix, das Invite-Verhalten und deine Erwartungen an Quiet-Streaming.

Die häufigsten Matrix-Fehlerbilder

Bei Matrix tauchen in OpenClaw vor allem diese Symptome auf:

• Der Bot antwortet in DMs nicht, obwohl das Konto erreichbar wirkt.
• Einladungen in neue Räume bleiben wirkungslos.
• Der Bot ist im Raum, reagiert aber nur in manchen Räumen oder nur auf manche Nutzer.
• Quiet-Streaming zeigt einen stillen Entwurf, löst aber nie eine finale Push-Benachrichtigung aus.
• Antworten landen nicht dort, wo du sie erwartest, weil Account- oder Zielpräfixe missverstanden wurden.

Für genau diese Fälle lohnt sich eine Diagnose in fester Reihenfolge statt wildem Herumprobieren.

Baseline zuerst: Konto, Auth und Restart

OpenClaw erwartet unter channels.matrix entweder homeserver plus accessToken oder homeserver plus userId und password. Der interaktive Weg läuft über:

openclaw channels add
openclaw configure --section channels

Die Doku beschreibt, dass der Assistent nach Homeserver-URL, Auth-Methode, optionalem Gerätenamen und E2EE fragt. Auch Raumzugang und Auto-Join werden dort gesetzt. Danach gehört ein Gateway-Restart dazu. Wenn du diesen Restart auslässt, suchst du später an der falschen Stelle.

Eine zweite Stolperfalle: Matrix kann auch dann als konfiguriert gelten, wenn das Token nicht mehr sichtbar in der Hauptkonfiguration steht, weil OpenClaw zwischengespeicherte Zugangsdaten unter ~/.openclaw/credentials/matrix/ berücksichtigt. Das ist praktisch, kann aber verwirren, wenn du Konfiguration und Laufzeitbild gedanklich gleichsetzt.

Warum neue DMs und Räume oft an autoJoin hängen

Der wichtigste Matrix-spezifische Failure-Mode ist autoJoin. Laut Doku steht channels.matrix.autoJoin standardmäßig auf off. Dann tritt der Bot neuen Räumen und auch frischen DM-Invites nicht automatisch bei.

Das ist leicht zu übersehen, weil viele Nutzer erwarten, dass DMs lockerer behandelt werden. Genau das tut Matrix in OpenClaw aber nicht: Beim Invite kann OpenClaw noch nicht sicher unterscheiden, ob der Raum später als DM oder Gruppe klassifiziert wird. Deshalb läuft zunächst jede Einladung durch autoJoin. dm.policy greift erst später, nachdem der Bot beigetreten ist und der Raum klassifiziert wurde.

Für kontrollierte Setups sind diese Varianten sinnvoll:

• autoJoin: "allowlist" plus autoJoinAllowlist, wenn nur bekannte Räume oder Aliase erlaubt sein sollen.
• autoJoin: "always", wenn du Einladungen generell akzeptieren willst.
• autoJoin: "off" nur dann, wenn du bewusst manuell beitrittst und diese Reibung einkalkulierst.

Beim Format gibt es wenig Interpretationsspielraum: autoJoinAllowlist akzeptiert nur stabile Ziele wie !roomId:server, #alias:server oder *. Reine Anzeigenamen werden abgelehnt. Wenn du also “Marketing Raum” in eine Liste schreibst und der Bot nie beitritt, liegt der Fehler nicht bei Matrix, sondern im ungültigen Eintrag.

Diagnose: Reagiert der Bot im falschen Raum oder nur in manchen Räumen?

Hier geht es meist um erlaubte IDs, Aliase oder Name-Matching.

OpenClaw empfiehlt für die Auflösung vor dem Speichern einer Allowlist:

openclaw channels resolve --channel matrix "Projekt Raum"

Damit holst du dir den stabilen Zielwert, den du für groups, autoJoinAllowlist oder andere Allowlist-Felder wirklich brauchst. Für Nutzer- und Raumregeln unterscheidet die Matrix-Doku klar:

• Nutzer-Allowlists wie dm.allowFrom, groupAllowFrom oder groups.<room>.users sollten auf @user:server setzen.
• Raum-Keys in groups sollten !room:server oder #alias:server verwenden.
• Anzeigenamen werden standardmäßig ignoriert. Nur wenn du bewusst dangerouslyAllowNameMatching: true setzt, lässt du Kompatibilität mit Display-Namen zu.

Wenn OpenClaw also nur in einem Raum antwortet, in einem anderen aber schweigt, prüfe zuerst, ob dort echte IDs oder Aliase hinterlegt sind oder nur bequeme Anzeigenamen. Danach lohnt sich ein tieferer Blick auf Gruppenregeln und Mention-Gating. Für die Sicherheitslogik in Gruppen ist der Anschlussartikel zu OpenClaw-Gruppenchats, Commitments und Follow-ups der bessere zweite Schritt.

Quiet-Streaming: Aufgeräumt im Raum, aber nur mit funktionierender Push-Kette

streaming: "quiet" ist die eleganteste Matrix-Option, wenn du keine laufenden Zwischenmeldungen im Raum sehen willst. Laut OpenClaw editiert der Bot dabei einen einzelnen Preview-Event und markiert die finalisierte Preview mit einem eigenen Content-Flag.

Der Haken sitzt bei den Benachrichtigungen. Diese finale Bearbeitung erreicht Empfänger nur dann zuverlässig, wenn pro Empfänger eine passende Push-Regel installiert ist. Quiet-Streaming hängt deshalb am Kanalmodus, an einer passenden Push-Regel und an funktionierender Homeserver-Zustellung.

Die Doku nennt dafür drei Pflichtpunkte:

• Die Push-Regel muss auf den vollständigen Bot-Sender wie @bot:example.org matchen.
• Sie muss auf das Finalisierungs-Flag der Preview prüfen.
• Der Empfänger braucht bereits funktionierende Pushers. Wenn normale Matrix-Pushes schon kaputt sind, repariert Quiet-Streaming gar nichts.

Wenn du diesen Aufwand nicht willst, ist streaming: "partial" die robustere Wahl. Dann nutzt du das normale Matrix-Benachrichtigungsverhalten, statt pro Empfänger eigene Quiet-Preview-Regeln pflegen zu müssen. Wer noch andere Team-Kanäle vergleicht, sollte das mit Slack als Team-Frontend für OpenClaw-Agenten und Signal für OpenClaw: Pairing, Gruppen und sichere Replies gegenprüfen.

Replies landen falsch? Dann stimmt meist die Zielannahme

OpenClaw entscheidet laut Routing-Dokumentation deterministisch, wohin eine Antwort zurückgeht. Das Modell wählt den Kanal nicht selbst. Für Matrix bedeutet das praktisch:

• Eine Nachricht aus einem Raum wird wieder in diesen Raum geroutet.
• Eine DM wird als DM im selben Kanal-Kontext zurückgeführt.
• In Multi-Account-Setups greift channels.<channel>.defaultAccount, wenn ein Outbound-Pfad kein explizites accountId setzt.

Wenn du mehrere Matrix-Accounts betreibst und keinen klaren Default setzt, kann der Fallback bei einem normalisierten Account landen, den du gar nicht beabsichtigt hast. Das Ergebnis ist vorhersagbar falsch, auch wenn es zunächst wie Zufall wirkt.

Auch Präfixe werden oft überschätzt. Ein Ziel wie matrix:!room123:example.org hilft nur als Kanalhinweis, solange der Kanal noch nicht feststeht. Wenn bereits ein anderer expliziter Kanal gewählt ist, muss das Präfix zu diesem Kanal passen. Wer kanalübergreifende Zielsyntax erwartet, handelt sich eher Routingfehler als Komfort ein.

E2EE nur aktivieren, wenn du den Zusatzaufwand wirklich tragen willst

Matrix kann E2EE, und OpenClaw unterstützt den Bootstrap dafür. Die Dokumentation nennt dafür den Befehl:

openclaw matrix encryption setup

Praktisch heißt das: Der Bot muss dem Raum bereits beigetreten sein und die passenden Schlüssel besitzen. Für schnelle Tests ist E2EE deshalb oft der falsche Hebel. Baue lieber zuerst einen unverschlüsselten Testraum oder eine saubere DM-Strecke auf. Wenn Routing, Räume und Pushes dort zuverlässig laufen, kannst du Verschlüsselung darauf aufsetzen.

Sobald verschlüsselte Räume ins Spiel kommen, wird Matrix eher zu einem kleinen Betriebsmodell als zu einem simplen Messenger-Kanal. Wenn du eher einen klassisch selbst gehosteten Team-Chat ohne E2EE-Komplexität willst, ist der Vergleich mit OpenClaw in Mattermost: Kanal, Rechte und Self-Hosting-Fallen sinnvoll.

Recovery-Pfad, wenn Matrix stumm bleibt

Wenn du ein stilles Matrix-Setup wieder einfängst, geh in dieser Reihenfolge vor:

1. Prüfe, ob das Plugin wirklich installiert ist und channels.matrix mit Homeserver plus Auth vollständig gesetzt wurde.
2. Starte den Gateway nach der Konfiguration oder nach relevanten Kanaländerungen neu.
3. Kläre, ob der Bot dem Raum oder der frischen DM überhaupt beigetreten ist. Standardwert autoJoin: "off" ist hier der häufigste Bremsklotz.
4. Ersetze in Allowlists alle sichtbaren Namen durch stabile IDs oder Aliase, die Matrix laut Doku akzeptiert.
5. Prüfe bei DM-Problemen zusätzlich, ob du dm.policy mit autoJoin verwechselst. Invite-Zulassung und spätere DM-Regeln sind zwei verschiedene Schritte.
6. Wechsle testweise auf streaming: "partial", wenn Quiet-Streaming zwar einen Entwurf zeigt, aber nie einen Push auslöst.
7. Setze in Multi-Account-Setups einen expliziten defaultAccount, bevor du Routing-Probleme dem Modell oder dem Raum gibst.

Diese Reihenfolge ist bewusst nüchtern. Genau deshalb spart sie Zeit.

Was du selbst prüfen musst

Die OpenClaw-Doku ist bei Installation, Auth-Varianten, autoJoin und stabilen Allowlist-Formaten konkret genug. Auch Quiet-Streaming, Push-Regeln für finalisierte Previews, E2EE-Bootstrap und deterministisches Routing über defaultAccount und Kanalpräfixe sind beschrieben. Sie nimmt dir aber nicht jede Self-Hosting-Kante ab. Ungewöhnliche Homeserver-Setups, stark angepasste Clients oder eigenwillige Pusher musst du auf deiner Strecke testen.

Für mich ist die robuste Haltung zu Matrix in OpenClaw schlicht: Behandle den Kanal als eigenes Invite-Modell mit eigener Push- und Sicherheitslogik. Wenn etwas nicht ankommt, prüfe Join-Regeln, stabile IDs und Push-Voraussetzungen. Erst danach lohnt sich tiefere Fehlersuche im restlichen Agenten-Stack.

Der operative Punkt

Matrix lohnt sich für OpenClaw vor allem dort, wo du offene Infrastruktur und kontrollierte Räume mit nachvollziehbarem Routing willst. Der Preis dafür ist etwas mehr Betriebsdisziplin: Frische Invites werden nicht magisch als DMs erkannt. Quiet-Streaming braucht echte Push-Regeln, und Multi-Account-Setups sollten nicht auf implizite Defaults vertrauen.

Wenn du genau diese Stellen sauber setzt, wird Matrix zu einem präzisen OpenClaw-Kanal. Wenn du sie ignorierst, wirkt der Kanal schnell unzuverlässig, obwohl er nur konsequent deine eigene Konfiguration ausführt.