Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Control UI webchat can continue showing a busy or abortable state after an assistant response has completed, even though backend state is clean and messages continue working.

Steps to reproduce

1. Run OpenClaw 2026.5.26 (10ad3aa) with the gateway on 127.0.0.1:18789.
2. Open a Control UI webchat direct session in Windows Chrome.
3. Send a normal webchat message and wait for the assistant response to complete.
4. Observe that backend state is clean, but the UI can still show a busy/abortable state.
5. Hard refresh clears the visual state until the next message cycle.

Expected behavior

After the assistant response completes and no local stream is active, the bottom status badge and composer control should return to idle/send state.

Actual behavior

The chat response completes and messages still work, but the Control UI can continue showing "In progress" or keep the composer button as "Stop" even though backend state is clean.

OpenClaw version

2026.5.26 (10ad3aa)

Operating system

Windows 11 Chrome client with WSL2/Linux OpenClaw gateway

Install method

npm global

Model

gpt-5.5

Provider / routing chain

OpenClaw webchat direct session using OpenAI Codex runtime

Additional provider/model setup details

OpenClaw webchat direct session using OpenAI Codex runtime.

Environment details:

• Windows 11 Chrome client
• WSL2/Linux OpenClaw gateway
• Linux kernel: 6.6.87.2-microsoft-standard-WSL2
• Gateway: 127.0.0.1:18789

Logs, screenshots, and evidence

Backend evidence:
- Gateway reachable on 127.0.0.1:18789
- queue depth 0
- tasks active/queued/running all 0
- task audit clean
- messages still send/receive normally

Frontend evidence / likely cause:
The built Control UI asset appeared to derive visible busy/abort UI from stale `canAbort` / session-list state. `Gm(e)` can return true from `chatRunId` or `sessionsResult.sessions.some(...)`, and that stale value was enough to keep visible busy controls alive after the stream completed.

Local narrow patch that fixed the observed behavior:
- Define local live state: `r = e.sending || e.stream !== null`
- Badge fix: only force `in-progress` when `canAbort && r`
- Composer fix: pass `canAbort: a && r` instead of `canAbort: a`

Result:
After hard refresh, the false sticky badge and Stop button no longer reproduced. Backend remained clean before and after the patch.

Impact and severity

Affected users/systems/channels:
Control UI webchat users, especially in longer/tool-heavy sessions where session metadata can lag or rehydrate stale.

Severity:
Medium. Chat still works, but the UI falsely appears to be running or abortable after completion, which makes users think the run is stuck and may cause unnecessary refreshes/restarts.

Frequency:
Reproduced repeatedly in one OpenClaw 2026.5.26 environment until patched locally.

Consequence:
False stuck/busy UI state, user confusion, unnecessary troubleshooting, and possible accidental Stop clicks after a run is already complete.

Additional information

Suggested upstream fix: split visible main composer/badge busy state from stale session-list abortability. canAbort may still be useful for remote/session abort affordances, but the main webchat badge and Stop button should only show active/busy while an authoritative local live send/stream/run state is active.