Discord

Discord unterstützt Antwort-Tags in der Agent-Ausgabe:

• [[reply_to_current]]
• [[reply_to:<id>]]

Gesteuert durch channels.discord.replyToMode:

• off (Standard)
• first
• all
• batched

Hinweis: off deaktiviert implizites Antwort-Threading. Explizite [[reply_to_*]]-Tags werden weiterhin beachtet. first hängt die implizite native Antwortreferenz immer an die erste ausgehende Discord-Nachricht für den Turn an. batched hängt die implizite native Antwortreferenz von Discord nur an, wenn der eingehende Turn ein entprellter Batch aus mehreren Nachrichten war. Das ist nützlich, wenn Sie native Antworten hauptsächlich für mehrdeutige, stoßartige Chats wünschen, nicht für jeden einzelnen Nachrichten-Turn.

Nachrichten-IDs werden in Kontext/Verlauf bereitgestellt, damit Agents gezielt bestimmte Nachrichten adressieren können.

OpenClaw kann Antwortentwürfe streamen, indem es eine temporäre Nachricht sendet und sie bearbeitet, sobald Text eintrifft. channels.discord.streaming akzeptiert off | partial | block | progress (Standard). progress hält einen bearbeitbaren Statusentwurf vor und aktualisiert ihn bis zur endgültigen Zustellung mit Tool-Fortschritt; streamMode ist ein Legacy-Runtime-Alias. Führen Sie openclaw doctor --fix aus, um persistierte Konfiguration auf den kanonischen Schlüssel umzuschreiben.

Setzen Sie channels.discord.streaming.mode auf off, um Discord-Vorschaubearbeitungen zu deaktivieren. Wenn Discord-Block-Streaming explizit aktiviert ist, überspringt OpenClaw den Vorschaustream, um doppeltes Streaming zu vermeiden.

{
channels: {
discord: {
  streaming: {
    mode: "progress",
    progress: {
      label: "auto",
      maxLines: 8,
      toolProgress: true,
    },
  },
},
},
}

• partial bearbeitet eine einzelne Vorschaunachricht, sobald Tokens eintreffen.
• block gibt Entwurfs-Chunks aus (verwenden Sie draftChunk, um Größe und Umbruchpunkte abzustimmen, begrenzt durch textChunkLimit).
• Medien-, Fehler- und explizite Antwort-Finals brechen ausstehende Vorschaubearbeitungen ab.
• streaming.preview.toolProgress (Standard true) steuert, ob Tool-/Fortschrittsupdates die Vorschaunachricht wiederverwenden.
• streaming.preview.commandText / streaming.progress.commandText steuert Command-/Exec-Details in kompakten Fortschrittszeilen: raw (Standard) oder status (nur Tool-Label).

Rohtext für Command/Exec ausblenden, während kompakte Fortschrittszeilen beibehalten werden:

{
  "channels": {
    "discord": {
      "streaming": {
        "mode": "progress",
        "progress": {
          "toolProgress": true,
          "commandText": "status"
        }
      }
    }
  }
}

Vorschaustreaming ist rein textbasiert; Medienantworten fallen auf die normale Zustellung zurück. Wenn block-Streaming explizit aktiviert ist, überspringt OpenClaw den Vorschaustream, um doppeltes Streaming zu vermeiden.

Guild-Verlaufskontext:

• channels.discord.historyLimit Standard 20
• Fallback: messages.groupChat.historyLimit
• 0 deaktiviert

DM-Verlaufssteuerung:

• channels.discord.dmHistoryLimit
• channels.discord.dms["<user_id>"].historyLimit

Thread-Verhalten:

• Discord-Threads werden als Kanal-Sessions geroutet und erben die Konfiguration des übergeordneten Kanals, sofern sie nicht überschrieben wird.
• Thread-Sessions erben die Session-bezogene /model-Auswahl des übergeordneten Kanals als reinen Modell-Fallback; Thread-lokale /model-Auswahlen haben weiterhin Vorrang, und der übergeordnete Transkriptverlauf wird nur kopiert, wenn Transkriptvererbung aktiviert ist.
• channels.discord.thread.inheritParent (Standard false) aktiviert für neue Auto-Threads das Seeding aus dem übergeordneten Transkript. Kontospezifische Überschreibungen befinden sich unter channels.discord.accounts.<id>.thread.inheritParent.
• Nachrichten-Tool-Reaktionen können user:<id>-DM-Ziele auflösen.
• guilds.<guild>.channels.<channel>.requireMention: false wird während des Aktivierungs-Fallbacks in der Antwortphase beibehalten.

