openclaw - 💡(How to fix) Fix Control UI: user message disappears from chat view while agent runtime is processing (2026.4.29) [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78711Fetched 2026-05-07 03:33:30
View on GitHub
Comments
1
Participants
2
Timeline
8
Reactions
2
Timeline (top)
mentioned ×3subscribed ×3closed ×1commented ×1

In the OpenClaw Control UI (/chat), the user's submitted message disappears from the chat view after submit while the agent is processing, and only reappears (or is replaced by the assistant reply) when the agent emits its final response — which can be 60–90s later when agentRuntime: codex is configured and the model performs many exec / write tool calls.

This makes the UI feel like the message was lost, encouraging users to re-send.

Root Cause

In the OpenClaw Control UI (/chat), the user's submitted message disappears from the chat view after submit while the agent is processing, and only reappears (or is replaced by the assistant reply) when the agent emits its final response — which can be 60–90s later when agentRuntime: codex is configured and the model performs many exec / write tool calls.

This makes the UI feel like the message was lost, encouraging users to re-send.

Fix Action

Workaround

Cmd+Shift+R after submitting restores both the user message and the assistant reply from the persisted session.

RAW_BUFFERClick to expand / collapse

Summary

In the OpenClaw Control UI (/chat), the user's submitted message disappears from the chat view after submit while the agent is processing, and only reappears (or is replaced by the assistant reply) when the agent emits its final response — which can be 60–90s later when agentRuntime: codex is configured and the model performs many exec / write tool calls.

This makes the UI feel like the message was lost, encouraging users to re-send.

Environment

  • OpenClaw: 2026.4.29 (a448042)
  • Self-hosted gateway, exposed via Cloudflare named tunnel
  • Auth: gateway.auth.mode = "token" + per-device pairing
  • Agent: main, agentRuntime: { id: "codex" }, default model codex/gpt-5.5, thinking medium
  • Browser: Chrome (latest) on macOS
  • Front URL form: https://<host>/chat?session=agent%3Amain%3Amain

Repro

  1. Open the Control UI at /chat for an agent backed by the codex runtime.
  2. Send a multi-line / non-trivial message that triggers the agent to run several exec tool calls (e.g. asking it to inspect the workspace and produce a PR).
  3. Watch the chat pane during the ~60–90s the agent is working.

Expected

The submitted user message stays visible in the chat list throughout the turn, with a "thinking" / "running tools" indicator. Tool-call activity may be summarized but the user's bubble must not disappear.

Actual

  • The user message bubble briefly appears (optimistic render), then disappears from the visible chat list.
  • During the agent's tool-call loop, the chat pane shows no trace of the just-sent user message.
  • When the agent finishes (model.completed with assistantTexts != []), the assistant bubble appears, and the user bubble eventually reappears (sometimes only after a hard reload, e.g. Cmd+Shift+R).

The on-disk session jsonl does contain the user message correctly throughout, so this is a render/reconciliation issue in the UI, not a backend persistence issue.

Backend trace evidence

For one repro, agents/main/sessions/<sid>.trajectory.jsonl showed:

  • prompt.submitted timestamp matches the send time (backend received the message immediately).
  • ~25 tool.call / tool.result pairs over ~73s.
  • model.completed with data.assistantTexts: [...] at the end.
  • The corresponding <sid>.jsonl has the user message under role: "user" throughout.

So the message is present in storage; the UI just isn't displaying it during the in-flight turn.

Hypothesis

The Control UI seems to drop the optimistic-rendered user bubble once the backend acks prompt.submitted (or session.started), expecting the canonical user message to come back via WS. If the canonical record arrives only at the end of the turn — or via a reconciliation path that the renderer is not subscribed to during the turn — the bubble is missing during the wait.

A hard reload after the turn correctly shows both the user message and the assistant reply, which is consistent with this.

Suggested fix

Keep the user message rendered from submit until either:

  • the canonical user message arrives via WS (then swap the optimistic bubble with the canonical one), or
  • the turn fails (then mark the message as errored but keep it visible),

independent of the assistant turn lifecycle. Tool-call rendering during the turn (even a collapsed "agent is running tools…" affordance) would also reduce the perceived "lost message" problem.

Workaround

Cmd+Shift+R after submitting restores both the user message and the assistant reply from the persisted session.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Control UI: user message disappears from chat view while agent runtime is processing (2026.4.29) [1 comments, 2 participants]