#Discord message not routed anymore

1 messages · Page 1 of 1 (latest)

shy apex
#

Hi everyone,

I’ve been facing a persistent issue for the last 4–5 versions where the Discord gateway stalls indefinitely right after the model finish its generation.

The Symptoms:

Dashboard/Main Chat: The agent processes the request perfectly. I can see the full <thought> process and the text output in the UI.
Dashboard/Discord chat : The agent processes the request perfectly. I can see the full <thought> process and the text output in the UI.
But nothing routed to Discord.

I have Bot is typing 3-4 seconds and nothing...

What I've ruled out:

Discord Permissions/Intents: Fully checked. A standalone discord.js script using the exact same token and channel ID works flawlessly and sends messages instantly.

Network/DNS: Tested with NODE_OPTIONS="--dns-result-order=ipv4first", same deadlock.

Fresh Install: Same issue since openclaw 2026.5.7 or a little before but the behavior persists (Node v22.22.2).
Tested openclaw 2026.5.7, 2026.5.9 and the letest beta...

Send message using a Node JS script with the same Discord bot token ok.

It looks like a serialization deadlock or an IPC communication failure between the Core Event Loop and the isolated Sidecar worker managing the Discord transport layers.

Thanks for the help!

untold wigeonBOT
#

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

blissful glenBOT
# shy apex Hi everyone, I’ve been facing a persistent issue for the last 4–5 versions wher...

This sounds less like Discord token/permissions and more like the current guild-channel reply mode.

In Discord guild channels, OpenClaw now defaults visible room replies to the message tool. So the model can fully answer in the Dashboard/session, Discord shows typing, token usage happens, and then nothing posts if the model produced a normal final answer instead of calling message(action="send").

Fast checks:

openclaw --version
openclaw channels status --probe
openclaw config get messages.groupChat.visibleReplies
openclaw logs --follow

Then inspect the affected session/log for:

blissful glenBOT
# shy apex Hi everyone, I’ve been facing a persistent issue for the last 4–5 versions wher... 
didSendViaMessagingTool: false

If you see that, the immediate workaround is to restore legacy auto-posting for group/channel rooms:

{
  messages: {
    groupChat: {
      visibleReplies: "automatic"
    }
  }
}

Apply it with a config patch, then restart the gateway. Also make sure the Discord channel is allowed and not just being processed privately: https://docs.openclaw.ai/channels/discord and the troubleshooting flow: https://docs.openclaw.ai/channels/troubleshooting.

blissful glenBOT
# shy apex Hi everyone, I’ve been facing a persistent issue for the last 4–5 versions wher...

If visibleReplies is already automatic and the logs show an actual Discord send attempt hanging/failing, that’s much more likely to be a bug. In that case, please file a GitHub issue with the exact openclaw --version, sanitized openclaw channels status --probe, and the log lines around the completed model turn + attempted Discord delivery: https://github.com/openclaw/openclaw/issues

shy apex
#

Where do u have to set didSendViaMessagingTool: false ?

blissful glenBOT
# shy apex Where do u have to set didSendViaMessagingTool: false ?

You don’t set didSendViaMessagingTool: false. That’s only a diagnostic flag you look for in the session/log output.

If it appears, it means: “the model wrote a final answer privately, but did not call the Discord message tool, so nothing was posted to the channel.”

The config you set is this instead:

{
  messages: {
    groupChat: {
      visibleReplies: "automatic"
    }
  }
}

You can apply it with a small patch file:

blissful glenBOT
shy apex
#

Thanks a lot it works back with Legacy but why it has been broken with Message tool ?

blissful glenBOT
# shy apex Thanks a lot it works back with Legacy but why it has been broken with Message t...

Glad that narrowed it down.

With message_tool, OpenClaw intentionally separates “agent thought/final answer” from “visible Discord post”. In guild channels the final answer is private unless the model explicitly calls the message tool. That design lets the bot lurk, decide when a public reply is useful, and avoid accidentally posting every internal/session result into a server channel.

So it was probably not broken at the Discord transport layer. The likely failure was one of these:

  • The selected model produced a normal final answer instead of a tool call.
  • Tool calling was unreliable for that model/provider in this turn.
  • The message tool was not available/allowed in that agent/session config.
  • The prompt/session context didn’t strongly steer the model to use message(action="send") for visible Discord replies.

Legacy/automatic bypasses that requirement: if the agent has final text, OpenClaw posts it back to the room automatically.

If you want to debug the tool path later, check:

blissful glenBOT
shy apex
#

Config path not found: tools.allow

blissful glenBOT
# shy apex Config path not found: tools.allow

Yep, that just means tools.allow is not explicitly set in your config. That’s normal; it’s optional.

Better checks are:

openclaw config get tools
openclaw config get tools.profile
openclaw doctor

If tools.allow is missing, OpenClaw is using the base tool profile/default policy. Also, the docs say if the message tool is actually unavailable under tool policy, OpenClaw should fall back to automatic visible replies and openclaw doctor should warn about the mismatch.

So in your case, since automatic works, the more likely cause is: the model had the message tool available, but answered normally/private instead of calling it.

The setting that fixed it is still the right workaround:

blissful glenBOT
shy apex
#

thaks a lot it works

blissful glenBOT
# shy apex thaks a lot it works

Glad that fixed it! 🎉

Please mark the solution so it gets indexed for future users: right-click the solution message → Apps → ✅ Mark Solution.