Summary

After updating to 2026.2.17, the WebUI (control-ui) chat displays raw "Conversation info (untrusted metadata)" blocks inside user messages. These internal metadata blocks are intended for the model, not the end user.

Steps to reproduce

1. Open WebUI chat (/chat)
2. Send any message (e.g., "hello")
3. Message appears clean initially (local copy)
4. Wait for assistant to respond
5. After the assistant turn completes, the user message now shows:

Conversation info (untrusted metadata):
{"message_id":"...","sender":"openclaw-control-ui"}

[Wed 2026-02-18 18:04 GMT+1] hello

Expected behavior

User messages in the WebUI should display only the original text, without internal metadata blocks.

Actual behavior

Why the block is now generated for webchat

Two changes in 2026.2.17 populate sender_id and message_id in inbound metadata for all channels, including webchat:

• "Auto-reply/Prompts: include trusted inbound message_id in conversation metadata payloads" (tyler6204)
• "Auto-reply: include sender_id in trusted inbound metadata" (feat(inbound-meta): expose sender_id in trusted system metadata #18303, crimeacs)

In buildInboundUserContextPrefix(), the "Conversation info" block is generated when Object.values(conversationInfo).some(v => v !== undefined). Before 2026.2.17, SenderId and MessageSid were empty/undefined for webchat, so the block was never generated. Now SenderId = "openclaw-control-ui" and MessageSid = clientRunId, making the block non-empty.

Why stripping doesn't catch it

stripEnvelopeFromMessages() (used by chat.history RPC) only strips [Channel Timestamp] envelope headers via regex /^\[([^\]]+)\]\s*/. It does not recognize the newer "Conversation info (untrusted metadata):" block format.

The timing behavior

1. User sends message → frontend shows clean local copy
2. Assistant responds, turn ends → frontend calls chat.history to reload
3. stripEnvelopeFromMessages() runs but only strips [Channel Timestamp] headers
4. "Conversation info" block survives stripping → displayed to user

Suggested Fix

Either:

1. Extend stripEnvelopeFromMessages() to also strip the "Conversation info (untrusted metadata):" block
2. Or: Don't inject the block into webchat messages in the first place (webchat is an internal channel, not untrusted)

OpenClaw version

2026.2.17

Operating system

Linux (Xubuntu 24.04)

Install method

npm global

Logs, screenshots, and evidence

The metadata block appears in every user message bubble after the assistant completes its turn and the frontend reloads chat.history.
Server logs show no errors — the issue is purely in the strip logic for history responses.

Impact and severity

Affected: All WebUI/control-ui webchat users on 2026.2.17
Severity: Cosmetic (annoying, does not block functionality)
Frequency: 100% repro on every message after assistant responds
Consequence: Raw internal metadata visible in chat, clutters conversation view

Additional information

Regression introduced in 2026.2.17. Not present in 2026.2.15. Root cause: two new features (message_id + sender_id in inbound metadata) now populate fields for webchat that were previously empty, triggering the "Conversation info" block generation for the first time on the webchat channel.