Summary

Discord guild-channel messages that look like OpenClaw text slash/control commands can be silently dropped in preflight before they reach the agent session or produce any user-visible error.

This surfaced when a user sent a visually plain text /steer ... message in a Discord project channel. Discord did not execute it as a native slash command, so it arrived as a normal message. OpenClaw intercepted it at the Discord gateway and returned null, so the main agent never saw it and no rejection/usage message was sent.

Expected behavior

If the message is intended as a native slash command, it should route to the native command handler or return a clear error.

If Discord sends it as ordinary text, it should not vanish. OpenClaw should either:

• process it through the text command authorization path, or
• deliver it to the agent as normal chat, or
• reply with a clear message such as “command not accepted here / use native slash command / target an active subagent.”

Actual behavior

The text-looking /steer ... message was dropped before the agent session. The user only got attention after sending a plain-text follow-up asking whether the command was seen.

Evidence

Installed Discord plugin dist showed this branch in message-handler.preflight:

const botId = params.botUserId;
const baseText = resolveDiscordMessageText(message, { includeForwarded: false });
if (!isDirectMessage && baseText && hasControlCommand(baseText, params.cfg)) {
  logVerbose(`discord: drop text-based slash command ${message.id} (intercepted at gateway)`);
  return null;
}

A separate branch later drops actual Discord channel command echo messages by checking MessageType.ChatInputCommand / MessageType.ContextMenuCommand; that behavior should be preserved. The problem is the early drop of ordinary guild text that merely starts with an OpenClaw control command.

Local workaround tested

In the installed plugin dist, removing the early return null and allowing the message to continue into the existing authorization/mention routing path stopped the silent swallow:

if (!isDirectMessage && baseText && hasControlCommand(baseText, params.cfg)) {
  logVerbose(`discord: allow text-based slash command ${message.id} (routed to authorization)`);
}

This is only a local installed-dist patch and may be overwritten by plugin reinstall/update.

Environment

• OpenClaw version: 2026.5.4
• Channel: Discord
• Host: macOS Darwin arm64
• Gateway: local LaunchAgent, loopback WebSocket
• Policy: Discord DMs locked down; guild/group policy allowlist; user allowlist configured

Suggested fix

Do not silently return null for guild-channel text messages that match hasControlCommand(). Let them proceed through the normal text command authorization path, or explicitly reply with a rejection/usage error if text command handling is disabled or unauthorized.

Add a regression test covering a normal Discord guild message with content like /steer test and message type not equal to ChatInputCommand/ContextMenuCommand. The test should assert that it is not dropped silently.