Kanalthemen werden als nicht vertrauenswürdiger Kontext injiziert. Allowlists steuern, wer den Agent auslösen darf, sind aber keine vollständige Redaktionsgrenze für zusätzlichen Kontext.

Discord kann einen Thread an ein Session-Ziel binden, sodass Folgenachrichten in diesem Thread weiterhin an dieselbe Session geroutet werden (einschließlich Subagent-Sessions).

Commands:

• /focus <target> bindet den aktuellen/neuen Thread an ein Subagent-/Session-Ziel
• /unfocus entfernt die aktuelle Thread-Bindung
• /agents zeigt aktive Läufe und Bindungsstatus an
• /session idle <duration|off> prüft/aktualisiert die Inaktivitäts-Auto-Unfocus-Einstellung für fokussierte Bindungen
• /session max-age <duration|off> prüft/aktualisiert das harte Maximalalter für fokussierte Bindungen

Konfiguration:

{
session: {
threadBindings: {
  enabled: true,
  idleHours: 24,
  maxAgeHours: 0,
},
},
channels: {
discord: {
  threadBindings: {
    enabled: true,
    idleHours: 24,
    maxAgeHours: 0,
    spawnSessions: true,
    defaultSpawnContext: "fork",
  },
},
},
}

Hinweise:

• session.threadBindings.* legt globale Standards fest.
• channels.discord.threadBindings.* überschreibt das Discord-Verhalten.
• spawnSessions steuert das automatische Erstellen/Binden von Threads für sessions_spawn({ thread: true }) und ACP-Thread-Spawns. Standard: true.
• defaultSpawnContext steuert den nativen Subagent-Kontext für threadgebundene Spawns. Standard: "fork".
• Veraltete Schlüssel spawnSubagentSessions/spawnAcpSessions werden durch openclaw doctor --fix migriert.
• Wenn Thread-Bindungen für ein Konto deaktiviert sind, sind /focus und zugehörige Thread-Bindungsoperationen nicht verfügbar.

Siehe Subagents, ACP Agents und Konfigurationsreferenz.

Für stabile, "always-on" ACP-Arbeitsbereiche konfigurieren Sie typisierte ACP-Bindungen auf oberster Ebene, die auf Discord-Konversationen zielen.

Konfigurationspfad:

• bindings[] mit type: "acp" und match.channel: "discord"

Beispiel:

{
agents: {
list: [
  {
    id: "codex",
    runtime: {
      type: "acp",
      acp: {
        agent: "codex",
        backend: "acpx",
        mode: "persistent",
        cwd: "/workspace/openclaw",
      },
    },
  },
],
},
bindings: [
{
  type: "acp",
  agentId: "codex",
  match: {
    channel: "discord",
    accountId: "default",
    peer: { kind: "channel", id: "222222222222222222" },
  },
  acp: { label: "codex-main" },
},
],
channels: {
discord: {
  guilds: {
    "111111111111111111": {
      channels: {
        "222222222222222222": {
          requireMention: false,
        },
      },
    },
  },
},
},
}

Hinweise:

• /acp spawn codex --bind here bindet den aktuellen Kanal oder Thread direkt und hält zukünftige Nachrichten auf derselben ACP-Session. Thread-Nachrichten erben die Bindung des übergeordneten Kanals.
• In einem gebundenen Kanal oder Thread setzen /new und /reset dieselbe ACP-Session direkt zurück. Temporäre Thread-Bindungen können die Zielauflösung überschreiben, solange sie aktiv sind.
• spawnSessions steuert das Erstellen/Binden von Child-Threads über --thread auto|here.

Siehe ACP Agents für Details zum Bindungsverhalten.

Reaktionsbenachrichtigungsmodus pro Guild:

• off
• own (Standard)
• all
• allowlist (verwendet guilds.<id>.users)

Reaktionsereignisse werden in Systemereignisse umgewandelt und an die geroutete Discord-Session angehängt.

ackReaction sendet ein Bestätigungs-Emoji, während OpenClaw eine eingehende Nachricht verarbeitet.

Auflösungsreihenfolge:

• channels.discord.accounts.<accountId>.ackReaction
• channels.discord.ackReaction
• messages.ackReaction
• Agent-Identitäts-Emoji-Fallback (agents.list[].identity.emoji, andernfalls "👀")

Hinweise:

• Discord akzeptiert Unicode-Emoji oder benutzerdefinierte Emoji-Namen.
• Verwenden Sie "", um die Reaktion für einen Kanal oder ein Konto zu deaktivieren.

Kanalinitiierte Konfigurationsschreibvorgänge sind standardmäßig aktiviert.

Dies betrifft /config set|unset-Abläufe (wenn Command-Funktionen aktiviert sind).

Deaktivieren:

{
channels: {
discord: {
  configWrites: false,
},
},
}

Leiten Sie Discord-Gateway-WebSocket-Datenverkehr und REST-Startabfragen (Application-ID + Allowlist-Auflösung) über einen HTTP(S)-Proxy mit channels.discord.proxy.

{
channels: {
discord: {
  proxy: "http://proxy.example:8080",
},
},
}

Kontospezifische Überschreibung:

{
channels: {
discord: {
  accounts: {
    primary: {
      proxy: "http://proxy.example:8080",
    },
  },
},
},
}

Aktivieren Sie die PluralKit-Auflösung, um proxied Nachrichten der Identität eines Systemmitglieds zuzuordnen:

{
channels: {
discord: {
  pluralkit: {
    enabled: true,
    token: "pk_live_...", // optional; needed for private systems
  },
},
},
}

Hinweise:

• Allowlists können pk:<memberId> verwenden
• Anzeigenamen von Mitgliedern werden nur dann nach Name/Slug abgeglichen, wenn channels.discord.dangerouslyAllowNameMatching: true
• Lookups verwenden die ursprüngliche Nachrichten-ID und sind zeitfensterbeschränkt
• Wenn der Lookup fehlschlägt, werden proxied Nachrichten als Bot-Nachrichten behandelt und verworfen, sofern nicht allowBots=true

Verwenden Sie mentionAliases, wenn Agents deterministische ausgehende Erwähnungen für bekannte Discord-Benutzer benötigen. Schlüssel sind Handles ohne führendes @; Werte sind Discord-Benutzer-IDs. Unbekannte Handles, @everyone, @here und Erwähnungen innerhalb von Markdown-Code-Spans bleiben unverändert.

{
channels: {
discord: {
  mentionAliases: {
    Vladislava: "123456789012345678",
  },
  accounts: {
    ops: {
      mentionAliases: {
        OpsLead: "234567890123456789",
      },
    },
  },
},
},
}

Presence-Updates werden angewendet, wenn Sie ein Status- oder Aktivitätsfeld festlegen oder Auto-Presence aktivieren.

Beispiel nur für Status:

{
channels: {
discord: {
  status: "idle",
},
},
}

Aktivitätsbeispiel (benutzerdefinierter Status ist der Standardaktivitätstyp):

{
channels: {
discord: {
  activity: "Focus time",
  activityType: 4,
},
},
}

Streaming-Beispiel:

{
channels: {
discord: {
  activity: "Live coding",
  activityType: 1,
  activityUrl: "https://twitch.tv/openclaw",
},
},
}

Zuordnung der Aktivitätstypen:

• 0: Spielen
• 1: Streaming (erfordert activityUrl)
• 2: Hören
• 3: Zuschauen
• 4: Benutzerdefiniert (verwendet den Aktivitätstext als Statuszustand; Emoji ist optional)
• 5: Teilnehmen

Auto-Presence-Beispiel (Runtime-Health-Signal):

{
channels: {
discord: {
  autoPresence: {
    enabled: true,
    intervalMs: 30000,
    minUpdateIntervalMs: 15000,
    exhaustedText: "token exhausted",
  },
},
},
}

Automatische Präsenz ordnet die Runtime-Verfügbarkeit dem Discord-Status zu: healthy => online, degraded or unknown => idle, exhausted or unavailable => dnd. Optionale Textüberschreibungen:

• autoPresence.healthyText
• autoPresence.degradedText
• autoPresence.exhaustedText (unterstützt den Platzhalter {reason})

Discord unterstützt buttonbasierte Freigabeabwicklung in DMs und kann Freigabeaufforderungen optional im ursprünglichen Kanal posten.

Konfigurationspfad:

• channels.discord.execApprovals.enabled
• channels.discord.execApprovals.approvers (optional; fällt nach Möglichkeit auf commands.ownerAllowFrom zurück)
• channels.discord.execApprovals.target (dm | channel | both, Standard: dm)
• agentFilter, sessionFilter, cleanupAfterResolve

