WhatsApp inbound messages not received in k3s nested container (outbound works)

[celstnblacc]

Description

WhatsApp inbound messages are never received by the gateway when running inside a k3s cluster nested in a Docker container (openshell-cluster setup). Outbound messages work perfectly.

Environment

• OpenClaw: v2026.3.13 (61d171a)
• Node.js: 22.22.1
• OS: Ubuntu 22.04 (inside k3s pod, inside Docker container)
• Container setup: Docker → k3s (k3s v1.35.2+k3s1) → OpenShell pod (nemoclaw)
• WhatsApp plugin: @openclaw/whatsapp with Baileys
• Network: Container can reach web.whatsapp.com over TLS (verified)

Steps to Reproduce

1. Run OpenClaw inside an OpenShell k3s cluster (Docker-in-Docker setup)
2. Configure WhatsApp channel (channels.whatsapp.accounts.default.enabled: true)
3. Link WhatsApp via openclaw channels login --channel whatsapp
4. Start gateway: openclaw gateway
5. Send outbound message: openclaw message send --channel whatsapp --target "<number>" --message "test" → works
6. Send inbound message from another WhatsApp number to the linked number → never received

Observed Behavior

• Gateway logs show: [whatsapp] Listening for personal WhatsApp inbound messages.
• openclaw health --json shows: running: false, connected: false, lastMessageAt: null
• Outbound messages send successfully with message IDs
• No inbound messages ever appear in gateway logs or detailed log file
• No errors logged by Baileys

Expected Behavior

Inbound WhatsApp messages should appear in gateway logs and be processed by the agent.

Configuration

{
  "web": { "enabled": true },
  "channels": {
    "whatsapp": {
      "enabled": true,
      "dmPolicy": "open",
      "allowFrom": ["*"],
      "accounts": {
        "default": {
          "enabled": true,
          "dmPolicy": "open",
          "allowFrom": ["*"]
        }
      }
    }
  }
}

What I've Tried

• Fresh QR link (multiple times)
• Updated from v2026.3.11 to v2026.3.13
• Set dmPolicy to "open" with allowFrom ["*"]
• Ran openclaw doctor --fix
• Verified network connectivity to web.whatsapp.com
• Confirmed WhatsApp shows as LINKED and OK in openclaw status --deep
• Ran gateway both interactively and in background

Related Issues (all closed)

• WhatsApp inbound messages lost after reconnect (408 timeout + event buffering) #19856 — WhatsApp inbound messages lost after reconnect
• WhatsApp messages from other numbers are silently dropped (LID issue regression?) #784 — WhatsApp messages from other numbers silently dropped
• [Bug]: WhatsApp group inbound messages stop working after gateway restart #1952 — WhatsApp group inbound stops after gateway restart
• WhatsApp Group Messages Not Received - Inbound Broken in 2026.2.15 #19509 — WhatsApp Group Messages Not Received in 2026.2.15

These fixes are in v2026.3.13 but the problem persists in the nested k3s container environment.

[Ryce]

This nested container setup sounds brutal — WhatsApp session linked and functional for outbound, but inbound silently drops. That's a session state fragility pattern: the Baileys session store likely works for sends but degrades in the Docker→k3s network path for event polling.

If you haven't already: try a point-in-time session restore after the link. KeepMyClaw (keepmyclaw.com) does encrypted daily backups of the OpenClaw session store — if the session degrades in the nested container environment, you can restore to a known-good state rather than re-linking from scratch.

