Bug Description
WhatsApp outbound sends via the message tool fail with:
Error: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default.
Inbound messages and auto-replies work perfectly. Only the message tool outbound path is broken.
Versions Affected
Root Cause
Two separate listeners Map instances exist in the bundle due to a bundling issue:
dist/reply-*.js — contains a new Map() that the message tool reads from via requireActiveWebListener()dist/plugin-sdk/thread-bindings-*.js — contains a separate new Map() that the WhatsApp channel writes to via setActiveWebListener()
The WhatsApp plugin successfully registers its listener in Map #2, but the message tool looks it up in Map #1 — which is always empty.
How to reproduce
# Find the two separate Map instances
grep -rl "new Map" /opt/homebrew/lib/node_modules/openclaw/dist/ | xargs grep -l "Listener\|listener"
On v2026.3.12 this returns two files with separate Maps:
dist/reply-BEN3KNDZ.jsdist/plugin-sdk/thread-bindings-CPgqjJz5.js
On v2026.3.8, the listener registry is shared correctly (single Map instance).
Evidence from Logs
Gateway logs confirm WhatsApp IS fully connected:
[whatsapp] [default] starting provider (+971582031744)
[whatsapp] Listening for personal WhatsApp inbound messages.
[whatsapp] Inbound message +97155812399 -> +971582031744 (direct, 57 chars)
[whatsapp] Auto-replied to +97155812399
But the message tool fails immediately after:
[ws] ⇄ res ✗ send 9ms errorCode=UNAVAILABLE errorMessage=Error: No active WhatsApp Web listener (account: default).
Steps to Reproduce
- Install openclaw v2026.3.12 or v2026.3.13
- Configure WhatsApp channel, link with QR code
- Receive an inbound WhatsApp message — works fine, auto-reply works
- Try to send an outbound message via the
message tool — fails with "No active WhatsApp Web listener"
Workaround
Downgrade to v2026.3.8: npm install -g openclaw@2026.3.8
Environment
- macOS (arm64), Node v25.4.0
- WhatsApp channel with
channels.whatsapp.enabled: true
- Tested with and without
plugins.entries.whatsapp.enabled: true — same result
- Tested with and without
channels.whatsapp.defaultAccount: "default" — same result
- Fresh QR re-link (deleted credentials, re-scanned) — same result
Notes
The v2026.3.13 changelog mentions: "bundle plugin-sdk subpath entries in one shared build pass so published packages stop duplicating shared chunks" — this fix may not have fully resolved the shared state issue, or it introduced a regression that also affects v2026.3.12.
Bug Description
WhatsApp outbound sends via the
messagetool fail with:Inbound messages and auto-replies work perfectly. Only the
messagetool outbound path is broken.Versions Affected
Root Cause
Two separate
listenersMap instances exist in the bundle due to a bundling issue:dist/reply-*.js— contains anew Map()that themessagetool reads from viarequireActiveWebListener()dist/plugin-sdk/thread-bindings-*.js— contains a separatenew Map()that the WhatsApp channel writes to viasetActiveWebListener()The WhatsApp plugin successfully registers its listener in Map #2, but the message tool looks it up in Map #1 — which is always empty.
How to reproduce
On v2026.3.12 this returns two files with separate Maps:
dist/reply-BEN3KNDZ.jsdist/plugin-sdk/thread-bindings-CPgqjJz5.jsOn v2026.3.8, the listener registry is shared correctly (single Map instance).
Evidence from Logs
Gateway logs confirm WhatsApp IS fully connected:
But the message tool fails immediately after:
Steps to Reproduce
messagetool — fails with "No active WhatsApp Web listener"Workaround
Downgrade to v2026.3.8:
npm install -g openclaw@2026.3.8Environment
channels.whatsapp.enabled: trueplugins.entries.whatsapp.enabled: true— same resultchannels.whatsapp.defaultAccount: "default"— same resultNotes
The v2026.3.13 changelog mentions: "bundle plugin-sdk subpath entries in one shared build pass so published packages stop duplicating shared chunks" — this fix may not have fully resolved the shared state issue, or it introduced a regression that also affects v2026.3.12.