Slack mit OpenClaw verbinden: Bot, Mentions und Routing sauber einrichten

OpenClaw behandelt Slack nicht als Sonderfall, sondern als einen von mehreren Messaging-Kanälen. Laut OpenClaw-Doku ist Slack für Direct Messages und Channels produktionsreif nutzbar. Der Standardweg ist Socket Mode; alternativ unterstützt OpenClaw HTTP Request URLs. Für die Praxis heißt das: Erst entscheidest du über den Transport, dann über Zugriff, Mention-Regeln, sichtbare Antworten und Routing.

Wichtig: Dieser Artikel ist eine Setup- und Prüf-Checkliste für OpenClaw-seitige Slack-Integration. Er ersetzt keinen vollständigen Slack-App-OAuth-Klickpfad. Konkrete Workspace-Dialoge, Slack-Scopes und OAuth-Bestätigungen können sich je nach Slack-Workspace unterscheiden und wurden hier nicht live getestet.

Der häufigste Fehler beim Slack-Setup ist nicht der Bot selbst, sondern ein zu grobes mentales Modell. OpenClaw entscheidet nicht spontan, wohin eine Antwort geht. Nach Angaben der Channel-Routing-Doku laufen Antworten deterministisch zurück in den Kanal, aus dem die Nachricht kam. Die Host-Konfiguration kontrolliert diese Zuordnung, nicht das Modell. Das macht die Integration berechenbarer, zwingt dich aber auch, Zugriff und Raumlogik vor dem ersten produktiven Test sauber zu setzen.

Wenn du Slack nicht isoliert betrachten willst, lohnt sich zusätzlich der Blick auf die OpenClaw-Übersicht und die laufende Release-Einordnung. Beide helfen, Slack als Teil eines größeren Agenten-Setups einzuordnen statt als einmalige Bot-Bastelei.

Voraussetzungen vor dem Setup

Kläre vor dem ersten Test diese Punkte:

• Ein laufendes OpenClaw-Gateway und ein grundsätzlich funktionierender Agent sind vorhanden.
• Du darfst in deinem Slack-Workspace eine Slack-App einrichten oder installieren.
• Du hast dich für genau einen Transport entschieden: Socket Mode oder HTTP Request URLs.
• Für Socket Mode brauchst du laut OpenClaw-Doku einen Bot Token und einen App-Level Token mit connections:write.
• Für HTTP Request URLs brauchst du laut OpenClaw-Doku einen Bot Token und das Slack Signing Secret.
• Für HTTP Request URLs brauchst du zusätzlich eine öffentlich erreichbare HTTPS-URL mit DNS, TLS und Reverse Proxy oder Tunnel.
• Für Socket Mode muss ausgehender WebSocket-Traffic zu wss-primary.slack.com möglich sein.
• Du kennst die Slack-User und Slack-Channels, die OpenClaw ansprechen dürfen sollen.

Wenn einer dieser Punkte offen ist, nicht mit Channel-Freigaben anfangen. Sonst suchst du später gleichzeitig in Slack-App-Konfiguration, Transport, OpenClaw-Zugriff und Routing.

Transport: Socket Mode oder HTTP Request URLs

Laut Slack-Doku von OpenClaw erreichen Socket Mode und HTTP Request URLs Feature-Parität für Messaging, Slash Commands, App Home und Interaktivität. Die Wahl hängt deshalb weniger an Features als an deiner Betriebsumgebung.

Socket Mode ist der Standard und braucht keine öffentliche Gateway-URL. Dafür muss deine Umgebung ausgehend WebSocket-Verbindungen zu Slack zulassen; die Doku nennt konkret wss-primary.slack.com. Für private Setups, Heimserver oder kleine Agenteninstallationen ist das oft der leichtere Start, weil du keinen öffentlich erreichbaren HTTPS-Endpunkt betreiben musst.

