Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When using OpenClaw with WhatsApp and a Kimi-based model (k2p5 / provider normalized as kimi), malformed tool-call output can be delivered to the user as normal chat text instead of being parsed or suppressed.

The leaked message contains raw internal tool-call markers such as:

<|tool_calls_section_begin|> <|tool_call_begin|> <|tool_call_argument_begin|> <|tool_call_end|> <|tool_calls_section_end|>

Example of user-visible leaked output:

The tool syntax is showing up in chat. Let me check your Chrome profiles properly. <|tool_calls_section_begin|> <|tool_call_begin|> exec:12 <|tool_call_argument_begin|> {"command": "ls -la ~/Library/Application Support/Google/ | grep -i chrome", "timeout": 30} <|tool_call_end|> <|tool_calls_section_end|>

This should never be delivered to external messaging channels.

Steps to reproduce

1. Run OpenClaw 2026.4.2
2. Enable WhatsApp channel
3. Use a Kimi-based model for a user-facing WhatsApp session (k2p5 / kimi)
4. Trigger a tool-using turn where the model emits malformed or mixed tool-call output
5. Observe that raw tool-call marker syntax is sent to the WhatsApp user as plain assistant text

Expected behavior

Malformed tool-call output should be:

• parsed into structured tool calls, or • rejected internally, or scrubbed/suppressed before outbound delivery

Under no circumstance should raw internal tool-call markup be sent to end users on WhatsApp.

Actual behavior

The malformed tool-call markup is stored in the assistant message as plain text and then delivered through WhatsApp as if it were a normal reply.

OpenClaw version

2026.4.2

Operating system

iOS 26.4

Install method

pnpm

Model

moonshot kimi/k2p5

Provider / routing chain

OpenClaw gateway → configured Kimi-compatible model route (k2p5, provider reported by runtime as kimi) → WhatsApp outbound channel

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

• The leaked payload is already present in the stored assistant message before outbound delivery, so this is not only a WhatsApp formatting issue. • The installed WhatsApp delivery code already suppresses isReasoning === true and reasoning: text, but this payload is not marked as reasoning. • The installed 2026.4.2 runtime includes Kimi-specific malformed tool-call repair logic, which suggests this provider/model family is already known to produce malformed tool-call output. • This appears related to the same class of bugs as: • reasoning leaking to WhatsApp • internal commands/errors leaking to WhatsApp • tool-call/session corruption issues

Additional information

No response