fix(whatsapp): sanitize tool XML and hide configured error text by rubencu · Pull Request #71830 · openclaw/openclaw

rubencu · 2026-04-25T23:39:41Z

Fixes #71715

Summary

Problem: WhatsApp-visible replies could leak XML-style tool/function call payloads on some outbound paths, and WhatsApp lacked a per-channel way to hide raw provider/agent error text.
Why it matters: WhatsApp users can see internal tool-call markup or raw failure text that should stay out of user-facing chats.
What changed: WhatsApp now normalizes/sanitizes visible outbound payload text across auto-reply, channel outbound, and sendPayload paths; channels.whatsapp.exposeErrorText supports channel and account-level configuration; text-only error payloads can route through channel sendPayload when an adapter opts in.
What did NOT change (scope boundary): This does not add a generic configurable sanitizer system and does not change default WhatsApp behavior; exposeErrorText defaults to true for compatibility.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes WhatsApp: XML tool-tag sanitizer regression in 2026.4.23 + missing exposeErrorText/silentErrorReplies parity #71715
Related #
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: WhatsApp outbound paths did not consistently apply the assistant-visible XML tool-call sanitizer after payload coalescing/projection, and text-only error payloads normally bypassed channel sendPayload, so WhatsApp could not apply channel-owned error visibility policy on those payloads.
Missing detection / guardrail: Coverage did not lock sanitizer behavior across WhatsApp auto-reply, direct channel outbound, payload sendPayload, plural <function_calls> / <tool_calls> wrappers, or no-op suppressed error deliveries.
Contributing context (if known): Issue WhatsApp: XML tool-tag sanitizer regression in 2026.4.23 + missing exposeErrorText/silentErrorReplies parity #71715 reported production leakage on [email protected] with WhatsApp and provider fallback paths.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/shared/text/assistant-visible-text.test.ts, extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.test.ts, extensions/whatsapp/src/auto-reply/deliver-reply.test.ts, extensions/whatsapp/src/channel-outbound.test.ts, extensions/whatsapp/src/outbound-adapter.sendpayload.test.ts, src/infra/outbound/deliver.test.ts, src/config/zod-schema.providers-whatsapp.test.ts, extensions/whatsapp/src/config-schema.test.ts.
Scenario the test should lock in: XML tool/function call blocks are stripped from WhatsApp-visible text, plural wrappers with nested JSON are stripped safely, payloads that normalize to no visible content are not delivered, and exposeErrorText: false suppresses WhatsApp error payload text without recording a false delivery.
Why this is the smallest reliable guardrail: The tests cover the sanitizer helper, WhatsApp-owned delivery seams, config schema, and the one generic outbound contract change without requiring live WhatsApp infrastructure.
Existing test that already covers this (if any): None covered all affected paths before this PR.
If no new test is added, why not: N/A; new regression coverage is included.

User-visible / Behavior Changes

WhatsApp no longer displays XML-style tool/function call payload blocks that reach these outbound text paths.
New config: channels.whatsapp.exposeErrorText and channels.whatsapp.accounts.<id>.exposeErrorText.
Default remains true; setting it to false suppresses WhatsApp error payload text.

Diagram (if applicable)

Before:
[agent payload] -> [WhatsApp outbound path] -> [raw XML/error text may appear]

After:
[agent payload] -> [WhatsApp sanitizer/error policy] -> [visible reply or intentional no-op]

Security Impact (required)

New permissions/capabilities? (Yes/No) No
Secrets/tokens handling changed? (Yes/No) No
New/changed network calls? (Yes/No) No
Command/tool execution surface changed? (Yes/No) No
Data access scope changed? (Yes/No) No
If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

OS: macOS local development worktree
Runtime/container: Node 22 / pnpm repo scripts
Model/provider: Not provider-specific in local tests; issue repro involved provider fallback paths
Integration/channel (if any): WhatsApp
Relevant config (redacted): channels.whatsapp.exposeErrorText: false and account-level override scenarios

Steps

Send or simulate WhatsApp-bound payload text containing XML-style tool/function call blocks such as <function_calls><invoke ...></invoke></function_calls>.
Send or simulate a WhatsApp-bound payload with isError: true while channels.whatsapp.exposeErrorText is false.
Exercise auto-reply, channel outbound, payload sendPayload, and core delivery paths.

Expected

