openclaw - 💡(How to fix) Fix [Bug]: Webchat messages stored twice in session — duplicate bubbles in Control UI [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Bug: Every user message sent via the Control UI (webchat) is stored twice in the session .jsonl transcript, creating duplicate chat bubbles in the UI.

Root Cause: Each webchat message creates two separate user-role messages that share the same parentId (fork from the same parent):

Metadata envelope — emitUserTranscriptUpdate stores a bare text message with raw sender metadata: Copy Sender (untrusted metadata): { "label": "openclaw-control-ui", "id": "openclaw-control-ui" } Clean user text — The agent runner stores the actual user message: Copy [Mon 2026-04-27 08:21 GMT] Are there any sessions running in my openclaw? Both share the same parent ID → fork in the conversation tree → Control UI renders both → two bubbles per message.

Evidence: Analysed a live session .jsonl — found 12 fork points, each with 2 sibling user messages (metadata envelope + actual text). Happens for every webchat message.

Expected: Only one user message per actual input. Metadata should either be a property on the single message or marked hidden so the UI skips it.

Env: OpenClaw 2026.4.24, channel: webchat

Steps to reproduce

1. Start a fresh OpenClaw instance with the webchat channel enabled
2. Open the Control UI in a browser
3. Send any message via the webchat input
4. Observe: the message appears as two separate chat bubbles in the UI
5. Inspect the session .jsonl file in <dataDir>/agents/main/sessions/ — each user message creates two user-role entries with the same parentId

Expected behavior

Only one user message per actual input. Metadata should either be a property on the single message or marked hidden so the UI skips it.

Actual behavior

In a webchat session, every user message sent from the Control UI produces two user-role message entries in the session .jsonl file, both sharing the same parentId. For example, in session e1500991-1fb4-4954-8145-6d19f5a1XXXX.jsonl, analysis found 12 fork points where two sibling user messages share a parent:

One sibling contains the raw metadata envelope text: `Sender (untrusted metadata):\n```json\n{"label": "openclaw-control-ui", "id": "openclaw-control-ui"}\n```` The other sibling contains the actual user text: [Mon 2026-04-27 08:21 GMT] Are there any sessions running in my openclaw? The Control UI renders both siblings as separate chat bubbles, causing every message to appear duplicated.

OpenClaw version

OpenClaw 2026.4.24

Operating system

Debian GNU/Linux 12 (bookworm) inside Docker container; host kernel Linux 6.8.0-107-generic (Ubuntu)

Install method

No response

Model

glm-5.1

Provider / routing chain

Browser → Traefik reverse proxy (host) → Gateway container (local mode, port 18789) → Ollama cloud API

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Fork point analysis — 20 fork points found where two user messages share the same parentId. Every fork follows the same pattern: one metadata envelope + one clean user text.

Sample duplicate pair (fork at parentId=bc75024e...):

Copy
// Line 40 — metadata envelope
{
  "type": "message",
  "id": "fda1a6d7...",
  "parentId": "bc75024e...",
  "timestamp": "2026-04-26T22:59:33.751Z",
  "message": {
    "role": "user",
    "content": [{
      "type": "text",
      "text": "Sender (untrusted metadata):\n\n{\"label\":\"openclaw-control-ui\",\"id\":\"openclaw-control-ui\"}\n\n\n[Mon 2026-04-27 00:59 GMT+2] Or not. Cheered to soon"
    }]
  }
}

// Line 45 — clean user text  
{
  "type": "message",
  "id": "deeff732...",
  "parentId": "bc75024e...",
  "timestamp": "2026-04-26T22:59:43.163Z",
  "message": {
    "role": "user",
    "content": [{
      "type": "text",
      "text": "[Mon 2026-04-27 00:59 GMT+2] Or not. Cheered to soon"
    }]
  }
}
Both share parentId=bc75024e..., both are role=user, created 10 seconds apart. The first is the raw emitUserTranscriptUpdate entry (with metadata wrapper), the second is the agent runner's clean entry. The Control UI renders both as separate bubbles.

Impact and severity

No response

Additional information

No response