Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Discord guild text slash commands are silently dropped before agent session [1 pull requests, 4 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78080•Fetched 2026-05-06 06:17:06
View on GitHub
Comments
4
Participants
3
Timeline
12
Reactions
2
Author
ramitrkar-hashramitrkar-hash
Participants
clawsweeper[bot]clawsweeper[bot]ramitrkar-hashramitrkar-hashsteipetesteipete
Timeline (top)
commented ×4cross-referenced ×2mentioned ×2subscribed ×2

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.

Error Message

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. If the message is intended as a native slash command, it should route to the native command handler or return a clear error. 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.

Root Cause

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.

Fix Action

Fix / Workaround

Local workaround tested

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

PR fix notes

PR #78170: [AI-assisted] fix(discord): route text control commands

Description (problem / solution / changelog)

Summary

Fixes #78080 by letting ordinary Discord guild text control commands continue into the existing text-command authorization and mention gate instead of being swallowed by the early preflight guard.

Root Cause

Discord preflight dropped any non-DM message whose base text matched a control command before the later command gate ran. That was intended to avoid forwarding native Discord slash-command echoes to the agent, but native interaction echoes already have their own MessageType.ChatInputCommand / ContextMenuCommand drop later in preflight.

Changes

  • Remove the early guild text control-command return null.
  • Keep the existing native Discord command echo drop intact.
  • Add regression coverage for a typed guild /steer ... message and for a native command echo message.

Validation

  • corepack pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts
  • corepack pnpm exec oxfmt --check --threads=1 extensions/discord/src/monitor/message-handler.preflight.ts extensions/discord/src/monitor/message-handler.preflight.test.ts extensions/discord/src/monitor/message-handler.preflight.test-helpers.ts CHANGELOG.md
  • corepack pnpm check:changed
  • git diff --check

Real behavior proof

Behavior or issue addressed: A normal Discord guild text message like /steer use a darker sidebar now reaches the Discord text-command gate and becomes an effective mention, while native Discord command echo messages are still dropped.

Real environment tested: Windows local checkout at [email protected] on branch fix-discord-text-control-commands.

Exact steps or command run after this patch: Ran corepack pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts, targeted oxfmt --check, corepack pnpm check:changed, and git diff --check.

Evidence after fix: Terminal capture from the focused Discord preflight suite showed Test Files 1 passed (1) and Tests 40 passed (40). The new after-fix regression constructs a guild text message with content /steer use a darker sidebar and observes a non-null preflight result with messageText === "/steer use a darker sidebar" and effectiveWasMentioned === true; the paired native command echo regression constructs MessageType.ChatInputCommand and observes null.

Observed result after fix: The typed guild text control command is routed through the command gate instead of disappearing at early preflight, and the native Discord interaction echo remains ignored.

What was not tested: I did not run a live Discord gateway. This PR does not add the broader visible denial/help reply for unauthorized text commands mentioned in the issue follow-up.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/discord/src/monitor/message-handler.preflight.test-helpers.ts (modified, +2/-0)
  • extensions/discord/src/monitor/message-handler.preflight.test.ts (modified, +133/-1)
  • extensions/discord/src/monitor/message-handler.preflight.ts (modified, +1/-7)

Code Example

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;
}

---

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

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.

extent analysis

TL;DR

Remove the early return null in the message-handler.preflight to allow text-based slash commands to proceed through the authorization path.

Guidance

  • Identify the message-handler.preflight function in the Discord plugin and modify the condition to not drop messages that start with a control command but are not actual Discord slash commands.
  • Verify that the modified code allows text-based slash commands to be processed correctly and does not silently drop them.
  • Consider adding a regression test to ensure that normal Discord guild messages with content like /steer test are not dropped silently.
  • Review the hasControlCommand function to ensure it correctly identifies control commands and does not interfere with normal text messages.

Example

if (!isDirectMessage && baseText && hasControlCommand(baseText, params.cfg)) {
  logVerbose(`discord: allow text-based slash command ${message.id} (routed to authorization)`);
  // Continue with the existing authorization/mention routing path
}

Notes

The suggested fix may need to be adapted based on the specific requirements of the OpenClaw plugin and the Discord integration. Additionally, the regression test should be designed to cover different scenarios and edge cases to ensure the fix is robust.

Recommendation

Apply the workaround by modifying the message-handler.preflight function to not silently drop text-based slash commands, as this will allow for a more robust and user-friendly experience.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.”
#agent execution#callback error#memory management#API rate limit#retriever error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Discord guild text slash commands are silently dropped before agent session [1 pull requests, 4 comments, 3 participants]