Issue draft: WebUI Stop button can stay active after assistant reply is already visible

Title

WebUI Stop button sometimes remains active after the assistant reply has completed

Summary

In OpenClaw 2026.5.2, the WebUI / Control UI sometimes keeps showing the red Stop button even after the assistant reply has already appeared in the chat. Refreshing the page resets the UI back to the normal Send button.

From the user's perspective, the run looks complete because the final assistant message is visible, but the WebUI still appears to think a run is active.

Observed behavior

1. Send a message in WebUI.
2. Assistant reply appears in the chat.
3. The bottom-right button still remains the red Stop button.
4. Refreshing the WebUI page changes it back to the normal Send button.

The user did not click Stop or otherwise interrupt the assistant response.

Expected behavior

Once the assistant final reply has been rendered, the WebUI should clear the active run state and switch the input button back to Send automatically, without requiring a page refresh.

Local evidence / notes

Environment:

• OpenClaw: 2026.5.2 (8b2a6e5)
• OS: Windows 11 x64
• Surface: WebUI / Control UI direct chat
• Session key shape: agent:main:dashboard:<uuid>

A local session_status after the issue reproduced showed the current session still associated with a queue/run state even though the visible assistant reply had already appeared:

Session: agent:main:dashboard:<uuid>
Queue: steer (depth 0)

A sessions_list inspection shortly after also showed the same WebUI session with status: "running" while the last assistant message preview was already the completed visible reply:

{
  "key": "agent:main:dashboard:<uuid>",
  "channel": "webchat",
  "lastMessagePreview": "<redacted completed assistant reply preview>",
  "status": "running",
  "startedAt": <timestamp>
}

Recent logs around the same period showed repeated sessions.list / chat.history responses and liveness warnings while the UI remained in a running-looking state. Refreshing the page made the button normal again, suggesting the browser-side state may be missing or not applying the final lifecycle/update event, or the session store keeps status: running after the final message is visible.

Possible cause areas

From local inspection of the bundled Control UI code, the Send/Stop state appears tied to chatRunId, chatSending, and/or active session state such as hasActiveRun / session status.

Possible failure modes:

1. Final chat lifecycle event is missed or ignored by the WebUI, so chatRunId is not cleared.
2. Session list/state continues to report the session as active/running after the assistant final message has been written.
3. Reconnect or dashboard-scoped session switching causes the final event to be filtered out by run id/session key matching.
4. WebUI recovers on refresh because onHello / reload clears local chatRunId, but it does not reconcile this while the page stays open.

Requested improvement

Please make the WebUI robustly reconcile completed runs so that if the final assistant message is already present and there is no active run, the Stop button returns to Send automatically.

Potential fixes could include:

• Ensure the final chat event always clears the frontend run state.
• Ensure session status / hasActiveRun is updated promptly after final output.
• Add a reconciliation path after chat.history / sessions.list refreshes to clear stale local running state.
• If a run is marked running for too long after a final assistant message is visible, recover the input state or show a clearer stale-state indicator.

Related observation

This appeared while using dashboard-scoped sessions created by WebUI /new, e.g. agent:main:dashboard:<uuid>, but it is unclear whether the issue is specific to dashboard sessions or general WebUI run-state handling.