OpenClaw 2026.3.8: Discord Guild MESSAGE_CREATE Not Delivered to Gateway (Symptoms, Checks, Workarounds)

A community report indicates that OpenClaw 2026.3.8 may fail to receive Discord guild channel messages (MESSAGE_CREATE), even though Discord DMs still work.

Source issue: openclaw/openclaw#42615
Relevant docs: Discord channel setup

This article is not a generic release note. It’s a growth-style troubleshooting memo: what it looks like, what to verify first, and what to do if you need to unblock today.

TL;DR

If DM works but guild channel messages never show up in gateway logs, check these in order:

Guild allowlist / channel allowlist (most common)
requireMention or group policy settings that effectively filter all messages
Discord privileged intents + bot permissions
If all above are correct, treat it as a possible 2026.3.8 regression and use a workaround (DMs / downgrade / alternate channel) while tracking the issue.

What the symptom looks like

From the report:

Gateway logs show Discord login + resolution of guild/channels.
But messages sent in guild channels never appear as inbound events in gateway logs.
Meanwhile, DM messages work with the same bot/token.
A separate discord.js listener with the same token receives guild messages, suggesting the token/network are fine.

If you’re seeing the same pattern, you’re likely in one of two buckets:

Config/allowlist filters silently exclude guild traffic
A provider-side regression where guild MESSAGE_CREATE isn’t registered/forwarded

Fast checks (do these first)

1) Confirm you actually allow guild/channel traffic

OpenClaw treats Discord DMs and guild channels differently.

Typical safe baseline for a private server:

{
  channels: {
    discord: {
      groupPolicy: "allowlist",
      guilds: {
        "<YOUR_GUILD_ID>": {
          // Let messages in without needing @mention (private server only)
          requireMention: false,

          // OPTIONAL: allow only specific users
          users: ["<YOUR_USER_ID>"],

          // Strongest form: allow only explicit channels
          channels: {
            "<CHANNEL_ID_1>": { allow: true, requireMention: false },
            "<CHANNEL_ID_2>": { allow: true, requireMention: false }
          }
        }
      }
    }
  }
}

If your config only has DM allowlists (pairing / allowFrom) but no guild/channel allowlist, then DMs can work perfectly while guild messages are dropped by design.

Docs reference for allowlist semantics: OpenClaw Discord docs.

2) Check `requireMention` doesn’t filter everything

If requireMention: true, your bot will only react when explicitly @mentioned.

This setting does not usually prevent MESSAGE_CREATE from arriving at all, but in practice many people interpret “no response” as “no inbound event”. Make sure you are looking at raw inbound logs (or temporarily set requireMention: false in a private server).

3) Verify privileged intents and channel permissions

In Discord Developer Portal → Bot → Privileged Gateway Intents:

Message Content Intent: ON (required)
Server Members Intent: recommended (helps allowlists and name-to-ID mapping)
Presence Intent: optional

Also confirm the bot has channel permissions:

View Channel
Read Message History
Send Messages

The issue reporter explicitly checked intents and permissions, so if you match their setup and still see nothing, continue below.

If everything looks correct: treat as a potential 2026.3.8 regression

The report suggests a version-specific failure mode:

Environment: OpenClaw 2026.3.8
DM works
Guild MESSAGE_CREATE appears absent from gateway logs

At the time of writing, this is tracked upstream here:

openclaw/openclaw#42615

Safe workarounds (pick one)

Use Discord DMs temporarily
- If your workflow can tolerate it, keep work in DMs until the provider path is confirmed.
Route guild work to another channel
- If you already have Slack / Telegram / Feishu, bind that channel for the affected agent session while Discord is flaky.
Pin / downgrade to a known-good version (if you have one)
- If you upgraded recently and have a previously working build, pin back to that version.
- Do this carefully (back up config/state first). If you’re not sure, wait for an upstream fix.

What to collect before commenting on the issue (helps maintainers)

If you want to help upstream quickly, gather these (redact tokens):

