Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix WhatsApp message tool returns 'No active Web listener' while session replies work fine [3 comments, 4 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#49970•Fetched 2026-04-08 01:00:44
View on GitHub
Comments
3
Participants
4
Timeline
5
Reactions
0
Author
bobbyt74bobbyt74
Participants
bobbyt74bobbyt74DarkReitorDarkReitorhuntharohuntharoRyceRyce
Timeline (top)
commented ×3closed ×1locked ×1

Error Message

Error: No active WhatsApp Web listener (account: default)

Root Cause

Root cause hypothesis

Code Example

Error: No active WhatsApp Web listener (account: default)

---

[whatsapp] Web connection closed (status 440: session conflict)
[whatsapp] [default] auto-restart attempt 1/10 in 5s
[whatsapp] [default] starting provider (+14159351126)
[whatsapp] Listening for personal WhatsApp inbound messages.
# ^^^ looks healthy, but then:
[tools] message failed: Error: No active WhatsApp Web listener (account: default)
# Meanwhile auto-replies work:
[whatsapp] Auto-replied to +972544816020
RAW_BUFFERClick to expand / collapse

Bug

After a WhatsApp session conflict (status 440), the message tool permanently fails with:

Error: No active WhatsApp Web listener (account: default)

But at the same time:

  • ✅ Inbound messages arrive normally
  • ✅ Session auto-replies work ([whatsapp] Auto-replied to +972544816020)
  • ✅ openclaw channels login reports "✅ Linked"
  • ✅ Credentials are valid and fresh
  • ❌ message tool with action: send fails

Root cause hypothesis

The message tool checks for a "Web listener" component that is separate from the Baileys socket used by the session handler. After a 440 session conflict + auto-restart, the Baileys connection recovers (inbound + replies work) but the "Web listener" flag/reference that the message tool checks never gets re-initialized.

Steps to reproduce

  1. Have WhatsApp connected and working
  2. Run openclaw channels login --channel whatsapp from two places simultaneously (causes session conflict 440 in logs)
  3. Gateway auto-restarts WhatsApp provider
  4. Inbound + session replies work
  5. message tool with action: send fails with "No active WhatsApp Web listener"
  6. Full credential wipe + relink does NOT fix it

Remediation attempts (all failed)

  • openclaw channels login (multiple times) — reports "Linked" but send still fails
  • Gateway restart via SIGUSR1
  • Gateway restart via systemctl --user restart openclaw-gateway
  • Clearing all session state files (keeping creds.json)
  • Full credential wipe + fresh relink with new pairing code
  • npm install -g openclaw@latest --force (538 packages changed)
  • Multiple combinations of the above

Relevant logs

[whatsapp] Web connection closed (status 440: session conflict)
[whatsapp] [default] auto-restart attempt 1/10 in 5s
[whatsapp] [default] starting provider (+14159351126)
[whatsapp] Listening for personal WhatsApp inbound messages.
# ^^^ looks healthy, but then:
[tools] message failed: Error: No active WhatsApp Web listener (account: default)
# Meanwhile auto-replies work:
[whatsapp] Auto-replied to +972544816020

Environment

  • OpenClaw 2026.3.13 (61d171a)
  • Linux 5.15.0-170-generic (x64), node 22.22.0
  • WhatsApp via Baileys (multi-device)
  • Channel: whatsapp, account: default

Expected behavior

The message tool should use the same connection path that session auto-replies use, or the "Web listener" should be re-initialized after provider recovery.

extent analysis

Fix Plan

To resolve the issue, we need to re-initialize the "Web listener" flag/reference after a WhatsApp session conflict and auto-restart.

Here are the steps:

  • Modify the message tool to use the same connection path as session auto-replies.
  • Re-initialize the "Web listener" flag/reference after provider recovery.

Example code snippet to re-initialize the "Web listener" flag/reference:

// After provider recovery
if (providerRecovery) {
  // Re-initialize the Web listener flag/reference
  webListenerInitialized = true;
  // Restart the Web listener
  startWebListener();
}

// In the message tool
if (webListenerInitialized) {
  // Use the Web listener for sending messages
  sendMessagesViaWebListener();
} else {
  // Use the Baileys connection for sending messages
  sendMessagesViaBaileys();
}

Verification

To verify that the fix worked:

  • Run the message tool with action: send after a WhatsApp session conflict and auto-restart.
  • Check if the message is sent successfully.
  • Verify that the "Web listener" flag/reference is re-initialized after provider recovery.

Extra Tips

  • Make sure to handle errors and exceptions properly when re-initializing the "Web listener" flag/reference.
  • Consider adding logging to track the state of the "Web listener" flag/reference for debugging purposes.
  • Review the OpenClaw documentation and Baileys library documentation for any updates or changes related to WhatsApp Web listeners and session conflicts.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The message tool should use the same connection path that session auto-replies use, or the "Web listener" should be re-initialized after provider recovery.

#api#ssr#installation#tensor shape#autograd error#cache error#pipeline error#runtime error#dependency conflict#environment setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING