openclaw - 💡(How to fix) Fix [Bug]: Control UI intermittently loses webchat state and renders NO_REPLY as NO [2 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Summary

The OpenClaw Control UI/webchat sometimes appears to lose conversation or draft state, making it look like the user’s typed message/conversation disappeared. Separately, assistant responses that are exactly NO_REPLY appear to render incorrectly as NO in the UI.

Environment

• OpenClaw version: 2026.4.26
• Gateway: local, loopback WebSocket
• Host OS: Linux 7.0.0-14-generic x64
• Node: v22.22.1
• Surface: Control UI / webchat
• Browser/device: TBD

Observed behavior

1. Conversation/draft state disappears intermittently

Occasionally, while using the Control UI webchat, the conversation or typed message appears to reset/disappear, as if the user had not typed it.

Gateway did not appear to restart during the observed window. Session remained active.

Relevant log clue around one occurrence:

[diagnostic] lane wait exceeded: lane=session:agent:main:main waitedMs=4354 queueAhead=0

### Steps to reproduce

1. Use OpenClaw Control UI webchat.
2. During normal chat, occasionally the typed message or conversation appears to disappear/reset.
3. Trigger a cron/system event where the assistant is instructed to return exactly `NO_REPLY`.
4. Observe that the Control UI renders `NO` instead of suppressing the message or rendering `NO_REPLY`.

### Expected behavior

- Webchat should preserve visible conversation and draft/input state across reconnects or backend delays.
- `NO_REPLY` should not render partially as `NO`; it should either be suppressed or shown consistently as `NO_REPLY`.

### Actual behavior

- Conversation/input state sometimes appears to disappear.
- `NO_REPLY` appears in the Control UI as `NO`.

### OpenClaw version

2026.4.26

### Operating system

Linux 7.0.0-14-generic x64 / Ubuntu 26

### Install method

npm

### Model

openai-codex/gpt-5.5

### Provider / routing chain

OpenClaw Control UI webchat → local OpenClaw Gateway → main agent session → OpenAI/Codex model provider

### Additional provider/model setup details

- OpenClaw version: 2026.4.26
- Gateway: local, loopback WebSocket
- Host: Linux 7.0.0-14-generic x64
- Node: v22.22.1
- Surface: Control UI / webchat
- Session: main agent direct session
- Default model shown by status: gpt-5.5

### Logs, screenshots, and evidence

```shell
Observed issue 1: Control UI/webchat intermittently appears to lose typed message or conversation state.

Observed issue 2: A cron/system task instructed the assistant to reply exactly:

`NO_REPLY`

But the Control UI rendered it as:

`NO`

Relevant gateway log clue around the same session:


[diagnostic] lane wait exceeded: lane=session:agent:main:main waitedMs=4354 queueAhead=0

Impact and severity

Severity: Medium

Impact:

• User can lose confidence that messages were sent or preserved.
• Draft/conversation disappearance can cause lost work for longer prompts.
• NO_REPLY rendering as NO creates confusing/incorrect visible chat output for scheduled tasks and silent responses.
• This affects Control UI/webchat reliability and polish, but does not appear to corrupt backend session state.

Additional information

The disappearing conversation/draft issue is intermittent.

The NO_REPLY issue may be easier to reproduce:

1. Use Control UI webchat.
2. Trigger a cron/system event that instructs the assistant to return exactly NO_REPLY.
3. Observe Control UI rendering.

Expected behavior:

• Preserve conversation and draft state across reconnects/backend delays.
• Suppress NO_REPLY or render it consistently; do not partially render it as NO.

Suggested areas to inspect:

• WebSocket reconnect/session hydration path
• Local draft state persistence
• Message renderer/sentinel stripping logic
• Handling of silent replies from cron/system events