Bug: WhatsApp groups stop receiving messages after gateway restart* | Friends of the Crustacean 🦞🤝 | Page 1

wanton ember Apr 22, 2026, 12:51 PM

#

Version: OpenClaw 2026.4.21 (f788c88)
OS: Linux 6.8.0 (Ubuntu), Node v22.22.2

Symptom:
After any gateway restart (openclaw gateway restart), the bot stops receiving messages from WhatsApp groups entirely. Direct messages continue to work normally. messagesHandled counter increments only for direct messages — group messages never arrive.

Config:

groupPolicy: "allowlist" with 10 groups listed
8 groups bound to secondary agent (julie) via bindings[] with accountId: "*"
2 groups bound to main agent with requireMention: true

Steps to reproduce:

Bot running normally, receiving group messages fine
Gateway restarts (automatic watchdog timeout or manual openclaw gateway restart)
New connection established, reconnectAttempts: 1
From this point: lastInboundAt: null, messagesHandled: 0 for groups indefinitely
Direct messages arrive normally

Observed: Groups were active (confirmed via WhatsApp mobile) but zero group messages in logs. Persists across multiple restarts and OpenClaw update from 2026.4.15 → 2026.4.21.

Question: Is there a way to force group subscription/sync after reconnect? Is this a known issue?

crystal surgeBOT Apr 22, 2026, 12:51 PM

#

torn ledgeBOT Apr 22, 2026, 12:51 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

oblique minnowBOT Apr 22, 2026, 12:57 PM

#

I checked the WhatsApp inbound path a bit deeper. I’m going to verify whether there’s any documented/manual “force resubscribe” path, then I’ll give you the straight answer plus the best logs to grab.

#

I dug through the WhatsApp docs + runtime a bit.

Short version: I don’t see a user-facing “force group resubscribe/sync” command today, and this does look like a real bug/regression, not just a normal config mistake.

What I found:

On reconnect, OpenClaw does rebuild the WhatsApp socket/listener.
It also does a one-shot sock.groupFetchAllParticipating() on connect.
I do not see a retry loop or manual CLI for “rehydrate groups again”.

So if DMs keep working but groups never recover after restart, the likely failure is one of these:

group hydration fails on reconnect and never retries, or
group messages are arriving but getting dropped before messagesHandled increments, especially in groupPolicy: "allowlist" mode.

Important nuance: messagesHandled / lastInboundAt only move after a message survives normalization/policy checks, so those counters staying at zero do not prove the socket never saw the group message.

The strongest diagnostic next step is:

#

openclaw logs --follow

Right after a restart, look for any of these:

Hydrated ... participating groups on connect
Failed hydrating participating groups on connect: ...
Blocked group message ... (groupPolicy: allowlist)
LID mapping not found ...
Failed to fetch group metadata for ...

If you want a very good isolate test, temporarily set the affected WhatsApp account to:

groupAllowFrom: ["*"]

#

just to test after restart.

If groups suddenly start working again, that points pretty hard at post-reconnect sender resolution / allowlist gating, not missing subscription.

So my answer would be:

Force sync command: no, not currently
Known issue: I don’t see this exact bug called out in docs/changelog, but it definitely smells like a runtime bug worth filing

Docs:

If you paste the post-restart log lines around Hydrated / Failed hydrating / Blocked group message, I can narrow it down fast.

wanton ember Apr 22, 2026, 1:21 PM

#

Result of groupAllowFrom: [""] test:*

Still no group messages received. Zero @g.us entries in logs even with allowlist fully open and confirmed active groups (verified via mobile).

So it's not a sender resolution / allowlist issue.

Timeline:

Gateway restarted ~02h55 BRT (05h55 UTC) — automatic watchdog or system restart
From that point: messagesHandled only increments for direct messages, never groups
Multiple restarts since then (manual + update to 2026.4.21) — same result
Groups confirmed active on mobile throughout

Hypothesis: group hydration failed on reconnect and never retried. Socket is connected but not receiving group events.

Is there a way to force group re-subscription / re-hydration without full re-auth? Or is this a known regression in reconnect logic?

oblique minnowBOT Apr 22, 2026, 1:23 PM

#

That’s a really useful isolate, thank you. If groupAllowFrom: ["*"] still gives zero @g.us events, then yeah, this has moved out of policy/gating territory and into the WhatsApp runtime itself.

