openclaw - 💡(How to fix) Fix Discord plugin still stuck at 'awaiting gateway readiness' in v2026.5.18 — --verbose workaround no longer works

What happened

After upgrading to v2026.5.18, all 7 Discord bots in a multi-account setup hang at client initialized as <id>; awaiting gateway readiness and never reach logged in to discord. No received message events are dispatched. The bots do show as online (green dot) in the Discord client, confirming Carbon's WebSocket actually connects — but OpenClaw's ReadyListener never observes the Ready event, so the channel handler never registers its message listener.

The --verbose workaround from #60559 no longer fixes this in v2026.5.x.

This is a continuation of the symptom cluster from #56492 / #57075 / #58290 / #58577 / #59820 / #60559 / #61505 — all closed and now locked. Filing a fresh issue since none of those accept comments anymore.

Reproduction

• Platform: macOS Darwin 24.6.0 arm64 (Mac laptop, direct internet, no corp proxy)
• OpenClaw: v2026.5.18 (50a2481), upgraded from v2026.4.15 today via npm install -g openclaw@latest
• Node: v24.14.0 (nvm)
• Discord plugin: @openclaw/discord (newly external in 2026.5.x), installed via openclaw plugins install
• Bots: 7 bot accounts in one guild, sharing one channel
• All 7 bots have Message Content Intent enabled in Discord Developer Portal
• channels.discord.accounts.<id>.intents: explicitly {presence: false, guildMembers: false} per account
• launchd ProgramArguments: node ... gateway --port 18789 --verbose (verified via launchctl print)

Symptom

[discord] [main] starting provider (@MacClaw)
[discord] client initialized as 1506519147683643423; awaiting gateway readiness
[discord] [main] Discord bot probe resolved @MacClaw
[discord] [main] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
... (same for all 7 bots, staggered by rate-limit delay) ...

After 7+ minutes (all rate-limit delays elapsed):

$ grep "client initialized" gateway.log | wc -l
7
$ grep "logged in to discord" gateway.log | wc -l
0

Channel users @-mention bots → no log lines, no dispatch, no reply.

After ~5 min the health-monitor flips them all to disconnected and restarts → same hang.

Direct WebSocket test (proves the problem is OpenClaw, not network/credentials/intents)

Using the same node binary, same env, same tokens:

const WebSocket = require('/Users/.../openclaw/node_modules/ws');
const TOKEN = '<one of the 7 bot tokens>';
const ws = new WebSocket('wss://gateway.discord.gg/?v=10&encoding=json');
const t = setTimeout(() => { console.log('TIMEOUT'); process.exit(1); }, 8000);
ws.on('message', (data) => {
  const msg = JSON.parse(data);
  if (msg.op === 10) {
    ws.send(JSON.stringify({op:2, d:{
      token: TOKEN,
      intents: 32513, // GUILDS|GUILD_MESSAGES|MESSAGE_CONTENT
      properties: {os:'linux', browser:'t', device:'t'}
    }}));
  } else if (msg.t === 'READY') {
    clearTimeout(t);
    console.log('READY');
    ws.close();
    process.exit(0);
  }
});

Result for all 7 tokens: op:0 t:READY in <1 second.

So tokens, intents, network, IPv4/IPv6 routing, the bundled ws module — all fine. The bug is entirely in the OpenClaw → Carbon glue.

Tested workarounds (all ineffective in 2026.5.18)

Root cause (per closed-issue analysis, still applicable)

Quoting #56492 / #60559 / #61505: Carbon Client constructor calls

for (const plugin of plugins) {
  plugin.registerClient?.(this);   // not awaited — fire-and-forget async
  plugin.registerRoutes?.(this);
}

SafeGatewayPlugin.registerClient is async (awaits fetchDiscordGatewayInfoWithTimeout() before super.registerClient(client) opens the WS). The constructor returns immediately, OpenClaw enters runDiscordGatewayLifecycle() and the DISCORD_GATEWAY_READY_TIMEOUT_MS poll silently fails because this.client is undefined during the race window — IDENTIFY no-ops with no error.

The --verbose workaround used to win the race via synchronous console.log I/O perturbing event-loop ordering. In 2026.5.x the timing has presumably shifted further so verbose-mode no longer wins.

Suggested fix

Properly await the async registerClient chain in Carbon's Client constructor (or have SafeGatewayPlugin.registerClient provide a sync init path that doesn't race the polling loop).

Use case

Multi-agent Discord deployment (1 main + 5 specialised sub-agents, each a separate bot for identity differentiation in the channel). The same multi-agent system runs perfectly on Feishu. Migrating to Discord is blocked entirely on this bug.

Happy to:

• Provide more reproduction data
• Test a candidate fix
• Capture a node --inspect trace if helpful

Logs (all 7 bots — abbreviated)

2026-05-20T13:41:38.664+08:00 [discord] client initialized as 1506519147683643423; awaiting gateway readiness
2026-05-20T13:41:39.003+08:00 [discord] [main] Discord bot probe resolved @MacClaw
2026-05-20T13:41:48.004+08:00 [discord] [sre-backend] starting provider
2026-05-20T13:41:49.334+08:00 [discord] client initialized as 1506519789151977493; awaiting gateway readiness
...
2026-05-20T13:42:39.397+08:00 [discord] client initialized as 1506520415747440671; awaiting gateway readiness
[no "logged in to discord" entries — none of the 7 ever transition]