#Can't send messages to whatsapp from the TUI or from cronjobs

1 messages · Page 1 of 1 (latest)

fathom linden
#

In the TUI I said: "do a manual message send to whatsapp right now. send me "foobar" there."

Got back: "Error: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default."

However, I am actively talking with openclaw in the whatsapp channel right now. I have had a ton of frustration with openclaw security defaults changing and preventing usage patterns that I had been relying on. 😕

bleak mangoBOT
#

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

burnt nacelleBOT
#

That error is coming from the gateway-side WhatsApp socket, not from “permissions”/pairing.

No active WhatsApp Web listener (account: default) specifically means: the Gateway instance your TUI is connected to does not currently have an active WhatsApp Web connection for the WhatsApp account id default. Outbound sends hard-fail in that case (even if some other WhatsApp account is linked, or you’re accidentally talking to a different Gateway/profile).

The two most common causes:

  1. You have multiple gateway profiles/instances (local vs VPS, or --profile differences), and your TUI is connected to the one without WhatsApp linked.
  2. Multi-account WhatsApp config: you’re linked under personal/work etc, but “default account selection” is still trying default.

Quick checks (paste output)

First, version (it matters a lot for channel/account defaults):

openclaw --version

Then (this usually reveals the mismatch immediately):

# 
openclaw gateway status
openclaw channels status --channel whatsapp

If you want one “safe to share” bundle (tokens redacted), this is ideal:

openclaw status --all

What to look for / likely fix

  • If channels status --channel whatsapp shows the linked account is not default (e.g. personal), set the default explicitly:
    {
  channels: {
    whatsapp: {
# 
        defaultAccount: "personal",
      },
    },
  }

(Config reference calls this out: channels.whatsapp.defaultAccount.) Then restart the gateway.

  • If gateway status shows you’re editing one config/state dir but the service is running another (the classic “Config (cli) vs Config (service)” mismatch), you’re effectively operating two different OpenClaw installs/profiles.

Docs for reference:

Drop those three command outputs and I’ll tell you exactly which of the two cases you’re in.

fathom linden
#

openclaw channels status --channel whatsapp
gives: "error: unknown option '--channel'"

...but "openclaw channels status" outputs in part:

  • WhatsApp default: enabled, configured, linked, running, connected, dm:pairing
#

Still there, @burnt nacelle ?

burnt nacelleBOT
#

Yep, I’m here.

To get you unstuck, I need the concrete “which gateway instance is this?” info — because that error only makes sense if the send path is hitting a different gateway/profile than the one that’s actually connected to WhatsApp (or there’s a reproducible bug).

Can you paste these (tokens are redacted in --all)?

openclaw --version
openclaw gateway status
openclaw status --all
openclaw message send --channel whatsapp --target +<your_number> --message "foobar"

If message send also throws “No active WhatsApp Web listener”, it’s almost certainly a profile/service mismatch and gateway status will show it. If it succeeds, then the problem is specific to the TUI/cron send path and we’ll follow logs next.

fathom linden
#

GatewayClientRequestError: Error: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default.

burnt nacelleBOT
#

That stack (GatewayClientRequestError: … No active WhatsApp Web listener) means your send request did reach a Gateway, but that specific Gateway process thinks it has zero active WhatsApp sockets registered for account=default.

If you truly can chat with OpenClaw on WhatsApp “right now”, then you almost certainly have two different gateway instances/profiles in play:

  • one instance that’s actually connected to WhatsApp (the one replying in your WhatsApp chat)
  • another instance that your TUI / cron / openclaw message send is talking to (and that one has no WhatsApp listener)

To confirm which is which, can you paste these outputs (just raw text is fine):

openclaw --version
openclaw gateway status
openclaw channels status

And please include:

  • the WhatsApp … connected line from channels status
#
  • from gateway status, the lines that show Probe target + Config (cli) vs Config (service) (that’s the giveaway for profile/state-dir mismatches)

Also: are you using --profile … anywhere (or OPENCLAW_STATE_DIR / remote mode)? That’s the other usual source of “WhatsApp works here, but sends fail over there”.

Once I see gateway status, I can tell you exactly where the mismatch is (wrong profile, wrong service config, or hitting the wrong gateway URL).

fathom linden
burnt nacelleBOT
#

Yep — that issue matches your symptom exactly.

Issue #48507 is specifically about proactive outbound sends (the message tool path, which cron delivery also uses) failing with:

No active WhatsApp Web listener (account: default)

…even while WhatsApp is linked/connected and auto-replies to inbound messages work (because the auto-reply path uses a different connection reference and doesn’t go through the listeners registry).

So in your case, this isn’t “security defaults” biting you — it’s a real regression/bug in the WhatsApp web outbound plumbing.

Practical impact / what you can do right now

  • Inbound replies: still work (what you’re seeing).
  • Proactive sends (TUI → WhatsApp, cron → WhatsApp): broken until that bug is fixed.

Workarounds (pick one)

  1. Use a different channel for proactive notifications (Telegram/Discord/etc.) temporarily.
  2. Trigger sends via the inbound/auto-reply path (i.e., have WhatsApp receive a message and reply), if that fits your workflow (not great for cron).