OpenClaw mit Discord verbinden: Bot, Intents und Serverrechte ohne Blindflug

Discord wirkt im OpenClaw-Alltag oft einfacher, als es ist: Der Bot ist sichtbar, zeigt vielleicht sogar “typing”, aber es kommt keine Antwort. In der Praxis hängen Discord-Probleme fast nie an einem einzigen Schalter. Meist reißt die Kette an einer von vier Stellen: Bot-Setup im Developer Portal, Rechte und Intents, laufende OpenClaw-Runtime oder Pairing.

Der belastbare Pfad sieht deshalb nicht nach “Token eintragen und hoffen” aus, sondern nach einer festen Diagnoseleiter. Du legst Anwendung und Bot an, aktivierst genau die Intents, die OpenClaw braucht, lädst den Bot mit bewusst knappen Rechten ein, referenzierst den Token sauber in OpenClaw und prüfst danach Pairing und Guild-Verhalten getrennt. So lassen sich die typischen Fehlerbilder sauber voneinander trennen: Bot online, aber keine Reaktion; Slash Commands fehlen; DM-Pairing kommt, aber Guild-Channels bleiben still; der Bot tippt, ohne sichtbar zu posten.

Was du vor dem Setup brauchst

Bevor du im Discord Developer Portal klickst, sollten diese Punkte erfüllt sein:

• OpenClaw ist installiert und grundsätzlich konfiguriert.
• Der OpenClaw-Gateway-Prozess kann auf dem Zielsystem laufen.
• Du hast Shell-Zugriff auf die Maschine, auf der OpenClaw läuft.
• Du hast in Discord die Berechtigung, Anwendungen/Bots zu verwalten oder den Bot mindestens auf den gewünschten Server einzuladen.
• Du hast einen privaten Testserver oder einen klar abgegrenzten Testkanal. Für den Start ist ein produktiver Community-Server die schlechtere Wahl.

Das Fehlerbild zuerst eingrenzen

Bevor du im Developer Portal oder in der OpenClaw-Konfiguration weiterdrehst, ordne das Symptom einer Ebene zu:

Symptom	Wahrscheinlich zuerst prüfen	Warum
Bot erscheint nicht auf dem Server	OAuth2-Invite und Bot-Scope	Dann ist noch nicht einmal die Discord-Seite sauber verbunden
Bot ist auf dem Server, reagiert aber nicht auf Nachrichten	Message Content Intent, Kanalrechte, laufende Runtime	Der Bot sieht die Nachricht oft gar nicht oder OpenClaw verarbeitet sie nicht
DM liefert Pairing-Code, Guild-Channel bleibt still	Guild-Allowlist, requireMention, Kanalrechte	DM und Guild laufen in OpenClaw unterschiedlich

Bei sichtbaren, aber unvollständigen Reaktionen liegt der Fehler meist eine Ebene tiefer:

Symptom	Wahrscheinlich zuerst prüfen	Warum
Slash Commands fehlen	applications.commands beim Invite oder Command-Registrierung	Ohne diesen Scope oder bei unvollständiger Registrierung tauchen die Befehle nicht sauber auf
Discord zeigt Typing, aber kein sichtbarer Post kommt	messages.groupChat.visibleReplies oder Ambient-Routing des Turns	Dann arbeitet die Runtime, aber die Antwort landet nicht als normaler Channel-Post

Diese Reihenfolge spart Zeit. Erst Discord-Grundlagen, dann OpenClaw-Runtime, dann Pairing und Guild-Routing.

Anwendung und Bot im Developer Portal anlegen

Nach Angaben der OpenClaw-Dokumentation beginnt das Setup im Discord Developer Portal. Dort legst du eine neue Anwendung an, typischerweise mit einem Namen wie „OpenClaw“. Danach wechselst du in der Seitenleiste zum Bereich „Bot“ und setzt den Bot-Namen auf den Namen, unter dem dein Agent später in Discord sichtbar sein soll.

Wichtig ist die Trennung zwischen Anwendung und Bot. Die Anwendung ist der Container im Discord Developer Portal. Der Bot ist die Identität, die später deinem Server beitritt und Nachrichten verarbeitet. Für OpenClaw zählt am Ende diese Bot-Identität, nicht nur der Anzeigename der Anwendung.

