openclaw - 💡(How to fix) Fix Bug: WhatsApp pairing message includes internal JSON metadata visible to users

Environment

• OpenClaw version: 2026.5.7 (eeef486)
• Channel: WhatsApp
• Policy: dmPolicy: pairing (default)
• Platform: QNAP NAS (Docker container)

Problem

When an unapproved contact sends a message via WhatsApp, they receive the expected pairing prompt. However, the message includes internal JSON metadata that should not be visible to external users.

Actual behavior

User receives:

OpenClaw: access not configured.

Your WhatsApp phone number: +19545998159
Pairing code:

ZJUP5PJ3


Ask the bot owner to approve with:
openclaw pairing approve whatsapp ZJUP5PJ3

openclaw pairing approve whatsapp ZJUP5PJ


Sender (untrusted metadata):
{
  "schema": "openclaw.inbound_meta.v2",
  "channel": "whatsapp",
  "provider": "whatsapp",
  "messageId": "...",
  "fromJid": "...",
  ...
}

The entire Sender (untrusted metadata): JSON block is visible in the WhatsApp conversation to the external user.

Expected behavior

The pairing message should end after the approval commands. No internal metadata should be sent to the WhatsApp user.

Expected:

OpenClaw: access not configured.

Your WhatsApp phone number: +19545998159
Pairing code: ZJUP5PJ3

Ask the bot owner to approve with:
openclaw pairing approve whatsapp ZJUP5PJ3

Impact

• Unprofessional appearance: Users see raw JSON in their WhatsApp conversation
• Information disclosure: Exposes internal message routing metadata, schema versions, channel details
• User confusion: Recipients don't understand what the technical JSON means
• Poor first impression: This is often the first message someone receives from the bot

Reproduction

1. Configure WhatsApp channel with dmPolicy: "pairing"
2. Have an unapproved contact send a message to the bot's WhatsApp number
3. Contact receives pairing message with JSON metadata appended

Suggested fix

The pairing response template should exclude the Sender (untrusted metadata): block when sending to external channels. This metadata should remain available in internal logs/dashboards but never be part of the outbound message payload.

Workaround

Currently disabling WhatsApp channel (channels.whatsapp.enabled: false) until fixed.