openclaw - 💡(How to fix) Fix WebChat / Control UI can duplicate assistant replies in new sessions [2 comments, 3 participants]

Summary

In webchat / OpenClaw Control UI, starting a new chat can cause assistant messages to appear twice. The duplication also affected subsequent normal replies in the same session.

Based on logs + session history, this does not look like the model generated two different replies. It looks more like the same assistant message was written/applied twice during new-session initialization, history replay, or state restore.

Environment

• OpenClaw: 2026.4.24
• Surface: webchat
• Client label: openclaw-control-ui
• Session type: direct
• Observed on: 2026-04-26 16:35-16:40 Asia/Shanghai

What happened

After opening a new session, the first assistant reply appeared twice. Then later replies in the same session also appeared duplicated in pairs.

Key evidence

1) sessions_history contains duplicated records

In agent:main:main, duplicated assistant replies appear as pairs. The same is true for the corresponding user messages.

For each duplicated assistant pair:

• text is identical
• timestamp is identical
• responseId is identical

That strongly suggests this was not two separate model generations.

2) Gateway logs show only a single chat.send

For the relevant window (2026-04-26 16:34:00 to 16:41:30 Asia/Shanghai), logs show only a single chat.send for the duplicated reply window, for example:

2026-04-26T16:39:33.565+08:00 [ws] ⇄ res ✓ chat.send 66ms runId=6b2ca02e-43d4-4601-a6be-e6f6d87031d1 conn=1d5c9dbd…7664 id=9d3334c1…06ab

At the same time, there are many chat.history and sessions.list requests around new-session initialization.

3) Timing lines up with new-session bootstrap / history replay

In the 16:34:58 to 16:35:34 window, there are repeated:

• chat.history
• sessions.list
• models / commands / node list initialization requests

This looks consistent with Control UI bootstrap behavior after opening a fresh session.

Expected

A message should be persisted/applied exactly once.

Actual

The same message seems to be duplicated into session history / applied twice.

Likely area

One of these seems likely:

1. The first assistant message is applied once from the live event stream and again from chat.history
2. WebSocket reconnect / state restore re-applies the same message event
3. Session store append path lacks idempotency for the same stable message / responseId
4. History merge logic appends without deduping by stable id

Notes

This does not look like a pure UI-only duplicate rendering bug, because sessions_history itself already contains the duplicate records.

If helpful

I can provide a fuller local evidence bundle, but the most important discriminator is:

• single chat.send in logs
• duplicated sessions_history records with identical responseId + identical timestamp