HTTP Request URLs drehen die Netzwerkrichtung um. OpenClaw braucht dann eine öffentliche URL mit DNS, TLS und Reverse Proxy oder Tunnel. Der Vorteil: Du musst keine ausgehende WebSocket-Verbindung offenhalten. Der Nachteil: Du hast sofort mehr Deployment-Oberfläche, mehr Zertifikats- und Proxy-Fragen und eine klarere Verantwortung für Erreichbarkeit von außen.

Die Credential-Seite unterscheidet sich ebenfalls. Für Socket Mode nennt die OpenClaw-Doku Bot Token plus App-Level Token mit connections:write. Für HTTP Request URLs nennt sie Bot Token plus Signing Secret. Halte diese Entscheidung vor dem Setup fest, statt später zwischen beiden Betriebsarten zu wechseln. Viele Slack-Probleme wirken wie Berechtigungsfehler, sind aber eigentlich ein Mischbetrieb aus falschem Transport und unvollständiger App-Konfiguration.

DMs, Channels und Gruppenlogik trennen

OpenClaw beschreibt Gruppenchats kanalübergreifend gleich: Discord, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp und Zalo folgen denselben Grundregeln. Das ist praktisch, weil Slack-Channels dadurch nicht als komplett eigene Welt verstanden werden müssen.

Die Groups-Doku nennt drei Stellschrauben:

• Direct-Message-Zugriff läuft über *.allowFrom.
• Gruppenzugriff läuft über *.groupPolicy plus Allowlist-Felder wie *.groups und *.groupAllowFrom.
• Ob eine Nachricht tatsächlich als Anfrage gilt, steuern Mention-Regeln wie requireMention und /activation.

Der Default ist bewusst defensiv. Laut Groups-Doku sind Gruppen eingeschränkt, groupPolicy steht auf "allowlist", und Antworten benötigen eine Mention, solange du Mention-Gating nicht explizit abschaltest. Für Slack ist das sinnvoll: Ein Agent in einem viel genutzten Channel sollte nicht jedes Nebengeräusch als Arbeitsauftrag interpretieren.

Ein sauberer Start sieht so aus: Erlaube zuerst DMs für die Personen, die OpenClaw wirklich nutzen sollen. Danach nimmst du genau die Slack-Channels in die Gruppen-Allowlist auf, in denen der Agent sichtbar arbeiten darf. Erst danach entscheidest du, ob Mentions Pflicht bleiben oder ein bestimmter Raum bewusst stärker automatisiert laufen soll.

Mention-Gating praktisch prüfen

Die Groups-Doku beschreibt den Ablauf sinngemäß so:

1. Wenn Gruppen deaktiviert sind, wird die Gruppennachricht verworfen.
2. Wenn groupPolicy auf Allowlist steht und der Raum nicht erlaubt ist, wird sie verworfen.
3. Wenn requireMention aktiv ist und keine Mention vorliegt, wird sie höchstens als Kontext behandelt, aber nicht als Anfrage beantwortet.
4. Mention, Reply, Command oder Direct Message können eine echte Nutzeranfrage auslösen.

Für Slack heißt das: Ein erlaubter Channel allein reicht nicht zwingend aus. Wenn Mention-Gating aktiv ist, muss der Agent auch passend angesprochen werden. Umgekehrt ist eine Mention in einem nicht erlaubten Channel kein Freifahrtschein, wenn die Gruppen-Allowlist den Raum blockiert.

Routing nicht dem Modell überlassen

Die Channel-Routing-Doku formuliert den Kern klar: OpenClaw routet Antworten zurück zu dem Kanal, aus dem die Nachricht kam. Das Modell wählt keinen Zielkanal. Für Slack-Betrieb ist diese Trennung wichtig, weil sie zwei Fehlerbilder verhindert.

