openclaw - 💡(How to fix) Fix Dynamic reload doesn't disable a running WhatsApp account when its enabled flag flips to false

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

OpenClaw detects an accounts.<name>.enabled true→false change on hot reload but does not tear down the running WhatsApp provider; the session stays connected and keeps processing inbound until a cold gateway restart.

Steps to reproduce

1. Configure a WhatsApp account with an active session (enabled: true, allowlist set); confirm [whatsapp] [default] starting provider and Listening for personal WhatsApp inbound messages. in the gateway log.
2. Edit openclaw.json, set accounts.default.enabled to false, save.
3. Watch the log: [reload] config change detected, then [reload] config change applied (dynamic reads: ...accounts.default.enabled).
4. Send a DM to that account from an allowlisted number.
5. Bug: the message is still received and processed — the session was not torn down.

Expected behavior

When accounts.<name>.enabled flips true→false, the running provider should stop the Baileys socket cleanly (sock.end() or equivalent), stop processing inbound for that account, and leave credentials on disk for later re-enable — all without a full gateway restart.

Actual behavior

The reload is detected and reported as 'applied', but the provider connection is not torn down. The account keeps receiving and processing inbound messages until a cold systemctl --user restart openclaw-gateway.service.

OpenClaw version

2026.4.26 (first observed 2026.4.20; upstream 2026.5.7 not yet tested)

Operating system

Debian 13 "trixie" (arm64), Raspberry Pi 5, kernel 6.12.75

Install method

npm global: sudo npm install -g openclaw@<version>; gateway run via systemd --user as user piserver. Node 22.22.0 / 24.14.1.

Model

N/A — WhatsApp channel / config-reload bug, not model-related

Provider / routing chain

N/A — not model/routing related

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Gateway log on the toggle:

[reload] config change detected
[reload] config change applied (dynamic reads: ...accounts.default.enabled)

No provider teardown (`sock.end()`) follows; inbound from the allowlisted number is still processed. Workaround:

systemctl --user restart openclaw-gateway.service

(~60s of agent unavailability + full plugin reload.)

Impact and severity

• Affected: anyone using accounts.<name>.enabled to soft-disable a WhatsApp account without losing credentials.
• Severity: there is no way to disable a running account without a ~60s gateway outage.
• Frequency: every time enabled is toggled true→false on a running account.
• Consequence: discourages the 'soft retire / re-enable later' pattern the config field was designed to support.

Additional information

WhatsApp library bundled: @whiskeysockets/[email protected] (also tested with @innovatorssoft/[email protected] via npm alias — same behaviour). Expected teardown on disable: stop the socket, stop inbound, keep creds on disk for later reconnect. Reported as part of a hardening sprint on a self-hosted Pi 5 OpenClaw build.