Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Reasoning/thinking tokens and tool call intermediates leak into Telegram chat (GLM, MiniMax) [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#72363•Fetched 2026-04-27 05:30:55
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
SweetSophiaSweetSophia
Participants
SweetSophiaSweetSophia
Timeline (top)
cross-referenced ×1

Fix Action

Fixed

PR fix notes

PR #72482: fix(telegram): suppress tool progress in non-streaming mode

Description (problem / solution / changelog)

Summary

  • Stop forwarding default tool-progress messages in Telegram when streamMode/preview streaming is off.
  • Keep existing behavior for streaming-enabled turns and for non-text tool outputs that must still route through runtime controls.
  • Update the Telegram dispatch test to assert the corrected non-streaming behavior.

Root Cause

Telegram only suppressed default tool-progress messages when an answer draft stream existed. In non-streaming mode there is no draft stream, so tool progress remained visible even though the turn should be final-only from the user perspective.

Why This Fix Is Safe

The change only adjusts the suppressDefaultToolProgressMessages flag in Telegram dispatch setup for the non-streaming path. It does not alter delivery ordering, final-reply routing, approval handling, or media/tool-result fallback behavior.

Security/Runtime Controls Unchanged

  • Exec approval prompts and approval gating remain runtime-enforced and unchanged.
  • Existing tool/media fallback delivery rules in dispatch-from-config are unchanged.
  • Error handling, silent-reply policy, and abort-fence behavior are unchanged.

Test Plan

  • pnpm test extensions/telegram/src/bot-message-dispatch.test.ts -- --reporter=verbose -t "tool progress messages when answer preview streaming is off|tool progress by default when preview streaming is active|suppresses Telegram tool progress when explicitly disabled"
  • pnpm test extensions/telegram/src/reasoning-lane-coordinator.test.ts -- --reporter=verbose
  • pnpm test extensions/telegram/src/bot-message-dispatch.test.ts -- --reporter=verbose -t "tool progress messages when answer preview streaming is off"
  • git diff --check
  • pnpm check:changed

Additional Notes

  • AI-assisted: yes

Closes #72363

Made with Cursor

Changed files

  • extensions/telegram/src/bot-message-dispatch.test.ts (modified, +2/-2)
  • extensions/telegram/src/bot-message-dispatch.ts (modified, +2/-1)

Code Example

find ~/.openclaw -name "CHANGELOG*" -o -name "changelog*" 2>/dev/null | head -5
RAW_BUFFERClick to expand / collapse

Bug Description

On Telegram (non-streaming mode), model reasoning/thinking tokens and tool call intermediates are being sent as visible messages before being cleaned up when the final response is ready. This occurs approximately 3 out of 5 messages with GLM and MiniMax models.

Observed Behavior

  1. Reasoning/thinking bleed: The model's internal reasoning (the thinking/deliberation before the actual response) is rendered as a visible message in the Telegram chat. This happens frequently with zai/glm-5.1 and minimax/MiniMax-M2.7-highspeed.

  2. Tool calls visible before deletion: Tool calls (exec, image, etc.) are posted as visible messages in the chat, then deleted once the final answer is assembled. For example, the user reported seeing bash commands like:

    find ~/.openclaw -name "CHANGELOG*" -o -name "changelog*" 2>/dev/null | head -5

    appear in the chat before being removed.

  3. Combined with non-streaming mode: This should not happen without streaming enabled. The intermediate output should be buffered and only the final response should be delivered.

Expected Behavior

  • Reasoning/thinking tokens should be stripped from the response before delivery to the user
  • Tool call intermediates should never be visible in non-streaming mode
  • Only the final assembled response should be delivered to the Telegram chat

Environment

  • OpenClaw: 2026.4.23 (a979721)
  • Channel: Telegram
  • Streaming: Not enabled
  • Affected models: zai/glm-5.1, minimax/MiniMax-M2.7-highspeed
  • Also observed occasionally with other models but at much lower frequency

Additional Context

  • The reasoning bleed shows the model's full internal deliberation as a visible message
  • Tool calls appear briefly then get deleted — suggesting the cleanup runs after delivery instead of before
  • Checked changelogs for 2026.4.24 and 2026.4.25-beta.1 through beta.10 — no mentions of fixing this behavior
  • The issue persists across OpenClaw updates

extent analysis

TL;DR

The issue can be mitigated by modifying the message handling logic to buffer and clean up intermediate outputs before delivering the final response to the user.

Guidance

  • Investigate the message handling logic in the OpenClaw codebase to identify where the intermediate outputs are being sent to the Telegram chat without being cleaned up.
  • Verify that the buffering mechanism is correctly implemented and configured for non-streaming mode, ensuring that only the final response is delivered to the user.
  • Check the model-specific configurations for zai/glm-5.1 and minimax/MiniMax-M2.7-highspeed to see if there are any model-specific settings that could be contributing to the issue.
  • Consider adding additional logging or debugging statements to track the flow of messages and identify where the intermediate outputs are being sent incorrectly.

Example

No code snippet is provided as the issue description does not include specific code references.

Notes

The issue appears to be related to the message handling logic in OpenClaw, and modifying this logic may require changes to the codebase. Additionally, the issue may be specific to certain models or configurations, so thorough testing and verification will be necessary to ensure that any changes do not introduce new issues.

Recommendation

Apply a workaround by modifying the message handling logic to buffer and clean up intermediate outputs before delivering the final response to the user, as this is the most direct way to address the issue based on the provided information.

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…
#memory optimization#batch processing#GPU compatibility#latency issue#model 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