WhatsApp: heartbeat/alerts leak into user DMs (sendPolicy bypass) + pairing issues

[rare moon]

Hi OpenClaw team,
I’m running into a WhatsApp issue where internal heartbeat/alert messages are being sent into WhatsApp direct messages, despite outbound being disabled/denied at the config level.

Environment
• OpenClaw version: 2026.2.6-3
• OS: macOS 26 (arm64)
• Channel: WhatsApp Web
• Gateway: local loopback

Issue A - Internal alerts leaking into WhatsApp DMs (security)
This is on WhatsApp Web with loopback gateway.

A system-generated alert (e.g., “WhatsApp gateway disconnected … status=499”) appears as an outgoing WhatsApp message in a DM thread. Internal health/heartbeat alerts should never be delivered to end-user WhatsApp conversations. It looks like an internal path (web-heartbeat -> web-outbound).

[wet marlin]

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

[rare moon]

Issue B - sendPolicy deny / channel actions disabled do not fully block this path
Config intent:
• session.sendPolicy denies any outbound to channel=whatsapp
• channels.whatsapp.actions.sendMessage=false
Observed: outbound WhatsApp messages still occur from an internal module/path (heartbeat/outbound), seemingly bypassing session.sendPolicy.

Possible contributing factor - config divergence / legacy config
Two config files diverge:
• ~/.openclaw/openclaw.json had heartbeat alerts disabled
• ~/.openclaw/clawdbot.json (legacy) had heartbeat alerts enabled
Runtime may still read/merge legacy config, which can re-enable WhatsApp heartbeat alerts.

Repro steps (approx)
1. Enable WhatsApp Web channel
2. Trigger connection instability (disconnect/reconnect / status 499)
3. Observe whether the gateway/heartbeat produces a WhatsApp DM outbound message containing an internal alert

Impact
• High severity: internal operational messages can leak to real WhatsApp contacts.
• Hard to guarantee “no outbound WhatsApp” even with sendPolicy deny + actions disabled.

Also: WhatsApp pairing/login via Dashboard seems unreliable/broken on my side (can share steps).

I can share sanitized log snippets showing correlation IDs and module names (no personal identifiers).

Thanks!

[untold pagoda]

This can happen today depending on how your heartbeat + session routing is set up — and it can definitely look like “internal alerts leaking into a random WhatsApp DM”.

Two key bits from the docs:

1. Agent heartbeat delivery defaults to target: "last"
   So heartbeat alerts get delivered to “the last used external channel” for that session. If that session is currently “bound” to a WhatsApp DM, the heartbeat alert will show up as an outgoing WhatsApp message.
   Docs: https://docs.openclaw.ai/gateway/heartbeat (see target: last|none|<channel> + visibility controls)

2. By default, DMs collapse into one “main” DM session (session.dmScope: "main")
   That’s convenient for a single-user setup, but in a multi-user inbox it means “last external channel” can effectively become “whoever DM’d most recently”.
   Docs: https://docs.openclaw.ai/gateway/configuration (see session.dmScope)

Immediate mitigation (stop any heartbeat/alert delivery into WhatsApp)

Pick one:

A) Don’t deliver heartbeat output externally at all

{
  agents: {
    defaults: {
      heartbeat: { target: "none" }
      // or every: "0m" to disable heartbeats entirely
    }
  }
}

B) Suppress heartbeat alerts specifically for WhatsApp

channels:
  whatsapp:
    heartbeat:

      showAlerts: false

(That keeps heartbeats running but prevents “alert” text from being sent on WhatsApp.)
Docs: https://docs.openclaw.ai/gateway/heartbeat#visibility-controls

Structural fix (prevents cross-DM “last channel” weirdness)

If more than one person can DM this bot, switch to isolated DM sessions:

{
  session: {
    dmScope: "per-channel-peer"
  }
}

Docs: https://docs.openclaw.ai/gateway/configuration (session.dmScope)

About “outbound disabled/denied”

There are a couple different “policies” people mean by that. The one that governs whether session replies are allowed to be sent back out is:

session: {
  sendPolicy: {
    rules: [{ action: "deny", match: { channel: "whatsapp", chatType: "direct" } }],
    default: "allow"
  }
}

Docs: https://docs.openclaw.ai/gateway/configuration (session.sendPolicy)

To confirm whether this is heartbeat delivery vs a true send-policy bypass

Can you paste:

1. the relevant bits of your config for agents.defaults.heartbeat, channels.whatsapp.heartbeat (if any), session.dmScope, session.sendPolicy
2. openclaw gateway status (this often reveals “Config (service) != Config (cli)” mismatches)
3. ~30 lines of openclaw logs --follow around the first time you see web-heartbeat log the disconnect and the moment the WhatsApp DM message is emitted