Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
On OpenClaw 2026.5.3 with the external Discord channel plugin loaded and the Discord account connected, generic outbound delivery can lose the Discord outbound adapter, causing cron announcements and final Discord replies to fail with Unsupported channel: discord / Outbound not configured for channel: discord.
Steps to reproduce
- Run OpenClaw 2026.5.3 as a gateway with the official external Discord plugin enabled and connected.
- Use Discord as an inbound channel and configure at least one cron/session delivery target using
delivery.mode = "announce", delivery.channel = "discord", and a Discord channel target.
- Trigger normal gateway/plugin activity that reloads or inspects plugin/runtime state while the gateway remains running.
- Let a Discord-targeted cron delivery run, or send a Discord message that should receive a final assistant reply.
- Observe delivery failures even though the Discord provider remains configured/running/connected.
Expected behavior
If the Discord channel plugin is loaded and the Discord account is connected, cron announce delivery and final replies should continue resolving the Discord outbound adapter and sending messages.
Actual behavior
The gateway continues running and the Discord provider can remain connected, but generic delivery fails with errors like:
[cron:<redacted>] Unsupported channel: discord
[discord] final reply failed (target=<redacted> session=<redacted>): Error: Outbound not configured for channel: discord
A direct Discord send from the CLI still succeeds, which suggests the Discord credentials/provider are not the failing part:
openclaw message send --channel discord --target <redacted> --message <redacted> --json
# result: ok, messageId=<redacted>, channelId=<redacted>
After applying a local patch to channel plugin resolution and restarting the gateway, pending Discord deliveries were recovered successfully:
[delivery-recovery] Found 2 pending delivery entries — starting recovery
[delivery-recovery] Recovered delivery <redacted> on discord
[delivery-recovery] Recovered delivery <redacted> on discord
[delivery-recovery] Delivery recovery complete: 2 recovered, 0 failed, 0 skipped (max retries), 0 deferred (backoff)
OpenClaw version
2026.5.3 (06d46f7)
Operating system
Ubuntu 24.04 LTS, Linux x86_64
Install method
npm global, gateway launched as a systemd service
Model
openai-codex/gpt-5.5
Provider / routing chain
OpenClaw gateway -> OpenAI Codex provider
Additional provider/model setup details
No model/provider-specific behavior was observed. The failure occurs in Discord outbound delivery resolution after an agent run has already produced output.
Logs, screenshots, and evidence
Sanitized evidence from a live gateway process:
[gateway] http server listening (4 plugins: brave, browser, discord, openclaw-mem0; ...)
[discord] [default] starting provider (@OpenClaw Bot)
[discord] client initialized as <redacted>; awaiting gateway readiness
[cron:<redacted>] Unsupported channel: discord
[discord] final reply failed (target=<redacted> session=<redacted>): Error: Outbound not configured for channel: discord
Health/status at the same time showed the Discord channel configured/running/connected, with token available and no channel error. A direct openclaw message send --channel discord ... invocation from the same host/user environment succeeded.
Local code inspection of the built 2026.5.3 runtime found two relevant resolution paths:
// dist/load-ChklS5lb.js
const loadOutboundAdapterFromRegistry = createChannelRegistryLoader((entry) => entry.plugin.outbound);
async function loadChannelOutboundAdapter(id) {
return loadOutboundAdapterFromRegistry(id);
}
// dist/channel-resolution-DICdY7UT.js
function resolveDirectFromActiveRegistry(channel) {
const activeRegistry = getActivePluginRegistry();
...
}
A local hotfix changed outbound/target resolution to use/fall back through the pinned channel plugin registry / loaded channel plugin. After restart, the gateway recovered the pending Discord deliveries shown above and no new Unsupported channel: discord or Outbound not configured for channel: discord errors appeared in the observed post-fix window.
Impact and severity
Affected: Discord channel users relying on OpenClaw final replies, cron announce delivery, or pending delivery recovery.
Severity: High for Discord deployments because inbound events can be received and agent runs can complete, but the user-visible response is not delivered.
Frequency: Observed after gateway/plugin runtime activity on 2026.5.3; once in the bad state, affected Discord deliveries consistently failed until restart plus local hotfix.
Consequence: Missed Discord replies and missed cron announcements, while the gateway appears otherwise healthy.
Additional information
This looks related in theme to #54599 and older Unsupported channel delivery reports, but the observed 2026.5.3 failure is specifically Discord outbound adapter resolution in a running gateway where the external Discord plugin is loaded and direct Discord sends still work.
Temporary local workaround that restored delivery:
- Make
loadChannelOutboundAdapter(id) fall back to getChannelPlugin(id)?.outbound when the channel registry lookup misses.
- Make direct outbound channel resolution read from
getActivePluginChannelRegistry() instead of the mutable active plugin registry.
This report intentionally redacts channel IDs, session keys, delivery IDs, tokens, file paths, and local config details.
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
On OpenClaw 2026.5.3 with the external Discord channel plugin loaded and the Discord account connected, generic outbound delivery can lose the Discord outbound adapter, causing cron announcements and final Discord replies to fail with
Unsupported channel: discord/Outbound not configured for channel: discord.Steps to reproduce
delivery.mode = "announce",delivery.channel = "discord", and a Discord channel target.Expected behavior
If the Discord channel plugin is loaded and the Discord account is connected, cron
announcedelivery and final replies should continue resolving the Discord outbound adapter and sending messages.Actual behavior
The gateway continues running and the Discord provider can remain connected, but generic delivery fails with errors like:
A direct Discord send from the CLI still succeeds, which suggests the Discord credentials/provider are not the failing part:
After applying a local patch to channel plugin resolution and restarting the gateway, pending Discord deliveries were recovered successfully:
OpenClaw version
2026.5.3 (06d46f7)
Operating system
Ubuntu 24.04 LTS, Linux x86_64
Install method
npm global, gateway launched as a systemd service
Model
openai-codex/gpt-5.5
Provider / routing chain
OpenClaw gateway -> OpenAI Codex provider
Additional provider/model setup details
No model/provider-specific behavior was observed. The failure occurs in Discord outbound delivery resolution after an agent run has already produced output.
Logs, screenshots, and evidence
Sanitized evidence from a live gateway process:
Health/status at the same time showed the Discord channel configured/running/connected, with token available and no channel error. A direct
openclaw message send --channel discord ...invocation from the same host/user environment succeeded.Local code inspection of the built 2026.5.3 runtime found two relevant resolution paths:
A local hotfix changed outbound/target resolution to use/fall back through the pinned channel plugin registry / loaded channel plugin. After restart, the gateway recovered the pending Discord deliveries shown above and no new
Unsupported channel: discordorOutbound not configured for channel: discorderrors appeared in the observed post-fix window.Impact and severity
Affected: Discord channel users relying on OpenClaw final replies, cron
announcedelivery, or pending delivery recovery.Severity: High for Discord deployments because inbound events can be received and agent runs can complete, but the user-visible response is not delivered.
Frequency: Observed after gateway/plugin runtime activity on 2026.5.3; once in the bad state, affected Discord deliveries consistently failed until restart plus local hotfix.
Consequence: Missed Discord replies and missed cron announcements, while the gateway appears otherwise healthy.
Additional information
This looks related in theme to #54599 and older
Unsupported channeldelivery reports, but the observed 2026.5.3 failure is specifically Discord outbound adapter resolution in a running gateway where the external Discord plugin is loaded and direct Discord sends still work.Temporary local workaround that restored delivery:
loadChannelOutboundAdapter(id)fall back togetChannelPlugin(id)?.outboundwhen the channel registry lookup misses.getActivePluginChannelRegistry()instead of the mutable active plugin registry.This report intentionally redacts channel IDs, session keys, delivery IDs, tokens, file paths, and local config details.