Gateway logs around a test message
Your guild/channel IDs and allowlist snippet
Confirmation that discord.js external listener receives messages with the same token
Your OpenClaw version and how you installed it (npm/source/docker)

Then add it to: openclaw/openclaw#42615

Fast FAQ for DM works but guild messages disappear

If someone searches `discord guild message_create missing openclaw 2026.3.8`, what should this page answer first?

The first answer should be: if DM still works, do not assume the entire Discord integration is down.

That pattern usually means one of two things:

guild traffic is being filtered by config or policy
guild-only event handling regressed while DM handling still works

This helps readers avoid wasting time on token rotation or full reinstall first.

What is the fastest way to separate allowlist mistakes from a real provider regression?

Use one controlled guild channel and test in this order:

explicit guild/channel allowlist enabled
requireMention: false in that private test channel
privileged intents confirmed in Discord Developer Portal
same token tested with an external discord.js listener

If OpenClaw still sees nothing while the external listener receives the event, the case becomes much stronger as a provider-level regression report.

When should operators stop debugging and switch to a workaround path?

Switch early if the affected Discord guild path is blocking support, alerts, or daily operations and the first-pass checks are already clean.

In that situation, the practical move is to keep work flowing through DM or another stable channel while collecting clean evidence for upstream, instead of burning more time on blind retries.

If troubleshooting traffic lands here, separate Discord event delivery from gateway session recovery

GA4 now shows this Discord guild message page beside gateway restart and setup traffic, so readers may arrive with a channel symptom even when the real failure is upstream event delivery.

Before rotating bot tokens or rebuilding the gateway, split the trace into three checks:

Discord never emits MESSAGE_CREATE to the gateway: verify gateway intents, guild subscription scope, bot permissions, and whether the event appears in raw Discord adapter logs.
The event reaches OpenClaw but no session receives it: inspect channel binding, workspace routing, and conversation lookup before changing Discord credentials.
Only post-restart sessions miss messages: compare this page with orphaned-session recovery logs so restart ordering is not mistaken for a Discord API outage.

This keeps high-intent Discord readers on the shortest path: prove event delivery first, then debug routing, and only then treat the problem as a resumed-session recovery issue.

Sources

Issue report: openclaw/openclaw#42615
Docs: Discord - OpenClaw

If you arrived from the homepage, install path, or migration guide

GA4 now places this Discord guild.message.create missing-event page inside the same small Chinese discovery cluster. First confirm that you are debugging Discord gateway events not reaching OpenClaw, not installation, migration, provider-key, or Control UI problems.

OpenClaw was just installed and Gateway or Web UI health is still unknown: use the Mac install guide or installation success checklist before blaming Discord events.
A Moltbot migration left tokens, channels, or old bot config mixed together: use the 1-minute migration guide and confirm the running bot/config is OpenClaw’s current one.
Only Discord guild messages do not trigger while other entrances work: stay on this page and check Discord intents, bot permissions, channel visibility, gateway logs, and the message_create event path.

This routing separates “not installed”, “not migrated”, and “Discord event did not arrive” so platform-config issues do not get misread as OpenClaw message-handling bugs.

Search-entry triage: what to check when Discord guild message create events are missing

If you landed here from searches like “Discord guild message create missing”, “OpenClaw Discord messages not received”, or “Discord bot does not trigger agent”, split the issue into four layers:

Check whether Discord actually delivered the event: inspect gateway events, bot intents, guild id, channel id, and message type before relying on whether the OpenClaw UI replied.
Check permissions and intent configuration: message content intent, channel permissions, and whether the bot is in the target guild can all make messages look lost.
Check whether the adapter filtered the event: bot messages, thread messages, replies, system messages, or unsupported channels may be intentionally skipped by the channel adapter.
Preserve a minimal reproduction packet: event timestamp, guild/channel/message id, bot logs, and OpenClaw session id are more useful than saying “Discord did not respond”.

Do not debug this class of issue only by restarting the bot. The shortest path is to compare Discord gateway delivery, permissions/intents, adapter filtering, and OpenClaw session creation.