openclaw - ✅(Solved) Fix WhatsApp: XML tool-tag sanitizer regression in 2026.4.23 + missing exposeErrorText/silentErrorReplies parity [1 pull requests, 1 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#71715Fetched 2026-04-26 05:09:27
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×1

Two related observations from production WhatsApp deployment on [email protected]:

  1. Sanitizer regression — Anthropic-style XML tool-calling tags (<function_calls>…</function_calls>, <invoke>, <parameter>, <tool_call>) are bleeding through to user-visible WhatsApp messages on certain agent paths. Pre-2026.4.23 these were stripped reliably; current versions leak the literal tags into the final delivered text.

  2. Missing per-channel error visibility knob — there is no way to suppress raw error text on WhatsApp without disabling all error reactions. telegram has silentErrorReplies and errorPolicy: silent; whatsapp channel schema has neither. An exposeErrorText: false (or analogous errorPolicy) at channels.whatsapp level would close the gap.

Error Message

  1. Missing per-channel error visibility knob — there is no way to suppress raw error text on WhatsApp without disabling all error reactions. telegram has silentErrorReplies and errorPolicy: silent; whatsapp channel schema has neither. An exposeErrorText: false (or analogous errorPolicy) at channels.whatsapp level would close the gap.
  • User sees raw error text on WhatsApp — there's no per-channel toggle to suppress it.

Root Cause

Two related observations from production WhatsApp deployment on [email protected]:

  1. Sanitizer regression — Anthropic-style XML tool-calling tags (<function_calls>…</function_calls>, <invoke>, <parameter>, <tool_call>) are bleeding through to user-visible WhatsApp messages on certain agent paths. Pre-2026.4.23 these were stripped reliably; current versions leak the literal tags into the final delivered text.

  2. Missing per-channel error visibility knob — there is no way to suppress raw error text on WhatsApp without disabling all error reactions. telegram has silentErrorReplies and errorPolicy: silent; whatsapp channel schema has neither. An exposeErrorText: false (or analogous errorPolicy) at channels.whatsapp level would close the gap.

Fix Action

Fix / Workaround

Workarounds in place locally

  1. Re-validate that the XML-tag sanitizer is applied at every outbound projection step on WA (post-coalesce, post-fallback merge, pre-Baileys send).
  2. Add exposeErrorText: boolean (or errorPolicy/silentErrorReplies) to the channels.whatsapp schema, parity with telegram.
  3. Optionally: extract the sanitizer regex into config (channels.<channel>.outboundSanitizers) so operators can extend it without core patches — aligns with the "no core patches" principle some of us run with.

PR fix notes

PR #71830: fix(whatsapp): sanitize XML tool text and suppress errors

Description (problem / solution / changelog)

Fixes #71715

Summary

  • Strip XML-style tool/function call payloads from WhatsApp-visible text across auto-reply, channel outbound, and payload send paths.
  • Normalize WhatsApp auto-reply payloads before both delivery and echo bookkeeping so sent text matches remembered text.
  • Add channels.whatsapp.exposeErrorText with account-level inheritance and suppress error payloads in inbound and routed outbound WhatsApp delivery when disabled.

Validation

  • pnpm config:channels:check
  • pnpm config:docs:check
  • pnpm test extensions/whatsapp/src/outbound-adapter.sendpayload.test.ts extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.test.ts
  • pnpm test extensions/whatsapp/src/outbound-adapter.sendpayload.test.ts extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.test.ts extensions/whatsapp/src/auto-reply/deliver-reply.test.ts src/agents/pi-embedded-utils.test.ts src/config/zod-schema.providers-whatsapp.test.ts extensions/whatsapp/src/config-schema.test.ts
  • pnpm check:changed
  • codex review --base origin/main clean: no discrete regression found

User manual verification: owner performs final manual verification outside this agent run.

Changed files

  • docs/.generated/config-baseline.sha256 (modified, +3/-3)
  • docs/channels/whatsapp.md (modified, +17/-1)
  • extensions/whatsapp/src/accounts.ts (modified, +2/-0)
  • extensions/whatsapp/src/auto-reply/deliver-reply.test.ts (modified, +46/-0)
  • extensions/whatsapp/src/auto-reply/monitor.ts (modified, +1/-0)
  • extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.test.ts (modified, +104/-0)
  • extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.ts (modified, +30/-6)
  • extensions/whatsapp/src/channel-outbound.test.ts (modified, +46/-0)
  • extensions/whatsapp/src/channel-outbound.ts (modified, +3/-1)
  • extensions/whatsapp/src/config-schema.test.ts (modified, +14/-0)
  • extensions/whatsapp/src/config-ui-hints.ts (modified, +4/-0)
  • extensions/whatsapp/src/outbound-adapter.sendpayload.test.ts (modified, +44/-0)
  • extensions/whatsapp/src/outbound-adapter.ts (modified, +5/-4)
  • extensions/whatsapp/src/outbound-base.ts (modified, +9/-1)
  • extensions/whatsapp/src/outbound-media-contract.ts (modified, +15/-3)
  • src/agents/pi-embedded-utils.test.ts (modified, +15/-0)
  • src/channels/plugins/outbound.types.ts (modified, +1/-0)
  • src/config/bundled-channel-config-metadata.generated.ts (modified, +10/-0)
  • src/config/types.whatsapp.ts (modified, +2/-0)
  • src/config/zod-schema.providers-whatsapp.test.ts (modified, +15/-0)
  • src/config/zod-schema.providers-whatsapp.ts (modified, +1/-0)
  • src/infra/outbound/deliver.test.ts (modified, +66/-0)
  • src/infra/outbound/deliver.ts (modified, +8/-5)
  • src/shared/text/assistant-visible-text.ts (modified, +20/-8)

Code Example

/<\s*\/?\s*(?:tool_call|tool_result|function_calls?|function|tool_calls)\b/i
RAW_BUFFERClick to expand / collapse

Summary

Two related observations from production WhatsApp deployment on [email protected]:

  1. Sanitizer regression — Anthropic-style XML tool-calling tags (<function_calls>…</function_calls>, <invoke>, <parameter>, <tool_call>) are bleeding through to user-visible WhatsApp messages on certain agent paths. Pre-2026.4.23 these were stripped reliably; current versions leak the literal tags into the final delivered text.

  2. Missing per-channel error visibility knob — there is no way to suppress raw error text on WhatsApp without disabling all error reactions. telegram has silentErrorReplies and errorPolicy: silent; whatsapp channel schema has neither. An exposeErrorText: false (or analogous errorPolicy) at channels.whatsapp level would close the gap.

Reproduction (item 1)

  • Deploy openclaw 2026.4.23 with WhatsApp channel + an agent whose model returns Anthropic-style tool XML on a fallback/embedded-harness path (observed with Claude Sonnet 4.6 fallback when primary openai-codex/gpt-5.5 fails over).
  • Send a group message that triggers tool use (e.g., bot replies in a group with web-search style follow-up).
  • Observe in WhatsApp: outbound message contains literal <function_calls>...<invoke name="...">...</invoke>...</function_calls> blocks.

The existing sanitizer regex (in dist as a precompiled token, recovered as):

/<\s*\/?\s*(?:tool_call|tool_result|function_calls?|function|tool_calls)\b/i

…seems to match but is no longer applied at the right point in the pipeline for WA outbound — possibly the sanitizer runs before merge of fallback-harness output, or a later coalescer concatenates raw assistant chunks that bypass it.

Reproduction (item 2)

  • WA agent fails an inbound turn (provider 5xx, malformed tool result, etc.).
  • User sees raw error text on WhatsApp — there's no per-channel toggle to suppress it.

Workarounds in place locally

(none of these are real fixes — please consider them documentation of the gap)

  • Added explicit anti-XML rule to agents.list[main].systemPromptOverride instructing the model never to emit <function_calls> etc. — works on cooperative models, useless when the leak happens post-model.
  • acp.stream.deliveryMode: final_only, coalesceIdleMs: 250, maxChunkChars: 4000, repeatSuppression: true to reduce streaming surface area.
  • messages.queue.debounceMsByChannel.whatsapp: 1200 to coalesce bursts.

Asks

  1. Re-validate that the XML-tag sanitizer is applied at every outbound projection step on WA (post-coalesce, post-fallback merge, pre-Baileys send).
  2. Add exposeErrorText: boolean (or errorPolicy/silentErrorReplies) to the channels.whatsapp schema, parity with telegram.
  3. Optionally: extract the sanitizer regex into config (channels.<channel>.outboundSanitizers) so operators can extend it without core patches — aligns with the "no core patches" principle some of us run with.

Environment

  • openclaw 2026.4.23, Mac mini host, LaunchAgent gateway on 127.0.0.1:18789.
  • Channels: whatsapp via Baileys, telegram.
  • Providers in play during repro: openai-codex/gpt-5.5 (primary), anthropic/claude-sonnet-4-6, workers-ai/@cf/moonshotai/kimi-k2.6.

Happy to provide redacted log snippets privately if helpful.

extent analysis

TL;DR

The most likely fix involves re-validating the application of the XML-tag sanitizer at every outbound projection step on WhatsApp and adding an exposeErrorText option to the channels.whatsapp schema.

Guidance

  • Review the sanitizer's position in the pipeline to ensure it runs after the merge of fallback-harness output and coalescer concatenation.
  • Consider adding a configuration option for the sanitizer regex in channels.<channel>.outboundSanitizers for easier extension.
  • Implement the exposeErrorText: boolean option in the channels.whatsapp schema to control error text visibility.
  • Verify the fix by testing WhatsApp messages with Anthropic-style XML tool-calling tags and error scenarios.

Example

No code snippet is provided due to the lack of specific implementation details in the issue.

Notes

The provided workarounds are not real fixes and may not cover all scenarios. The solution should focus on re-validating the sanitizer's application and adding the exposeErrorText option.

Recommendation

Apply the workaround by re-validating the sanitizer's position and adding the exposeErrorText option, as this addresses the root causes of the issues and provides a more robust solution.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix WhatsApp: XML tool-tag sanitizer regression in 2026.4.23 + missing exposeErrorText/silentErrorReplies parity [1 pull requests, 1 participants]