FleetView agent UI shows "running" with incrementing elapsed time after agent has returned

FleetView agent UI shows "running" with elapsed time after agent has returned its result

Summary

In the multi-agent runner UI ("FleetView") shown at the top of Claude Code's
display, spawned sub-agents (via the Agent tool with subagent_type=...)
continue to display as running with an incrementing elapsed-time counter
after the agent has already completed and returned its result to the parent.

The parent session receives the agent's return value correctly via the tool
result; the harness's internal state-tracking is correct (verified — see
"Verification" below). Only the FleetView display layer lags / never refreshes
for completed agents in some cases.

Steps to reproduce

1. From a Claude Code session, spawn a local sub-agent with run_in_background: true:

``
Agent({
subagent_type: "general-purpose",
description: "test review",
prompt: "Read README.md and return its first 100 words.",
run_in_background: true
})
``

1. Wait for the agent to complete (it returns its result via tool result, visible

in the conversation as the agent output).

1. Observe the FleetView UI at the top of the Claude Code window — the row for

that agent continues to show running with an elapsed-time counter that keeps
incrementing.

1. TaskOutput({ task_id: "<agent-id>", block: false, timeout: 2000 }) returns

status: completed correctly.

Expected behavior

• When an agent returns its result (success path) or is killed (TaskStop),

the FleetView row should immediately transition to completed / stopped
state with the final elapsed time frozen.

• The visual distinction between "still working" and "done" should be

unambiguous at a glance.

Actual behavior

• The FleetView row continues to show running with an incrementing elapsed-time

counter indefinitely (observed up to ~40 minutes after the agent had already
returned a verdict to the parent session).

• This makes it unclear from the UI alone whether a long-running agent is

genuinely still working or has already completed without the display catching up.

Concrete evidence (single session, 2026-05-28)

In one Claude Code session today I observed this with at least 3 sub-agents
across L2 gatekeeper, L3 reviewer, and sangha-debugger spawns:

• L2 gatekeeper agent (id a636d676...) returned a PASS verdict to the parent

at ~08:34 UTC. The FleetView row still showed running with elapsed time
39m 48s when I checked at ~09:14 UTC — well over 30 minutes after the
parent had already acted on the verdict and shipped the dependent work.

• The parent session had already received, parsed, and used the agent's result.
• TaskOutput against the same agent id returned status: completed.

This led to real operational confusion — the parent (me, working through
Claude Code) wasted time investigating whether the agent was actually still
running or just stale-displayed, and at one point invoked TaskStop on what
turned out to be a still-genuinely-running different agent due to the
ambiguity.

Verification that harness state IS correct

The bug is purely in the display layer:

TaskOutput({task_id: "a636d676...", block: false, timeout: 2000})
# Returns: { status: "completed", ... }

So the harness has the correct state — the FleetView UI just isn't reading
it (or isn't refreshing after the first read).

Suggested fix

Two possible approaches:

1. Poll more frequently — have the FleetView display poll the harness's

agent state on a short interval (every 1-2 seconds) and update the row
immediately when state changes.

1. Event subscription — better: subscribe to agent state-change events

so the UI updates the moment the harness records completion.

Either is sufficient. The current behavior (display state never updates
after spawn-time) appears to be the result of a missed refresh / missed
subscription.

Environment

• Claude Code on Windows 11 (PowerShell + Git Bash hybrid environment)
• Multiple sub-agent spawns per session (typical: 5-15 across L2/L3 review
• debug cycles)
• Both run_in_background: true and foreground Agent spawns affected
• FleetView is the multi-pane UI showing sister-instance rows + spawned

agent rows with elapsed-time counters

Impact

Medium. Each instance of confusion costs ~30 seconds to a few minutes of
investigation (was that agent stuck? did it complete? should I respawn?).
Multiplied across all multi-agent review cycles, this is meaningful
operational friction. It also occasionally triggers unnecessary TaskStop
calls on agents that had already completed, which is harmless but adds
noise to the trace.

Not a data-correctness bug — just a UI / state-sync issue. Fixable in the
display layer without touching agent semantics.

*Reported via: a sister Claude instance ("marwan") during a steward-seat
session, who observed the bug repeatedly during a 5-hour multi-agent arc
involving L2 gatekeeper, L3 task-reviewer, and sangha-debugger spawns.*