OpenClaw empfiehlt außerdem, den Bot in einen eigenen privaten Server einzuladen. Falls du noch keinen hast, nutze Discords normalen Server-Erstellungsfluss. Für Experimente ist ein privater Server sinnvoller als ein produktiver Community-Server, weil du Rollen, Berechtigungen und Nachrichtenfluss testen kannst, ohne echte Nutzer zu stören.

Privileged Intents bewusst setzen

Im Bot-Bereich des Developer Portals nennt die OpenClaw-Dokumentation drei Privileged Gateway Intents:

• Message Content Intent: für OpenClaw erforderlich. Ohne ihn kann der Bot Nachrichteninhalte nicht so verarbeiten, wie OpenClaw sie für den Discord-Kanal braucht.
• Server Members Intent: empfohlen und für rollenbasierte Allowlists sowie Name-zu-ID-Zuordnung relevant.
• Presence Intent: optional und nur nötig, wenn Präsenz-Updates für dein Setup eine Rolle spielen.

Diese Intents sind kein kosmetisches Detail. Sie entscheiden, welche Ereignisse Discord überhaupt an den Bot ausliefert. Gerade Message Content Intent ist für den typischen OpenClaw-Chatbetrieb ein früher Prüfpunkt, wenn ein Bot sichtbar online ist, aber normale Nachrichten nicht verarbeitet. Server Members Intent wird wichtig, sobald du mit rollenbasierten Allowlists oder Name-zu-ID-Zuordnungen arbeitest.

Token erzeugen und sicher behandeln

Für den Bot-Token beschreibt OpenClaw den Weg über den Bot-Bereich: oben auf der Seite „Reset Token“ anklicken und den erzeugten Token kopieren. Die Dokumentation weist darauf hin, dass der Button trotz des Namens beim initialen Setup den Token erzeugt; es wird also nicht zwangsläufig ein bestehender Token zerstört.

Der Token ist die wichtigste geheime Komponente dieses Setups. Er gehört nicht in Screenshots, nicht in öffentliche Repositories und nicht in Chat-Ausgaben. Wenn du ihn versehentlich veröffentlichst, rotiere ihn in Discord sofort und aktualisiere die betroffene OpenClaw-Konfiguration.

Praktisch ist die sicherere Variante, den Token als Umgebungsvariable zu halten und OpenClaw nur auf diese Variable verweisen zu lassen:

export DISCORD_BOT_TOKEN="dein-discord-bot-token"

Laut OpenClaw-Dokumentation ist der saubere Weg anschließend eine Config-Patch-Datei mit SecretRef auf diese Umgebungsvariable. Das hat zwei Vorteile: Du siehst vor dem Schreiben mit --dry-run, ob die Konfiguration plausibel ist, und der Token landet nicht als Klartext in deiner Konfiguration:

cat > discord.patch.json5 <<'JSON5'
{channels: {discord: {enabled: true, token: {source: "env", provider: "default", id: "DISCORD_BOT_TOKEN"}}}}
JSON5
openclaw config patch --file ./discord.patch.json5 --dry-run
openclaw config patch --file ./discord.patch.json5
openclaw gateway

Wenn OpenClaw bereits als Dienst läuft, reicht das reine Patchen nicht. Dann muss die Runtime neu starten und dieselbe Umgebungsvariable auch wirklich sehen. Für Managed-Service-Setups nennt die Dokumentation dafür zwei sichere Wege: openclaw gateway install aus einer Shell mit gesetzter Variable oder eine persistente Ablage in ~/.openclaw/.env.

Wenn du wissen willst, welche Konfigurationsdatei OpenClaw gerade nutzt, kannst du sie mit folgendem Befehl anzeigen lassen:

openclaw config file

Falls dein Host beim Discord-Start durch Application-Lookups blockiert oder rate-limitiert wird, empfiehlt die Dokumentation zusätzlich die applicationId aus dem Developer Portal in die Discord-Konfiguration zu setzen. Damit kann OpenClaw diesen REST-Schritt beim Start überspringen.

Bot zum Server hinzufügen