Erstens solltest du nicht erwarten, dass ein Slack-Thread plötzlich nach Telegram, WhatsApp oder Discord ausweicht, nur weil ein Prompt das nahelegt. Explizite Outbound-Ziele können zwar Provider-Präfixe wie telegram:123 oder tg:123 enthalten, aber die Doku beschreibt diese Präfixe als Kanalhinweise nur dann, wenn der gewählte Kanal noch offen ist. Wenn ein Kanal bereits eindeutig ausgewählt wurde, müssen Präfix und Kanal zusammenpassen.

Zweitens sind Slack-Zielangaben nicht dasselbe wie globale Agentenidentität. Die Routing-Doku trennt Channel, AccountId, AgentId und SessionKey. Channel meint unter anderem slack, telegram, whatsapp, discord oder signal. AccountId beschreibt eine konkrete Konto-Instanz, wenn der Kanal mehrere Konten unterstützt. AgentId steht für isolierten Workspace und Session Store, während SessionKey den Kontext-Bucket und die Nebenläufigkeit bestimmt.

Für kleine Setups klingt das abstrakt, spart aber später Fehlersuche. Wenn eine Antwort im falschen Raum landet, prüfst du nicht zuerst den Prompt, sondern Kanal, AccountId und SessionKey. Wenn ein Agent nicht auf eine Slack-Nachricht reagiert, prüfst du nicht zuerst das Modell, sondern Gruppenpolicy, Allowlist und Mention-Gating.

Threads und sichtbare Antworten vorsichtig behandeln

Slack-Arbeit passiert selten nur in DMs. Channels und Threads sind der Normalfall. Die hier herangezogene OpenClaw-Groups-Doku beschreibt sichtbare Antworten für Gruppen und Channels über messages.groupChat.visibleReplies, standardmäßig mit "automatic". In diesem Modus kann finaler Assistant-Text über den sichtbaren Reply-Pfad erscheinen.

Für gemeinsam genutzte Räume nennt die Doku zusätzlich "message_tool": Dann soll der Agent bewusst per Message-Tool entscheiden, wann er sichtbar spricht. Das passt zu Räumen, in denen viel Kontext mitläuft, aber nicht jede Nachricht eine sichtbare Antwort auslösen soll. Wichtig ist die Betriebsgrenze: Diese Variante funktioniert laut Doku am besten mit aktuellen, tool-zuverlässigen Modellen.

Nicht überinterpretieren: Diese Einstellung ist ein Gruppen-/Channel-Ausgabeverhalten, kein hier belegter Slack-spezifischer Thread-Routing-Vertrag. Wenn Threads für dein Team kritisch sind, musst du sie in deinem Workspace gesondert abnehmen: Teste eine DM, eine Channel-Mention, eine Thread-Mention und eine Nachricht ohne Mention. Gehe erst produktiv, wenn sichtbar ist, ob Antworten im erwarteten Thread, im Channel oder gar nicht erscheinen.

Praktisch heißt das: In einem kleinen privaten Slack kannst du zunächst mit Mention-Pflicht und automatischen sichtbaren Antworten starten. In einem größeren Channel ist ein stärker kontrollierter Modus besser. Der Agent darf Kontext aufnehmen, aber sichtbare Antworten sollten an klare Auslöser gebunden bleiben: Mention, Reply, Command oder Direct Message. So bleibt Slack ein Arbeitskanal und wird nicht zur Bühne für jedes Zwischenrauschen.

Abnahmetests vor Produktivbetrieb

Teste nicht sofort im wichtigsten Team-Channel. Nimm einen privaten Test-Channel und prüfe die Schichten nacheinander:

Test	Erwartung
Direct Message von erlaubter Person	OpenClaw verarbeitet die Anfrage.
Direct Message von nicht erlaubter Person	OpenClaw reagiert nicht oder blockiert gemäß Zugriffskonfiguration.
Nachricht im nicht allowlisteten Channel	Keine sichtbare Agentenantwort.
Nachricht im allowlisteten Channel ohne Mention bei aktivem requireMention	Keine sichtbare Antwort; höchstens Kontextverarbeitung gemäß OpenClaw-Verhalten.
Nachricht im allowlisteten Channel mit Mention	Antwort im selben Slack-Kontext, sofern Transport und App-Konfiguration funktionieren.
Thread-Antwort oder Thread-Mention	Tatsächliches Verhalten dokumentieren und erst danach im Team freigeben.
Falscher Provider-Präfix in explizitem Outbound-Ziel	Kein Cross-Channel-Ausweichen erwarten; Präfix und Kanal müssen zusammenpassen.

