Skip to content

[Bug]: WebChat briefly hides newly sent message before it reappears #66176

@hansolo949

Description

@hansolo949

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In WebChat / Control UI, a newly sent user message can briefly disappear and then reappear a moment later.

Steps to reproduce

Observed on a local macOS install after a hard refresh of Control UI:

  1. Open WebChat / Control UI
  2. Send a normal text message
  3. Watch the message list immediately after send
  4. The just-sent user message appears, briefly disappears, then reappears once the UI catches up

Expected behavior

A just-sent user message should remain stably visible after optimistic send.

Actual behavior

The just-sent message is rendered optimistically, then briefly vanishes from the visible transcript, then reappears.

OpenClaw version

2026.4.12

Operating system

macOS Darwin 24.6.0 (x64), Node v22.22.0

Install method

npm / LaunchAgent-hosted local gateway

Model

openai-codex/gpt-5.4

Provider / routing chain

WebChat Control UI -> local OpenClaw gateway/runtime -> openai-codex/gpt-5.4

Additional provider/model setup details

No response

Logs, screenshots, and evidence

No screenshot captured yet, but the behavior was directly visible in WebChat during a clean post-refresh sanity pass.

Likely implementation clue from local bundle inspection:

  • outgoing user messages are appended optimistically on send
  • the UI also does a full chat.history replacement of the current message list
  • if chat.history returns before the just-sent message is fully persisted server-side, the optimistic message can disappear briefly and then reappear once history/event state catches up

This looks like a client-side optimistic-send/history-resync race, not the separate System (untrusted) exec-leak bug.

Impact and severity

Affected: WebChat / Control UI users
Severity: Annoying
Frequency: Intermittent but easy to notice when watching closely
Consequence: Makes the UI feel unreliable even when the message is not actually lost

Additional information

This was observed in the same general debugging session as the WebChat internal-system-message leak, but it appears to be a separate issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions