Fix / Workaround: WhatsApp messages show up as [object Object] in OpenClaw (sanitizeChatSendMessageInput)

If you run OpenClaw with WhatsApp via Baileys, you may see a confusing failure mode: the agent receives the user’s message as the literal string [object Object].

This isn’t a “model hallucination” problem. It’s a type/normalization bug in the input sanitization path.

Source

• Issue report: openclaw/openclaw#52464

What the symptom looks like

• Some WhatsApp messages (DM or groups) arrive correctly.
• Intermittently, a message arrives as [object Object].
• The agent can’t answer, because it never sees the real text.

If you log the inbound payload, you’ll typically discover that the WhatsApp adapter sometimes forwards the raw Baileys message structure (an object containing fields like conversation, extendedTextMessage, etc.), instead of extracting the final text.

Why it happens (root cause)

The issue report traces the problem to sanitizeChatSendMessageInput().

That function assumes the message input is a string, and does a Unicode normalization call:

message.normalize("NFC")

If message is not a string, JavaScript may implicitly coerce it.

For a plain object, that coercion becomes:

String({}) === "[object Object]"

So the LLM sees [object Object] as the user’s message.

How to confirm you’re hitting this exact bug

1. Reproduce the issue once.
2. Inspect gateway logs around the inbound WhatsApp event.
3. Check whether the payload delivered to the chat/session layer contains a non-string message (object) that later becomes [object Object].

If you can confirm it’s an object coming from the WhatsApp adapter, skip “prompt fixes”. You need a type guard or correct extraction.

Practical mitigations (no code changes)

These reduce user pain without changing OpenClaw code:

1. Ask the user to resend when [object Object] arrives.

   • It’s intermittent, so the second attempt often works.

2. Avoid treating [object Object] as a command trigger.

   • If you have any automation rules that pattern-match generic text, consider ignoring this exact string.

3. Collect one minimal diagnostic sample.

   • Save one instance of the inbound Baileys message object (redact phone numbers) so you can extract text reliably.

Safer fixes (recommended)

There are two places to fix it; the safest approach is to fix it at the boundary where WhatsApp messages enter OpenClaw.

Option A — Fix the WhatsApp adapter: always extract text first

Ensure the WhatsApp channel handler converts the Baileys message object into a plain string (e.g., choose conversation or extendedTextMessage.text) before it reaches the chat input sanitizer.

This keeps the sanitizer simple and avoids losing structured fields.

Option B — Add a type guard in sanitizeChatSendMessageInput()

The issue proposes adding a defensive guard:

• If message is not a string:
  • attempt to read text, body, conversation, etc.
  • otherwise fall back to String(message)

This prevents the specific [object Object] failure mode.

Risk note: If you convert arbitrary objects to strings, you may accidentally leak metadata into the prompt (IDs, timestamps). Prefer Option A when possible.

What to watch for after patching

• Messages with emojis / non-Latin characters should still normalize correctly.
• Quoted replies, media captions, and group messages may use different fields in Baileys.
• If you implement extraction, add unit tests for at least:
  • simple text (conversation)
  • extended text (extendedTextMessage.text)
  • captions

Search-intent checklist: what users usually mean when they search this problem

Most operators do not search for the underlying function name.

They usually search the visible symptom, for example:

• OpenClaw WhatsApp [object Object]
• WhatsApp message becomes [object Object] in OpenClaw
• OpenClaw Baileys sends object object to model
• sanitizeChatSendMessageInput object instead of string
• OpenClaw WhatsApp cannot read incoming text

If you landed here from one of those searches, use this shortest decision tree:

1. If only WhatsApp is affected
   • this is a strong match for the adapter / sanitization bug described here.
2. If the model literally receives [object Object]
   • this is the clearest symptom of object-to-string coercion.
3. If messages fail on every channel, not just WhatsApp
   • start with broader session or message-routing problems before blaming this exact bug.
4. If the issue only affects media, captions, or replies
   • you may still be in the same family of bug, but field extraction is the first place to inspect.

That symptom-first framing is usually faster than chasing internal function names.

When this article is probably NOT your problem

This page is likely the wrong match if:

• the user message never arrives at all
• WhatsApp delivery itself is failing before OpenClaw receives anything
• the model receives empty text, but never the literal string [object Object]
• the same corruption happens identically on Telegram, Discord, and Feishu too

In those cases, start with transport, delivery, or broader input-pipeline regressions before assuming you hit this specific WhatsApp object-coercion path.

3-step operator summary

If you only have two minutes, do this in order:

1. capture one failing inbound WhatsApp sample
2. confirm whether message is an object before sanitization
3. patch extraction at the WhatsApp boundary before trying prompt-side workarounds

If step 2 is yes, you are very likely dealing with the same bug shape. If the issue disappears after extracting conversation or extendedTextMessage.text, treat the adapter boundary as the real fix point.

Tracking

Upstream: openclaw/openclaw#52464