Skip to content

[Feature]: Control UI should show compact run progress for long or multi-agent tasks #52960

Open
Open
[Feature]: Control UI should show compact run progress for long or multi-agent tasks#52960
Labels
P2Normal backlog priority with limited blast radius.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.impact:ux-frictionUser-facing flow adds avoidable confusion or support burden without fully blocking progress.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.maturity:stableIssue affects a taxonomy feature currently scored M4/M5.

Description

@betamod
betamod
opened on Mar 23, 2026

Summary

The Control UI needs a compact run-progress indicator for long or multi-agent tasks. Right now a run can appear stalled even when OpenClaw is still making progress or has already finished internal work but has not yet surfaced the final reply.

This is not a request for verbose logs. The goal is a low-noise, phase-based status display that makes active work legible.

Observed behavior

During multi-agent runs, the backend emitted meaningful internal milestones such as:

  • executor finished
  • reviewer requested revise
  • final refinement running
  • loop complete

But from the Control UI, it was difficult to tell whether OpenClaw was:

  • still working
  • waiting on a subagent or tool
  • finished internally but still finalizing reply delivery
  • affected by websocket reconnect noise rather than actual execution delay

In practice, the run looked stuck for stretches even though the backend was progressing or had already completed.

Why this matters

This is mostly a trust and usability problem. For long-running or multi-agent work, users need to know whether to wait, intervene, or retry. When the UI collapses several different states into "maybe stuck", normal operation looks like failure.

Requested behavior

Expose a compact run-state model in the Control UI for the active chat run, for example:

  • queued
  • running
  • waiting on subagent
  • waiting on tool
  • writing artifacts
  • finalizing reply
  • reply delivery delayed
  • completed
  • failed

Also surface:

  • the latest meaningful progress line or phase
  • a last-activity timestamp
  • elapsed time for the current run
  • whether the websocket/session reconnected during the run

Minimal acceptable version

Even a small status strip near the composer or thread would solve most of this:

  • current run state
  • latest meaningful action
  • last activity time

The important constraint is: useful but not noisy. Many other coding agents already do this better by showing the current phase and latest meaningful action without turning the UI into a raw event log.

Example mockup (illustrative, not a strict UI spec)

┌──────────────────────────────────────────────────────────────────────────────┐
│ OpenClaw Control UI                                              Online     │
├──────────────────────────────────────────────────────────────────────────────┤
│ Session: openclaw-safe-update regression check                               │
│ Run State: RUNNING                                                           │
│ Latest: Reviewer evaluating bounded diff and evidence                        │
│ Last activity: 6s ago                           Elapsed: 01:42               │
│                                                                              │
│ Progress                                                                     │
│ [1] Executor started                         10:26:05                        │
│ [2] Tool run: git diff                       10:26:12                        │
│ [3] Tool run: bash -n                        10:26:18                        │
│ [4] Executor wrote RESULT.md                 10:26:34                        │
│ [5] Reviewer started                         10:26:46                        │
│ [6] Reviewer checking evidence               10:27:16                        │
│ [ ] Final reply delivery pending                                             │
│                                                                              │
│ Status Details                                                               │
│ • Active agent: Reviewer                                                     │
│ • Waiting on: none                                                           │
│ • Subagents: 2 completed / 0 running                                         │
│ • Tools used: git diff, bash -n                                              │
│ • Connection: websocket reconnected 1 time during this run                   │
├──────────────────────────────────────────────────────────────────────────────┤
│ Chat                                                                         │
│                                                                              │
│ User: Can you verify the updater fix with an executor/reviewer loop?         │
│                                                                              │
│ OpenClaw:                                                                    │
│ Working on it. Executor completed a bounded patch review and wrote           │
│ RESULT.md. Reviewer is now checking control-flow fidelity and evidence.      │
│                                                                              │
│ [streaming reply continues here]                                             │
├──────────────────────────────────────────────────────────────────────────────┤
│ Message…                                                     [Stop] [Send]   │
└──────────────────────────────────────────────────────────────────────────────┘

Notes

  • This request is about Control UI visibility, not orchestration redesign.
  • There may be some related overlap with websocket reconnect/delivery issues, but even without transport problems the current run state is too opaque.
  • OpenClaw already appears to have some internal event/tool-stream machinery; the gap is that the overall run lifecycle is not surfaced clearly enough in the user-facing chat experience.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.impact:ux-frictionUser-facing flow adds avoidable confusion or support burden without fully blocking progress.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.maturity:stableIssue affects a taxonomy feature currently scored M4/M5.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions