openclaw - 💡(How to fix) Fix [Bug]: WebChat composer can show stale `In progress` state hours later

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

The WebChat composer can continue showing an In progress status pill long after the assistant turn appears to have completed or should no longer be active.

Steps to reproduce

Exact reproduction is not confirmed yet, but the observed flow was:

1. Use WebChat in a direct conversation.
2. Start an assistant interaction that shows the composer In progress state.
3. Allow the interaction to complete, stall, or be interrupted.
4. Return to the conversation hours later.
5. Observe that the composer still shows In progress.

Expected behavior

The composer status should clear when the active assistant turn/session reaches a terminal state, such as:

• completed
• failed
• cancelled
• interrupted
• timed out
• disconnected and later reconciled as inactive

If the frontend cannot determine the run state, it should eventually recover to a neutral state or show a retry/reconnect affordance instead of leaving the composer indefinitely marked as In progress.

Actual behavior

The composer footer still showed an In progress pill several hours after the relevant assistant activity.

Visible UI details from the screenshot:

• Composer placeholder: Message Lily Vale (Enter to send)
• Footer controls visible:
  • attach file
  • Start Talk
  • settings
  • In progress
• The stale In progress pill remained visible even though the associated work should have been complete or inactive by then.

OpenClaw version

OpenClaw 2026.5.27 (27ae826)

Operating system

Ubuntu 26.04 LTS (resolute), Linux 7.0.0-15-generic, x86_64

Install method

npm global

Model

GPT-5 / Codex runtime

Provider / routing chain

openclaw -> openai-codex -> GPT-5

Additional provider/model setup details

Default route for this WebChat turn is OpenClaw -> Codex runtime -> GPT-5.

The local OpenClaw config has provider profiles for ollama, openai, openai-codex, and lmstudio, but this specific assistant response is being handled by the Codex runtime, not the minimax default shown in the placeholder.

No API keys, tokens, or passwords included.

Logs, screenshots, and evidence

A screenshot shows the WebChat composer footer still displaying `In progress` hours after the relevant activity.

The screenshot was captured later than the original event, but the stale state was still present at capture time.

Impact and severity

A stale In progress indicator makes it look like OpenClaw is still busy. This can confuse users about whether they should wait, refresh, retry, or send a follow-up message.

It also weakens trust in the composer status indicator for genuinely long-running work.

Additional information

This may be caused by one of:

• frontend inProgress state not clearing after terminal run states
• missed session/run completion event
• websocket disconnect or reconnect missing a completion event
• no periodic reconciliation of active run status
• backend session status remaining active after the worker/turn has stopped
• local UI state persisting across reloads/navigation without validation

Ensure composer progress state is driven by authoritative session/run status and reconciled after reconnects or stale local state.

Potential implementation checks:

• Clear local inProgress state on all terminal run states.
• On WebSocket reconnect, refetch active session/run status.
• Add a timeout or stale-state reconciliation path for long-running composer states.
• If a run cannot be found or has no active worker, clear the composer state or show a recoverable warning.
• Avoid persisting inProgress UI state without validating it against backend status.