Summary

Discord guild/channel messages can show a noticeable delay before the bot appears to start typing, even when agents.defaults.typingMode = "instant" and no inbound debounce is configured.

Observed behavior: in Discord server channels, the user sends a message, then there is often ~5-7 seconds of no typing indicator before the bot starts typing. The response itself then takes a few more seconds.

This appears to affect multiple routed agents/channels, not just one workspace/agent.

Environment

• OpenClaw: 2026.5.6
• Runtime model: openai-codex/gpt-5.5
• Channel: Discord guild channels
• Config uses guild-scoped allowlist + per-channel agent bindings
• agents.defaults.typingMode = "instant"
• No configured messages.inbound debounce
• No configured messages.queue debounce
• No configured Discord-specific debounce/eventQueue override

Config shape checked

Relevant config summary:

{
  "channels": {
    "discord": {
      "groupPolicy": "allowlist",
      "dmPolicy": "pairing",
      "guilds": {
        "<guildId>": {
          "requireMention": false,
          "users": ["<authorizedUserId>"],
          "channels": {
            "<channelId>": { "enabled": true }
          }
        }
      }
    }
  },
  "agents": {
    "defaults": {
      "typingMode": "instant"
    }
  },
  "bindings": [
    {
      "agentId": "alex",
      "match": {
        "channel": "discord",
        "peer": { "kind": "group", "id": "<channelId>" }
      }
    }
  ]
}

openclaw config validate passes, and openclaw doctor --non-interactive exits 0.

Timing example

For one Discord guild channel test message:

• User Discord message timestamp: 21:34:36.424Z
• Session transcript user message write: 21:34:43.790Z
• Assistant Discord reply timestamp: 21:34:47.250Z

Approximate breakdown:

• ~7.4s from Discord message timestamp to session write / processing
• ~3.5s from processing to reply

This matches the human-visible symptom: ~5-7 seconds before typing appears, then a few seconds until the response arrives.

Source/code observation

Current Discord plugin bundle appears to only send the early accepted typing cue for DMs:

function shouldSendAcceptedDiscordTypingCue(ctx) {
  if (ctx.abortSignal?.aborted) return false;
  if (!ctx.isDirectMessage || ctx.isGuildMessage || ctx.isGroupDm) return false;
  if (!ctx.messageText.trim()) return false;
  const configuredTypingMode = ctx.cfg.session?.typingMode ?? ctx.cfg.agents?.defaults?.typingMode;
  return configuredTypingMode === void 0 || configuredTypingMode === "instant";
}

Path in installed bundle:

@openclaw/discord/dist/message-handler-CSPx1uqO.js

This seems inconsistent with docs that say group typing indicators follow agents.defaults.typingMode:

Typing indicators in groups follow agents.defaults.typingMode...

Docs path checked:

docs/channels/group-messages.md

Expected behavior

With typingMode: "instant", once a Discord guild-channel message is accepted for processing, OpenClaw should send a typing indicator immediately (or at least without a multi-second silent period), similar to DMs.

If there is an intentional guild-channel debounce/batching delay, it should be visible/configurable/documented. In this setup, no inbound debounce is configured.

Actual behavior

Discord guild-channel messages can sit for ~5-7 seconds with no typing indicator before the bot appears to start working.

Questions

1. Is the DM-only early typing cue intentional for Discord guild channels?
2. Should typingMode: "instant" apply to accepted guild-channel messages as the docs imply?
3. Is there another default Discord guild inbound debounce/batching path that could explain ~7s before session write even when messages.inbound is absent?

Impact

This makes multi-agent Discord channels feel laggy or broken even when the model response itself is fast. It also makes it hard to distinguish actual model latency from hidden inbound/typing pipeline delay.