openclaw - 💡(How to fix) Fix [Bug] Discord skill command dedup loop causes CPU saturation and blocks gateway readiness (v2026.5.7)

Related issues

• #61703 (race condition — locked, so filing separately)
• #60559 (--verbose workaround)

Summary

On v2026.5.7, the external Discord plugin triggers a skill command deduplication loop that inflates to 30+ iterations, saturating the event loop and preventing the Discord WebSocket ready event from being processed.

Environment

• WSL2 (Ubuntu 22.04) on Windows 11
• Single Discord account, single guild
• Socket Mode not used (standard Discord gateway)
• External Discord plugin installed via openclaw plugins install @openclaw/discord

Reproduction

1. Fresh install of v2026.5.7
2. openclaw gateway (or via helper script)
3. Discord client initializes, logs awaiting gateway readiness, never progresses
4. CPU pegged at 100%

New finding: skill command dedup loop → CPU saturation

With --verbose, the gateway log reveals a skill command deduplication loop that inflates to 30+ iterations:

[skills] De-duplicated skill command name for "discord" to "/discord_1"
[skills] De-duplicated skill command name for "discord" to "/discord_2"
...
[skills] De-duplicated skill command name for "discord" to "/discord_32"

This loop saturates the event loop (CPU pegged at 100%, util=1.0), which appears to prevent the Discord WebSocket ready event from being processed — even though the WebSocket itself opens successfully:

discord gateway: Gateway websocket opened

The --verbose workaround from #60559 does NOT help on v2026.5.7 — the skill dedup loop dominates the event loop regardless of logging I/O yields.

Timeline from verbose log

T+0.0s  http server listening (9 plugins including discord)
T+2.5s  gateway ready                              ← fires before Discord init
T+5.0s  discord channels resolved
T+8.4s  skill dedup loop: /discord_1.../discord_32  ← CPU saturated
T+8.4s  deploy-commands:schedule (72 commands)
T+8.4s  discord client initialized; awaiting gateway readiness  ← missed the ready event
T+8.4s  Gateway websocket opened                    ← WS is open but ready never fires

Workaround

Downgraded to v2026.4.27 where Discord is still bundled. Gateway connects within ~10s and CPU stays normal. The skill dedup loop does not occur on 4.x.

Hypothesis

The external Discord plugin re-registers its skill commands on each plugin registry reload cycle. Combined with the existing race condition (ready event fires before Discord init completes), the dedup loop starves the event loop so severely that the ready signal can never be processed, even with workarounds that add I/O yields.