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

Ein Slack-Bot, der auf eine Mention antwortet, ist schnell eingerichtet. Ob er auch an den richtigen Stellen schweigt, zeigt dieser Test nicht. Für den Einsatz in Team-Channels zählen die negativen Fälle: Ein nicht freigegebener Channel bleibt stumm, ein unbekannter DM-Absender landet im Pairing, und jede Antwort erscheint im richtigen Thread.

Dieses Tutorial baut dafür eine kontrollierte Abnahme mit Socket Mode auf. Du brauchst zwei Slack-Konten und zwei private Channels – genug, um jede Schranke einzeln auszulösen, ohne die Freigaben eines produktiven Workspace anzufassen.

Welcher Agent antwortet, in welcher Session und an welchem Slack-Ziel, entscheidet die Host-Konfiguration. Das Modell hat darauf keinen Einfluss.

1. Slack-Plugin installieren

Laut der OpenClaw-Dokumentation zum Slack setup installierst du auf dem Gateway-Host zuerst das Plugin:

openclaw plugins install @openclaw/slack

Der Befehl registriert und aktiviert das Plugin. Mehr passiert noch nicht. Solange Slack-App und Channel-Einstellungen fehlen, bleibt das Plugin untätig, und eine Transportprobe ergibt an dieser Stelle noch keinen Sinn.

2. Testszenario und Slack-App vorbereiten

Socket Mode ist laut OpenClaw-Doku der Standardtransport. Eine öffentliche Gateway-URL brauchst du dafür nicht, wohl aber ausgehende WSS-Verbindungen zu wss-primary.slack.com. Auf einem Entwicklerlaptop oder hinter einer Firewall, die nur ausgehenden Verkehr erlaubt, funktioniert das ohne Tunnel.

Lege zwei private Channels an, etwa oc-allowed-private und oc-denied-private, und notiere jeweils die Channel-ID im Format C.... Am schnellsten geht das per Rechtsklick auf den Channel und Copy link: Die ID steht am Ende der URL.

Für die App sieht die Setup-Seite den Weg über ein Manifest vor:

1. Im Slack API Dashboard Create New App → From a manifest wählen, den Workspace auswählen und das empfohlene Manifest der Setup-Seite einfügen.
2. Socket Mode ist im Basis-Manifest bereits aktiviert. Erzeuge einen App-Level Token mit connections:write; er wird als appToken konfiguriert.
3. Installiere die App im Workspace und kopiere den Bot User OAuth Token für botToken.
4. Lade den Bot in beide Test-Channels ein und prüfe, dass er in der Mitgliederliste erscheint.

Der letzte Schritt wirkt banal, trennt aber zwei Schranken voneinander: Slack stellt Ereignisse nur aus Channels zu, in denen die App Mitglied ist, und erst danach entscheidet OpenClaw, ob es sie verarbeitet oder verwirft.

Welche Manifest-Teile die Tests tragen

Das Basis-Manifest auf der OpenClaw-Seite Slack manifest and scopes enthält deutlich mehr Scopes und Events, als diese Abnahme braucht. Für die Texttests kommt es auf diese Einträge an:

Wer das Manifest kürzt, sollte genau diese Einträge behalten. Datei-, Reaktions- und Pin-Funktionen brauchen weitere Scopes. Ändert sich ein OAuth-Scope, muss die App im Workspace neu installiert werden, sonst arbeitet die bestehende Installation mit den alten Rechten weiter.

3. Die aktive Konfiguration finden

Im Standardprofil liegt die Gateway-Konfiguration unter ~/.openclaw/openclaw.json im JSON5-Format. Benannte Profile, Container oder angepasste Dienste können allerdings eine andere Datei laden. Kläre deshalb mit openclaw status, welches Gateway tatsächlich läuft, und prüfe bei einem Dienst auch dessen Startparameter und Umgebung. Sonst pflegst du eine plausible openclaw.json, die der aktive Prozess gar nicht liest.

Mehr zum Aufbau der Datei steht in Gateway-Konfiguration: openclaw.json verständlich erklärt.

4. Zugriff begrenzen

Die Slack-Zugriffskontrolle beantwortet drei getrennte Fragen. Wer darf per DM schreiben? Welche Channels verarbeitet OpenClaw überhaupt? Und wer darf innerhalb eines freigegebenen Channels den Bot auslösen?

Laut der OpenClaw-Seite Slack access control regelt dmPolicy den DM-Zugang, und allowFrom ist die DM-Allowlist mit Slack User IDs. Mit groupPolicy: "allowlist" verarbeitet OpenClaw nur Channels, die unter channels.slack.channels eingetragen sind. Die Schlüssel dort müssen stabile Channel-IDs sein: Ein Name wie #oc-allowed-private scheitert laut Troubleshooting-Seite unter allowlist stillschweigend, weil das Routing standardmäßig über IDs läuft. Pro Channel begrenzt eine users-Liste die zugelassenen Absender, requireMention erzwingt eine Erwähnung.

