Should a run blocked on foreground subagents read as waiting on subagents?

[Marker-bit]

Area

apps/web and packages/client-runtime (the live activity row), with the state produced by the OpenCode 2 adapter. Seen on T3 Code Nightly 0.0.46-nightly.20261010.2908, provider opencode (binary opencode2), OpenCode v2.0.22.

Problem or use case

Reported and reproduced in #17767. When an OpenCode parent turn calls the native subagent tool without background: true (the default), OpenCode runs the child to completion inside the parent execution, so the parent app run stays running for the whole fleet. T3 then shows the generic Thinking live row and keeps the composer in the busy state. The Waiting on N subagents roster never appears, because it is gated on the run being settled: orchestrationV2PendingBackgroundWork.ts returns [] while any run is preparing|starting|running, and ChatView.tsx mirrors it with activeBackgroundTasks = !isWorking && ….

For a fleet that runs for minutes, there is no way to tell "blocked on subagents" from "model is generating", and a follow-up has to go through steer or queue rather than a fresh turn.

This is the same surface question that closed #16213 (waiting-row presentation without maintainer sign-off), so I am asking for direction here before writing anything.

Proposed direction

Recommended, smallest scope: presentation only. While the active run's live activity is only provider-native subagent items and nothing else, the trailing live row reads Waiting on N subagents instead of Thinking, reusing the composer strip's wording and grouping (presentPendingBackgroundWork). The thread still counts as working; Stop, steer, and queue are unchanged. Surfaces: packages/client-runtime (threadExecution.ts), apps/web (MessagesTimeline.logic.ts), and the mobile equivalent if it shares the row.

Held for a separate decision. The report also asks for a usable composer while the parent run is technically open. That is a behavior change, not a label: OpenCode's foreground call keeps the parent execution open, and the adapter already supports steering and queueing, so "usable" means choosing between a new run, a steer, or a queue. I would not fold that into the presentation change without your call.

Alternatives

• Provider-side only: launch subagents with background: true, or use delegate_task. This is the existing workaround; no T3 change.
• Park the run at waiting for foreground calls in the adapter. Rejected in OpenCode foreground subagents keep the parent run active, so the thread reads as "Thinking" with no waiting state #17767: the parent turn genuinely cannot accept a new turn until the child returns, so waiting would misrepresent the run.

Ask

Confirm or redirect the direction and scope. If presentation-only is right, I will implement it with focused tests and before/after screenshots and open the PR linking that approval. I am happy to take a different surface or wording, or to leave it provider-side.

[juliusmarminge]

Closing as a duplicate of #17767, which tracks the same request. Please follow along there.