openclaw - 💡(How to fix) Fix [Bug]: Webchat composer stays stuck on red Stop button after response completes

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In the webchat UI, the composer button sometimes remains stuck as the red Stop button after the assistant has visibly finished responding. The backend appears idle: session status/gateway stability can show queue depth 0, and the next message sends immediately even though the UI labels it as queued. This looks like the frontend run/composer state is not being cleared after response completion.

Steps to reproduce

1. Open the OpenClaw webchat/control UI.
2. Send a normal chat message.
3. Wait until the assistant response is visibly complete.
4. Observe the composer button.
5. Sometimes the button remains red and says Stop instead of returning to Send. Other times, it returns to the send button and then many seconds later, it returns to the Stop button even though it didn't start thinking again or anything.
6. Type another message and send via the queue button.
7. The UI does not queue the message, but rather sends immediately.
8. Check backend status; queue depth can show 0 while the UI still appears stuck in active-run state.

Expected behavior

Bug: Webchat send button remains stuck as red Stop button after response is complete

Summary

In the OpenClaw webchat UI, the message composer button sometimes remains in the red Stop state even after the assistant has clearly finished responding. The next message can still be sent immediately, but the UI continues to look like the previous run is active.

Expected behavior

After the assistant finishes responding, the composer button should change back from red Stop to normal Send.

Actual behavior

After the response is complete and visible in the chat, the composer button sometimes stays as the red Stop button. If I type another message, the button/action appears as Queue, but the message sends immediately rather than waiting behind an active run. This suggests the backend is no longer busy but the frontend still thinks the run is active.

Reproduction steps

1. Open the OpenClaw webchat UI.
2. Send a normal message.
3. Wait for the assistant response to complete.
4. Observe the composer button.
5. In some cases, the button remains red Stop even though the response is done.
6. Type another message and send it.
7. The next message sends immediately, despite the UI implying it is queued behind an active run.

Environment

• OpenClaw version: 2026.5.27
• Install type: pnpm
• Channel: stable
• OS: Linux 6.8.0-117-generic x64
• Node: 22.22.2
• Gateway mode: local (Ubuntu 24.04 64bit headless)
• Gateway bind: loopback
• Gateway service: systemd user service
• UI surface: OpenClaw webchat / control UI
• Browser: Chrome 148.0.7778.179 (64-bit)
• Client OS/device: windows 11 64bit

Relevant status output

openclaw update status reports:

Install: pnpm
Channel: stable (default)
Update: pnpm · up to date · npm latest 2026.5.27
openclaw gateway status reports:

Copy
CLI version: 2026.5.27
Gateway version: 2026.5.27
Runtime: running
Connectivity probe: ok
Capability: admin-capable
When the UI appears stuck, backend status can show no active queue:

Copy
Queue: steer (depth 0)
openclaw gateway stability also showed recent heartbeat entries with:

Copy
queued=0
Why I think this is a UI state bug
The UI remains in Stop/Queue mode, but the backend appears idle and the next message sends immediately using the queue button. That makes it look like the frontend run-state/composer state is not being cleared after the assistant response completes.  Also, sometimes, it finishes and is clearly ready for the next chat message, but then the stop button appears after a few seconds of being ready for the next message.  This started maybe a week or two ago and I've updated several times since then.  Obviously restarting the gateway and even the pc.

Workarounds tried
Updated OpenClaw to latest stable: still occurs.
Refreshed/reopened the chat: temporarily clears the UI state.
Backend queue does not appear stuck when checked.

### Actual behavior

After an assistant response is visibly complete in the webchat UI, the composer button sometimes remains in the red Stop state instead of returning to Send. When typing another message, the UI may present it as Queue/queued behavior, but the message sends immediately.

Evidence from backend checks during/around this state:
- Session status showed queue depth 0.
- `openclaw gateway stability` showed heartbeat entries with `queued=0`.
- The next user message was accepted immediately, which suggests no active backend run was actually blocking the queue.

No user-visible error message appears; the issue is stale/incorrect composer button state.

### OpenClaw version

2026.5.27

### Operating system

Windows 11 64bit client, Ubuntu 24.04 64bit server headless

### Install method

pnpm / npm-global CLI

### Model

local and paid (qwen3.5, gemma4 as local models as well as gemini flash 2.5 and in the screenshot (gpt codex 5.5)

### Provider / routing chain

Browser webchat UI -> OpenClaw control UI at private web page -> local OpenClaw gateway on 127.0.0.1:18789 -> selected model provider

### Additional provider/model setup details

screenshot attached

<img width="1878" height="362" alt="Image" src="https://github.com/user-attachments/assets/bb3e5ca4-2de1-42a0-a5e6-e9125e19560d" />

### Logs, screenshots, and evidence

```shell

Impact and severity

Affected users/systems/channels: Observed in the OpenClaw webchat/control UI. Backend gateway/session state appears healthy when checked, so the observed impact is on the webchat UI composer state rather than message delivery.

Severity: Annoying / confusing UI state bug. It does not appear to block sending messages, and I have not observed data loss or missed messages. This is especially problematic when using slower local models. It's hard to know if it is done.

Frequency: Intermittent. It happens often enough (more times than not, like 80%) to notice during normal chat use, but not on every message. I can't figure out why it sometimes doesn't happen, but even when it doesn't, if I wait a few seconds, it just changes the sent button to a stop button after it's clearly done thinking.

Consequence: The UI incorrectly suggests an assistant run is still active after the response is complete. This can cause confusion because the composer remains in red Stop/Queue mode even though the next message sends immediately and backend status can show queue depth 0. Practical consequence is extra user uncertainty and needing to refresh/reopen the chat to clear the stale state.

Additional information

I'm sorry, I don't know what version (if this is a bug) where it didn't happen, but a few weeks ago, I didn't notice it.