Discord aktiviert native Exec-Freigaben automatisch, wenn enabled nicht gesetzt oder "auto" ist und mindestens ein Freigebender aufgelöst werden kann, entweder aus execApprovals.approvers oder aus commands.ownerAllowFrom. Discord leitet Exec-Freigebende nicht aus Kanal-allowFrom, Legacy-dm.allowFrom oder Direct-Message-defaultTo ab. Setzen Sie enabled: false, um Discord explizit als nativen Freigabeclient zu deaktivieren.

Für sensible, nur Eigentümern vorbehaltene Gruppenbefehle wie /diagnostics und /export-trajectory sendet OpenClaw Freigabeaufforderungen und Endergebnisse privat. Es versucht zuerst eine Discord-DM, wenn der aufrufende Eigentümer eine Discord-Eigentümerroute hat; falls diese nicht verfügbar ist, fällt es auf die erste verfügbare Eigentümerroute aus commands.ownerAllowFrom zurück, zum Beispiel Telegram.

Wenn target channel oder both ist, ist die Freigabeaufforderung im Kanal sichtbar. Nur aufgelöste Freigebende können die Buttons verwenden; andere Benutzer erhalten eine flüchtige Ablehnung. Freigabeaufforderungen enthalten den Befehlstext. Aktivieren Sie daher die Kanalzustellung nur in vertrauenswürdigen Kanälen. Wenn die Kanal-ID nicht aus dem Sitzungsschlüssel abgeleitet werden kann, fällt OpenClaw auf DM-Zustellung zurück.

Discord rendert auch die gemeinsam genutzten Freigabe-Buttons, die von anderen Chatkanälen verwendet werden. Der native Discord-Adapter ergänzt hauptsächlich DM-Routing für Freigebende und Kanal-Fanout. Wenn diese Buttons vorhanden sind, sind sie die primäre Freigabe-UX; OpenClaw sollte nur dann einen manuellen /approve-Befehl einschließen, wenn das Tool-Ergebnis besagt, dass Chat-Freigaben nicht verfügbar sind oder die manuelle Freigabe der einzige Weg ist. Wenn die native Discord-Freigabe-Runtime nicht aktiv ist, hält OpenClaw die lokale deterministische Eingabeaufforderung /approve <id> <decision> sichtbar. Wenn die Runtime aktiv ist, aber keine native Karte an ein Ziel zugestellt werden kann, sendet OpenClaw einen Fallback-Hinweis im selben Chat mit dem exakten /approve- Befehl aus der ausstehenden Freigabe.

Gateway-Authentifizierung und Freigabeauflösung folgen dem gemeinsamen Gateway-Clientvertrag (plugin:-IDs werden über plugin.approval.resolve aufgelöst; andere IDs über exec.approval.resolve). Freigaben laufen standardmäßig nach 30 Minuten ab.

Siehe Exec-Freigaben.

• Message Content Intent aktivieren
• Server Members Intent aktivieren, wenn Sie von Benutzer-/Mitgliedsauflösung abhängen
• Gateway nach dem Ändern von Intents neu starten

• groupPolicy prüfen
• Guild-Allowlist unter channels.discord.guilds prüfen
• wenn eine Guild-channels-Map existiert, sind nur aufgeführte Kanäle erlaubt
• Verhalten von requireMention und Erwähnungsmuster prüfen

Nützliche Prüfungen:

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

Häufige Ursachen:

• groupPolicy="allowlist" ohne passende Guild-/Kanal-Allowlist
• requireMention an der falschen Stelle konfiguriert (muss unter channels.discord.guilds oder dem Kanaleintrag stehen)
• Absender durch Guild-/Kanal-users-Allowlist blockiert

Typische Logs:

• Slow listener detected ...
• stuck session: sessionKey=agent:...:discord:... state=processing ...

Discord-Gateway-Warteschlangenoptionen:

• einzelnes Konto: channels.discord.eventQueue.listenerTimeout
• mehrere Konten: channels.discord.accounts.<accountId>.eventQueue.listenerTimeout
• dies steuert nur Listener-Arbeit des Discord-Gateway, nicht die Lebensdauer des Agent-Turns

Discord wendet kein kanaleigenes Timeout auf eingereihte Agent-Turns an. Nachrichten-Listener übergeben sofort, und eingereihte Discord-Läufe bewahren die Reihenfolge pro Sitzung, bis der Sitzungs-/Tool-/Runtime-Lebenszyklus abgeschlossen ist oder die Arbeit abbricht.

