#WhatsApp message tool fails with "No active listener" but auto-reply works fine

1 messages · Page 1 of 1 (latest)

fading dove
#

Goal: Send proactive WhatsApp messages using the message tool (action=send, target=+number).

What happens: Every send attempt fails with:
Error: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default.

But: Auto-reply (responding to incoming messages) works perfectly. The agent receives and replies to WhatsApp messages without any issue.

Environment:

  • OpenClaw 2026.3.13 (61d171a)
  • macOS 15.7.3 (arm64), Node 22.22.0
  • WhatsApp channel: linked, running, connected (confirmed via openclaw channels status --probe)
  • Gateway mode: local, bind: loopback
  • Config: allowCrossContextSend: true, sendMessage: true, dmPolicy: open

Logs show:

[tools] message failed: Error: No active WhatsApp Web listener (account: default)

And gateway/delivery-recovery retries also fail with same error.

Meanwhile, the web-auto-reply module delivers replies successfully using deliverWebReply.

What I tried:

  • Gateway restart (openclaw gateway restart)
  • Re-checking credentials (~/.openclaw/credentials/whatsapp/default/)
  • Verifying config (sendMessage: true, allowCrossContextSend: true)
  • All channel probes show OK

It seems like the message tool looks for the WhatsApp listener through a different path than the auto-reply module. Is this a known issue or am I missing a config?

iron remnantBOT
#

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

flint tundraBOT
#

That error is coming from the proactive outbound path, which requires a registered “active WhatsApp Web listener” by account id. The reason auto-reply can still work is that replies are sent via the already-open socket for the inbound message (deliverWebReply), so it can bypass the “active listener registry” lookup that the message tool uses.

In practice there are two common causes:

1) You’re connected on a non-default WhatsApp account id

If you have any multi-account config (even accidentally), proactive sends will try accountId = "default" unless you explicitly tell it otherwise.

Check what WhatsApp account is actually connected:

openclaw channels status --channel whatsapp --json

If the connected account id is e.g. work / biz / personal, then either:

  • pass it explicitly when sending (CLI example):
# 
openclaw message send --channel whatsapp --account work --target +15551234567 --message "test"
  • or set a default in config:
  • channels.whatsapp.defaultAccount: "work" (recommended), or
  • add an actual channels.whatsapp.accounts.default: {} and link that one.

Docs: https://docs.openclaw.ai/channels/whatsapp (see “Multi-account and credentials”)

2) If you truly are on default and it still fails: likely a real bug/regression

Your description (“auto-reply works, proactive send always says no active listener”) matches a class of issues where the listener is alive, but the message tool’s lookup can’t see it.

If (1) is ruled out, I’d open a GitHub issue with:

  • openclaw status --all
  • openclaw channels status --channel whatsapp --json
  • log snippet from gateway startup (“WhatsApp gateway connected…”) + one failed send
#

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

If you paste the channels status --json output here (redact phone numbers if you want), I can tell you immediately whether it’s the account-id/defaultAccount mismatch case.

reef finch
#

Having the same issue too!

flint tundraBOT
#

If a second person is seeing the exact same “No active WhatsApp Web listener (account: default)” while inbound + auto-reply works, you’re almost certainly not missing a config knob — it points to a proactive-send path bug/regression rather than a pairing/linking problem.

A quick way to narrow it down:

1) Verify it’s not just an account-id default mismatch (multi-account)

Run:

openclaw channels status --channel whatsapp --json
  • If you’re connected on an account id not named default (e.g. work, biz), proactive sends will fail unless you either:
  • send with --account work, or
  • set channels.whatsapp.defaultAccount: "work" in config.

(That part is expected behavior per docs: https://docs.openclaw.ai/gateway/configuration-reference#whatsapp)