openclaw - 💡(How to fix) Fix [Bug]: Control UI renders assistant commentary as same-level replies alongside final answer [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In Control UI, a single user request can appear as multiple same-level assistant replies because intermediate assistant commentary is rendered as normal chat bubbles alongside the final answer.

This does not look like a pure frontend repaint issue. The stronger signal is that commentary/final-answer phase metadata is lost before or during transcript/history persistence or projection, so Control UI cannot reliably distinguish commentary from the final answer when rendering chat history.

Steps to reproduce

1. Open a Control UI chat.
2. Send a prompt that causes the assistant to emit commentary/progress text before making one or more tool calls.
3. Let the run complete and return a final answer.
4. Inspect the resulting chat transcript in Control UI.
5. Optionally inspect the persisted session transcript JSONL for the corresponding turn.

Expected behavior

For a single user request:

• intermediate commentary/progress text should not appear as a normal same-level assistant reply, or should be visually differentiated / collapsed
• the final answer should be the primary assistant reply shown for the turn
• users should not experience the turn as if the assistant answered multiple times

Actual behavior

A single turn may appear as multiple same-level assistant messages, for example:

1. commentary such as “I’ll check the logs/history first...”
2. another progress/commentary message
3. the final answer

From the user perspective, this looks like the same question was answered 2–3 times.

OpenClaw version

2026.4.26

Operating system

macOS

Install method

Local/direct install

Model

Observed with normal tool-using assistant turns in Control UI (not model-specific from current evidence)

Provider / routing chain

Control UI → OpenClaw Gateway → main assistant session

Additional provider/model setup details

Local Control UI session. The issue appears in normal assistant turns that include commentary before tool execution.

Logs, screenshots, and evidence

Transcript inspection of one affected turn showed two separate persisted assistant messages:

• commentary/progress message

  • message id: 4fb901fa
  • role: assistant
  • first text block:
    • type = text
    • textSignature = None
  • stopReason = toolUse

• final answer

  • message id: 8eb03737
  • role: assistant
  • first text block:
    • type = text
    • textSignature = None
  • stopReason = stop

Control UI code already appears to have phase-aware logic for assistant text:

• provider-stream-BtN3gEYv.js

  • parseTextSignature(...)
  • supports commentary and final_answer

• control-ui/assets/index-DV4QBOU4.js

  • Qa(textSignature) parses phase
  • eo(...) prefers final_answer

However, the persisted transcript messages above did not retain textSignature, so the frontend had no phase metadata available for rendering.

Impact and severity

Affected users/systems/channels:

• Control UI chat users, especially on tool-using / investigative turns

Severity:

• UX / behavior bug that makes the assistant appear repetitive or broken

Frequency:

• Observed repeatedly, not as a one-off incident

Consequence:

• a single request can look like multiple replies
• trust in the chat experience degrades
• tool-heavy turns feel noisy and duplicated

Additional information

This looks more like a transcript/history metadata loss bug than a simple frontend repaint bug.

Most likely affected areas:

• assistant transcript persistence / append path
• transcript-to-history projection
• chat.history response shaping
• Control UI fallback rendering when phase metadata is missing

Suggested fix direction:

• preserve textSignature.phase (commentary vs final_answer) end-to-end through transcript persistence, history projection, and Control UI rendering
• as a fallback, Control UI could visually downgrade or collapse assistant messages associated with stopReason=toolUse when they are commentary-like rather than final answers