Open claw not responding in What’s app groups

[austere fog]

Hey guys,

Just a follow up.

WhatsApp group messages not received — registered: false persists across all re-links

Setup: OpenClaw 2026.4.26, macOS, WhatsApp companion device (primary phone + Mac Mini linked device). Was working fine until a gateway restart loop caused ~20 rapid reconnections overnight.

Symptom: DMs work perfectly. Zero group messages received. Messages don't arrive at the Baileys layer at all — not filtered, just never delivered by WhatsApp's servers.

creds.json: registered: false after every re-link attempt. Manually patching to true doesn't fix delivery.

What we've tried:

• Full credential wipe (creds.json + creds.json.bak) + fresh login ×3
• Upgrade 2026.4.23 → 2026.4.26, downgrade back, upgrade again
• openclaw configure from scratch
• Remove/re-add Alfred's number from groups
• App-state-sync key deletion
• Stopped watchdog during re-link to prevent interference
• Phone kept open during sync
• Manually set registered: true in creds.json
• Device IDs progressed :8 → :9 → :10 → :11 across attempts

Key finding: Group messages are not arriving at the Baileys WebSocket layer at all. WhatsApp's servers appear to not be routing group events to this companion device regardless of re-link attempts.

Question: Is registered: false persisting a known bug in 2026.4.26? Is there a way to force the registration handshake to complete, or is this a WhatsApp server-side rate limit that needs time to clear?

[eager owl]

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

[elfin pecan]

Exec approval is required, but no interactive approval client is currently available.

Approve it from the Web UI or terminal UI, or enable a native chat approval client such as Discord. If those accounts already know your owner ID via allowFrom or owner config, OpenClaw can often infer approvers automatically. Then retry the command. You can usually leave execApprovals.approvers unset when owner config already identifies the approvers.

Exec approval is required, but no interactive approval client is currently available.

Approve it from the Web UI or terminal UI, or enable a native chat approval client such as Discord. If those accounts already know your owner ID via allowFrom or owner config, OpenClaw can often infer approvers automatically. Then retry the command. You can usually leave execApprovals.approvers unset when owner config already identifies the approvers.

Automatic session resume failed, so sending the status directly.

Exec denied (gateway id=0b3cd523-7a5f-4f30-b88d-1a3d939e6302, approval-timeout (allowlist-miss)): if [ -d "$HOME/openclaw-ref/.git" ]; then cd "$HOME/openclaw-ref" && git pull --ff-only --stat; else git clone https://github.com/openclaw/openclaw "$HOME/openclaw-ref"; fi

Automatic session resume failed, so sending the status directly.

Exec denied (gateway id=9fee324e-a881-4024-b92a-42519ed5ff72, approval-timeout (allowlist-miss)): find /home/krill -maxdepth 3 -type d ( -name .git -o -name openclaw-ref ) 2>/dev/null | head -50

Hmm — I’d not chase registered: false as the primary signal here. If DMs work and status says linked/connected, the WhatsApp session is functioning; manually flipping that field won’t complete a missing handshake.

The known “DMs work, groups look invisible / no web-inbound log” case is usually config gating, not WhatsApp server routing:

• channels.whatsapp.groups = group JID allowlist
• channels.whatsapp.groupPolicy + groupAllowFrom = sender allowlist, so groupAllowFrom should be phone numbers/E.164, not [e-mail]
• group replies require mention by default unless requireMention: false / activation always is set (docs.openclaw.ai)

Try the safe targeted shape:

openclaw config set channels.whatsapp.groupPolicy allowlist
openclaw config set channels.whatsapp.accounts.default.groupPolicy allowlist

openclaw config set 'channels.whatsapp.groupAllowFrom' '["[phone]"]'
openclaw config set '[e-mail]' false

openclaw gateway restart

Replace [phone] with the human sender number(s) allowed to trigger OpenClaw, and replace the [e-mail] key with the actual group JID.

Important bit: “no inbound log” can happen because access control rejects before the normal inbound log is emitted, so it can look like Baileys/WhatsApp never delivered it even when OpenClaw saw and dropped it. Current issue review explicitly called out that exact confusion. (api.github.com)

If that config is already exactly right and you’ve truly instrumented below OpenClaw at raw Baileys socket level with zero group frames, then I’d stop re-linking for a while and file a GitHub issue with the raw logs + config redacted. Repeated rapid re-links may make WhatsApp grumpier, and there isn’t an OpenClaw-side “force registration handshake” knob I’d trust here.

