Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Assistant output tags (<final> / </final>) are not stripped in Control UI (v4.11) [2 pull requests, 1 comments, 2 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#65182•Fetched 2026-04-12 13:25:10
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
zpmljzzczpmljzzc
Participants
lui62233lui62233zpmljzzczpmljzzc
Timeline (top)
cross-referenced ×2commented ×1labeled ×1mentioned ×1

Since upgrading to version 4.11, the internal assistant tags <final> and </final> are no longer being stripped by the Control UI / webchat surface and are appearing as raw text in the chat bubbles.

Root Cause

Since upgrading to version 4.11, the internal assistant tags <final> and </final> are no longer being stripped by the Control UI / webchat surface and are appearing as raw text in the chat bubbles.

Fix Action

Fix / Workaround

Upgrade to OpenClaw 4.11. Start a conversation with any agent (e.g., using google/gemma-4-31b-it or deepseek/deepseek-chat). Observe the assistant's replies.

PR fix notes

PR #65187: test: add regression tests for <final> tag stripping in UI message extraction

Description (problem / solution / changelog)

Summary

Adds regression tests to verify that the extractText and extractTextCached functions properly strip internal <final> and </final> assistant output tags from both content array and text property message formats in the Control UI.

Context

Issue #65182 reports that <final> tags are leaking through to the Control UI chat surface as raw text. After thorough investigation:

  • The tag-stripping pipeline (stripReasoningTagsFromText → stripAssistantInternalScaffolding → stripThinkingTags → extractTextCached) is working correctly for all tested message formats
  • All existing tests pass
  • The stripping correctly handles: single-line tags, multiline blocks, mixed <think>/<final> tags, closing-only tags, and tags in both content array and text property formats

This PR

Adds 4 new test cases to ui/src/ui/chat/message-extract.test.ts:

  • strips <final> tags from assistant content — basic content array format
  • strips multiline <final> blocks from assistant content — multiline block format
  • strips mixed <think> and <final> tags from assistant content — combined reasoning + final format
  • strips <final> tags from assistant text property — legacy text property format

These tests serve as regression prevention and document the expected stripping behavior through the full UI extraction pipeline.

Testing

  • All UI tests pass (pnpm vitest run --config vitest.ui.config.ts)
  • All shared-core text tests pass
  • No changes to production code

Fixes openclaw/openclaw#65182

Changed files

  • ui/src/ui/chat/message-extract.test.ts (modified, +33/-0)

PR #65336: test: add missing extractTextCached assertions to final-tag regression tests

Description (problem / solution / changelog)

Summary

Addresses review feedback from PR #65187 — specifically the Greptile P2 comment about missing extractTextCached assertions.

Changes

  • Added expect(extractTextCached(message)).toBe(...) to 3 of the 4 new regression tests that were missing it:
    • "strips multiline <final> blocks from assistant content"
    • "strips mixed <think> and <final> tags from assistant content"
    • "strips <final> tags from assistant text property"

The first new test already had both assertions correctly; the remaining three now match that pattern.

Testing

All 4 new regression tests pass, including both extractText and extractTextCached assertions.

Related: openclaw/openclaw#65182

Changed files

  • ui/src/ui/chat/message-extract.test.ts (modified, +36/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Since upgrading to version 4.11, the internal assistant tags <final> and </final> are no longer being stripped by the Control UI / webchat surface and are appearing as raw text in the chat bubbles.

Steps to reproduce

Upgrade to OpenClaw 4.11. Start a conversation with any agent (e.g., using google/gemma-4-31b-it or deepseek/deepseek-chat). Observe the assistant's replies.

Expected behavior

The system should strip the internal <final> and </final> tags and only render the content inside them to the user.

Actual behavior

The raw <final> and </final> tags are visible in the output.

OpenClaw version

2026.4.11

Operating system

Windows 10

Install method

No response

Model

no

Provider / routing chain

no

Additional provider/model setup details

This issue persists across multiple models (both Gemma 4 and DeepSeek). Restarting the gateway/server does not resolve the issue. It appears to be a regression in the rendering layer of the Control UI in the latest version.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue can likely be resolved by updating the rendering layer of the Control UI to properly strip the internal <final> and </final> tags in OpenClaw version 4.11.

Guidance

  • Verify that the issue is indeed caused by the regression in the rendering layer of the Control UI by checking the rendering logic for any changes or updates that may have introduced this bug.
  • Check the OpenClaw documentation or release notes for version 4.11 to see if there are any known issues or workarounds related to the rendering of internal tags.
  • Test the rendering of other internal tags to see if the issue is specific to <final> and </final> tags or if it's a more general problem.
  • Consider reaching out to the OpenClaw support team or community to report the issue and ask for assistance or guidance on how to resolve it.

Example

No code snippet is provided as the issue does not include enough technical details to create a specific example.

Notes

The issue seems to be specific to OpenClaw version 4.11 and the Control UI rendering layer. The fact that restarting the gateway/server does not resolve the issue suggests that it's a problem with the rendering logic rather than a transient error.

Recommendation

Apply workaround: The best course of action would be to apply a workaround, such as manually stripping the <final> and </final> tags from the output or using a different rendering layer, until a fixed version of OpenClaw is released.

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

The system should strip the internal <final> and </final> tags and only render the content inside them to the user.

#retrieval issue#search optimization#API routing#API middleware#SSR setup

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 [Bug]: Assistant output tags (<final> / </final>) are not stripped in Control UI (v4.11) [2 pull requests, 1 comments, 2 participants]