{
channels: {
discord: {
  accounts: {
    default: {
      eventQueue: {
        listenerTimeout: 120000,
      },
    },
  },
},
},
}

OpenClaw ruft vor dem Verbinden Discord-/gateway/bot-Metadaten ab. Bei vorübergehenden Fehlern wird auf die Standard-Gateway-URL von Discord zurückgegriffen; die Meldungen in den Logs werden rate-limitiert.

Regler für Metadata-Timeouts:

• Einzelkonto: channels.discord.gatewayInfoTimeoutMs
• Mehrfachkonto: channels.discord.accounts.<accountId>.gatewayInfoTimeoutMs
• Env-Fallback, wenn keine Konfiguration gesetzt ist: OPENCLAW_DISCORD_GATEWAY_INFO_TIMEOUT_MS
• Standardwert: 30000 (30 Sekunden), max.: 120000

OpenClaw wartet beim Start und nach erneuten Verbindungen zur Laufzeit auf das Gateway-READY-Event von Discord. Mehrfachkonto-Setups mit gestaffeltem Start können ein längeres READY-Fenster beim Start benötigen als den Standardwert.

Regler für READY-Timeouts:

• Start, Einzelkonto: channels.discord.gatewayReadyTimeoutMs
• Start, Mehrfachkonto: channels.discord.accounts.<accountId>.gatewayReadyTimeoutMs
• Env-Fallback beim Start, wenn keine Konfiguration gesetzt ist: OPENCLAW_DISCORD_READY_TIMEOUT_MS
• Standardwert beim Start: 15000 (15 Sekunden), max.: 120000
• Laufzeit, Einzelkonto: channels.discord.gatewayRuntimeReadyTimeoutMs
• Laufzeit, Mehrfachkonto: channels.discord.accounts.<accountId>.gatewayRuntimeReadyTimeoutMs
• Env-Fallback zur Laufzeit, wenn keine Konfiguration gesetzt ist: OPENCLAW_DISCORD_RUNTIME_READY_TIMEOUT_MS
• Standardwert zur Laufzeit: 30000 (30 Sekunden), max.: 120000

Berechtigungsprüfungen mit channels status --probe funktionieren nur für numerische Kanal-IDs.

Wenn Sie Slug-Schlüssel verwenden, kann die Laufzeitzuordnung weiterhin funktionieren, aber die Probe kann Berechtigungen nicht vollständig überprüfen.

• DM deaktiviert: channels.discord.dm.enabled=false
• DM-Richtlinie deaktiviert: channels.discord.dmPolicy="disabled" (Legacy: channels.discord.dm.policy)
• ausstehende Kopplungsgenehmigung im pairing-Modus

Standardmäßig werden von Bots verfasste Nachrichten ignoriert.

Wenn Sie channels.discord.allowBots=true setzen, verwenden Sie strikte Erwähnungs- und Allowlist-Regeln, um Schleifenverhalten zu vermeiden. Bevorzugen Sie channels.discord.allowBots="mentions", um nur Bot-Nachrichten zu akzeptieren, die den Bot erwähnen.

{
channels: {
discord: {
  accounts: {
    mantis: {
      // Mantis listens to other bots only when they mention her.
      allowBots: "mentions",
    },
    molty: {
      // Molty listens to all bot-authored Discord messages.
      allowBots: true,
      mentionAliases: {
        // Lets Molty write "@Mantis" and send a real Discord mention.
        Mantis: "MANTIS_DISCORD_USER_ID",
      },
    },
  },
},
},
}

• halten Sie OpenClaw aktuell (openclaw update), damit die Wiederherstellungslogik für den Discord-Voice-Empfang vorhanden ist
• bestätigen Sie channels.discord.voice.daveEncryption=true (Standardwert)
• beginnen Sie mit channels.discord.voice.decryptionFailureTolerance=24 (Upstream-Standardwert) und passen Sie den Wert nur bei Bedarf an
• beobachten Sie die Logs auf:
  • discord voice: DAVE decrypt failures detected
  • discord voice: repeated decrypt failures; attempting rejoin
• wenn die Fehler nach dem automatischen erneuten Beitritt weiter auftreten, sammeln Sie Logs und vergleichen Sie diese mit der Upstream-DAVE-Empfangshistorie in discord.js #11419 und discord.js #11449