The repo refresh command didn’t run — it timed out at approval because it was an allowlist miss.

I already answered using the current public issue/docs context, though. The important correction remains: don’t use the group JID in groupAllowFrom; use channels.whatsapp.groups.<groupJid> for the group, and groupAllowFrom for allowed sender phone numbers. Also set requireMention: false for WhatsApp groups if you expect normal group messages to trigger replies.

That second local lookup also didn’t run — same issue: approval timed out on an allowlist miss.

No further action needed from the user unless we want to locally inspect the checkout later. For this support thread, the useful answer is already grounded from the GitHub issue/docs context: this likely isn’t registered: false; it’s WhatsApp group admission/sender gating config, plus mention gating.

[austere fog]

---

Update + follow-up — WhatsApp groups still not receiving

Thanks for the earlier advice — confirmed the config was wrong and have now fixed it exactly as you prescribed:

• groupAllowFrom now contains sender phone numbers (Dave, Sophie, Lisa) — group JIDs removed
• Both group JIDs have requireMention: false set under channels.whatsapp.groups
• groupPolicy: allowlist
• Config hot-reloaded + full gateway restart after changes

Still no group messages arriving after the fix. DMs continue to work fine.

What we think happened: A previous troubleshooting session this morning changed groupPolicy from what it was originally, which activated the groupAllowFrom check against incorrectly configured group JIDs. That config error was masking the real state all day.

Current state:

• Config is now correct per your recommendation
• WhatsApp session: linked, running, connected
• registered: false in creds.json (noted as red herring per your advice)
• 11+ re-link attempts were made before the config issue was identified — concerned WhatsApp may have server-side rate limited this device from group delivery as a result

Question: With the config now correct, is this likely to self-resolve once the session stabilises overnight? Or given the volume of re-links today, is there anything else we should do — or just wait it out?

[elfin pecan]

I wouldn’t keep re-linking now — that’s the one thing I’d stop doing.

Before waiting overnight, I’d check one last config gotcha: account-level overrides. If channels.whatsapp.accounts.default.* exists, it can override the channel-level values. So make sure the same sender policy is correct there too, or remove stale account-level WhatsApp policy keys.

For a quick isolation test, temporarily set:

openclaw config set channels.whatsapp.groupPolicy open
openclaw config set channels.whatsapp.accounts.default.groupPolicy open
openclaw gateway restart

Keep channels.whatsapp.groups.<groupJid>.requireMention=false in place. If group messages suddenly work, the issue is still groupAllowFrom / sender normalization, not WhatsApp delivery. Then switch back to allowlist and fix the sender list at both levels.

If it still doesn’t work with groupPolicy: open, then yeah: stop touching credentials and let the linked device sit stable for 12–24h. With 11+ re-links and a restart loop, WhatsApp server-side companion weirdness/rate-limiting is plausible, but not something OpenClaw can force-complete.

Docs for the two-layer group model are here: https://docs.openclaw.ai/channels/whatsapp

[austere fog]

---

Further update — tested open policy, still no group messages

Followed your advice exactly:

1. Confirmed no channels.whatsapp.accounts.default.* overrides exist
2. Set groupPolicy: open + full gateway restart
3. Sent test messages to the group immediately after restart

Still zero group messages arriving — not even with open policy bypassing all sender gating. DMs continue to work perfectly.

This confirms it's not a config/allowlist issue. Group messages simply aren't reaching OpenClaw at the Baileys layer at all.

So as you predicted — 11+ re-links today has likely triggered WhatsApp server-side companion device rate limiting/weirdness. Config is now correct (reverted to allowlist with proper phone numbers in groupAllowFrom), session is stable, no more re-links.

Planning to leave it untouched for 12–24 hours and check tomorrow morning.

Question: Is there anything else worth trying before the wait? Or is stable + time the only path from here? And roughly how long does WhatsApp server-side companion recovery typically take in your experience?

---

[elfin pecan]

I’d do one last non-invasive config sanity check, then wait.

Because channels.whatsapp.groups is also the group JID allowlist, verify the actual stored JSON shape:

openclaw config get channels.whatsapp.groups

You want literal keys like:

{
  "[e-mail]": { "requireMention": false }
}

Not a accidentally nested shape caused by the .g.us in the key.