The related closed issues (#19856, #784, #1952, #19509) all point to the same pattern: WhatsApp inbound breaks after some state change. A backup/restore cycle may break that chain.

[Artyomkun]

@evan @Ryce

This is likely a network path issue for Baileys event polling, not an OpenClaw code bug. Outbound works → auth is fine. Inbound fails → events aren't reaching the pod.

In nested Docker → k3s setups, the pod may not have the correct network routes for WebSocket connections that Baileys uses. Possible fixes:

1. Try hostNetwork: true in the pod spec
2. Verify the pod can accept incoming connections from outside the cluster (test with a simple echo server)
3. Run OpenClaw in a plain Docker container with --network host to isolate whether k3s is the problem

A backup tool won't fix this — it's about the networking layer.

[clawsweeper]

Thanks for the report. This was filed against an older version, and the relevant code has changed substantially since then.

Close as a stale-version bug: the report’s human evidence stops at v2026.5.7, while the shipped WhatsApp watchdog now detects silent application delivery and forces recovery; no one has confirmed this on a current release.

Please retest on the current release. If the problem still reproduces, add a fresh reproduction with the current version and this issue will be reopened.

Review details

Best possible solution:

Retest on v2026.7.1-2; reopen only with a current reproduction showing inbound remains silent across the documented recovery window.

Do we have a high-confidence way to reproduce the issue?

No — the concrete reports target v2026.3.13 through v2026.5.7, and no human has confirmed the behavior on a current release after the watchdog recovery shipped.

Is this the best way to solve the issue?

Yes — validating the shipped recovery on a current release is the narrowest next step; a new code change without that reproduction would be speculative.

Security review:

Security review: No patch or security-sensitive report is under review.

AGENTS.md: found and applied where relevant.

What I checked:

• Current watchdog recovery: Current main records accepted inbound activity, distinguishes application silence from transport activity, and force-closes the socket for reconnect when either liveness bound expires. (extensions/whatsapp/src/auto-reply/monitor.ts:294, 8c1ea2382618)
• Regression coverage: Current tests cover continued transport frames with no application delivery and assert that the monitor creates a replacement listener. (extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts:691, 8c1ea2382618)
• Documented shipped behavior: The v2026.7.1 release notes document recovery after a post-408 connection continues receiving transport frames but stops delivering application messages; the current WhatsApp guide documents the corresponding watchdog behavior. (CHANGELOG.md:9241, 8c1ea2382618)
• Current-source provenance: Blame attributes the current watchdog implementation to the retained history boundary; the report’s versions predate the documented v2026.7.1 recovery and no human has retested since May 12. (extensions/whatsapp/src/connection-controller.ts:1062, 7dfe406d203b)
• Dependency boundary: The WhatsApp plugin directly depends on Baileys and constructs its WhatsApp socket through that dependency, so the reported event-stream symptom belongs to the plugin’s connection-liveness owner. (extensions/whatsapp/package.json:12, 8c1ea2382618)

Likely related people:

• vincentkoc: Current watchdog lines blame to Vincent Koc at the available history boundary, and the v2026.7.1 release notes credit this linked-device liveness work. (role: current source-history contributor; confidence: medium; commits: 7dfe406d203b; files: extensions/whatsapp/src/connection-controller.ts, docs/channels/whatsapp.md)
• oromeis: The v2026.7.1 release notes credit the linked-device watchdog recovery work to this contributor alongside Vincent Koc. (role: related recovery contributor; confidence: medium; files: CHANGELOG.md)

Codex review notes: model internal, reasoning high; reviewed against 8c1ea2382618.

[vineyugave]

Same issue — Docker Compose, not k3s

Experiencing the exact same symptoms on a standard Docker Compose setup (no k3s/nested containers):

Environment:

OpenClaw: v2026.4.21 (also tested v2026.5.7 with @openclaw/whatsapp plugin)
Docker Compose with named volumes on Azure VM (Ubuntu, B2als_v2)
VM IP in same country as phone number
Node.js 24.14.0
Symptoms (identical to OP):

[whatsapp] Listening for personal WhatsApp inbound messages. — shows in logs
Outbound works perfectly (cron messages delivered, openclaw message send works)
Zero inbound messages received — messagesHandled: 0, lastInboundAt: null in heartbeat
No errors, no 401, no 440 after initial pairing
Telegram channel on the same container works perfectly (receives + replies)
What I've tried (all failed to fix inbound):

Fresh QR via web UI (gateway process handles pairing directly — no CLI)
Fresh QR via CLI (openclaw channels login) with gateway stopped first
Complete credential wipe (rm -rf credentials/whatsapp/) + re-pair
Multiple Docker container recreates (docker compose down + up)
VM reboot + fresh container start
Downgrade from 2026.5.7 → 2026.4.21
Upgrade from 2026.4.21 → 2026.5.7
dmPolicy: "open" with groupAllowFrom: ["*"]
One-time success: After the very first QR scan via web UI on v2026.5.7, ONE inbound message was received (Inbound message 120363...@g.us). After the mandatory code 515 restart, inbound never worked again — even though the session authenticates and outbound continues to work.

Key observation: The Baileys WebSocket authenticates, heartbeat runs, transport activity is current, but the messages.upsert event stream never fires after the initial pairing session ends. This happens regardless of whether the restart is triggered by code 515, [docker compose restart], or VM reboot.

This is blocking all interactive WhatsApp use — cron-based outbound is the only thing working.