WhatsApp group messages not routing to agent — only goes through web-inbound/web-auto-reply | Friends of the Crustacean 🦞🤝 | Page 1

brisk ingot Apr 15, 2026, 7:14 PM

#

OpenClaw 2026.4.14, WhatsApp plugin 2026.4.12

Problem: Group messages are received by the gateway but never routed to the agent session. DMs work fine.

What happens:

Group message arrives → web-inbound picks it up
web-auto-reply processes it
whatsapp/inbound logs it as (group, N chars)
Nothing else — no agent routing, no session created, no "blocked" or "dropped" log
Log example:

web-inbound: from=120363XXXXX@g.us to=+18xxxxxxx5 body="Test message"
web-auto-reply: processMessage (group JID)
whatsapp/inbound: Inbound message 120363XXXXX@g.us -> +18xxxxxxx15 (group, 100 chars)

{
  "channels": {
    "whatsapp": {
      "dmPolicy": "allowlist",
      "allowFrom": ["+1xxxxxxxxx6", "+1xxxxxxxxxxxx3"],
      "groupPolicy": "open",
      "groupAllowFrom": ["+14xxxxxxxxxx6", "+13xxxxxxxxx3"],
      "sendReadReceipts": false,
      "reactionLevel": "off",
      "enabled": true
    }
  },
  "agents": {
    "list": [{
      "id": "main",
      "groupChat": {
        "historyLimit": 50,
        "mentionPatterns": ["@?alf", "\\+?18xxxxxxx5"]
      }
    }]
  }
}

What I've tried:

• groupPolicy: "open" — no change
• groups: { "*": { "requireMention": false } } — no change
• Added agents.list with groupChat.mentionPatterns — no change
• Disabled hooks system — no change
• Disabled custom whatsapp-monitor hook — no change

Gateway also logs: "Listening for personal WhatsApp inbound messages." — not sure if "personal" is significant here.

Any ideas what I'm missing?

fair folioBOT Apr 15, 2026, 7:22 PM

#

I don’t think "Listening for personal WhatsApp inbound messages." is the issue. That line is just the startup banner from the WhatsApp monitor, not a DM-only mode flag.

The more important clue is this:

whatsapp/inbound: Inbound message ... (group, N chars)

In current code, that happens inside processMessage, which is after:

resolveAgentRoute(...)
applyGroupGating(...)

So if you’re seeing that line, this is probably not failing at groupPolicy, groups, or mentionPatterns anymore.

A few concrete notes:

groupPolicy: "open" only affects access control
requireMention is a separate gate, via channels.whatsapp.groups

#

if channels.whatsapp.groups exists anywhere without * or the exact 120363...@g.us, it becomes an allowlist

Given your log sequence, I’d check these next, in this order:

Version skew first
You’re on core 2026.4.14 and WhatsApp plugin 2026.4.12. I’d update the WhatsApp plugin to match core before chasing config further.
Silent resolver path
After whatsapp/inbound, one code path is:
- Skipping auto-reply: silent token or no text/media returned from resolver
That log is verbose-only, so at normal log level it looks exactly like “it just stops”.
Account-specific config shadowing
If you use channels.whatsapp.accounts.<id>, check there isn’t a hidden groups/groupPolicy override on the active account.

I’d grab these next:

#

openclaw status --all
openclaw plugins list --verbose
openclaw plugins doctor

Then reproduce once with debug logging enabled and paste the lines after whatsapp/inbound:

OPENCLAW_LOG_LEVEL=debug ...
or openclaw --log-level debug ...

Docs:

If you paste status --all + the debug snippet after that inbound line, I can narrow this down pretty fast.

brisk ingot Apr 15, 2026, 8:28 PM

#

Core: OpenClaw 2026.4.14
WhatsApp plugin: 2026.4.12 (version skew confirmed — bundled, no npm package available) Diagnostics:

ollama: memory embedding provider already registered: ollama (owner: memory-core). {
"dmPolicy": "allowlist",
"allowFrom": ["+14xxxxxx6", "+13xxxxxxx3"],
"groupPolicy": "open",
"sendReadReceipts": false,
"reactionLevel": "off",
"enabled": true,
"groupAllowFrom": ["+14xxxxx06", "+132xxx323"],
"groups": {
"*": {
"requireMention": false
}
}
}. No channels.whatsapp.accounts block exists — single account only.

Status: LINKED, connected, agent replies generate in transcript but never trigger outbound send. Zero delivery attempts in logs at normal level.

We'll reproduce with OPENCLAW_LOG_LEVEL=debug next and share the lines after whatsapp/inbound. Want us to restart with debug logging now?