If that looks good, then yes: stop touching it and let the companion session settle. Don’t re-link, don’t wipe creds, don’t restart-loop it. I don’t know of any OpenClaw-side “force group delivery handshake” knob.

Recovery timing: WhatsApp doesn’t publish anything reliable here, so any number is anecdotal — I’d expect 12–24h, and I’d give it up to 48h before doing another clean unlink/relink attempt. If it’s still broken after 48h with correct config + stable session, that’s worth a GitHub issue with redacted openclaw status --all, WhatsApp config, and logs.

Docs reference: https://docs.openclaw.ai/channels/whatsapp

[austere fog]

---

Final config check done — all clear, waiting it out

Ran the JSON shape check on channels.whatsapp.groups:

{
  "*": { "requireMention": true },
  "[e-mail]": { "requireMention": false },
  "[e-mail]": { "requireMention": false }
}

Literal JID keys, correct shape, no nesting issue.

Full config state confirmed:

• groupPolicy: allowlist
• groupAllowFrom: sender phone numbers only (3 team members)
• groups: both group JIDs with requireMention: false
• No accounts.default.* overrides

Session is stable, no more re-links, no restarts. Leaving it for 12–48h as you suggested.

Thanks for the guidance — hugely helpful in narrowing this down. Will update here if it comes back or if still broken at 48h.

---

[elfin pecan]

Nice, that shape looks right. 👍

At this point I’d leave it completely still — no re-link, no credential edits, no restart loop. If DMs stay healthy and groups start flowing again, that strongly points to WhatsApp companion/session recovery rather than OpenClaw config.

If it’s still dead after ~48h, file a GitHub issue with:

• openclaw --version
• openclaw status --all redacted
• redacted WhatsApp config
• logs around startup + a group test message timestamp
• note that groupPolicy: open was tested and still produced no group inbound

Glad we narrowed the config side down. 🦐

[austere fog]

---

Critical update — diagnosis confirmed

We've identified the exact issue. Alfred's physical phone [phone]) IS receiving group messages normally — they land on the phone's WhatsApp inbox as expected, and we can even reply from the phone and messages go through.

The problem is exclusively that OpenClaw's Baileys companion session on the Mac Mini is not syncing group messages from the primary phone. DMs work fine in both directions. Config is correct (verified groupAllowFrom, requireMention, group JIDs all confirmed correct shape).

This is a Baileys companion sync bug — registered: false persists in creds.json despite multiple re-links and a full credential wipe. Our current theory is the companion registration handshake isn't completing, which causes group message forwarding from the primary device to the companion to fail silently.

Currently investigating the compiled plugin code to see if there's a patchable fix. Will report back.

Is there any known issue in 2026.4.26 with companion device group sync specifically? Or any way to manually trigger/force the registration handshake completion from the Mac Mini side ?

[elfin pecan]

Yep — this is now much closer to a known WhatsApp Web/Baileys group bootstrap / reconnect problem, not config.

There was a very similar report: DMs arrive, group messages never fire messages.upsert, and the fix was PR #58007 “WhatsApp: hydrate participating groups on connect”. That added a sock.groupFetchAllParticipating() call after connect:
https://github.com/openclaw/openclaw/pull/58007

So for 2026.4.26 specifically:

• registered: false is still probably a red herring for QR-linked Baileys sessions.
• There is no supported CLI/config knob to “force the registration handshake.”
• The closest “force group bootstrap” mechanism is exactly groupFetchAllParticipating() after socket connect.
• If 2026.4.26 has that call and groups still don’t arrive, this looks related to the open 2026.4.26 regression report:
  https://github.com/openclaw/openclaw/issues/73914

One useful thing to check while you’re in compiled plugin code/logs: do you see a log like “Hydrated N participating groups on connect” or the groupFetchAllParticipating() call in the installed WhatsApp plugin? If it’s missing, your installed package may not include #58007 correctly. If it’s present and succeeds but still no group inbound, please add this repro to #73914 or file a fresh issue with the exact evidence.

I’d avoid random compiled patches beyond that. If you do test a patch, the targeted one is: call sock.groupFetchAllParticipating() once after the socket opens, before/around presence setup. But as a durable fix, this should be handled upstream, not locally edited dist.

They reported macOS on a Mac Mini. The latest issue-style details say OpenClaw 2026.4.26 on macOS, companion WhatsApp device, primary phone + Mac Mini linked device.

