Named background subagents persist in FleetView after completion; no dismiss affordance + inconsistent shutdown_request reaping

Open 💬 0 comments Opened Jun 29, 2026 by flavio-bongiovanni

Summary

When an orchestrator dispatches subagents via the Agent/Task tool with a name + background execution, completed/idle named subagents remain in the FleetView agent tree (under ● main), each rendering its full initial <agent_prompt> block. Over a long orchestration session with several named dispatches these accumulate and consume a large portion of the terminal (observed ~half the screen with ~6 completed agents still listed).

Environment

  • Claude Code (CLI), tmux-hosted session, model Opus 4.8, --dangerously-skip-permissions.
  • Long-running orchestrator dispatching one named subagent per task across a multi-wave workflow.

Steps to reproduce

  1. Dispatch several subagents via the Agent tool with a name parameter (so each is addressable/background), e.g. one per task across several waves.
  2. Let each complete its task and go idle (the orchestrator receives Teammate @X finished / an idle_notification).
  3. Observe the FleetView agent tree still lists every completed/idle subagent, each with its full prompt text.

Expected

Completed/idle named subagents should either auto-dismiss after going idle for some interval, or there should be an explicit affordance to dismiss completed agents from the FleetView (e.g. a "dismiss completed" action).

Actual

  • Completed/idle named subagents persist in the FleetView with their full prompt text, indefinitely.
  • The only dismissal mechanism appears to be SendMessage { type: "shutdown_request" }. In one batch of 7 simultaneous shutdown_requests, only 1 agent terminated (emitted shutdown_approved + teammate_terminated); the other 6 acknowledged with an idle_notification but did not terminate until the request was re-issued in a later turn.

Impact

  • FleetView clutter (≈half the terminal) on long sessions.
  • Ambiguity about whether the listed agents are still consuming resources/context.
  • Inconsistent shutdown reaping makes cleanup unreliable.

Notes / workaround

Using ephemeral (unnamed) one-shot dispatches, or separate tmux sibling processes that render in their own compact status line with an independent lifecycle, avoids the accumulation. The request is two-fold: (a) a cleaner dismiss/auto-reap affordance for completed named background subagents, and (b) more reliable / batch-consistent shutdown_request reaping for idle agents.

View original on GitHub ↗