fair folioBOT Apr 15, 2026, 8:29 PM

#

Yep, I’d restart with debug now.

You’ve narrowed it down nicely: if the agent reply is showing up in the transcript, the failure is after inbound/routing, in the outbound path, basically dispatchWhatsAppBufferedReply() / deliverWebReply().

Please grab one full reproduction and paste the lines after whatsapp/inbound, especially if you see any of these exact messages:

Reply body: ...
Skipping auto-reply: silent token or no text/media returned from resolver
Suppressed reasoning payload to ...
Sent chunk ...
auto-reply sent (text)
auto-reply sent (media)
failed handling inbound web message
failed to send web media reply

One extra check: WhatsApp outbound intentionally suppresses some payloads, including:

#

tool payloads
compaction notices
reasoning payloads
text that starts with reasoning:

So if the “reply in transcript” is reasoning-only, that would exactly explain “reply exists, zero outbound send attempts”.

If you can, paste 3 things next:

the debug lines after whatsapp/inbound
the first assistant reply text as stored in the transcript
the agent’s model/provider

That should tell us pretty quickly whether this is payload suppression or an actual send-path bug.

brisk ingot Apr 15, 2026, 8:44 PM

#

Core: OpenClaw 2026.4.14
WhatsApp plugin: 2026.4.12 (version skew confirmed — bundled, no npm package available)

Diagnostics:

ollama: memory embedding provider already registered: ollama (owner: memory-core)

{
"dmPolicy": "allowlist",
"allowFrom": ["+14xxxxxx6", "+13xxxxxxx3"],
"groupPolicy": "open",
"sendReadReceipts": false,
"reactionLevel": "off",
"enabled": true,
"groupAllowFrom": ["+14xxxxx06", "+132xxx323"],
"groups": {
"*": {
"requireMention": false
}
}
}

No channels.whatsapp.accounts block exists — single account only.

Status: LINKED, connected, agent replies generate in transcript but never trigger outbound send. Zero delivery attempts in logs at normal level.

We'll reproduce with OPENCLAW_LOG_LEVEL=debug next and share the lines after whatsapp/inbound. Want us to restart with debug logging now?

fair folioBOT Apr 15, 2026, 8:44 PM

#

Yep, please do.

At this point it really looks like an outbound suppression/send-path issue, not inbound routing anymore.

After restart, I’d capture the first WhatsApp debug lines after whatsapp/inbound, especially any of these:

Reply body: ...
Skipping auto-reply: silent token or no text/media returned from resolver
Suppressed reasoning payload to ...
Sent chunk ...
auto-reply sent (text|media)
failed handling inbound web message
failed to send web media reply

If possible, also paste the exact assistant reply text from the transcript, since payloads that are reasoning-only / start with reasoning: can be intentionally suppressed.

That trace should make the next step pretty obvious.

brisk ingot Apr 15, 2026, 8:51 PM

#

No agent run triggered at all. The transcript shows the reply was generated (e.g. "You can't fire me, I'm the Alfred 😎") but the gateway never attempts delivery.

Version skew: WhatsApp plugin 2026.4.12 vs core 2026.4.14. Plugin is bundled — openclaw plugins install @openclaw/whatsapp re-installs from the same bundled copy. No newer version available via npm or clawhub.

Want us to try anything else?

#

missed the first part Debug capture after whatsapp/inbound:

After the whatsapp/inbound line, there is literally nothing. No Skipping auto-reply, no Reply body, no Sent chunk, no failed handling inbound web message, no auto-reply sent. The message just dies silently.

Full sequence (with logging.level: debug):

20:48:41.046 web-inbound: inbound message
20:48:41.061 web-auto-reply: inbound web message
20:48:41.063 whatsapp/inbound: Inbound message 12xxxxxxxx799@g.us -> +18xxxxx15 (group, 117 chars)
... crickets ...
20:49:03 memory-core dreaming cron warning (unrelated)
20:49:06 web-heartbeat (heartbeat, unrelated)

fair folioBOT Apr 15, 2026, 8:52 PM

#

Yep, two good next tests.

Raw outbound send to the same group JID
```
openclaw message send --channel whatsapp --target 120363XXXXX@g.us --message "manual group send test"
```
WhatsApp targets support E.164 or group JID.

That splits the problem cleanly:
- if this fails, it’s a general WhatsApp group outbound problem
- if this works, the bug is specifically in the auto-reply group path before deliverWebReply()
One debug repro
Restart with debug and capture the first lines after whatsapp/inbound, especially:
- Reply body: ...
- Skipping auto-reply: silent token or no text/media returned from resolver
- Suppressed reasoning payload to ...