[austere fog]

Hey @outer brook

macOS, haha I’ve been trying to fix this all day. It’s really effected my business 😓

[elfin pecan]

Oof, that’s rough — especially if it’s business-facing 😓

Given the config is now ruled out, I’d treat this as a 2026.4.26 WhatsApp Web/Baileys regression and stop burning time on re-link attempts.

Most useful next move: add your findings to the open 2026.4.26 issue here: https://github.com/openclaw/openclaw/issues/73914

Include:

• macOS + Mac Mini
• OpenClaw 2026.4.26
• DMs work, groups don’t
• groupPolicy: open test still failed
• channels.whatsapp.groups shape verified
• registered: false persists but manually changing it doesn’t help
• whether installed plugin code contains groupFetchAllParticipating()

For the business side: I’d set up a temporary fallback path if you can, rather than waiting on this one session to recover. Don’t keep re-linking — that’s likely making WhatsApp companion state worse, not better.

Not fully yet. Current status is:

• Config issue was found and fixed.
• DMs still work.
• WhatsApp groups still don’t arrive even with groupPolicy: open.
• So it looks like a WhatsApp Web/Baileys companion sync regression on 2026.4.26, not user config.

Best next step is to stop re-linking/restarting, preserve logs, and add the findings to the open issue: https://github.com/openclaw/openclaw/issues/73914

[austere fog]

Nope. Stuck

[elfin pecan]

Yeah, that sucks. At this point I’d call it blocked on the WhatsApp Web/Baileys side, not something you can fix with more config.

If you want one concrete thing before giving up for now: check whether your installed WhatsApp plugin actually contains the groupFetchAllParticipating() hydration call from PR #58007. If it doesn’t, that’s the likely missing fix. If it does, then your case belongs on the open 2026.4.26 regression issue.

For business continuity, I’d stop trying to rescue this session today and use a temporary fallback path:

• keep WhatsApp DMs only if those work
• move group workflow to another channel temporarily
• or use a fresh/dedicated WhatsApp number/device if available

I know that’s not the satisfying answer, but repeated relinks are probably making the companion state worse, not better.

[austere fog]

Are you offical support @outer brook

Sorry man, can’t see any offical role on your account.

Yes — Krill said:

Hey Krill — thanks for the direction. Confirmed everything you asked:

• groupFetchAllParticipating() ✅ present in installed plugin
• No "failed hydrating" error in logs — runs without throwing
• registered: false through all re-links, manual patch doesn't help
• Zero group messages all day, messages.upsert never fires
• DMs working perfectly

Stopping re-links as you suggested, and will file on #73914.

You mentioned a targeted patch — calling sock.groupFetchAllParticipating() after socket opens. Given groups are our primary business comms channel, we'd like to try it. Can you point us to exactly where in the compiled plugin to add that call? We can identify the relevant file (monitor-BifLJ1dl.js / monitor-CDmWxvsU.js) — just need to know the precise insertion point.

───

[elfin pecan]

If groupFetchAllParticipating() is already present and running without throwing, then the exact #58007 patch is already in your installed plugin — adding the same call in the same place probably won’t change anything.

For reference, the source-level insertion point from #58007 is:

• file: extensions/whatsapp/src/inbound/monitor.ts
• function: monitorWebInbox(...)
• immediately after the socket connection listener is attached
• immediately before createWebSendApi({ ... })

Source PR: https://github.com/openclaw/openclaw/pull/58007

In compiled JS, the anchor is usually: search for createWebSendApi(, then look just above it for the connection.update / handleConnectionUpdate listener setup. That’s where the existing async hydration block belongs.

But I’d be careful: since you confirmed the call exists and doesn’t fail, I don’t think a compiled edit is the right next fix. The stronger evidence is for the 2026.4.26 reconnect/inbound regression: https://github.com/openclaw/openclaw/issues/73914. For business-critical use, I’d either roll back to the last known working OpenClaw version with the now-correct config, or use a temporary fallback channel/number rather than hot-patching bundled dist files.

[austere fog]

Hey Krill — update: rolled back to 2026.4.23 and groups are working immediately. Confirmed the regression is 2026.4.26 specific — messages.upsert simply never fires for groups on that version regardless of config, credentials, or re-linking. Filing on #73914 with this confirmation. Thanks for the steer — saved us from a bad compiled patch.