Diese Tests sind wichtiger als ein einzelner erfolgreicher Bot-Ping. Ein Agent, der überall antworten kann, ist noch keine saubere Integration. Sauber ist die Integration erst, wenn er in nicht erlaubten Räumen zuverlässig schweigt.

Setup-Reihenfolge für weniger Fehlersuche

Beginne mit der Transportentscheidung. Socket Mode ist passend, wenn du keinen öffentlichen Gateway betreiben willst und ausgehende WebSocket-Verbindungen möglich sind. HTTP Request URLs passen, wenn du ohnehin DNS, TLS und Reverse Proxy sauber betreibst und eingehenden HTTPS-Traffic kontrollieren willst.

Danach richtest du die Slack-App mit den für den gewählten Transport nötigen Credentials ein. Teste zuerst eine Direct Message. Erst wenn DMs stabil laufen, nimmst du Channels dazu. Dort setzt du Gruppenpolicy, Allowlist und Mention-Gating so eng wie möglich. Wenn du Threads nutzt, prüfe anschließend, ob Antworten dort erscheinen, wo dein Team sie erwartet, statt global im Channel zu stören.

Der letzte Schritt ist die Betriebsprüfung. Eine gute Slack-Integration ist nicht daran zu erkennen, dass der Agent überall antworten kann. Sie ist daran zu erkennen, dass er nur dort antwortet, wo er soll, und dass du bei Fehlern weißt, welche Schicht zuständig ist: Slack-App, Transport, Zugriff, Mention-Regel, sichtbare Antwortlogik oder Routing.

Fazit: Slack braucht weniger Magie, mehr Grenzziehung

Slack wird mit OpenClaw nicht dadurch robust, dass der Agent möglichst viel darf. Robust wird das Setup, wenn Transport, Zugriff, Mention-Gating und Routing getrennt geplant werden. Die OpenClaw-Doku liefert dafür ein klares Modell: Socket Mode oder HTTP Request URLs für den Transport, Allowlists für Räume und Personen, sichtbare Replies für die Ausgabe und deterministisches Routing für Antworten.

Für die Praxis ist das die wichtigste Konsequenz: Starte eng, teste DMs zuerst und erweitere Slack-Channels schrittweise. Wenn später etwas schiefläuft, suchst du nicht im Prompt-Nebel, sondern in der zuständigen Schicht.

Reality Check

• Getestet mit: nicht selbst getestet; Grundlage sind die OpenClaw-Dokumentationsseiten zu Slack, Groups und Channel Routing.
• Funktioniert gut für: private Slack-Workspaces, kleine Teams und Agentenräume mit klarer Mention-Regel.
• Bricht wahrscheinlich bei: gemischten Transportannahmen, fehlender Gruppen-Allowlist, fehlendem HTTP Signing Secret, fehlendem Socket-Mode-App-Level-Token oder unklarer AccountId in Multi-Account-Setups.
• Nicht getestet: konkrete Slack-App-OAuth-Schritte, Workspace-spezifische Berechtigungsdialoge und Thread-Verhalten in einem Live-Workspace.
• Sicherheitsrisiko: mittel, weil ein falsch erlaubter Channel Agentenantworten in gemeinsame Räume bringen kann.
• Betriebsaufwand: mittel bei Socket Mode, höher bei HTTP Request URLs mit öffentlichem Gateway.
• Recovery: ja, wenn du Transport, Allowlist, Mention-Gating, sichtbare Antworten und Routing getrennt prüfst.