openclaw - 💡(How to fix) Fix [Feature]: Add a compact runtime status indicator beside the Web UI composer actions [1 comments, 1 participants]

Summary

Add a small runtime status indicator in the Web UI composer toolbar, next to the existing voice and file-upload buttons, so users can tell whether OpenClaw is currently working, interrupted, or finished without reading internal logs or guessing from streaming behavior.

Problem

In the current Web UI chat experience, the area under the dialog/input box has voice and file controls, but the nearby empty space does not communicate the runtime state. During real usage this makes it hard to answer a basic question: is OpenClaw still running, did it get interrupted, or is the turn actually complete?

This ambiguity is especially painful when:

• a response takes a long time because tools, agents, or network calls are running
• streaming pauses and the user cannot distinguish "still working" from "stuck"
• a run is interrupted by refresh, disconnect, gateway restart, cancellation, or terminal failure
• the final assistant text looks complete, but background work or cleanup may still be happening
• the user wants to know whether it is safe to send another instruction

Proposed UX

Use the blank space beside the voice and send-file/upload controls in the composer area for a compact, always-visible status chip.

Minimum states:

1. In progress / 进行中

   • shown when the current session has an active run, tool call, child-agent wait, or queued/finalizing response
   • should include subtle motion or a spinner/dot pulse, but must not resize the composer

2. Interrupted / 已中断

   • shown when the client loses authoritative continuity for the current run, for example cancel, disconnect, gateway restart, stale run, failed terminal event, or unknown ownership after reconnect
   • should fail closed: do not keep showing In progress if the client is no longer sure work is still active

3. Done / 已完成

   • shown after the current user turn has reached a terminal completed state and the UI is ready for the next instruction
   • can fade back to an idle/neutral state after a short delay if the design wants less visual noise

Optional future states can be layered later, such as waiting for user, waiting for approval, waiting for sub-agent, or failed, but the first version should solve the common three-state uncertainty without making the composer busy.

Placement and interaction details

• Place the indicator in the composer toolbar row, beside the microphone and upload/file buttons, using the currently unused horizontal space.
• Keep the indicator visually secondary: compact chip, icon + short text, no large card or extra message in the transcript.
• The status should not be appended as a chat message and should not pollute conversation history.
• It should remain visible while the input is focused and while the user scrolls the transcript.
• It should be accessible: expose an aria-label or tooltip with the current state and timestamp/elapsed time if available.
• It should be responsive: on narrow mobile widths, collapse to an icon-only chip with tooltip/accessible label rather than wrapping the toolbar.
• It should avoid flicker on very fast turns, for example by showing In progress only after a short delay or by smoothing transitions.

Runtime behavior

Prefer using a session-scoped activity source rather than inferring from message text. This should connect cleanly with the direction in #39127.

Recommended mapping:

• active session run / active tool / finalizer in progress -> In progress
• terminal success for the current turn -> Done
• cancel, failed reconnect resync, stale active run, missed terminal event, gateway restart with unknown ownership -> Interrupted

If a richer activity API is not available yet, the Web UI can start with the best existing client-side lifecycle signals, but the implementation should avoid hard-coding brittle text heuristics.

Why this is distinct from related issues

Related:

• #39127 covers the gateway-owned per-session activity API and WebSocket state changes.
• #52640 covers a persistent task-status surface for long-running channel turns, especially editable channel messages.

This request is narrower and UI-specific: add a lightweight status display directly in the Web UI composer area where the user is already looking before sending the next prompt. It can consume the runtime state from #39127 when available, but it should not require adding visible status messages to the transcript.

Acceptance criteria

• The Web UI composer shows a compact runtime status indicator near the voice/file controls.
• The first version supports at least In progress, Interrupted, and Done.
• The indicator does not create chat transcript messages or modify conversation content.
• The state is session-scoped, not global across unrelated sessions.
• The indicator updates on run start, normal completion, cancellation/interruption, and reconnect/resync.
• On uncertain state after reconnect/restart, the UI shows Interrupted or a clearly non-running state instead of pretending work is still active.
• The composer layout does not jump or overlap controls on desktop or mobile.
• The UI is accessible via aria-label/tooltip and works when the input is focused.
• Fast turns do not cause distracting flicker.

Impact

This would make the Web UI much easier to operate because the user can immediately see whether OpenClaw is still processing, has been interrupted, or has completed the turn. It reduces duplicate prompts, accidental interruptions, and the need to inspect logs or infer state from partial streaming.