Nach dem Bot-Setup folgt der OAuth2-Schritt im Discord Developer Portal. Wechsle zur Anwendung, öffne den OAuth2-Bereich und erzeuge eine Invite-URL.

Für das von OpenClaw dokumentierte Setup aktivierst du im OAuth2 URL Generator:

• bot
• applications.commands

Danach erscheint der Bereich für Bot Permissions. Als dokumentierte Baseline für normale Textkanäle nennt OpenClaw mindestens:

• View Channels
• Send Messages
• Read Message History
• Embed Links
• Attach Files
• Add Reactions (optional)

Wenn du später in Threads, Forum-Kanälen oder Media-Channel-Workflows posten willst, kommt zusätzlich Send Messages in Threads dazu. Genau dieser Punkt wird leicht übersehen: In normalen Textkanälen wirkt der Bot gesund, scheitert aber dort, wo Discord intern mit Threads arbeitet.

Öffne danach die erzeugte Invite-URL, wähle den Zielserver aus und autorisiere den Bot.

Prüfe nach dem Invite konkret:

• Erscheint der Bot in der Mitgliederliste des Servers?
• Hat seine Rolle Zugriff auf den Testkanal?
• Kann er den Kanal sehen?
• Darf er dort Nachrichten senden?
• Ist der Bot nur auf dem Testserver oder versehentlich auch auf einem produktiven Server gelandet?

Die OpenClaw-Seite nennt als Ziel sowohl Direktnachrichten als auch Guild Channels. Bei Guild Channels entscheidet Discords Rechte- und Rollenmodell mit darüber, ob Nachrichten überhaupt beim Bot ankommen können.

IDs und DMs nicht vergessen

OpenClaw braucht für einen robusten Discord-Setup mehr als nur den Bot-Token. Die Dokumentation empfiehlt, im Discord-Client den Developer Mode zu aktivieren, dann Server ID und User ID zu kopieren und zusammen mit dem Token bereitzuhalten.

Für DM-Pairing kommt noch eine leicht übersehene Stelle dazu: In den Privacy Settings des Servers müssen Direktnachrichten von Server-Mitgliedern erlaubt sein. Wenn das aus ist, kann dein Bot technisch korrekt laufen und trotzdem keinen nutzbaren Pairing-Dialog in DMs aufbauen.

OpenClaw starten oder neu laden

Nachdem Token und Serverzugriff stimmen, muss OpenClaw mit der aktualisierten Konfiguration laufen. Der genaue Start- oder Reload-Befehl hängt von deiner Installation ab: lokal im Terminal, als Dienst, über systemd, Docker oder einen anderen Prozessmanager.

Der Mindestcheck ist:

openclaw config validate

Für die eigentliche Diagnose nennt die aktuelle OpenClaw-Dokumentation zusätzlich diese drei Checks:

openclaw doctor
openclaw channels status --probe
openclaw logs --follow

Damit trennst du sauber zwischen Konfigurationsfehler, fehlenden Intents/Berechtigungen und einer Runtime, die zwar läuft, aber auf Discord-Ebene blockiert ist.

Wichtig für die Fehlersuche: Wenn du einen Token rotiert oder applicationId, Allowlist oder Guild-Verhalten geändert hast, testest du immer gegen die frisch gestartete Runtime. Sonst jagst du ein altes Prozessbild und hältst Discord für kaputt, obwohl nur die Runtime noch mit dem vorherigen Snapshot läuft.

Pairing nicht überspringen

Die OpenClaw-Dokumentation verweist beim Discord-Kanal auch auf Pairing und sagt, dass Discord-DMs standardmäßig in den Pairing-Modus gehen. Das ist wichtig, weil der Kanal nicht nur technisch verbunden sein muss. Nachrichten müssen auch einem passenden OpenClaw-Kontext zugeordnet werden.

Der praktische Ablauf ist klar beschrieben: Gateway starten, dem Bot in Discord eine DM schicken, den Pairing-Code empfangen und diesen Code dann über einen bereits funktionierenden Kanal oder per CLI freigeben. Die Codes laufen nach einer Stunde ab. Wenn also alles korrekt wirkt, aber eine ältere DM nicht mehr freigeschaltet werden kann, ist ein abgelaufener Code wahrscheinlicher als ein Bot-Defekt.

