Summary

Discord routinely closes the bot gateway WebSocket with code 1006 (abnormal, empty reason) — normal server-side rebalancing that every long-lived bot sees. After such a close, the @openclaw/discord plugin does not re-establish the connection on its own (no successful RESUME / re-IDENTIFY, no recovery markers) for minutes. The connection only comes back when the entire gateway process is restarted. Because a full gateway restart interrupts whatever agent turns are mid-execution, this causes user-facing message loss: a user asks an agent something in Discord, the turn is running, the gateway restarts to recover Discord, and the turn dies with no reply.

Steps to reproduce

1. Run the gateway with a Discord channel bound via bot token, kept online for hours.
2. Wait for Discord to close the gateway WS (code 1006, reason=<empty>) — happens ~4–8×/day for any long-lived bot; it is server-initiated, not an auth/intent 4xxx close.
3. Observe the plugin does not reconnect: no RESUME succeeds, no starting provider / channels resolved markers appear.
4. After ~120s an external watchdog (or an operator) restarts the whole gateway — only then does Discord come back.

Expected behavior

On a 1006/1005 close, the plugin should RESUME (or re-IDENTIFY) and reconnect its own WebSocket within seconds, without requiring a gateway process restart — standard Discord gateway client behavior. A transient WS close should never require a full-process restart.

Actual behavior

The plugin goes silent after the close. Two full episodes from gateway.log — nothing happens between the close and the (external) full gateway restart:

2026-07-03T13:24:29.742 [discord] gateway websocket closed flow=fde9370a… code=1006 reasonBytes=0 reason=<empty>
2026-07-03T13:24:29.744 [discord] gateway: Gateway websocket closed: 1006
                          … ~3 minutes of NO discord reconnect activity …
2026-07-03T13:27:28.701 [gateway] http server listening (…)          ← only after a full gateway restart
2026-07-03T13:27:28.943 [discord] [default] starting provider
2026-07-03T13:27:30.191 [discord] [default] Discord bot probe resolved
2026-07-03T13:27:32.331 [discord] channels resolved: …
2026-07-03T13:27:35.398 [main-session-restart-recovery] resumed interrupted main session: agent:<name>:main

Same shape at 10:31:46 close → 10:34:20 restart. A single auto-restart attempt N/10 is logged per close but never re-establishes; recovery attempts sometimes fail with WebSocket was closed before the connection was established.

OpenClaw version

2026.6.10 (aa69b12); @openclaw/discord plugin 2026.6.10

Operating system

macOS (Darwin 24.6.0), Apple Silicon Mac mini, wired Ethernet

Install method

npm global (/usr/local/lib/node_modules/openclaw)

Model / Provider / routing chain

Not applicable — this is a channel-transport (Discord gateway) reliability bug, independent of model/provider.

Logs

• Gateway websocket closed events in the current log: 127× code 1006, 98× code 1005, all reason=<empty> / reasonBytes=0 (server-initiated transport closes).
• Frequency on one representative day (2026-07-03): ~4–8 WS closes, 7 full gateway restarts forced to recover Discord.

Impact and severity

High — user-facing message loss. Full-gateway restarts (2–6×/day) interrupt in-flight interactive agent turns; the user gets silence and must re-ask. The gateway itself logs the interruption (main-session-restart-recovery: resumed interrupted main session).

Additional information

Ruled out (so this isn't a local-environment red herring):

• Not power management — pmset sleep 0, powernap 0, no Sleep/Wake events at close times.
• Not flaky WiFi — wired Ethernet.
• Not our-side overload/rate-limit — steady ~170 gateway ops/hr, uniform, uncorrelated with the drops.
• Not an outdated plugin — on the latest 2026.6.10.

No turn-safe recovery is exposed today (verified 2026-07-03):

• openclaw channels login --channel discord → Error: Channel "discord" does not support login.
• openclaw channels capabilities --channel discord Actions = send, broadcast, poll, react, …, channel-*, set-presence — no reconnect / restart / reload verb.
• So the only recovery for a dead WS is a full gateway restart, which is exactly what kills in-flight turns.

Secondary ask: if fixing the plugin's auto-reconnect is non-trivial, please expose a turn-safe, channel-scoped reconnect (CLI/RPC to restart just the Discord provider connection) so operators can recover Discord without restarting the gateway and killing agent turns.

Happy to supply fuller gateway.log excerpts or run diagnostics.