Show what each background monitor and command is running in the waiting strip

[saphid]

Problem

When a thread has settled but is still waiting on background work, the composer strip says something like "Waiting on 2 monitors" and lists their names. Nothing says what each monitor or background command is running, how long it has run, or whether it is still alive. The strip's (i) popup repeats the names, so you have to scroll back through the transcript to the tool call that started each one.

Proposed direction

Keep it small and read-only:

• Add optional command and startedAt fields to the pending background task roster entry. Older clients ignore them.
• Claude adapter: record the command and start time from the Monitor or run_in_background Bash call that started the task. Shared turn-item path: do the same for Codex and Grok. Commands are capped at 500 chars because rosters ride on every thread shell.
• Web: the strip's (i) popup lists each item with its status ("Monitor · running 2m") and its command. Mobile: tapping the waiting pill shows the same details.

There is no live output tailing and no new terminal surface. The popup just says what is running and for how long.

Before / after, from a real Claude turn running two Monitors:

I have an implementation with tests and evidence. I'll link it below as a PR marked "approval pending". I'm happy to reshape the scope or close it if this isn't the direction you want.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks — open PR #15585 looks like the implementation for this idea (waiting-strip roster command / startedAt, Claude/Codex/Grok adapters, web (i) popup and mobile waiting-pill details). Linking it here so reviewers can find the evidence and discussion in one place.

[rsaulo]

Related visibility gap: Codex processes that run asynchronously while the agent's turn is still active.

Observed on T3 Code Nightly 0.0.46-nightly.20261007.2774, macOS arm64, Codex / GPT-6.1 Sol, High, Full Access.

During a real CI/deploy task, Codex started two gh run watch ... --exit-status --interval 15 processes, one per pipeline, then continued running other commands and posting progress updates. The timeline showed two separate Running gh rows, and the sidebar showed Working. There was no process list near the composer; discovering what remained active required finding and expanding the original commands in the transcript.

Read-only inspection of T3's thread activity confirmed that the run was active and the watches were tracked as command_execution items. On a later snapshot, one watch was completed and the other still running. This is about discoverability of tracked processes, not a claim that the agent or commands are stuck.

Reproduction pattern:

1. Ask Codex to launch two long-running watches asynchronously and continue checking their progress within the same turn.
2. Let it execute more commands and post commentary while the watches continue.
3. Observe the generic Working status and the Running rows in the transcript, with no persistent active-process summary near the composer.

The current source explicitly hides that surface during an active turn, in both .2774 and .2787:

• derivePendingBackgroundWork returns [] when hasActiveRun is true.
• ChatView uses const activeBackgroundTasks = !isWorking && activeThread ? pendingBackgroundTasks : [];.

This discussion and #15585 improve the existing strip after the turn settles. The observed case occurs before that, even though the processes are already running asynchronously and the agent is free to do other work.

It would help to expose a compact active-process summary during Working too: number of running commands, their command/name and elapsed time, with a link to the original transcript item. The active-process presentation can remain separate from post-turn waiting/completion semantics; this request does not require live output tailing or a new terminal surface.

Could this active-turn case be tracked alongside the waiting-strip work, or pointed to an existing issue/discussion if one already covers it?

[jeprecated]

I've built the two pieces this thread asks for, on a branch:

1. The background-work banner shows the actual command line, not just the agent's short description. It's capped at 500 characters, since the roster rides on every thread shell.
2. Clicking the command opens its live output: a popover on web, and a sheet from the status pill on mobile. Output only streams while it's open. Claude's comes from its task output file, and commands that are still turn items reuse subscribeCommandOutput.

Thread rows, Working/Waiting placement, and notifications are out of scope.

1. The command line in the banner	2. Its live output, on click

Would a maintainer approve (1) on its own, or (1) and (2) together?

[jieyuexing]

Note

Drafted by Claude Opus 5.5 in Claude Code (T3 Code); reviewed and posted by @jieyuexing

Two additions not covered above:

1. Auto-backgrounded commands lose live output. fix: command output streams live while it runs #15094 tails Claude's task output file only for foreground calls (is_backgrounded !== true in ClaudeAdapterV2) and stops the tail when the tool result arrives. A Bash call that Claude moves to the background after its timeout therefore stops streaming exactly when it becomes long-running. Because CommandOutputHub.subscribe settles once the turn item is no longer active, this case needs the same roster-entry path as run_in_background, not the original row.
2. A stall signal. Showing when a background command last produced output (or "no output for N min") would let users tell a stalled job from a slow one without asking the agent. In our case a ~25 min background download showed no progress at all, and the agent's own ad-hoc du check misread it as 0 MB/s.

[vilmerfrost]

+1 from daily use, on 0.1.7-nightly.20261101.4035 (macOS, Claude).

My agents run long test gates in the background, 10 to 20 minutes each. The strip reads, for example, "Waiting on Run the agent-config integration gate in the background". That is all I get, so I can't tell a slow run from a hung one without asking the agent.

Two things would fix it:

1. Click the row to open the command with its output streaming live. This is piece 2 of @jeprecated's branch above.
2. A timer on each row, such as "running 12m 40s", visible without opening anything.

#15585 closed unmerged, and the question above about approving these pieces has no answer yet. Could a maintainer say whether the live output part is wanted? It's the part I'd use most.

Written with Claude Opus 5.5 in T3 Code.

[vilmerfrost]

Still the case on the current nightly (macOS, Claude). Tonight the strip read only:

Waiting · Commit the test update and run the gate Stop

That gate ran for about 20 minutes, part of it queued behind another project's tests. Nothing on screen said how long it had run, whether it was queued or running, or whether it had hung. To find out I had to ask the agent, which then had to read the output file for me.

Same two asks as my comment above, and I think they are small:

1. A live timer on the row, e.g. "running 12m 40s". For a single Claude background command it is missing entirely today ([Bug]: Waiting strip shows no timer for a Claude background command, because the task id does not match the turn item #28899).
2. Press the row to open that command with its output streaming live, which is piece 2 of @jeprecated's branch.

#15585 closed unmerged and the question about whether the live-output part is wanted is still open. A yes or no from a maintainer would help, so someone can pick it up.

Written with Claude Opus 5.5 in T3 Code.