Für den Test steht nur Testkonto A in den Allowlisten, und nur oc-allowed-private ist freigegeben:

{
  channels: {
    slack: {
      botToken: { source: "env", provider: "default", id: "SLACK_BOT_TOKEN" },
      appToken: { source: "env", provider: "default", id: "SLACK_APP_TOKEN" },

      dmPolicy: "pairing",
      allowFrom: ["U11111111"], // Testkonto A

      groupPolicy: "allowlist",
      channels: {
        C22222222: {
          enabled: true,
          requireMention: true,
          users: ["U11111111"],
        },
      },

      replyToMode: "all",
    },
  },

  messages: {
    groupChat: {
      visibleReplies: "automatic",
    },
  },
}

Ersetze U11111111 durch die User ID von Testkonto A und C22222222 durch die ID von oc-allowed-private. Die ID des zweiten Channels fehlt absichtlich.

Bei dmPolicy: "pairing", laut Doku der Standard, schreiben Einträge aus allowFrom ohne Pairing-Code, während ein unbekannter Absender zunächst einen Code erhält. Deshalb braucht der Test zwei Konten. Eine DM vom bereits freigegebenen Konto sagt über das Pairing nichts aus.

replyToMode: "all" legt Antworten auf Channel-Nachrichten als Thread-Antworten ab; der Standard ist off. thread.historyScope steht per Default auf thread, der Kontext wird also pro Slack-Thread getrennt. messages.groupChat.visibleReplies: "automatic" ist ebenfalls der Standard und postet die finale Antwort direkt in den Raum. Im Modus "message_tool" bliebe der finale Text privat, solange das Modell nicht ausdrücklich message(action=send) aufruft – im Test sieht das aus wie ein stummer Bot.

5. Tokens setzen und Transport prüfen

Lege SLACK_BOT_TOKEN und SLACK_APP_TOKEN im geschützten Laufzeitkontext des Gateways ab, nicht in einer versionierten Datei oder einem gemeinsam lesbaren Startskript. Starte das Gateway anschließend über den Dienst deiner Installation neu und prüfe die Verbindung:

openclaw channels status --probe

Meldet die Probe botTokenStatus oder appTokenStatus als configured_unavailable, ist das Konto zwar konfiguriert, die Laufzeit konnte den SecretRef aber nicht auflösen. Prüfe dann, ob die Variable im Kontext des Dienstes ankommt. Eine Logzeile slack token mismatch ... bedeutet laut Troubleshooting-Seite, dass Bot- und App-Token zu verschiedenen Slack-Apps gehören. Fehlende Scopes, widerrufene Tokens und ungültige Authentifizierung brechen sofort ab, statt endlos neu zu versuchen.

Erst wenn diese Probe sauber durchläuft, lohnt die Suche bei Mentions und Allowlisten.

6. DM-Pairing mit zwei Konten

Testkonto A steht in allowFrom. Testkonto B darf weder dort noch in einem früheren Pairing-Eintrag stehen; openclaw pairing list slack zeigt den aktuellen Stand.

Testkonto A schickt dem Bot eine DM. Erwartung: direkte Antwort in derselben Unterhaltung, kein Code.

Testkonto B schickt eine DM und erhält einen Pairing-Code. Bestätige ihn auf dem Gateway-Host:

openclaw pairing approve slack <CODE>

Die zweite DM von Testkonto B wird nun verarbeitet, ein zusätzlicher Eintrag in allowFrom ist nicht nötig. Laut der OpenClaw-Seite zu Gruppen öffnet die Pairing-Freigabe allerdings nur DMs. In oc-allowed-private bleibt Testkonto B blockiert, solange es nicht in der users-Liste steht. Das ist ein lohnender Zusatztest.

7. Channel-Freigabe, Mentions und Threads

Alle Channel-Tests laufen über Testkonto A.

Vorab ein Detail, das sonst für Verwirrung sorgt: Wird der Bot in einen freigegebenen Channel eingeladen, postet OpenClaw laut Access-Control-Seite standardmäßig eine kurze Vorstellung, auch ohne Mention. Das ist kein Loch im Mention-Gating. Wer das im Test nicht will, setzt channels.slack.joinIntro: false.

Nicht freigegebener Channel

Erwähne den Bot in oc-denied-private. Slack stellt das Ereignis zu, OpenClaw antwortet nicht. Laut Troubleshooting-Seite protokolliert das Info-Log dann Slack inbound event rejected during preparation mit Grund und Routing-IDs. Kommt doch eine Antwort, greift die Allowlist nicht – oder der Prozess liest eine andere Konfiguration.

Freigegebener Channel ohne Mention

Sende eine normale Nachricht in oc-allowed-private. Der Bot bleibt stumm.

Neue Nachricht mit Mention

