Bug: Guild messages not received - intents:content=limited

[inland nebula]

OpenClaw 2026.2.3-1, Windows

• Bot sends to guilds ✅
• Bot receives DMs ✅
• Bot receives guild messages ❌ (even when @mentioned)
• Status shows intents:content=limited despite all intents ON in Dev Portal

Tried: new token, new bot from scratch, re-invite, update OpenClaw. Nothing works.
Seems like gateway doesn't request MESSAGE_CONTENT intent?

[warm bear]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[dense hull]

intents:content=limited in openclaw status is not “the gateway didn’t request it” — it’s Discord’s application flags (what Discord says your bot is allowed to do). “limited” is a real Discord mode and can be totally normal for small/unverified bots.

Given your symptoms (DMs ✅, guild messages ❌), the most common cause in OpenClaw is actually config gating, not the Discord intent:

1) Check OpenClaw is allowing guild traffic at all

In recent versions, Discord guild handling is gated by channels.discord.groupPolicy and channels.discord.guilds.

Run:

openclaw channels status --channel discord --probe

If your groupPolicy is allowlist (common), and you have no channels.discord.guilds entries, OpenClaw will happily do DMs but ignore all guild channels.

Quick “just make it work for testing” config:

{
  channels: {
    discord: {
      enabled: true,
      groupPolicy: "open",      // <— for testing
      guilds: { "*": { requireMention: true } },
    },
  },
}

Then restart the gateway.

Docs: https://docs.openclaw.ai/channels/discord (see “Bot connects but never replies in a guild channel” + the groupPolicy notes)

2) If you’re testing inside a forum post/thread

Discord forum posts are threads. OpenClaw treats threads as separate channels and they inherit parent channel config, so if you allowlisted #help but you’re typing in a forum thread, you can still get blocked depending on your guilds.*.channels rules.

Docs note: “Threads inherit parent channel config … unless you add the thread channel id explicitly.”
https://docs.openclaw.ai/channels/discord

3) Sanity-check basic Discord perms (not intents)

Make sure the bot has (in that channel/thread):

• View Channel
• Send Messages
• Read Message History

(You can send without reliably receiving if perms are weirdly set.)

If you paste one thing, paste this

• Output of openclaw channels status --channel discord --probe
• Your channels.discord config block (redact token)

That’ll usually make the failure mode obvious in 30 seconds.

[inland nebula]

Thanks for the detailed response. I've checked and my config looks correct:

"discord": {
"groupPolicy": "open",
"guilds": {
"*": { "requireMention": true },
"1468198642031657249": {
"requireMention": false,
"users": ["405369141743058954"]
}
}
}

Symptoms:
DMs: ✅ work perfectly
Guild message sending (via API/bot): ✅ works
Guild message receiving: ❌ nothing arrives

What I tried:
Created a brand new bot "Yumka" with all intents enabled BEFORE generating token
Set groupPolicy: "open"
Configured my guild explicitly with requireMention: false
Regenerated token, re-invited bot, restarted gateway multiple times
Bot has all permissions (View Channel, Send Messages, Read Message History)

openclaw status still shows intents:content=limited despite Message Content Intent being enabled in Discord Developer Portal.

The bot is in the guild, can send messages there, but never receives any guild messages. Any other ideas?

[dense hull]

intents:content=limited in openclaw status is not “OpenClaw didn’t request MESSAGE_CONTENT” — it’s reading Discord’s application flags (/oauth2/applications/@me) and reporting that your app has the limited privileged-intent flag set (common for unverified bots). So I wouldn’t chase that line by itself.

Given your symptoms (DM receive ✅, guild send ✅, guild receive ❌), the two most likely causes are:

1. The Gateway is running with a different config/token than you think (Windows service vs CLI config mismatch is super common), or
2. Guild messages are being received but dropped by policy (groupPolicy / guild allowlist / channel allowlist / requireMention / users), and you’re not seeing the drop reason yet.

What I need next (these 3 outputs usually make it obvious)

Please paste:

openclaw gateway status
openclaw channels status --probe
openclaw status --all

(Those are safe-ish to share; tokens get redacted.)

And do one live test:

openclaw logs --follow

Then, while logs are streaming, send a message in the guild channel and paste the few log lines that appear (or confirm “literally nothing logs when I talk in a guild channel”).

Quick “strip it to the bone” config test

Temporarily remove all gating (no users allowlist, no mention requirement), restart gateway, and test in a normal text channel (not a thread):

{
  channels: {
    discord: {
      groupPolicy: "open",

      guilds: {
        "*": { requireMention: false }
      }
    }
  }
}

If this still doesn’t receive anything, it’s almost certainly not your allowlist/mention settings — it’ll be “wrong token/config actually in use” or something at the gateway connection layer, and the --probe + logs will show it.

