Summary

In OpenClaw Control UI chat, a just-sent user message appears immediately, then disappears for about 1 to 2 seconds, then reappears.

This appears to have started after the latest update.

Symptoms

When sending a message in Control UI:

• the message lands in the chat area immediately
• then vanishes briefly
• then pops back into the transcript about 1 to 2 seconds later

This was observed repeatedly, including on plain text messages.

Expected behavior

A sent user message should remain visible continuously after local send, without disappearing during reconciliation.

Actual behavior

The message appears optimistically, then disappears, then reappears after the server-backed transcript catches up.

Repro

1. Open Control UI chat
2. Send a normal text message
3. Watch the just-sent message in the transcript
4. Observe it appear immediately, disappear briefly, then reappear 1 to 2 seconds later

Evidence / investigation notes

This looks like a front-end optimistic-message reconciliation problem rather than a transport failure.

Relevant Control UI runtime behavior observed locally in dist/control-ui/assets/index-*.js:

• the send path appends the user message locally to chatMessages immediately
• chat.send is then issued to the gateway
• later, the UI refresh path calls chat.history
• the returned history replaces chatMessages

The local optimistic user message does not appear to carry a stable persisted message id, and display keys fall back to combinations like timestamp/index when no stable id is present.

That makes it plausible for the optimistic local message and the later persisted/history-backed message to be treated as different entries rather than a clean reconciliation of the same message.

Likely root cause

Control UI is showing an optimistic local user message first, then a later chat.history refresh replaces the full message list before the persisted server-backed version is reconciled cleanly.

That causes the optimistic copy to disappear briefly, then the history-backed copy to show up shortly after.

Suggested fix

Possible approaches:

Preferred:

• assign optimistic user messages a stable client id and reconcile them against the persisted history message

Also reasonable:

• merge chat.history results with pending optimistic messages instead of replacing the full array blindly

Less ideal:

• reduce or defer full-history replacement immediately after send

Environment

• OpenClaw Control UI
• User reports this started after the latest update