Per CLI läuft die Freigabe so:

openclaw pairing list discord
openclaw pairing approve discord <CODE>

Wenn der Bot erreichbar ist, aber die Unterhaltung nicht so reagiert wie erwartet, ist also nicht automatisch der Bot-Token falsch. Es kann auch an Pairing, Server-Kontext oder Berechtigungen liegen. Arbeite die Kette von außen nach innen ab:

1. Bot existiert im Discord Developer Portal.
2. Message Content Intent ist aktiv.
3. Bot-Token ist aktuell und in OpenClaw referenziert.
4. Bot ist auf dem richtigen Server.
5. Bot sieht den Testkanal und darf dort schreiben.
6. OpenClaw läuft mit der aktualisierten Konfiguration.
7. Pairing ist für die gewünschte Unterhaltung abgeschlossen.

Guild-Channels: DM funktioniert nicht automatisch gleich Serverbetrieb

Ein häufiger Denkfehler: Wenn DMs funktionieren, ist Discord komplett erledigt. OpenClaw trennt aber DMs und Guild-Channels im Laufzeitmodell bewusst. Direktchats teilen sich standardmäßig die Main-Session, Guild-Channels bekommen eigene Session-Keys. Genau deshalb kann ein Bot in DMs sauber laufen und in einem Server trotzdem „stumm“ wirken.

Laut Dokumentation musst du für echte Servernutzung zusätzlich den Server in die Guild-Allowlist aufnehmen, wenn du mit groupPolicy: "allowlist" arbeitest. Typisch ist dabei eine Konfiguration wie:

{channels: {discord: {groupPolicy: "allowlist", guilds: {YOUR_SERVER_ID: {requireMention: true, users: ["YOUR_USER_ID"]}}}}}

Danach entscheidest du bewusst, wie gesprächig der Bot in Guild-Channels sein soll:

• requireMention: true hält den Bot zurück und ist für geteilte Server meist die sichere Voreinstellung.
• requireMention: false ist für private Server praktischer, weil der Bot nicht erst erwähnt werden muss.
• Für gemeinsame Dauerkanäle nennt die Dokumentation zusätzlich messages.groupChat.visibleReplies: "message_tool". Dann kann der Agent mitlesen und nur dann sichtbar posten, wenn der Turn wirklich einen Channel-Reply auslöst.

Wichtig dabei: requireMention: false öffnet nicht automatisch jeden Kanal. Wenn du unter einer Guild zusätzlich einen channels-Block definierst, sind nur die dort gelisteten Kanäle erlaubt. Genau das ist ein häufiger Grund, warum der Bot in einem Server teilweise reagiert und teilweise nicht.

Gerade der sichtbare Reply-Modus erklärt außerdem ein reales Fehlerbild, das sonst schwer greifbar ist: Discord zeigt Typing und im Hintergrund wird auch gearbeitet, aber im Kanal erscheint keine normale Antwort. Dann ist oft nicht das Gateway tot, sondern der sichtbare Reply-Modus passt nicht zum Raumtyp oder der Turn läuft als Ambient-Event statt als normaler sichtbarer Reply.

Slash Commands realistisch einordnen

Wenn Slash Commands fehlen, liegt das oft zuerst am Invite-Scope applications.commands oder an einer noch nicht sauber abgeschlossenen Registrierung. OpenClaw selbst startet hier standardmäßig nicht mit einer manuellen Spezialkonfiguration: Für Discord stehen native Commands laut aktueller Dokumentation standardmäßig auf commands.native = "auto".

Heißt praktisch: Wenn der Bot da ist, aber /help, /status oder andere native Befehle nicht auftauchen, prüfst du zuerst den Invite und danach die Runtime, nicht irgendeine exotische Zusatzkonfiguration.

Typische Fehlerquellen