If you paste the 3 command outputs above, I can tell you exactly which branch you’re in.

[inland nebula]

Here are the outputs:

openclaw gateway status: Service running, probe ok, listening on 0.0.0.0:18789

openclaw channels status --probe:
Discord default: enabled, configured, running, in:1m ago, out:just now, bot:@Yumka, token:config, intents:content=limited, works, audit ok
Warning: Some configured guild channels are not numeric IDs (unresolvedChannels=2)

Key finding in openclaw logs --follow:
discord channel resolve failed; using config entries. Discord API /channels/1468198642031657249 failed (404): Unknown Channel

But 1468198642031657249 is my guild ID, not a channel ID. The bot CAN list all channels via API (I verified with

channel-list - it returns 25+ channels correctly).

Current config (stripped to bone as you suggested):
"discord": {
"groupPolicy": "open",
"guilds": {
"*": { "requireMention": false },
"1468198642031657249": { "requireMention": false, "users": ["405369141743058954"] }
}
}

Live test: Sent message in #général - literally nothing appears in logs. Only DMs trigger log entries.

Bot can send to guild channels, can list channels, but receives zero inbound guild messages.

[dense hull]

That log line is a really good clue, and it also explains why this feels like “receives nothing”.

1) The /channels/<guildId> 404 is an OpenClaw resolver bug (cosmetic, but confusing)

OpenClaw has a “resolve guild/channel allowlist entries” step on startup. The parser currently treats a bare numeric string as a channel id first, so when it sees your guild key "1468198642031657249" it tries:

• GET /channels/1468198642031657249 → 404 (because that’s a guild id)

Then it prints:

discord channel resolve failed; using config entries...

That resolution failure shouldn’t prevent receiving messages by itself; it just means it couldn’t “normalize” the config keys.

2) Why you see “zero inbound” in logs: OpenClaw drops Discord messages with empty content

In the Discord handler, OpenClaw does:

• build messageText = resolveDiscordMessageText(...)

• and if it’s empty: it drops the message (drop message ... (empty content))

That drop is logged at verbose/debug level, so with normal logging you’ll see… nothing.

This exact pattern happens when Discord delivers guild MESSAGE_CREATE events but strips content (Message Content intent not actually effective), so messageText becomes empty → OpenClaw drops it.

3) The unresolvedChannels=2 warning strongly suggests config mismatch (or leftover guilds.*.channels)

You said your “bone config” has no channels allowlist at all, yet channels status --probe still says:

unresolvedChannels=2

That means the running config still contains something like:

channels: { discord: { guilds: { "<guild>": { channels: { "<non-numeric>": ... }}}}}

So before anything else, can you paste the full raw output of:

• openclaw gateway status (the lines that show Config (cli) vs Config (service) are the key)
• openclaw status --all

On Windows it’s very common to edit one config file while the scheduled-task service is running another.

4) One quick confirm: does inbound activity time update when you chat in a guild?

Do this in order:

1. Run: openclaw channels status --probe and note the in: ... time.
2. Send 2-3 messages in #général.
3. Run openclaw channels status --probe again.

• If in: updates → OpenClaw is receiving guild events, but likely dropping them as empty content.
• If in: does not update → it’s not getting guild events at all (different problem; config/gateway intents/session).

5) If it’s “empty content”: what to do

Turn on debug logs temporarily so we can see the real drop reason:

{ logging: { level: "debug" } }

Restart gateway, then send a guild message and look for lines like:

• discord: inbound ... type=guild content=no
• discord: drop message ... (empty content)

If that’s what you see, the fix is Discord-side: Message Content intent still isn’t actually being granted/applied for that bot (despite the portal UI). At that point, the most useful next artifact is the debug log snippet + your openclaw status --all, and I’d suggest filing a GitHub issue with those logs because OpenClaw could also improve behavior here (e.g., not “silent drop” / better warning).
https://github.com/openclaw/openclaw/issues

Paste the two full outputs + whether the in: timestamp changes, and we can narrow it to the exact branch in one round.

[inland nebula]

Test done. Results:

in: timestamp check: Didn't update after sending guild messages.

Logs show:

Discord login success: logged in to discord as 1469426295581573395
DM messages arrive fine: channel=discord chatId=channel:1469429544024014889 messageId=...
Zero guild message events in logs - not even a "drop" message
No "drop message (empty content)" lines anywhere. It's not dropping messages - it's simply not receiving any guild MESSAGE_CREATE events at all.

Cleaned config (removed the custom-1/custom-2 that caused unresolvedChannels warning):

"guilds": {
"*": { "requireMention": false },
"1468198642031657249": { "requireMention": false, "users": ["405369141743058954"] }
}
Summary:

DMs ✅ (arrive and process)
Guild send ✅ (bot can post)
Guild receive ❌ (zero events, not even empty content drops)
Feels like Discord isn't sending MESSAGE_CREATE for guilds despite the bot being connected and having permissions. The gateway session might not be requesting the right intents?

[dense hull]

That’s a really useful data point: if DM MESSAGE_CREATE events arrive but guild MESSAGE_CREATE events never arrive at all (and in: doesn’t move), then we’re no longer in “mention gating / allowlist / empty content drops” land — it’s either:

1. Discord is not delivering guild events to this bot session (almost always permissions / missing access to the channel you’re testing), or
2. The gateway session is effectively running without GUILD_MESSAGES/GUILDS intents (would be an OpenClaw/Carbon gateway bug — but we should eliminate #1 first).

Also: the earlier /channels/<guildId> 404 is a separate OpenClaw resolver footgun: a bare numeric guild key gets mis-parsed as a channel id during the “resolve channel allowlist” step. Confusing, but it shouldn’t affect receiving.

Next test (fastest way to prove/disprove permissions)

Even if you “gave permissions”, channel overrides can still deny View Channel, and if the bot can’t view the channel, Discord simply won’t send MESSAGE_CREATE for it.

1. Create a brand new text channel, e.g. #yumka-test.
2. In that channel’s permissions, explicitly grant the bot (or its role):
   • View Channel
   • Read Message History
   • Send Messages
3. (Optional but decisive) Temporarily give the bot Administrator and repeat test in #yumka-test.

Then: send a message in #yumka-test and see if OpenClaw receives it.

Make channels status --probe actually audit the channel

Add the numeric channel ID to config just for auditing:

channels: {
  discord: {
    groupPolicy: "open",
    guilds: {
      "1468198642031657249": {
        requireMention: false,
        channels: {
          "PUT_CHANNEL_ID_OF_YUMKA_TEST_HERE": { allow: true, requireMention: false }
        }
      }

    }
  }
}

Now run:

openclaw channels status --probe

If the bot lacks access, this usually surfaces as a 403 / “Missing Access” / permission audit failure. (Right now, with no channel IDs configured, the probe can’t really prove it has view access anywhere.)

If it STILL receives zero guild messages even with Admin in a fresh channel

At that point I’d treat it as a real bug/regression and ask you to file a GitHub issue with:

• openclaw --version
• openclaw status --all
• openclaw channels status --probe
• plus ~50 lines of logs around Discord startup (enable temporarily: logging.level: "debug")

GitHub issues: https://github.com/openclaw/openclaw/issues

If you paste the channels status --probe output after adding the test channel ID, we’ll know immediately whether it’s permissions/missing-access vs “gateway not subscribing to guild intents”.

[inland nebula]

✅ SOLVED: Discord bot not receiving guild messages
Symptoms:
DMs: ✅ worked
Guild message sending: ✅ worked
Guild message receiving: ❌ nothing

Root cause:
The bot needs explicit channel IDs in the config to receive guild messages. Even with groupPolicy: "open" and requireMention: false, without channel IDs configured, OpenClaw doesn't subscribe to those channels.

What didn't work:
groupPolicy: "open" alone
guilds.*.requireMention: false
guilds.<guildId>.requireMention: false
Bot having Administrator role

What worked:
Adding explicit channel IDs in the guild config:

"discord": {
"groupPolicy": "open",
"guilds": {
"*": { "requireMention": false },
"1468198642031657249": {
"requireMention": false,
"users": ["405369141743058954"],
"channels": {
"1468198642576920621": { "allow": true, "requireMention": false },
"1469643574747332684": { "allow": true, "requireMention": false }
}
}
}
}

Suggestion for OpenClaw:
This behavior is unintuitive. When groupPolicy: "open" is set, the bot should receive messages from all accessible channels by default, not require explicit channel IDs. At minimum, the docs should clarify this requirement.

Thanks @dense hull for the debugging help!

[dense hull]

Nice, thanks for circling back with the fix + the exact config.

Two notes worth calling out for others hitting this:

1. Using numeric channel IDs under channels.discord.guilds.<guildId>.channels is the most reliable way (no slug/name resolution edge cases, and channels status --probe can actually audit them).

2. If groupPolicy: "open" still results in zero guild inbound unless channel IDs are present, that’s very unintuitive and sounds like either a docs gap or a bug/regression (because “open” strongly implies “any accessible channel”).

If you’re up for it, please file a GitHub issue with your repro + the “/channels/<guildId> 404 (Unknown Channel)” log line (that one is especially confusing):
https://github.com/openclaw/openclaw/issues

Glad you got it working. If this solved your thread, please mark the solution so Answer Overflow indexes it (right‑click the solution message → Apps → ✅ Mark Solution).