Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Raw <tool_call> shadow text leaks to Telegram and QQ Bot on baishan/GLM-5 toolUse turns in 2026.4.2 [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#61645•Fetched 2026-04-08 02:56:31
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
takoii2025takoii2025
Participants
takoii2025takoii2025

On OpenClaw 2026.4.2 (d74a122), user-visible messaging channels can leak raw XML-like tool-call shadow text such as <tool_call>...</tool_call> instead of suppressing it.

This is not only a Gemini thought-tag problem. We reproduced it on fallback provider/model aishan/GLM-5, and we observed it on two different channel surfaces on the same host:

  • Telegram
  • QQ Bot

The common pattern is:

  • the assistant turn contains a valid structured oolCall
  • the model also emits a plain-text shadow representation like <tool_call>exec... or <tool_call>read...
  • the channel delivery path forwards that shadow text to the user

Root Cause

On OpenClaw 2026.4.2 (d74a122), user-visible messaging channels can leak raw XML-like tool-call shadow text such as <tool_call>...</tool_call> instead of suppressing it.

This is not only a Gemini thought-tag problem. We reproduced it on fallback provider/model aishan/GLM-5, and we observed it on two different channel surfaces on the same host:

  • Telegram
  • QQ Bot

The common pattern is:

  • the assistant turn contains a valid structured oolCall
  • the model also emits a plain-text shadow representation like <tool_call>exec... or <tool_call>read...
  • the channel delivery path forwards that shadow text to the user
RAW_BUFFERClick to expand / collapse

Summary

On OpenClaw 2026.4.2 (d74a122), user-visible messaging channels can leak raw XML-like tool-call shadow text such as <tool_call>...</tool_call> instead of suppressing it.

This is not only a Gemini thought-tag problem. We reproduced it on fallback provider/model aishan/GLM-5, and we observed it on two different channel surfaces on the same host:

  • Telegram
  • QQ Bot

The common pattern is:

  • the assistant turn contains a valid structured oolCall
  • the model also emits a plain-text shadow representation like <tool_call>exec... or <tool_call>read...
  • the channel delivery path forwards that shadow text to the user

Environment

  • OpenClaw: 2026.4.2 (d74a122)
  • Install: npm global / system install on Ubuntu 24.04.3
  • Node: 24.14.0
  • Channels affected:
    • Telegram
    • QQ Bot
  • Runtime model during the affected turns: aishan/GLM-5

Telegram reproduction / evidence

Session transcript:

  • /home/hiiy/.openclaw/agents/main/sessions/13ea836b-34af-49c4-8891-2f41786f077b.jsonl.reset.2026-04-05T15-34-20.780Z

Affected assistant message ids:

  • 452b8ce7
  • 84d78d58
  • 483e743b

Each affected assistant message had both:

  • a structured oolCall block, and
  • an extra plain-text block like:

ext <tool_call>exec<arg_key>command</arg_key><arg_value>cd /home/hiiy/.openclaw && gh pr list --repo openclaw/openclaw --limit 10 --state open</arg_value><arg_key>timeout</arg_key><arg_value>30</arg_value></tool_call>

Gateway journal later showed Telegram sends in the same window:

  • 2026-04-05 23:29:37 Asia/Shanghai
  • 2026-04-05 23:29:37 Asia/Shanghai
  • 2026-04-05 23:29:39 Asia/Shanghai
  • 2026-04-05 23:29:40 Asia/Shanghai

QQ Bot reproduction / evidence

Session transcript:

  • /home/hiiy/.openclaw/agents/main/sessions/990d478f-681f-4866-a504-e11a99f3aa9d.jsonl

Affected assistant message id:

  • a850a03

That assistant oolUse turn again contained both:

  • a structured oolCall, and
  • a plain-text shadow block:

ext <tool_call>read<arg_key>path</arg_key><arg_value>/home/hiiy/.openclaw/workspace/memory/2026-04-05.md</arg_value></tool_call>

Additional delivery evidence:

  • QQ outbound cache persisted the leaked content under ref index REFIDX_8uNMI3Z2ViD8ptuXh611lQ==
  • gateway journal showed QQ final delivery at 2026-04-06 09:53:54 Asia/Shanghai with:
    • Sent markdown chunk (124/124 chars)

Actual behavior

Internal/plain-text tool-call shadow text is delivered to user-facing channels.

Examples:

ext <tool_call>exec<arg_key>command</arg_key>...

ext <tool_call>read<arg_key>path</arg_key>...

Expected behavior

If an assistant turn already contains a real structured oolCall, any plain-text shadow representation of that tool call should be stripped or otherwise prevented from reaching user-visible channels.

This should hold consistently across messaging surfaces, including Telegram and QQ Bot.

Why this seems distinct enough to track directly

There are several existing issues about raw reasoning/tag leakage or internal traces leaking to chat, but this reproduction is specifically about:

  • raw XML-like <tool_call>...</tool_call> shadow text
  • cross-channel delivery (Telegram + QQ Bot)
  • OpenClaw 2026.4.2
  • fallback aishan/GLM-5, not just Gemini

So this looks like a broader channel-delivery sanitization gap for tool-call shadow text, not only a Gemini thought/final-tag parsing problem.

Related issues

  • #38291
  • #45000
  • #60465
  • #61350

extent analysis

TL;DR

The most likely fix involves modifying the channel delivery path to strip or sanitize plain-text tool-call shadow representations before forwarding them to user-facing channels.

Guidance

  • Review the channel delivery code to identify where the plain-text shadow text is being forwarded to the user and modify it to strip or sanitize this text.
  • Verify that the structured toolCall block is being properly handled and that the plain-text shadow representation is not being appended to the message.
  • Check the fallback provider/model configuration to ensure that it is not contributing to the issue.
  • Test the fix on both Telegram and QQ Bot channels to ensure that the plain-text shadow text is no longer being delivered to the user.

Example

No specific code example can be provided without more information about the channel delivery code, but a possible solution might involve adding a text sanitization step before sending the message to the user, such as using a regular expression to remove any <tool_call>...</tool_call> blocks.

Notes

The issue seems to be specific to OpenClaw 2026.4.2 and the fallback provider/model aishan/GLM-5, but it is not clear if this is a bug in the OpenClaw code or a configuration issue. Further investigation is needed to determine the root cause of the problem.

Recommendation

Apply a workaround to sanitize the plain-text tool-call shadow representations before they are delivered to the user, as the root cause of the issue is not yet clear and upgrading to a fixed version may not be possible.

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…

FAQ

Expected behavior

If an assistant turn already contains a real structured oolCall, any plain-text shadow representation of that tool call should be stripped or otherwise prevented from reaching user-visible channels.

This should hold consistently across messaging surfaces, including Telegram and QQ Bot.

#serialization error#model compatibility#GPU setup#container setup#orchestration issue

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 - 💡(How to fix) Fix [Bug]: Raw <tool_call> shadow text leaks to Telegram and QQ Bot on baishan/GLM-5 toolUse turns in 2026.4.2 [1 participants]