#

Sent chunk ...
- auto-reply sent (text|media)

Also, the Ollama embedding line looks like unrelated noise.

Since the transcript reply is normal text ("You can't fire me, I'm the Alfred 😎"), this looks less like reasoning suppression and more like a bug in the bundled 2026.4.12 WhatsApp plugin’s group auto-reply path.

If the manual group send works but auto-reply still never reaches Sent chunk / auto-reply sent, I’d call that a bug and file it here with the debug trace:
https://github.com/openclaw/openclaw/issues

If this helps isolate it, please mark the solution after we land it so Answer Overflow picks it up.

#

That’s a really useful clue.

If there’s nothing at all after whatsapp/inbound, then it looks less like a normal “reply suppressed” case and more like the group reply path is getting stuck before delivery logging.

The next thing I’d test is typing/composing.

In the WhatsApp group path, OpenClaw wires reply startup to a WhatsApp sendPresenceUpdate("composing", chatJid) call. If that hangs on a group JID, you can get exactly this pattern: inbound logs, then silence.

Try this temporary config

{
  agents: {
    defaults: {
      typingMode: "never"
    }
  }

#

Then restart and reproduce once.

Also run one manual outbound test to the same group

openclaw message send --channel whatsapp --target 120363XXXXX@g.us --message "manual group send test"

That gives a clean matrix:

manual send fails → general WhatsApp group outbound bug
manual send works, typingMode=never fixes auto-reply → likely composing/typing hang on group replies
manual send works, typingMode=never still broken → likely a real bug in the bundled WhatsApp auto-reply group path

#

At that point I’d open a GitHub issue with:

core version
bundled plugin version
the “dies after whatsapp/inbound” trace
result of typingMode: "never"
result of manual message send to the group JID

Issue tracker: https://github.com/openclaw/openclaw/issues

If you want, paste the result of those 2 tests and I’ll help narrow it one step further.

brisk ingot Apr 15, 2026, 8:55 PM

#

manual message worked

fair folioBOT Apr 15, 2026, 8:55 PM

#

Nice, that narrows it a lot.

If manual message send worked, then:

WhatsApp group outbound itself is fine
the failure is specifically in the group auto-reply path

So the next best test is still:

{
  agents: {
    defaults: {
      typingMode: "never"
    }
  }

#

Then restart and repro once.

How to read that result

works with typingMode: "never"
then the likely culprit is the WhatsApp group composing/typing path hanging before reply delivery
still broken with typingMode: "never"
then I’d call this a real bug in the bundled WhatsApp group auto-reply flow, not your config

At that point I’d file an issue with these exact facts:

core 2026.4.14
bundled WhatsApp plugin 2026.4.12

#

group inbound reaches web-auto-reply + whatsapp/inbound
manual group send works
auto-reply group path dies silently after whatsapp/inbound
no blocked, dropped, Reply body, Sent chunk, or auto-reply sent

Issue tracker: https://github.com/openclaw/openclaw/issues

If you test typingMode: "never", paste that result, that’s probably the last high-signal branch here.

brisk ingot Apr 15, 2026, 9:05 PM

#

Still broken with typingMode: "never". Same exact behavior — inbound arrives, reply shows in control web UI transcript, but zero outbound delivery.

Filing the issue now with the facts:

• Core: 2026.4.14
• Bundled WhatsApp plugin: 2026.4.12
• Group inbound reaches web-auto-reply + whatsapp/inbound
• Manual group send works
• Auto-reply group path dies silently after whatsapp/inbound
• No blocked, dropped, Reply body, Sent chunk, or auto-reply sent in logs
• typingMode: "never" does not fix it

fair folioBOT Apr 15, 2026, 9:05 PM

#

Yep, that sounds like the right move.

At this point I’d treat it as a real bug, not a config miss. The combo of:

manual group send works
agent reply is visible in the Control UI transcript
group auto-reply never emits any outbound delivery log
typingMode: "never" changes nothing

pretty strongly points to a break between reply generation and WhatsApp auto-reply delivery for group sessions.

If you want to make the issue especially maintainer-friendly, I’d include these two extra notes:

the reply is visible in the session/control transcript, so the agent run is completing
the failure seems to be specifically in the WhatsApp group auto-reply delivery hook, not generic group outbound send

And if you have room, paste:

#WhatsApp group messages not routing to agent — only goes through web-inbound/web-auto-reply

Try this temporary config

Also run one manual outbound test to the same group

How to read that result