#Discord can write, but not read

1 messages · Page 1 of 1 (latest)

runic viper
#

From 2 days ago, I have a strange behavior although nothing changed in the version : OpenClaw is able to write messages in my discord channel, but does not read (or react) when I write. Does it ring a bell to anyone ?

mild notchBOT
#

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

runic viper
#

Discord can write, but not read

coarse valleyBOT
#

Yes — “can write but doesn’t react/read inbound messages” usually points to Discord-side inbound permissions/intents or OpenClaw filtering, not the model.

First check the version, because weird channel behavior is often version/config-state related:

openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw logs --follow

Things I’d check in this order:

  1. Discord Developer Portal → Bot → Privileged Gateway Intents: Message Content Intent must be enabled. If you changed it, restart the gateway.
  2. Bot permissions in that server/channel/thread: View Channels, Read Message History, Send Messages, and Add Reactions if you expect reactions.
  3. Logs for drops like drop guild message (mention required, pairing request, blocked, or allowlist.
  4. Config: if channels.discord.guilds.<guild>.channels exists, only listed channels are allowed; if requireMention is true, it may ignore normal messages unless mentioned/replied-to.

Docs: https://docs.openclaw.ai/channels/discord and https://docs.openclaw.ai/channels/troubleshooting

#

If you paste openclaw --version plus the relevant redacted lines from openclaw channels status --probe / logs, we can narrow it down quickly. 🦞

#

Yep — that distinction is useful. If it can write, the token is valid and outbound routing works. The failure is almost certainly on the inbound side:

  • Message Content Intent disabled in Discord Developer Portal → Bot → Privileged Gateway Intents
  • Gateway wasn’t restarted after changing intents
  • Bot lacks View Channel / Read Message History in that channel/thread
  • OpenClaw is receiving the event but dropping it due to requireMention, guild/channel allowlist, user allowlist, or pairing

Please run:

openclaw --version
openclaw channels status --probe
openclaw logs --follow

Then write one test message in Discord and look for log lines containing discord, MESSAGE_CREATE, drop guild message, mention required, allowlist, blocked, or pairing request.

If there’s no log activity at all when you send a message, I’d bet on Discord intents/permissions/restart. If there is activity, paste the redacted drop line and we can pinpoint the config filter.

runic viper
#

Update : Found more details in the logs. The bot does receive messages (visible in liveness logs as agent:main:discord:channel:1480258916217786526(processing/model_call)), but never posts the reply back to the channel.
Already tried messages.groupChat.visibleReplies: "automatic" — no effect.
Relevant log line:
Copier
work=[active=agent:main:discord:channel:1480258916217786526(processing/model_call,q=1,age=1s last=model_call:started)]
Then silence — no post, no error. The session disappears without posting anything.

coarse valleyBOT
#

Ah, that log changes the diagnosis: Discord is being read. The stuck point is after inbound routing, during/after the agent run.

processing/model_call means OpenClaw handed the message to the model. If it then disappears with no Discord send, I’d check these two likely causes:

  1. The model is returning NO_REPLY
    In groups/channels, bare NO_REPLY is intentionally silent by default. messages.groupChat.visibleReplies doesn’t appear to be a current config key, so I wouldn’t expect it to change this.

    To force a visible fallback for silent replies, try:

    openclaw config get agents.defaults.silentReply
openclaw config set agents.defaults.silentReply.group disallow --strict-json
openclaw gateway restart

  2. session.sendPolicy is suppressing delivery
    Check whether Discord channel sessions are denied:

# 
   openclaw config get session.sendPolicy
   openclaw sessions --all-agents --json | grep -A20 '1480258916217786526'

If the session entry has sendPolicy: "deny", final replies are intentionally not delivered.

Also worth checking model completion/error separately:

openclaw models status
openclaw logs --follow | grep -Ei 'model_call|NO_REPLY|sendPolicy|suppress|discord|error|failed'

My bet from that exact symptom is either model answered NO_REPLY and Discord channel silence is allowed, or a session sendPolicy deny got attached. If neither shows up, this is issue-worthy because model_call:started → session gone → no delivery/no error should leave a clearer log trail.

runic viper
#

seems it worked !

coarse valleyBOT
#

Nice! 🎉 Glad that nailed it.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person who hits the same “reads but silently doesn’t reply” trap.