Discord channel silently disabled after 2026.4.x → 2026.5.x upgrade (externalised plugin not auto-installed)

Heads-up to anyone reading this in the future: don't upgrade over a working Discord channel without openclaw plugins install discord ready to run. The upgrader doesn't migrate the channel and there is no warning; the bot looks alive in logs but is in fact zombie.

Summary

Upgrading from OpenClaw 2026.4.27 to 2026.5.12 leaves any previously-working Discord channel silently disabled. The bot appears alive (gateway log shows WebSocket reconnect-opcodes from Discord) but it never re-authenticates and the agent receives no incoming messages. There is no upgrade-time warning that user action is required.

Root cause is the 2026.5.x change that externalised the Discord channel into the separately-installed @openclaw/discord npm package (per CHANGELOG: "Plugins: externalize Slack, OpenShell sandbox, and Anthropic Vertex…" — Discord appears to fall in the same bucket even though it isn't explicitly named in that bullet). The upgrader does not migrate the previously-bundled plugin to its new install location, and there is no message at upgrade time pointing the operator at openclaw plugins install discord.

Environment

• OpenClaw upgraded from 2026.4.27 to 2026.5.12 (commit f066dd2)
• Linux (Ubuntu, kernel 6.1.0-1025-rockchip, arm64), Node v22.22.2
• Discord channel was previously configured with bot token + guild/channel selectors at channels.discord in openclaw.json and was working on 2026.4.x

Symptoms

After the upgrade:

1. openclaw channels list shows "no configured chat channels" despite the channels.discord block being intact in openclaw.json.
2. openclaw channels list --all shows "Discord: not installed, not configured, disabled".
3. Gateway log (/tmp/openclaw/openclaw-YYYY-MM-DD.log) shows only discord gateway: Gateway reconnect scheduled in 0ms (reconnect-opcode, resume=true) lines, no logged in to discord as … confirmation.
4. The http server listening (7 plugins: browser, canvas, device-pair, file-transfer, memory-core, phone-control, talk-voice; 5.3s) boot line confirms the Discord channel plugin is not loaded.
5. Around the same time, an unhandled_rejection crash dump was generated at ~/.openclaw/logs/stability/openclaw-stability-…-unhandled_rejection.json with code: ERR_MODULE_NOT_FOUND, originating from the Discord channel module-loading path on the running pre-upgrade gateway. (Stale gateway carrying the old code into the new layout.)

Reproduction (approximate)

1. On 2026.4.27 with a working Discord channel configured in openclaw.json under channels.discord (token, guilds, etc.).
2. Upgrade to 2026.5.12.
3. Restart the gateway (or let the auto-restart at upgrade time fire).
4. Observe: Discord channel silently disabled, no warning printed, agent stops receiving Discord messages.

Fix that worked

openclaw plugins install discord
openclaw gateway restart

After this the gateway boot line reads http server listening (8 plugins: … discord …) and openclaw channels status reports Discord default: enabled, configured, running, connected, bot:@….

Suggested upstream changes

1. Upgrade-time migration: at the point a previously-bundled channel plugin is externalised, detect that the operator's openclaw.json still references the channel and either:
   • auto-install the new external package (preferred), or
   • print a loud, blocking-style warning that explicitly names the openclaw plugins install <name> command needed to restore the channel.
2. CLI inconsistency: openclaw channels list reports "no configured chat channels" while the config file still has a configured channels.discord block. The CLI should at least say "discord is configured but the plugin is not installed; run openclaw plugins install discord". Same shape for any externalised channel.
3. Stale-gateway behaviour: the pre-upgrade gateway's Discord WebSocket continued to receive reconnect-opcode from Discord and dutifully scheduled reconnects, even though the channel module had been removed under it. The log contained nothing alarming-looking — no error, no warning — for hours. Consider tightening the reconnect-without-prior-IDENTIFY pattern into a warn-level log line.
4. Possibly: include discord (and the other commonly-used previously-bundled channels) in the install-time plugins.allow allowlist when they are explicitly installed by openclaw plugins install, so the operator doesn't see the "plugins.allow is empty; discovered non-bundled plugins may auto-load: discord" warning on next boot. (Minor.)

Other context

I'm filing this because the same release (or a near sibling) appears to have caused a similar regression in May with chokidar/readdirp missing from the plugin-runtime-deps extraction — the failure mode was nearly identical from the operator side (Discord silent, no errors). Both are quiet failures, and both could be caught by a single guard at upgrade time: "this config references a plugin that is not installed in the new layout — operator must run X."

Happy to test a candidate fix if there is one.