Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
On stable 2026.6.1 (2e08f0f), Discord inbound handling and the agent turn completed, but final reply delivery failed with:
Error: Outbound not configured for channel: discord
The gateway was otherwise healthy, Discord status was OK, config validation passed, and @openclaw/discord@2026.6.1 was loaded. After a gateway restart, delivery recovery replayed the single pending Discord reply successfully.
This looks related to closed issues #77254, #84147, and especially #84568. I am filing a new issue because those reports are closed as fixed, while the current stable 2026.6.1 install and current main source still show the same risky active-registry fallback path in src/channels/plugins/registry-loader.ts.
Steps to reproduce
- Run OpenClaw
2026.6.1 with the official Discord plugin enabled and connected.
- Use Discord as an inbound channel and send a normal message that should produce a final assistant reply.
- Observe that the agent turn completes, but the final Discord reply is not posted.
- Check gateway logs for
Outbound not configured for channel: discord.
- Restart the gateway and observe delivery recovery replay the pending Discord delivery.
Expected behavior
If Discord inbound is connected and the Discord plugin is loaded, final assistant replies should continue resolving the Discord outbound adapter and post to the originating Discord channel without requiring a gateway restart.
Actual behavior
The agent run completed, but final reply delivery failed:
[plugins] openclaw-mem0: skills-mode agent_end (no auto-capture)
[discord] final reply failed (target=<redacted> session=<redacted>): Error: Outbound not configured for channel: discord
After a gateway restart, the pending delivery recovered:
[delivery-recovery] Found 1 pending delivery entries — starting recovery
[delivery-recovery] Recovered delivery <redacted> on discord
[delivery-recovery] Delivery recovery complete: 1 recovered, 0 failed, 0 skipped (max retries), 0 deferred (backoff)
OpenClaw version
2026.6.1 (2e08f0f)
Operating system
Ubuntu 24.04 LTS, Linux x86_64
Install method
npm global, gateway launched as a systemd service
Model
gpt-5.5
Provider / routing chain
OpenClaw gateway -> OpenAI Codex runtime
Additional provider/model setup details
The model/provider path appears healthy. The failure happened after an agent turn had already produced output, and the failed surface was Discord final-reply delivery.
openclaw status --deep after restart showed Discord OK and the active session runtime as OpenAI Codex.
The Discord plugin was loaded as @openclaw/discord@2026.6.1 from the npm-project install. plugins inspect discord also reported a duplicate plugin-id warning from an older install/copy, but the active selected runtime was the npm-project Discord plugin.
Logs, screenshots, and evidence
Sanitized live checks:
openclaw --version
OpenClaw 2026.6.1 (2e08f0f)
curl /health
{"ok":true,"status":"live"}
openclaw config validate
Config valid: ~/.openclaw/openclaw.json
Current source inspection on main shows src/channels/plugins/registry-loader.ts still falls back from the channel registry to getActivePluginRegistry() after a channel-registry miss. That matches the root-cause family described in #84568.
Current src/infra/outbound/deliver.ts calls loadBootstrappedOutboundAdapter(), then resolveOutboundChannelMessageAdapter(), and throws Outbound not configured for channel: ${params.channel} when neither path yields a send-capable handler.
Current src/infra/outbound/channel-bootstrap.runtime.ts records a per-channel/per-registry bootstrap attempt before verifying that the resulting registry has a send-capable channel entry. Inference: if bootstrap resolves without making Discord send-capable, later retries can be skipped for the same registry version until process restart clears the attempt state.
Impact and severity
Affected: Discord users relying on final assistant replies.
Severity: High for Discord deployments because inbound messages can be processed and agent turns can complete, but the user-visible final response is not delivered until restart recovery.
Frequency: Observed once on stable 2026.6.1; the source path matches previously reported closed regressions.
Additional information
Related closed issues: #77254, #84147, #84568.
This report intentionally redacts Discord channel IDs, session keys, delivery IDs, message content, tokens, hostnames, IPs, file paths containing usernames, and local config details.
Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
On stable
2026.6.1 (2e08f0f), Discord inbound handling and the agent turn completed, but final reply delivery failed with:Error: Outbound not configured for channel: discordThe gateway was otherwise healthy, Discord status was OK, config validation passed, and
@openclaw/discord@2026.6.1was loaded. After a gateway restart, delivery recovery replayed the single pending Discord reply successfully.This looks related to closed issues #77254, #84147, and especially #84568. I am filing a new issue because those reports are closed as fixed, while the current stable
2026.6.1install and currentmainsource still show the same risky active-registry fallback path insrc/channels/plugins/registry-loader.ts.Steps to reproduce
2026.6.1with the official Discord plugin enabled and connected.Outbound not configured for channel: discord.Expected behavior
If Discord inbound is connected and the Discord plugin is loaded, final assistant replies should continue resolving the Discord outbound adapter and post to the originating Discord channel without requiring a gateway restart.
Actual behavior
The agent run completed, but final reply delivery failed:
After a gateway restart, the pending delivery recovered:
OpenClaw version
2026.6.1 (2e08f0f)Operating system
Ubuntu 24.04 LTS, Linux x86_64
Install method
npm global, gateway launched as a systemd service
Model
gpt-5.5Provider / routing chain
OpenClaw gateway -> OpenAI Codex runtime
Additional provider/model setup details
The model/provider path appears healthy. The failure happened after an agent turn had already produced output, and the failed surface was Discord final-reply delivery.
openclaw status --deepafter restart showed Discord OK and the active session runtime as OpenAI Codex.The Discord plugin was loaded as
@openclaw/discord@2026.6.1from the npm-project install.plugins inspect discordalso reported a duplicate plugin-id warning from an older install/copy, but the active selected runtime was the npm-project Discord plugin.Logs, screenshots, and evidence
Sanitized live checks:
Current source inspection on
mainshowssrc/channels/plugins/registry-loader.tsstill falls back from the channel registry togetActivePluginRegistry()after a channel-registry miss. That matches the root-cause family described in #84568.Current
src/infra/outbound/deliver.tscallsloadBootstrappedOutboundAdapter(), thenresolveOutboundChannelMessageAdapter(), and throwsOutbound not configured for channel: ${params.channel}when neither path yields a send-capable handler.Current
src/infra/outbound/channel-bootstrap.runtime.tsrecords a per-channel/per-registry bootstrap attempt before verifying that the resulting registry has a send-capable channel entry. Inference: if bootstrap resolves without making Discord send-capable, later retries can be skipped for the same registry version until process restart clears the attempt state.Impact and severity
Affected: Discord users relying on final assistant replies.
Severity: High for Discord deployments because inbound messages can be processed and agent turns can complete, but the user-visible final response is not delivered until restart recovery.
Frequency: Observed once on stable
2026.6.1; the source path matches previously reported closed regressions.Additional information
Related closed issues: #77254, #84147, #84568.
This report intentionally redacts Discord channel IDs, session keys, delivery IDs, message content, tokens, hostnames, IPs, file paths containing usernames, and local config details.