I’m going to do one quick pass for any explicit reconnect/group bug notes or upstream Baileys patterns, then I’ll give you the cleanest recommendation.

#

Yep, with that groupAllowFrom: ["*"] result, I’d now call this a known class of issue rather than config.

What I found:

There is no exposed “force WhatsApp group resync/re-hydrate” command right now.
In source, OpenClaw only does a best-effort groupFetchAllParticipating() once on connect.
If you’re seeing zero @g.us events at all, this matches the “device/socket is not getting group inbound after reconnect” class, not policy filtering.

Matching GitHub issues:

#1952, “WhatsApp group inbound messages stop working after gateway restart”
#20952, “WhatsApp group messages not working after restart (append bug, correct config)”
#14069, “WhatsApp group messages stop arriving after relinking device (syncFullHistory: false prevents group sync)”

So the straight answer is:

Force re-subscription without re-auth: I don’t see a supported way today
Known issue: yes, or at least a clearly recurring regression class

One important nuance: the old “append messages are skipped after reconnect” bug was already patched in 2026.3.22, so if you’re still hitting this on 2026.4.21, this looks like another reconnect/group-sync failure mode, not just the old append-only bug.

#

My recommendation:

Grab the exact post-restart lines around:
- Hydrated ... participating groups on connect
- Failed hydrating participating groups on connect: ...
Then file or add your findings on GitHub:

If you want, paste the Hydrated / Failed hydrating lines here and I’ll help you turn it into a tight bug report.

wanton ember Apr 22, 2026, 1:45 PM

#

Searched both today's and yesterday's logs for "Hydrated", "Failed hydrating", "participating groups" — zero results in either day's log file (/tmp/openclaw/openclaw-YYYY-MM-DD.log).

Is there a more verbose log level we can enable? Or are those lines only visible in stdout/journald?

For context: we're on 2026.4.21, Linux/systemd, gateway runs as user service. Log file is the only output we have access to currently.

oblique minnowBOT Apr 22, 2026, 1:46 PM

#

I’m going to verify where those WhatsApp connect/hydration lines actually go, and whether there’s a documented way to turn them on under systemd.

#

Yep, that explains it.

Those Hydrated ... participating groups on connect lines are verbose-only, and in current code they go through the gateway’s console runtime, not normal file logging.

So:

Hydrated ...: only shows when the gateway process itself is started with --verbose
Failed hydrating ...: should hit normal warn logging too, so that one can show in file/journald
No hits in /tmp/openclaw/openclaw-YYYY-MM-DD.log does not mean hydration never ran, it mostly means you were not running the gateway in verbose mode

Important nuance:

Raising logging.level / OPENCLAW_LOG_LEVEL=debug alone is probably not enough for those specific hydration lines
They are gated by the gateway runtime’s verbose boolean, not just log level

Best ways to capture it:

If you can access journald

#

   journalctl --user -u openclaw-gateway.service -f

and make sure the service is running the gateway with --verbose

Simplest one-shot repro
stop the service, then run foreground once:
```
openclaw gateway run --verbose
```
If you want extra logging too:
```
openclaw --log-level debug gateway run --verbose
```

What I’d expect:

if hydration is happening, you should finally see either:

#

Hydrated N participating groups on connect
- or Failed hydrating participating groups on connect: ...

Since you’re on systemd user service, those verbose lines are much more likely in stdout/journald than in the file log.

Docs:

If you want, I can help you write the exact systemctl --user edit override to add --verbose just for one repro run.

wanton ember Apr 22, 2026, 8:43 PM

#

Bug #66920 — recurrence after doctor --fix

Hi Krill, following up on the group hydration issue.

We ran openclaw doctor --fix twice today (around 10h UTC and 15h UTC). Both times groups started receiving messages briefly, but then went silent again within a few hours — without any gateway restart in between.

So the fix resolves the symptom temporarily, but groups drop inbound again on their own. DMs continue working normally throughout.

Setup: OpenClaw 2026.4.21, 14 WhatsApp groups, all with requireMention: true, groupPolicy: "allowlist".

Is there a more permanent fix, or is this a known recurrence of #66920? Any workaround that doesn't require running doctor --fix every few hours?

#

Krill?

#Bug: WhatsApp groups stop receiving messages after gateway restart*