Symptom	Wahrscheinliche Ursache	Prüfung
Bot ist auf dem Server, reagiert aber nicht auf normale Nachrichten	Message Content Intent fehlt oder OpenClaw läuft nicht mit aktueller Konfiguration	Intents im Developer Portal prüfen, danach Runtime neu starten
Slash Commands fehlen	applications.commands-Scope beim Invite nicht gesetzt oder Befehle noch nicht registriert	OAuth2-Invite prüfen und Runtime/Registrierung neu anstoßen
DM funktioniert, Guild-Channel bleibt still	Guild-Allowlist, requireMention, Kanalrechte oder eingeschränkter channels-Block passen nicht	Server-ID, Guild-Config, Kanal-Overrides und Channel-Allowlist prüfen
Discord zeigt Typing, aber keine sichtbare Antwort erscheint	sichtbare Replies laufen über message_tool oder der Turn bleibt im Ambient-/Room-Modus	messages.groupChat.visibleReplies und Routing prüfen

Wenn der Bot grundsätzlich läuft, aber einzelne Betriebszustände brechen:

Symptom	Wahrscheinliche Ursache	Prüfung
Direktnachricht landet im Pairing, aber keine nutzbare Unterhaltung entsteht	Pairing nicht abgeschlossen oder Pairing-Code ist abgelaufen	Pairing-Code neu erzeugen und innerhalb einer Stunde freigeben
Nach Token-Rotation funktioniert nichts mehr	OpenClaw nutzt noch alten Token oder Prozess wurde nicht neu geladen	Env-Variable, SecretRef und laufenden Prozess prüfen
Start oder Reconnect wirkt instabil	Discord-Application-Lookup am Host blockiert oder wird rate-limitiert	applicationId explizit setzen und Runtime neu starten

Die häufigsten Discord-Probleme entstehen an Schnittstellen, nicht in einem einzelnen großen Schritt. Ein fehlender Message Content Intent kann aussehen wie ein kaputter Agent. Ein Bot ohne Serverrechte kann aussehen wie ein OpenClaw-Problem. Ein unvollständiges Pairing kann aussehen wie ein Kommunikationsfehler zwischen Nutzer und Agent.

Darum lohnt sich ein Setup-Check, bevor du an der Agentenseite debuggt: Stimmen Anwendung und Bot im Developer Portal? Sind die benötigten Privileged Intents gesetzt? Wurde der aktuelle Bot-Token verwendet? Ist der Bot wirklich auf dem richtigen Server? Sieht er den Kanal, in dem du testest? Erst wenn diese Punkte grün sind, wird tieferes Debugging sinnvoll.

Reality Check

• Discord ist für OpenClaw kein reiner Token-Kanal. Ohne Intents, IDs, Pairing und saubere Guild-Regeln wird der Bot schnell „halb lebendig“.
• DMs und Guild-Channels solltest du getrennt testen. Ein grüner DM-Test heißt nicht automatisch, dass dein Server-Setup stimmt.
• Für private Testserver ist requireMention: false praktisch. Für geteilte Teams oder Community-Server ist die restriktivere Guild-Config meist die bessere Ausgangsbasis.
• Wenn du mit mehreren Discord-Bots arbeitest, lohnt sich eine explizite Konto-Trennung mit eigener applicationId und eigenem Token je Account. Die Dokumentation weist darauf hin, dass doppelt aufgelöste Tokens in der Runtime zusammengezogen werden können.

Weiterlesen

• Wenn du statt Discord eher private Messenger nutzen willst, hilft der Vergleich mit Signal für OpenClaw: Pairing, Gruppen und sichere Replies.
• Für teamartige Server-Setups lohnt sich der Gegencheck mit Slack als Team-Frontend für OpenClaw-Agenten.
• Wenn du Matrix statt Discord einsetzt, ist Matrix mit OpenClaw verbinden: Räume, Push Rules und sichere Replies der naheliegende Nachbarartikel.
• Für wiederkehrende Jobs und Zustellprobleme außerhalb von Discord hilft der Überblick zu Cron-Jobs, Heartbeats und Automationen.

Merksatz

Discord wird für OpenClaw berechenbar, wenn du nicht nur „den Bot online“ bekommst, sondern die ganze Kette absicherst: Intents, Rechte, IDs, Runtime-Neustart, Pairing und Guild-Verhalten. Genau dort entscheiden sich die meisten realen Fehlerbilder. Wer diese Reihenfolge einhält, findet die Ursache meist schneller als mit blindem Neuinstallieren.