openclaw - 💡(How to fix) Fix [Bug]: WhatsApp plugin caches group allowlist at process start; SIGUSR1 hot-reload does not pick up channels.whatsapp.groups changes

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Adding a new entry under [email protected] via gateway config.patch (or any change that triggers only a SIGUSR1 hot-reload) does not update the WhatsApp plugin's in-memory group allowlist. Inbound messages from the newly-added group are then silently dropped after web-inbound and never reach web-auto-reply / the agent. A full process restart is required for the new group entry to take effect.

This is silent at the default info log level. The only diagnostic is at debug:

debug {"message":"Skipping group message @g.us (not in allowlist)"} verbose

Steps to reproduce

1. Run a gateway with channels.whatsapp.groupPolicy: "allowlist" and at least one group already listed under channels.whatsapp.groups. Confirm that group works end-to-end (inbound message produces an agent turn and a reply).

2. Add a new group entry via gateway config.patch: json {"channels":{"whatsapp":{"groups":{"@g.us":{"requireMention":false}}}}}

   Verify it lands in ~/.openclaw/openclaw.json.

3. Confirm the bot is actually a member of the group (openclaw directory groups list --channel whatsapp shows it).

4. Send a message in that group (with or without mentioning the bot).

5. Observe openclaw logs --plain:

   • web-inbound logs the message (Baileys received it).
   • No web-auto-reply ... "inbound web message" log.
   • No gateway/channels/whatsapp/inbound Inbound message ... log.
   • No agent turn.

6. Restart the gateway via gateway config.patch -> gateway.restart (which uses SIGUSR1). Repeat step 4. Same silent drop.

7. Wait for a deferred full process restart (or run a real restart). Repeat step 4. Now the message flows through end-to-end.

Expected behavior

Either:

• (a) Hot-reload of channels.whatsapp.groups updates the plugin's allowlist live, OR
• (b) The config-reload pipeline detects this path as restart-required (like it already does for env.vars.OPENCLAW_LOG_LEVEL) and surfaces "restart required" to the operator instead of silently continuing with stale state.

Either way, the runtime should not silently drop messages for a group that is in the on-disk config.

Actual behavior

Plugin keeps using the allowlist that was resolved at process start. Verified by:

• A standalone Node script that imports @openclaw/whatsapp/dist/access-control-...js and calls resolveWhatsAppInboundPolicy({ cfg: , accountId: "default", ... }).resolveConversationGroupPolicy(@g.us) returns { allowlistEnabled: true, allowed: true }.
• Meanwhile the live runtime, with the same on-disk config, logs Skipping group message @g.us (not in allowlist) for inbound messages from that group.
• After a real process restart (not just SIGUSR1), the live runtime starts accepting messages from that group immediately and consistently.

OpenClaw version

2026.5.7

Operating system

Linux x64, Node 24.14, Docker (single-process, PID 1 = openclaw)

Install method

docker image

Model

anthropic/claude-opus-4-7

Provider / routing chain

whatsapp -> openclaw

Additional provider/model setup details

No response

Logs, screenshots, and evidence

## Code pointer

`extensions/whatsapp/src/auto-reply/monitor/group-gating.ts` -> `applyGroupGating` calls `resolveWhatsAppInboundPolicy(...).resolveConversationGroupPolicy(conversationId)`. The skip line is:

ts
params.logVerbose(Skipping group message ${params.conversationId} (not in allowlist));
return { shouldProcess: false };


`resolveWhatsAppInboundPolicy` reads `cfg.channels.whatsapp.groups` through `resolveWhatsAppAccount(...)` -> `resolveMergedWhatsAppAccountConfig(...)`. Somewhere in that chain the resolved groups map is captured at startup and not refreshed on `SIGUSR1`.

Two small wins regardless of the root fix:
1. Promote that "Skipping group message ... (not in allowlist)" line to `info`. It is currently invisible at the default log level and there is no other on-disk evidence of the drop. This is the single line that would have made this debuggable in minutes instead of hours.

2. If `channels.whatsapp.groups` (and ideally any allowlist) cannot be hot-reloaded, mark the path as restart-required in the config-reload classifier so the deferred-restart machinery kicks in automatically when an operator patches it (mirroring the existing behavior for `env.vars.OPENCLAW_LOG_LEVEL`).

## Logs (redacted)


14:07:54 info web-inbound from=120363..[email protected] body="@ hello" -> inbound message
                                                                       (no follow-up)
14:19:25 info web-inbound from=120363..[email protected] body="@ test ..." -> inbound message
14:19:25 debug Skipping group message 120363..[email protected] (not in allowlist)  <-- only visible at debug

(after full restart at 15:21)

15:33:09 info  web-inbound from=120363..[email protected] body="@ test" -> inbound message
15:33:09 debug group mention debug ... wasMentioned=true
15:33:09 info  web-auto-reply ... inbound web message
15:33:09 info  gateway/channels/whatsapp/inbound Inbound message ... (group, 121 chars)
15:33:18 info  web-auto-reply auto-reply sent (text)


## Notes

- Same on-disk config in both the failing and working cases.
- The bot is a confirmed member of the group (`openclaw directory groups list --channel whatsapp`).
- Both other groups added earlier (which were already in the cached allowlist at process start) keep working across reloads.
- `openclaw doctor` reports no issues during the failure state.

Impact and severity

No response

Additional information

Workaround

After modifying channels.whatsapp.groups, force a real process restart (not SIGUSR1). In a Docker setup, docker restart works. Inside the container, kill 1 will terminate the supervisor and let it relaunch.