WhatsApp-visible text strips tool/function XML payloads while preserving real visible text.
Error payload text is suppressed on WhatsApp when exposeErrorText is disabled.
Suppressed no-op payloads do not count as delivered and do not fire message-sent hooks or transcript mirroring.

Actual

Covered scenarios pass in focused regression tests and changed-surface validation on this PR head.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Regression tests were added for the issue scenarios and pass after the fix. Issue #71715 contains the production reproduction report.

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios: Local regression tests for sanitizer behavior, WhatsApp auto-reply normalization, WhatsApp sendPayload suppression, config schema/defaults, core no-op delivery handling, and generated config/API baselines.
Edge cases checked: Plural <function_calls> / <tool_calls> wrappers, nested JSON containing closing tag text inside strings, payloads that sanitize to empty visible text, account-level exposeErrorText overrides, and suppressed no-op delivery results.
What you did not verify: Live WhatsApp/Baileys delivery against a production account; owner/manual production verification remains separate.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

Backward compatible? (Yes/No) Yes
Config/env changes? (Yes/No) Yes
Migration needed? (Yes/No) No
If yes, exact upgrade steps: No migration required. Existing WhatsApp behavior remains unchanged unless users opt into channels.whatsapp.exposeErrorText: false.

Risks and Mitigations

Risk: Over-stripping legitimate text that resembles tool-call XML.
- Mitigation: Sanitizer changes are scoped to existing assistant-visible tool-call tag handling and covered by targeted tests, including nested JSON close-tag cases.
Risk: Suppressed WhatsApp errors could be misreported as delivered.
- Mitigation: Core now ignores delivery results without a delivery identity, with regression coverage for hooks and transcript mirroring.

AI Assistance

AI-assisted PR: implemented and reviewed with Codex.
Testing degree: fully tested for the touched local surfaces via targeted tests, pnpm check:changed, generated baseline checks, local codex review --base origin/main, and GitHub CI.
I understand what the code does: WhatsApp owns the sanitizer/error-visibility behavior; core only adds the minimal generic adapter opt-in and no-op delivery identity handling needed for that channel-owned policy.

greptile-apps · 2026-04-25T23:41:26Z

Greptile Summary

This PR sanitizes XML tool/function-call payloads from WhatsApp-visible text across auto-reply, channel outbound, and sendPayload paths, and adds a new channels.whatsapp.exposeErrorText flag (with account-level inheritance) to suppress error text delivery on WhatsApp.

The inbound-dispatch.ts exposeErrorText check reads only the top-level channels.whatsapp.exposeErrorText, ignoring per-account overrides, while the sendPayload path in outbound-base.ts correctly uses resolveMergedWhatsAppAccountConfig. This creates an inconsistency for multi-account setups.

Confidence Score: 4/5

Safe to merge for single-account setups; multi-account deployments using per-account exposeErrorText overrides will not have errors suppressed in auto-reply flows.

One P1 defect: account-level exposeErrorText override is not honored in the inbound auto-reply dispatch path, creating a behavioral gap vs. the sendPayload path. No P0s found. All other changes (XML sanitization, schema, docs) look correct.

extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.ts — line 289 needs resolveMergedWhatsAppAccountConfig instead of direct config read.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.ts
Line: 289

Comment:
**Account-level `exposeErrorText` overrides ignored in auto-reply path**

