openclaw doctor --fix regression on v2026.3.22: tries to add whatsapp to plugins.allow

Summary

On OpenClaw 2026.3.22, openclaw doctor --fix fails on an otherwise healthy config when WhatsApp is configured as a channel.

Doctor reports:

• WhatsApp configured, enabled automatically.

Then exits with:

• Error: Config validation failed: plugins.allow: plugin not found: whatsapp

This appears to be a doctor migration bug, not a user-config error. Doctor seems to treat the channels.whatsapp channel id as if it were a plugin id and attempts to write whatsapp into plugins.allow, which then fails schema validation.

Environment

• OpenClaw version: 2026.3.22 (4dcc39c)
• OS: macOS 26.3.1 arm64
• Install type: global pnpm
• Gateway mode: local LaunchAgent

Current config shape

Relevant config excerpt:

{
  "channels": {
    "whatsapp": {
      "enabled": true,
      "dmPolicy": "allowlist",
      "allowFrom": ["+8615687411111"],
      "groupPolicy": "allowlist"
    }
  },
  "plugins": {
    "allow": [
      "memory-lancedb-pro",
      "synology-chat"
    ]
  }
}

Notes:

• plugins.allow does not contain whatsapp
• whatsapp is configured only under channels.whatsapp
• openclaw gateway health is OK
• openclaw status is healthy

Reproduction

1. Upgrade to v2026.3.22
2. Use a config with:
   • channels.whatsapp.enabled = true
   • no whatsapp entry in plugins.allow
3. Run:

openclaw doctor --fix

Actual result

Doctor prints migration hints, then exits with:

Error: Config validation failed: plugins.allow: plugin not found: whatsapp

Full tail of the output from a real run:

Synology Chat: configured
Agents: main (default), scheduler, ckm-rag, qa, backend-dev, tech-lead, system-maintenance
Heartbeat interval: 30m (main)
Session store (main): /Users/coxi/.openclaw/agents/main/sessions/sessions.json (3 entries)
- agent:main:whatsapp:direct:+8615687411111 (7736m ago)
- agent:main:main (8475m ago)
- agent:main:synology-chat-4 (9020m ago)

Memory search is explicitly disabled (enabled: false).

Error: Config validation failed: plugins.allow: plugin not found: whatsapp

Expected result

One of:

1. Doctor should leave plugins.allow unchanged and only keep WhatsApp under channels.whatsapp, or
2. Doctor should enable WhatsApp using the current channel-native configuration path instead of the plugin allowlist.

In either case, doctor should not write an invalid plugin id into plugins.allow.

Suspected root cause

Doctor appears to conflate channel ids with plugin ids during auto-enable/fix migration.

• channels.whatsapp is valid channel configuration
• plugins.allow accepts only installed plugin ids
• doctor seems to generate an invalid config candidate by inserting whatsapp into plugins.allow
• validation then fails before the fix flow can complete

Why this looks like a regression

v2026.3.22 includes breaking changes around plugins, channels, and config migration. On this version:

• WhatsApp works as a configured channel
• the gateway is healthy before running doctor
• doctor --fix is the command introducing the invalid config transition

That strongly suggests the bug is inside doctor's auto-enable/migration path rather than in the base config.

Impact

• users upgrading to v2026.3.22 may be blocked from using openclaw doctor --fix
• the recommended post-upgrade repair flow cannot complete successfully for configs with WhatsApp enabled
• users may think their config is broken even when the gateway is otherwise healthy

Workaround

• do not run openclaw doctor --fix on v2026.3.22 when WhatsApp is enabled
• openclaw doctor --non-interactive and openclaw doctor --deep --non-interactive still work for diagnostics
• keep whatsapp only under channels.whatsapp
• if plugins.allow gets polluted with whatsapp, remove it manually

Additional observations

• re-running openclaw doctor --fix after cleaning unrelated invalid plugin entries still reproduces the same failure
• the config file remained unchanged on the failed run in this environment, so the issue appears to occur during doctor's attempted write/validation cycle rather than from a pre-existing stale file