openclaw - 💡(How to fix) Fix [UX] Inbound user message not visible in control-UI until full turn completes (atomic session commit) [2 comments, 2 participants]

Summary

The OpenClaw control-UI / dashboard does not show inbound user messages or in-progress assistant turns until the full agent turn completes and the reply is delivered to the channel. For long turns (multi-step tool use, subagent spawns), the operator sees a dark UI for tens of seconds to several minutes between message arrival and reply delivery, with no signal that the agent is processing.

Reproduced on 2026.5.12; the user reports the same behavior on 2026.5.18. Likely architectural / longstanding.

Reproduction

1. Open the control-UI for a main-style agent (any active Telegram group/topic or DM).
2. From Telegram, send a message that triggers a long-running turn (e.g. one that fans out to subagents or runs several exec/web_search tools).
3. Observe the control-UI chat panel while the turn runs.

Expected: the inbound user message appears in the UI immediately on arrival; subsequent assistant deltas / tool calls show up incrementally as they are produced.

Actual: the chat panel remains empty / stale for the full duration of the turn. The new user message, all assistant deltas, and all tool calls appear in the UI simultaneously only after the channel-bound reply is delivered.

Evidence — atomic session-file commit

Captured from a real turn. Gateway journal:

06:30:11  [telegram] Inbound message ...                     ← inbound arrives
06:30:21  [ws] ⇄ res ✓ sessions.list                          ← UI poll (no new content)
06:30:22  [ws] ⇄ res ✓ chat.history                           ← UI poll (no new content)
06:30:44  [ws] ⇄ res ✓ chat.history                           ← UI poll (still nothing)
06:31:09  [telegram] outbound send ok ...                    ← reply delivered to channel
06:31:32  [ws] ⇄ res ✓ chat.history                           ← UI poll — now everything appears

Session file agents/main/sessions/<sid>.jsonl for the same turn:

06:31:11.274Z  type=session
06:31:11.274Z  role=user        len=45      ← the inbound user message
06:31:11.278Z  role=assistant   len=230
06:31:11.280Z  role=toolResult  len=790
06:31:11.282Z  role=assistant   len=494
06:31:11.285Z  role=toolResult  len=3288
06:31:11.288Z  role=assistant   len=692
06:31:11.291Z  role=toolResult  len=19310
06:31:11.293Z  role=assistant   len=1875
06:31:11.296Z  role=toolResult  len=470
06:31:11.298Z  role=assistant   len=52

All 11 lines have timestamps within a 25 ms window at 06:31:11, ≈ 60 seconds after the inbound at 06:30:11 and immediately after the channel reply was delivered at 06:31:09. The user-message entry (role=user, the actual inbound text) is timestamped 06:31:11.274Z, not 06:30:11 when Telegram delivered it.

So the session jsonl is being written atomically at end-of-turn: user message + every assistant chunk + every tool result are flushed together once the reply is finalized. Before that, the file does not contain the new turn. chat.history reads from this file (or its in-memory equivalent), which is why the UI cannot show anything until the turn closes.

Impact

• Operator cannot tell whether an inbound message was even received, much less whether the agent is making progress.
• For agentic flows with long tool chains (subagent spawns, web fetches, codex tool use), the dark window can be 30 s – 10 min+.
• No "typing" / "thinking" indicator in the UI bridges the gap.

Suggested fix direction

1. Persist the inbound user message to the session record (and emit a WS push event) immediately on arrival, before the turn is processed.
2. Emit incremental WS push events for assistant deltas / tool calls as they are produced, not only at turn-end.
3. Optionally, surface "agent is working" state from the existing [agent/embedded] strict-agentic execution contract active lifecycle into a UI badge.

Acceptance test idea: after dispatching an inbound message, a control-UI chat.history call within 1 second should return the new user message, even while the agent is still mid-turn.

Workaround for operators

None known short of tailing journalctl --user -u openclaw-gateway to see [telegram] Inbound, [plugins] active-memory:, and [agent/embedded] strict-agentic execution contract active events directly.

Versions

• Confirmed on 2026.5.12 (commit f066dd2).
• Reporter also observed the same on 2026.5.18.
• Not version-specific; appears to be longstanding architectural behavior of the session-message-persist path.