openclaw - ✅(Solved) Fix Internal thinking tags (<think>) are leaked to user [1 pull requests, 3 comments, 3 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#69843Fetched 2026-04-22 07:47:34
View on GitHub
Comments
3
Participants
3
Timeline
10
Reactions
0
Timeline (top)
referenced ×4commented ×3cross-referenced ×1mentioned ×1

Fix Action

Fixed

PR fix notes

PR #69875: fix(memory/dreaming): surface blocked status when heartbeat is disabled for main

Description (problem / solution / changelog)

Summary

Surface a blocked line in both openclaw memory status and /dreaming status|on|off when dreaming is enabled but heartbeat for main is not firing — currently fails silently.

  • Both the CLI status and the /dreaming slash command now flag a blocked cron, instead of appearing healthy while silently not running.
  • Added a Troubleshooting section in dreaming docsexplaining the blocked state and its common causes.
  • Memory-core reuses existing heartbeat-state logic from core instead of re-implementing heartbeat rules in the extension.

Refs #69811, #46046.

Scope note

Observability only, not execution semantics. The cron hardcodes sessionTarget: "main" regardless of the configured default agent — so if a user sets default: true on a non-main agent, dreaming still silently never runs. Fixing that is a behavior change to the cron target itself and belongs in a follow-up.

Test plan

  • pnpm test extensions/memory-core (503 pass)
  • pnpm tsgo:prod, pnpm lint:{core,extensions}, pnpm plugin-sdk:api:check
  • Manual preview against a live config with heartbeat.every: "0m" — renders as expected

Changed files

  • CHANGELOG.md (modified, +4/-0)
  • docs/concepts/dreaming.md (modified, +12/-0)
  • extensions/memory-core/src/cli.runtime.ts (modified, +8/-1)
  • extensions/memory-core/src/cli.test.ts (modified, +129/-0)
  • extensions/memory-core/src/dreaming-command.test.ts (modified, +91/-0)
  • extensions/memory-core/src/dreaming-command.ts (modified, +6/-1)
  • extensions/memory-core/src/dreaming.ts (modified, +31/-4)
  • src/plugin-sdk/infra-runtime.ts (modified, +1/-0)
RAW_BUFFERClick to expand / collapse

Bug Description

Internal <think> thinking tags are being leaked to the user in Telegram messages instead of being filtered out internally.

Steps to Reproduce

  1. Use OpenClaw with any model that has thinking/reasoning enabled
  2. Wait for the model to generate internal thoughts
  3. The <think> tags and their content appear in the Telegram message to the user

Expected Behavior

Internal thinking tags should be filtered out before the message is sent to the user. The user should not see any <think> or </think> tags or their content.

Environment

  • OpenClaw version: 2026.4.20
  • Channel: Telegram
  • Model: minimax/MiniMax-M2.7 (and other models)

Additional Context

This appears to be a rendering/filtering issue where the thinking tags that should be internal to the model are being exposed to the end user. The issue was present in previous versions and persists after upgrading to 2026.4.20.

extent analysis

TL;DR

Filtering out internal <think> tags before sending messages to the user is likely the most straightforward fix.

Guidance

  • Review the message processing pipeline in OpenClaw to identify where the filtering of <think> tags should occur, ensuring it happens before the message is sent to Telegram.
  • Verify that the model's output is being properly sanitized or filtered for internal tags, considering the specific requirements of the Telegram channel.
  • Check the documentation or configuration options for the minimax/MiniMax-M2.7 model and other affected models to see if there are settings related to internal thinking tags that need adjustment.
  • Test the filtering mechanism with different models and scenarios to ensure the fix is robust and does not introduce other issues.

Example

No specific code example can be provided without more details on the OpenClaw implementation, but a hypothetical filter might look like a string replacement function that removes <think> and </think> tags along with their content.

Notes

The persistence of the issue across different versions and models suggests a deeper issue in how internal thinking tags are handled, possibly requiring a review of the core logic in OpenClaw for processing and filtering model outputs.

Recommendation

Apply a workaround by implementing a custom filter in the message processing pipeline to remove <think> tags, as upgrading to a potentially fixed version is not explicitly mentioned as an option and the current version does not resolve the issue.

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 Internal thinking tags (<think>) are leaked to user [1 pull requests, 3 comments, 3 participants]