openclaw - 💡(How to fix) Fix doctor --lint blind to missing plugins.entries.<channel> after channel-account refactor — WhatsApp silently disabled on upgrade

Summary

After upgrading from 2026.5.3-1 → 2026.5.19, my WhatsApp channel silently stopped working. Messages were marked delivered/read by WhatsApp (because the linked-device slot still exists) but the gateway never replied — no error, no log entry. doctor --lint ran 17 checks and reported zero relevant findings.

Root cause: the channel-account refactor requires two new config keys that didn't exist in 2026.5.3-era configs:

1. channels.<name>.accounts.<id>.{authDir, enabled} — added by openclaw channels add.
2. plugins.entries.<name>.enabled = true — must be set manually.

The second one is the silent killer. Without it, the channel plugin isn't loaded at gateway boot, the channels.start RPC rejects with invalid channels.start channel, and nothing in doctor --lint notices.

This mirrors closed issue #84360 ("Discord channel silently disabled after 2026.5.18 update — plugin-entry migration missing"), but for WhatsApp the auto-migration hasn't been added. I confirmed state-migrations-*.js in 2026.5.19 contains only the Telegram migration path.

Reproduce

1. Install 2026.5.3-1, configure WhatsApp under channels.whatsapp.{enabled: true, allowFrom: [...], dmPolicy: "allowlist"}, pair via QR. Verify replies work.
2. Upgrade: npm install -g [email protected] && openclaw doctor --fix. The doctor wizard does not flag any channel issue and reports completion.
3. Restart gateway. Service comes up "ready", logs starting channels and sidecars... followed by silence — no provider-start line for WhatsApp.
4. openclaw channels list → no configured chat channels.
5. openclaw channels list --all → WhatsApp: installed, not configured, disabled.
6. openclaw doctor --lint --json → no related findings (security warnings + commands.ownerAllowFrom info only).
7. Send a WhatsApp message from an allowlisted number → message is acknowledged by WhatsApp but never reaches the agent.

Gateway plugin loadout for the broken state:

http server listening (8 plugins: browser, canvas, device-pair, duckduckgo, file-transfer, memory-core, phone-control, talk-voice; ...)

Note absence of whatsapp. After applying the workaround it becomes:

http server listening (9 plugins: ..., whatsapp; ...)
[channels/whatsapp] [default] starting provider (+xxxxxxxxxxx)
Listening for personal WhatsApp inbound messages.

Workaround

openclaw channels add --channel whatsapp --account default --auth-dir ~/.openclaw/credentials/whatsapp/default
openclaw channels login --channel whatsapp --account default   # session attaches without QR re-scan
openclaw config set plugins.entries.whatsapp.enabled true       # the hidden step
systemctl --user restart openclaw-gateway.service

The Baileys session attached cleanly and 98 backlog messages were pulled on the first connect.

Suggested fix

Two complementary fixes:

1. Auto-migration (parity with Discord #84360): at config load, if channels.<name> is present, channels.<name>.accounts is non-empty, and plugins.entries.<name>.enabled is unset, write plugins.entries.<name>.enabled = true. Apply at minimum to WhatsApp; ideally driven by a generic table of channel-plugin name pairs.
2. Doctor lint check: add a finding that fires when channels.<name> exists with at least one accounts.<id>.enabled === true but plugins.entries.<name>.enabled !== true. Severity error, with a fixHint to run openclaw config set plugins.entries.<name>.enabled true or apply --fix.

Both are cheap and would have caught this case at the doctor --fix invocation during my upgrade.

Environment

• OpenClaw 2026.5.19 (a185ca2), installed globally under nvm node v25.2.1
• Linux (Ubuntu Server 24.04.3 LTS), systemd user service
• Channels affected (verified): WhatsApp. Likely impacts any channel whose plugin-entry migration was not backfilled into state-migrations-*.js.