[Feature]: Make the composer reflect background agent work after the turn settles

[coygeek]

Summary

When the main turn ends but a background subagent is still running, the composer shows the normal send arrow and only a small grey "1 agent working · View · Stop" strip above it. Next to the red stop button used during an active turn, this reads as if the agent has stopped. The composer should make it clear that work is still in progress, even when that work is background work.

Problem to solve

A thread has two visually unrelated "busy" states:

• While the main turn runs, the composer's primary action is a prominent red stop button.
• After the main turn settles while background work continues (subagent fleets, workflow runs), the primary action goes back to the send arrow. The only signal that work continues is the low-emphasis composer banner reading "N agent(s) working" (or "Background work" / "Monitoring"), with small ghost-style View and Stop buttons.

At a glance, the second state looks idle. Users switching back into a thread cannot tell quickly whether anything is still running, and the only stop control has much less visual weight than the one they learned during the turn.

This shows up mostly with the Claude provider, because Claude Code runs subagents in the background by default and the parent turn often ends while a subagent keeps working. Codex subagents usually finish while the parent turn is still running, so the red stop button stays visible and the gap rarely appears.

Proposed behavior

• While the active thread has live background work and no running turn, the composer area signals ongoing work at a glance, with prominence comparable to the running-turn state.
• The wording makes the split clear, e.g. that the main agent is idle and ready for a message while N agents are still working.
• Stopping background work is as easy to find as the running-turn stop button.
• Sending a new message stays available in this state; the change is about communicating state, not blocking input.

Acceptance criteria

• With a Claude thread whose turn has settled while at least one background subagent is live, a user can tell from the composer alone that work is still in progress, without reading the small banner text.
• In that state the composer shows at least one visual cue besides banner text that differs from a fully idle thread.
• A stop control for background work stays visible in that state and is not visually subordinate to the send action.
• When all background work settles, the composer returns to the ordinary idle appearance with no leftover busy cue.
• A running main turn keeps its current stop-button behavior.

Affected area

• apps/web/src/components/ChatView.tsx: background-liveness composer banner, shown only when no turn is running.
• Thread backgroundLiveness (working / monitoring) already reaches the web client and drives the sidebar's Working/Monitoring pill.

Non-goals

• Changing how the Claude or Codex adapters detect or classify background work.
• Blocking or queueing new messages while background work runs.
• Changing what Stop does; it still routes through the existing stop-everything interrupt.

Alternatives considered

• Leaving it as-is and relying on the banner and sidebar pill. This is the current design and the source of the confusion.
• Reusing the red stop button while background work runs. That would hide the fact that sending a new message is possible in this state.

Supporting context

• Background liveness and the composer banner came from feat: native subagent & workflow observability #5219. A code comment there says that once the turn settles, the banner is the only visible stop affordance.
• Observed on T3 Code (Nightly) 0.0.43-nightly.20260927.2365 on macOS with the Claude provider.
• Related, but a different problem: [Bug]: OpenCode provider background delegations leave the thread looking Settled while they are still running #11730 (OpenCode background delegations look settled while still running).

[handst97]

Adding a data point from a Claude Workflow run, since it's an extreme case of this.

The parent turn ended right after it launched the workflow, and from the chat it looked like nothing was happening. In fact 84 agents across 5 phases were running for over 30 minutes. I didn't know where to look until I went digging and found Lineage. Once I opened it, the full roster was there (thanks to #12598).

A small change that would have solved it for me: while a Workflow runs in the background, show its progress where I'm already looking, for example Workflow · phase 4/5 · 79/84 agents done · View, with View opening that workflow in Lineage.

T3 Code (Nightly) 0.1.2-nightly.20261022.3541 · macOS 27.2