`exposeErrorText` is read directly from `params.cfg.channels?.whatsapp`, bypassing account-level inheritance. A user who sets `channels.whatsapp.accounts.work.exposeErrorText = false` while leaving the root flag at its default (`true`) will still have error text delivered through the auto-reply path, even though the `sendPayload` path (via `resolveMergedWhatsAppAccountConfig`) correctly suppresses it for the same account. `params.route.accountId` is already in scope (it's passed to `resolveChunkMode` on the line above), so the fix parallels what `outbound-base.ts` does:

```typescript
const exposeErrorText =
  resolveMergedWhatsAppAccountConfig({ cfg: params.cfg, accountId: params.route.accountId })
    .exposeErrorText !== false;
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(whatsapp): sanitize XML tool text an..." | Re-trigger Greptile}

greptile-apps · 2026-04-25T23:41:30Z

@@ -278,6 +286,7 @@ export async function dispatchWhatsAppBufferedReply(params: {
  });
  const mediaLocalRoots = getAgentScopedMediaLocalRoots(params.cfg, params.route.agentId);
  const disableBlockStreaming = resolveWhatsAppDisableBlockStreaming(params.cfg);
+  const exposeErrorText = params.cfg.channels?.whatsapp?.exposeErrorText !== false;


Account-level exposeErrorText overrides ignored in auto-reply path

exposeErrorText is read directly from params.cfg.channels?.whatsapp, bypassing account-level inheritance. A user who sets channels.whatsapp.accounts.work.exposeErrorText = false while leaving the root flag at its default (true) will still have error text delivered through the auto-reply path, even though the sendPayload path (via resolveMergedWhatsAppAccountConfig) correctly suppresses it for the same account. params.route.accountId is already in scope (it's passed to resolveChunkMode on the line above), so the fix parallels what outbound-base.ts does:

const exposeErrorText = resolveMergedWhatsAppAccountConfig({ cfg: params.cfg, accountId: params.route.accountId }) .exposeErrorText !== false;

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.ts Line: 289 Comment: **Account-level `exposeErrorText` overrides ignored in auto-reply path** `exposeErrorText` is read directly from `params.cfg.channels?.whatsapp`, bypassing account-level inheritance. A user who sets `channels.whatsapp.accounts.work.exposeErrorText = false` while leaving the root flag at its default (`true`) will still have error text delivered through the auto-reply path, even though the `sendPayload` path (via `resolveMergedWhatsAppAccountConfig`) correctly suppresses it for the same account. `params.route.accountId` is already in scope (it's passed to `resolveChunkMode` on the line above), so the fix parallels what `outbound-base.ts` does: ```typescript const exposeErrorText = resolveMergedWhatsAppAccountConfig({ cfg: params.cfg, accountId: params.route.accountId }) .exposeErrorText !== false; ``` How can I resolve this? If you propose a fix, please make it concise.

clawsweeper · 2026-04-26T10:34:17Z

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Current main still lacks the PR's central WhatsApp sanitizer and error-visibility behavior. The active PR is a focused implementation candidate for the production report in #71715, and the provided PR context shows the earlier account-level override review issue was addressed on the branch.

Best possible solution:

Keep this PR open for maintainer review and land this branch or an equivalent focused patch. The right boundary is WhatsApp-owned visible-text normalization across auto-reply, channel outbound, and sendPayload; documented channels.whatsapp.exposeErrorText with account inheritance; and the minimal generic outbound opt-in needed so text-only error payloads can reach channel-owned suppression without false delivered-message bookkeeping.

What I checked:

current-main-whatsapp-normalization-only-trims: On current main, WhatsApp payload normalization only trims leading whitespace; it does not call the assistant-visible sanitizer or strip the reported plural XML wrapper at this boundary. (extensions/whatsapp/src/outbound-media-contract.ts:33, b85edb3f0cf6)
current-main-auto-reply-lacks-error-visibility-policy: The auto-reply deliverable-payload filter suppresses reasoning/compaction/tool text without media, but has no isError or exposeErrorText policy and passes the payload directly to delivery/bookkeeping. (extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.ts:60, b85edb3f0cf6)
current-main-core-outbound-seam-absent: The channel outbound adapter contract has no sendTextOnlyErrorPayloads opt-in, and core sendPayload routing is still limited to structured payload content or audioAsVoice, so text-only error payloads cannot reach WhatsApp-owned suppression on main. (src/infra/outbound/deliver.ts:1108, b85edb3f0cf6)
current-main-config-docs-surface-absent: The WhatsApp shared config type, Zod schema, account resolution, and docs field list do not include exposeErrorText on current main; targeted rg for exposeErrorText returned no matches in the relevant paths. (src/config/types.whatsapp.ts:90, b85edb3f0cf6)
reported-plural-wrapper-still-preserved-by-shared-sanitizer: The current shared sanitizer test suite explicitly preserves the exact nested <function_calls><invoke ...></function_calls> prose shape reported in WhatsApp: XML tool-tag sanitizer regression in 2026.4.23 + missing exposeErrorText/silentErrorReplies parity #71715, supporting the need for the PR's WhatsApp-local opt-in behavior. (src/shared/text/assistant-visible-text.test.ts:338, b85edb3f0cf6)
active-pr-context-addresses-gap: Provided PR diff context shows the branch adds WhatsApp visible-text normalization across auto-reply/channel/sendPayload paths, channels.whatsapp.exposeErrorText at channel and account scope, the core sendTextOnlyErrorPayloads opt-in, and focused regression tests. It also shows the Greptile account-level override comment was addressed by using resolveMergedWhatsAppAccountConfig with params.route.accountId. (extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.ts:291, 4e880dc40940)

Likely related people:

mcaxtr: The PR timeline shows this person was assigned and pushed the maintainer follow-up commits on the active branch, including the localized WhatsApp sanitizer work and the account-level exposeErrorText fix noted by review. (role: recent maintainer and likely follow-up owner; confidence: high; commits: cfeebe2d4555, 301b5e91f1ea, 66fd84795f72; files: extensions/whatsapp/src/outbound-media-contract.ts, extensions/whatsapp/src/outbound-base.ts, extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.ts)
Peter Steinberger: Recent current-main history touches shared outbound/channel plugin boundaries and changelog/release maintenance, which are the non-WhatsApp core surfaces affected by this PR's adapter opt-in and no-op delivery bookkeeping. (role: recent adjacent core/channel maintainer; confidence: medium; commits: e27fe55aa8e3, 3dc6e408b95d, 855c220a631a; files: src/infra/outbound/deliver.ts, src/channels/plugins/outbound.types.ts, src/shared/text/assistant-visible-text.ts)
Sathvik-1007: Recent current-main history includes WhatsApp channel reliability work in the same plugin area, though not the exact sanitizer/error-text surface. (role: recent adjacent WhatsApp maintainer; confidence: low; commits: 7ddd815e469e; files: extensions/whatsapp, docs/channels/whatsapp.md)

Remaining risk / open question:

Closing this PR now would drop the active implementation candidate while current main still lacks the WhatsApp sanitizer/error-visibility changes for WhatsApp: XML tool-tag sanitizer regression in 2026.4.23 + missing exposeErrorText/silentErrorReplies parity #71715.
The PR changes a public channel outbound adapter contract plus generated config/API baselines, so it needs normal maintainer review and changed-surface CI before landing.
The main behavioral risk is over-stripping WhatsApp-visible text that resembles tool-call XML; the PR's targeted sanitizer tests are the right guardrail to review.

Codex review notes: model gpt-5.5, reasoning high; reviewed against b85edb3f0cf6.

mcaxtr · 2026-04-29T04:43:30Z

Merged via squash.

Prepared head SHA: 184d4a25e41744752225d947640af45db343556a
Merge commit: 652f34103a4d4873046475808ea91438b55f8aa4

Thanks @rubencu!

@mcaxtr

…claw#71830) Merged via squash. Prepared head SHA: 184d4a2 Co-authored-by: rubencu <[email protected]> Co-authored-by: mcaxtr <[email protected]> Reviewed-by: @mcaxtr

@mcaxtr

…claw#71830) Merged via squash. Prepared head SHA: 184d4a2 Co-authored-by: rubencu <[email protected]> Co-authored-by: mcaxtr <[email protected]> Reviewed-by: @mcaxtr

@mcaxtr

…claw#71830) Merged via squash. Prepared head SHA: 184d4a2 Co-authored-by: rubencu <[email protected]> Co-authored-by: mcaxtr <[email protected]> Reviewed-by: @mcaxtr

@mcaxtr

…claw#71830) Merged via squash. Prepared head SHA: 184d4a2 Co-authored-by: rubencu <[email protected]> Co-authored-by: mcaxtr <[email protected]> Reviewed-by: @mcaxtr

…text The Nextcloud Talk outbound adapter had no sanitizeText hook, so internal assistant tool-trace scaffolding (e.g. "⚠️ 🛠️ `exec (agent)` failed", raw <tool_call>/<function_response> XML) leaked verbatim into delivered chat messages. The same one-line sanitizeText hook was already shipped to 13 sibling channels (mattermost openclaw#98693, feishu openclaw#98705, twitch openclaw#103109, signal openclaw#97360, slack openclaw#97367, matrix openclaw#97372, irc openclaw#97214, telegram, googlechat openclaw#90684, qqbot openclaw#90132, discord, whatsapp openclaw#71830, sms). Add sanitizeText: ({ text }) => sanitizeAssistantVisibleText(text) to the outbound base adapter, matching those precedents. Co-Authored-By: Claude <[email protected]>

The Nostr outbound adapter had no sanitizeText hook, so internal assistant tool-trace scaffolding (e.g. "⚠️ 🛠️ `exec (agent)` failed", raw <tool_call>/<function_response> XML) leaked verbatim into delivered Nostr DMs. The same one-line sanitizeText hook was already shipped to 13 sibling channels (twitch openclaw#103109, mattermost openclaw#98693, feishu openclaw#98705, signal openclaw#97360, slack openclaw#97367, matrix openclaw#97372, irc openclaw#97214, telegram, googlechat openclaw#90684, qqbot openclaw#90132, discord, whatsapp openclaw#71830, sms). Add sanitizeText to the NostrOutboundAdapter type and adapter, matching those precedents. Co-Authored-By: Claude <[email protected]>

The Zalo outbound adapter had no sanitizeText hook, so internal assistant tool-trace scaffolding (e.g. "⚠️ 🛠️ `exec (agent)` failed", raw <tool_call>/<function_response> XML) leaked verbatim into delivered Zalo messages. The same one-line sanitizeText hook was already shipped to 13 sibling channels (twitch openclaw#103109, mattermost openclaw#98693, feishu openclaw#98705, signal openclaw#97360, slack openclaw#97367, matrix openclaw#97372, irc openclaw#97214, telegram, googlechat openclaw#90684, qqbot openclaw#90132, discord, whatsapp openclaw#71830, sms). Add sanitizeText: ({ text }) => sanitizeAssistantVisibleText(text) to the outbound adapter, matching those precedents. Co-Authored-By: Claude <[email protected]>

The Nostr outbound adapter had no sanitizeText hook, so internal assistant tool-trace scaffolding (e.g. "⚠️ 🛠️ `exec (agent)` failed", raw <tool_call>/<function_response> XML) leaked verbatim into delivered Nostr DMs. The same one-line sanitizeText hook was already shipped to 13 sibling channels (twitch openclaw#103109, mattermost openclaw#98693, feishu openclaw#98705, signal openclaw#97360, slack openclaw#97367, matrix openclaw#97372, irc openclaw#97214, telegram, googlechat openclaw#90684, qqbot openclaw#90132, discord, whatsapp openclaw#71830, sms). Add sanitizeText to the NostrOutboundAdapter type and adapter, matching those precedents. Co-Authored-By: Claude <[email protected]>

The Zalo outbound adapter had no sanitizeText hook, so internal assistant tool-trace scaffolding (e.g. "⚠️ 🛠️ `exec (agent)` failed", raw <tool_call>/<function_response> XML) leaked verbatim into delivered Zalo messages. The same one-line sanitizeText hook was already shipped to 13 sibling channels (twitch openclaw#103109, mattermost openclaw#98693, feishu openclaw#98705, signal openclaw#97360, slack openclaw#97367, matrix openclaw#97372, irc openclaw#97214, telegram, googlechat openclaw#90684, qqbot openclaw#90132, discord, whatsapp openclaw#71830, sms). Add sanitizeText: ({ text }) => sanitizeAssistantVisibleText(text) to the outbound adapter, matching those precedents. Co-Authored-By: Claude <[email protected]>

The Nostr outbound adapter had no sanitizeText hook, so internal assistant tool-trace scaffolding (e.g. "⚠️ 🛠️ `exec (agent)` failed", raw <tool_call>/<function_response> XML) leaked verbatim into delivered Nostr DMs. The same one-line sanitizeText hook was already shipped to 13 sibling channels (twitch openclaw#103109, mattermost openclaw#98693, feishu openclaw#98705, signal openclaw#97360, slack openclaw#97367, matrix openclaw#97372, irc openclaw#97214, telegram, googlechat openclaw#90684, qqbot openclaw#90132, discord, whatsapp openclaw#71830, sms). Add sanitizeText to the NostrOutboundAdapter type and adapter, matching those precedents. Co-Authored-By: Claude <[email protected]>

The Zalo outbound adapter had no sanitizeText hook, so internal assistant tool-trace scaffolding (e.g. "⚠️ 🛠️ `exec (agent)` failed", raw <tool_call>/<function_response> XML) leaked verbatim into delivered Zalo messages. The same one-line sanitizeText hook was already shipped to 13 sibling channels (twitch openclaw#103109, mattermost openclaw#98693, feishu openclaw#98705, signal openclaw#97360, slack openclaw#97367, matrix openclaw#97372, irc openclaw#97214, telegram, googlechat openclaw#90684, qqbot openclaw#90132, discord, whatsapp openclaw#71830, sms). Add sanitizeText: ({ text }) => sanitizeAssistantVisibleText(text) to the outbound adapter, matching those precedents. Co-Authored-By: Claude <[email protected]>

The Nostr outbound adapter had no sanitizeText hook, so internal assistant tool-trace scaffolding (e.g. "⚠️ 🛠️ `exec (agent)` failed", raw <tool_call>/<function_response> XML) leaked verbatim into delivered Nostr DMs. The same one-line sanitizeText hook was already shipped to 13 sibling channels (twitch openclaw#103109, mattermost openclaw#98693, feishu openclaw#98705, signal openclaw#97360, slack openclaw#97367, matrix openclaw#97372, irc openclaw#97214, telegram, googlechat openclaw#90684, qqbot openclaw#90132, discord, whatsapp openclaw#71830, sms). Add sanitizeText to the NostrOutboundAdapter type and adapter, matching those precedents. Co-Authored-By: Claude <[email protected]>

openclaw-barnacle Bot added docs Improvements or additions to documentation channel: whatsapp-web Channel integration: whatsapp-web agents Agent runtime and tooling size: M labels Apr 25, 2026

greptile-apps Bot reviewed Apr 25, 2026

View reviewed changes

rubencu force-pushed the codex/whatsapp-sanitizer-error-controls branch 2 times, most recently from a63b5df to 2e9485b Compare April 26, 2026 01:12

This was referenced Apr 26, 2026

WhatsApp: XML tool-tag sanitizer regression in 2026.4.23 + missing exposeErrorText/silentErrorReplies parity #71715

Closed

fix(whatsapp): support silentErrorReplies parity #68465

Closed

rubencu force-pushed the codex/whatsapp-sanitizer-error-controls branch from 2e9485b to 5dea76c Compare April 28, 2026 12:57

openclaw-barnacle Bot added size: L and removed size: M labels Apr 28, 2026

rubencu changed the title ~~fix(whatsapp): sanitize XML tool text and suppress errors~~ fix(whatsapp): sanitize tool XML and hide configured error text Apr 28, 2026

mcaxtr self-assigned this Apr 29, 2026

mcaxtr force-pushed the codex/whatsapp-sanitizer-error-controls branch from 5dea76c to bfdbf6b Compare April 29, 2026 02:53

openclaw-barnacle Bot removed the agents Agent runtime and tooling label Apr 29, 2026

mcaxtr force-pushed the codex/whatsapp-sanitizer-error-controls branch 6 times, most recently from 4e880dc to 96cc131 Compare April 29, 2026 04:41

rubencu and others added 5 commits April 29, 2026 01:42

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

6b5f011

fix: localize whatsapp outbound sanitization

b142f1d

test: drop generic function_calls extraction assertion

970a4a1

test: tighten whatsapp outbound sanitizer follow-up

3415706

fix: correct whatsapp normalized reply typing

184d4a2

mcaxtr force-pushed the codex/whatsapp-sanitizer-error-controls branch from 96cc131 to 184d4a2 Compare April 29, 2026 04:42

mcaxtr merged commit 652f341 into openclaw:main Apr 29, 2026
11 checks passed

clawsweeper Bot mentioned this pull request Apr 30, 2026

fix(whatsapp): emit hooks for auto-replies #67477

Closed

clawsweeper Bot mentioned this pull request May 16, 2026

feat: Add errorPolicy support to WhatsApp channel #59801

Closed

This was referenced Jul 10, 2026

fix(nextcloud-talk): strip internal tool-trace banners from outbound text #103355

Closed

fix(nostr): strip internal tool-trace banners from outbound text #103361

Open

fix(zalo): strip internal tool-trace banners from outbound text #103377

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(whatsapp): sanitize tool XML and hide configured error text#71830

fix(whatsapp): sanitize tool XML and hide configured error text#71830
mcaxtr merged 5 commits into
openclaw:mainfrom
rubencu:codex/whatsapp-sanitizer-error-controls

rubencu commented Apr 25, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Apr 25, 2026

Uh oh!

greptile-apps Bot Apr 25, 2026

Uh oh!

clawsweeper Bot commented Apr 26, 2026 •

edited

Loading

Uh oh!

Uh oh!

mcaxtr commented Apr 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

rubencu commented Apr 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

AI Assistance

Uh oh!

greptile-apps Bot commented Apr 25, 2026

Greptile Summary

Confidence Score: 4/5

Uh oh!

greptile-apps Bot Apr 25, 2026

Choose a reason for hiding this comment

Uh oh!

clawsweeper Bot commented Apr 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

mcaxtr commented Apr 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rubencu commented Apr 25, 2026 •

edited

Loading

clawsweeper Bot commented Apr 26, 2026 •

edited

Loading