#Discord Server Issue

1 messages · Page 1 of 1 (latest)

lyric apex
#

OpenClaw works great, but I can't get it to respond in my Discord server. I've troubleshooted it to the best of my ability, and it has all the intents needed. It responds to DMs, but just not in the server. It reacts to my messages, and it shows as typing, but doesn't send anything. The bot has Admin permission in the server. Any tips?

ashen walrusBOT
#

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

winter dirgeBOT
#

This pattern usually means OpenClaw did run the turn, but the final answer stayed private instead of being posted to the Discord channel.

First quick check: what does openclaw --version show?

Then check the session/logs for didSendViaMessagingTool: false. If you see that, it’s not a Discord permission/intents problem — the model answered normally instead of calling the message tool, and guild/channel replies are tool-only by default now.

Two fixes:

  1. Use a stronger tool-calling model for Discord/server sessions.
  2. Or restore legacy auto-posted final replies:
{
  messages: {
    groupChat: {
      visibleReplies: "automatic",
#
    },
  },
}

Gateway should hot-reload that messages config after saving.

Also, if this is happening inside forum/thread channels specifically, double-check the bot invite included Send Messages in Threads too — but the “reacts + typing + no send” symptom strongly points at visibleReplies: "message_tool" + model/tool-calling.

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

lyric apex
#

Appreciate that. I tried to use the legacy auto-post, restarted the bot, but it's still just reacting and showing as typing.

winter dirgeBOT
#

Got it — if visibleReplies: "automatic" didn’t change anything, I’d look for one of these next:

  1. Config didn’t actually load / wrong config file
    Run:
    openclaw --version
    openclaw status --all
    
    In the status output, confirm which config path the gateway is using, then make sure that same file contains:
    messages: {
      groupChat: {
        visibleReplies: "automatic",
      },
    }
    
#
  1. The run is never finishing
    Reacting + typing can also mean the gateway started the turn but the model/tool run is hanging or erroring before delivery. Check:

    openclaw logs --follow
    

    Then send one message in the Discord channel and watch for errors, timeouts, or send failures.

  2. The channel session is stuck in an old/running state
    Try a brand new Discord channel/thread after the config change. If the new channel works, the old channel session is wedged.

  3. Discord send is failing despite Admin
    Admin usually covers it, but forum/media threads need Send Messages in Threads. Logs should show a Discord API error if this is the case.

The key evidence would be the log lines after one attempted server message. If you can paste the redacted openclaw --version + the relevant openclaw logs --follow chunk from one attempt, we can tell pretty quickly whether it’s config-not-loaded, model-run-not-finishing, or Discord-send-failing.

lyric apex
#

OpenClaw 2026.5.7 (eeef486)

Confirmed: Correct config pathway
Confirmed: ```grep -A 3 "visibleReplies" ~/.openclaw/openclaw.json
"visibleReplies": "automatic"
}
},
"skills": {

Tried creating a new channel: Still only reactions.
winter dirgeBOT
#

Nice, that rules out the obvious config path/new-channel stuff. At this point I’d split it into “can Discord delivery work at all?” vs “is the agent run failing before delivery?”

Try these two quick probes:

openclaw config get messages.groupChat.visibleReplies --json
openclaw status --deep

The first should print exactly "automatic". If it errors or prints null/undefined, the value is in the wrong place even if grep found it.

Then, in the server, try a native slash command like /status if it’s available. Native Discord slash commands bypass the normal group visible-reply path:

  • If /status replies visibly: Discord sending works, and the normal text-message run is failing/stalling before final delivery.
  • If /status also does not reply: focus on Discord delivery/permissions/interaction logs.

Next thing I’d really want is one clean log attempt:

#
openclaw logs --follow

Send one message in the server, wait until typing stops / a minute passes, then paste the redacted chunk around that attempt. Look specifically for provider errors, sourceReplyDeliveryMode, didSendViaMessagingTool, DiscordAPIError, or timeout lines.

Given visibleReplies: automatic + new channel still failing, my bet is now the run is erroring/hanging before a final answer, not that Discord intents are wrong.

lyric apex
#

It prints "automatic".

Slash status returns: You are not authorized to use this command.

winter dirgeBOT
#

That /status result is a useful clue: your Discord delivery path is alive enough to answer the interaction, but OpenClaw thinks your Discord user is not authorized for commands in that guild.

I’d fix that first, because it may also be affecting the normal channel route in weird ways. In your Discord guild config, make sure the server/guild ID entry includes your Discord user ID:

{
  channels: {
    discord: {
      groupPolicy: "allowlist",
      guilds: {
        "YOUR_SERVER_ID": {
          requireMention: false,
          users: ["YOUR_DISCORD_USER_ID"],
        },
      },
    },
#
  },
  messages: {
    groupChat: {
      visibleReplies: "automatic",
    },
  },
}

Easy gotchas:

  • YOUR_SERVER_ID must be the guild/server ID, not the channel ID.
  • users should contain your Discord user ID, not the bot ID.
  • If you’re testing from another account, add that account too.

After saving/restart or reload, try /status again. If /status works but normal messages still only react/type, then we’re past auth and the next stop is logs from a single attempted message: