Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On OpenClaw 2026.4.25, Discord message read and message search hang indefinitely with empty stdout, and the Discord channel plugin does not appear to emit the standard inbound hooks (message_received / inbound_claim) that other channels expose. This appears to be a regression or incomplete coverage of the prior fix discussed in #31212 / #31264 / #33038.

Steps to reproduce

1. Install OpenClaw 2026.4.25 on macOS, with the Discord plugin enabled and a bot token configured for at least one guild.
2. Pair the local CLI device successfully (openclaw devices list --json shows the device with operator scopes).
3. Run: openclaw message read --channel discord --target <channelId> --limit 1 --json
4. Observe that the command hangs indefinitely with empty stdout (no JSON returned, no explicit error).
5. Run: openclaw message search --channel discord --guild-id <guildId> --channel-id <channelId> --query test --limit 1 --json
6. Observe the same hanging behavior.
7. Inspect the bundled Discord plugin code under dist/extensions/discord/ and the dispatch code under dist/dispatch-*.js. Observe that the Discord plugin has internal listener and processing code (DiscordMessageListener, processDiscordMessage) but no equivalent calls to runMessageReceived(...) or triggerInternalHook(createInternalHookEvent("message", "received", ...)) that other channels emit.
8. Compare release tag source v2026.4.25 and v2026.4.26 against the fallback logic proposed in PR Discord: guard message:received hook session keys #33038. Observe that the proposed fallback is not present in the current release line.

Expected behavior

For message read and message search:

• The command should either return a JSON payload of messages, or fail fast with a structured error.
• It should not hang indefinitely with empty stdout.

For Discord inbound hooks:

• Discord inbound messages should expose the standard inbound hook surface (message_received / inbound_claim) consistently with other channels (Telegram, WhatsApp, Signal), so that plugin authors and integrations can build push/event-driven workflows on top of Discord the same way they can with other channels.

Reference: PR #33038 was closed by a maintainer with the comment Superceded by existing commits on main, suggesting that this area was meant to be fixed on main. The current observable behavior on v2026.4.25 suggests the fix is either absent from the release, partial, or has regressed.

Actual behavior

1. openclaw message read --channel discord --target <channelId> --limit 1 --json hangs indefinitely. After 20s+ external timeout, stdout remains empty and no JSON or structured error is returned. Only generic startup lines appear on stderr (config warnings, plugin command registrations).

2. openclaw message search --channel discord --guild-id <guildId> --channel-id <channelId> --query <term> --limit 1 --json hangs in the same way.

3. Re-pairing the local CLI device with widened operator scopes (operator.admin, operator.read, operator.write, operator.approvals, operator.pairing, operator.talk.secrets) does not change the behavior. The hang persists.

4. The Discord plugin reports as loaded and enabled in openclaw plugins list --json. The bot is otherwise active in Discord channels.

5. Source inspection of v2026.4.25 and v2026.4.26 shows that the fallback logic proposed in PR Discord: guard message:received hook session keys #33038 (ctx.SessionKey?.trim() || ctx.CommandTargetSessionKey?.trim() || undefined in dispatch-from-config.ts, and the inboundSessionKey array in extensions/discord/src/monitor/message-handler.process.ts) is not present in the release source.

6. The bundled Discord extension contains internal listener and processing logic but does not appear to emit runMessageReceived(...) / toPluginMessageReceivedEvent(...) / triggerInternalHook(createInternalHookEvent("message", "received", ...)) the way other channel paths do in dist/dispatch-*.js.

OpenClaw version

2026.4.25

Operating system

macOS 26.4.1 (Darwin 25.4.0, arm64)

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

NOT_ENOUGH_INFO

Additional provider/model setup details

The agent gateway uses model openai-codex/gpt-5.4. This bug is not related to model behavior — the failure is in the OpenClaw CLI / gateway / Discord plugin path, not in the LLM. The model field is included for completeness as the template requests it.

Logs, screenshots, and evidence

Timed wrapper output for `message read` (typical):
ELAPSED_SEC: 20.008
TIMEOUT_SEC: 20
STDOUT<



STDOUT
STDERR<
Config warnings:




plugins.entries.whatsapp: plugin disabled (disabled in config) but config is present




STDERR




Discord plugin status from `plugins list --json`:


{
  "id": "discord",
  "name": "@openclaw/discord",
  "version": "2026.4.25",
  "format": "openclaw",
  "enabled": true,
  "status": "loaded",
  "channelIds": ["discord"],
  "httpRoutes": 0,
  "hookCount": 0
}


Code references inspected in the local install at `/Users/<user>/.npm-global/lib/node_modules/openclaw/dist/`:

- `dist/extensions/discord/provider-C7FYFXVp.js` — contains `DiscordMessageListener`, `registerDiscordMonitorListeners(...)`, `registerDiscordListener(...)`
- `dist/extensions/discord/message-handler.process-TPiKFEKP.js` — contains `processDiscordMessage(...)`
- `dist/extensions/discord/send-C5KMi0rM.js` — contains `readMessagesDiscord(...)` and `searchMessagesDiscord(...)` (REST implementations exist)
- `dist/dispatch-CerU5CEB.js` — contains generic `runMessageReceived(...)`, `toPluginMessageReceivedEvent(...)`, `triggerInternalHook(createInternalHookEvent("message", "received", ...))` for non-Discord paths
- `dist/plugin-sdk/src/plugins/hook-types.d.ts` — declares `message_received` and `inbound_claim` hooks

I could not find equivalent calls to those hook emissions inside the Discord extension files.

Verification against release tag sources:
- The fallback logic proposed in PR #33038 (`ctx.SessionKey?.trim() || ctx.CommandTargetSessionKey?.trim() || undefined`) is not present in `v2026.4.25` or `v2026.4.26` in `src/auto-reply/reply/dispatch-from-config.ts`.
- The `inboundSessionKey` construction proposed in PR #33038 is not present in `v2026.4.25` or `v2026.4.26` in `extensions/discord/src/monitor/message-handler.process.ts`.

Impact and severity

Affected: Any integration on top of OpenClaw 2026.4.25 that needs to read Discord channel history via openclaw message read / openclaw message search, or that needs to consume Discord inbound messages through the standard hook surface (message_received / inbound_claim).

Severity: High for Discord-based workflows. Discord becomes the only channel where neither historical fetch nor push/event-driven integrations work reliably, while Telegram / WhatsApp / Signal continue to work.

Frequency: Always. Every invocation of message read and message search on Discord hangs. Every attempt to subscribe to Discord inbound via the standard hook surface receives nothing.

Consequence: Plugin authors and integrators cannot build Discord ingest into agent queues, dashboards, or external automation systems using the documented surface. Workarounds require either patching the Discord plugin or using a separate Discord client outside OpenClaw.

Additional information

Related prior history that suggests this is a regression or incomplete coverage of an earlier fix:

• message:received hook does not fire for Discord guild channel messages #31212 — message:received hook does not fire for Discord guild channel messages — closed as not planned due to inactivity (auto-closed by stale bot)
• Discord: guard message:received hook session keys #31264 — Discord: guard message:received hook session keys — closed as superseded by Discord: guard message:received hook session keys #33038
• Discord: guard message:received hook session keys #33038 — Discord: guard message:received hook session keys — closed by maintainer with comment Superceded by existing commits on main

I checked the source of v2026.4.25 and v2026.4.26 and the specific guards proposed in #33038 are not present. This is what motivates the "regression or incomplete coverage" framing rather than a fresh feature request.

Adjacent open issues for context (not duplicates):

• Discord ingest lag of 100–400 s on stable connection persists after PR #68159 / 2026.4.1 reconnect-ownership change #71546 — Discord ingest lag of 100–400 s on stable connection persists after PR #68159 / 2026.4.1 reconnect-ownership change
• Discord inbound worker repeatedly times out after 1800s while gateway is still running #71948 — Discord inbound worker repeatedly times out after 1800s while gateway is still running
• Harden Discord reads and message targeting #61572 — Harden Discord reads and message targeting (open PR)

Last known reference of the proposed fix being acknowledged: 2026-03-03 (maintainer comment on #33038).
First version where the current observable symptoms were verified by me: 2026.4.25.

Questions for maintainers:

1. Is the March fix discussed in Discord: guard message:received hook session keys #31264 / Discord: guard message:received hook session keys #33038 actually present in the current release line, or did it never ship?
2. If it is supposed to be present, why do these symptoms persist (message read/search hang and missing inbound hook emission for Discord)?
3. Is the absence of the runMessageReceived(...) / triggerInternalHook(...) call path inside the Discord extension intentional design, or an oversight relative to other channels?