Sende eine Top-Level-Nachricht mit @DeinBot. Wegen replyToMode: "all" erscheint die Antwort als Thread darunter; ihr thread_ts entspricht dem ts deiner Nachricht. Laut der Seite Slack threads and sessions legt OpenClaw für einen solchen Mention-Root direkt die Session agent:<agentId>:slack:channel:<channelId>:thread:<rootTs> an, damit Root und spätere Thread-Antworten dieselbe Session teilen.

Folgeantworten im Thread

Antworte im Thread, diesmal ohne Mention. Der Bot reagiert trotzdem, weil implicitMentions.threadParticipation per Default aktiv ist: In einem Thread, in dem der Bot schon geantwortet hat, umgeht eine Folgeantwort das Mention-Gating. Wer dort eine neue explizite Erwähnung verlangen will, setzt den Wert auf false.

Starte anschließend einen zweiten Thread im selben Channel. Er bekommt eine eigene :thread:-Session und darf den Inhalt des ersten nicht kennen. Bei Thread-Problemen ist thread_ts verlässlicher als der optische Eindruck in der Slack-Oberfläche.

Die allgemeinen Routing-Regeln erklärt OpenClaw Channel-Routing: Mehrere Kanäle und Agenten sauber zuordnen.

8. HTTP Request URLs

Laut der Seite Slack transports bieten Socket Mode und HTTP Request URLs bei Messaging, Slash Commands, App Home und Interaktivität denselben Funktionsumfang; entscheiden sollte die Deployment-Form. HTTP braucht einen öffentlichen HTTPS-Endpunkt, das Signing Secret und mode: "http", dafür können mehrere Gateway-Replikas hinter einem Load Balancer eine App teilen. Socket Mode hält eine Session pro App und Host. Teilen sich mehrere Gateways per Socket Mode eine App, kann Slack jedes Ereignis an jede Verbindung zustellen, und alle Gateways brauchen dann gleichwertige Routing- und Zugriffsregeln.

HTTP ist hier bewusst kein zweiter Happy Path. Wer umsteigt, folgt dem vollständigen Ablauf auf der Transports-Seite, statt Socket-Mode-Felder mit halb eingerichtetem HTTP-Ingress zu mischen.

9. Fehler von unten nach oben eingrenzen

Bleibt der Bot stumm, ist die Allowlist der falsche Startpunkt.

1. Transport: openclaw channels status --probe meldet keine Token- oder Socket-Fehler.
2. Aktives Profil: Das laufende Gateway liest die Datei, die du bearbeitet hast.
3. Slack-App: Die aktuelle App-Fassung ist im richtigen Workspace installiert.
4. Mitgliedschaft: Der Bot steht in der Mitgliederliste des Channels.

Danach empfiehlt die Troubleshooting-Seite für Channels die Reihenfolge groupPolicy, Channel-Allowlist, requireMention und users-Liste, für DMs dm.enabled, dmPolicy und den Pairing-Status. openclaw logs --follow und openclaw doctor begleiten jeden Schritt. Bleibt ausschließlich ein privater Channel stumm, lohnt der Blick auf groups:history und message.groups.

10. Token-Recovery und Rückbau

Ist ein Bot- oder App-Level Token offengelegt, rotiere ihn in Slack, aktualisiere den Laufzeitkontext, starte das Gateway neu und wiederhole die Probe.

Kannst du nicht sofort neue Credentials bereitstellen, entferne den channels.slack-Block aus der aktiven Konfiguration. Ohne diesen Block startet das Gateway Slack laut Access-Control-Seite nicht automatisch aus SLACK_*-Umgebungsvariablen, solange es nicht mit --ambient-channels läuft.

Für einen vollständigen Rückbau entfernst du zusätzlich die Tokens aus dem Laufzeitkontext, prüfst den Channel-Status, nimmst den Bot aus beiden Test-Channels und deinstallierst die App bei Bedarf über die Slack-App-Verwaltung.

Weiterlesen

• OpenClaw mit Discord verbinden: Bot, Intents und Serverrechte ohne Blindflug
• OpenClaw Channel-Routing: Mehrere Kanäle und Agenten sauber zuordnen

Die Betriebsregel

Eine Bot-Antwort zeigt nur, dass ein Teil der Kette funktioniert. Freigabereif ist die Integration erst, wenn auch die negativen Tests sitzen: Der fremde Channel schweigt, das unbekannte Konto muss ins Pairing, und jeder Thread behält seine eigene Session. Der Ablauf folgt der aktuellen OpenClaw-Dokumentation und ist als Abnahmeplan gedacht, nicht als Messprotokoll einer bestimmten Installation.

Die Mindestregel für den Betrieb lautet: Zugriffspolitik nicht auf Verdacht lockern. Wer bei einem stummen Bot groupPolicy auf open stellt, findet vielleicht den Fehler, öffnet aber nebenbei jeden Channel, in dem die App Mitglied ist.