Show a background task's progress in the waiting strip while an agent waits on it

[zacin8or]

The problem

When an agent waits on a long background command (a test run, a build, a migration), the waiting strip shows its label and Stop, nothing else. A 12-minute test run looks the same at minute 1 and minute 11, and a hung command looks like a healthy one. To find out, I open a terminal or ask the agent, which costs usage. Subagents already show progress text in the strip; background commands don't.

Proposal

Add per-task progress to the strip, the desktop ⓘ popover and the mobile "Background work" sheet. When there's nothing to show, the UI looks the same as today.

Desktop, one task: a short bar and count after the task name.

Desktop, several tasks: a count after each label. The ⓘ popover becomes one row per task, with bar, count and latest output line, so desktop finally matches the list mobile already has.

Mobile: with one task, a short bar inset on the pill (same size pill). The sheet's rows get a bar, count and latest output line.

There's no combined bar for several tasks: they run in parallel and finish independently, so one bar would jump as tasks drop off the list.

Latest output line: shown for every task, so a stuck task is visible even with no bar.

Where progress comes from

The agent's turn has ended while it waits, so it describes progress once, up front. For Claude that's an optional field on t3_background_wait:

{ "taskIds": ["abc123"],
  "progress": { "abc123": { "pattern": "(\\d+)/(\\d+) tests", "format": "fraction" } } }

format is fraction (default) or percent, so the agent picks what makes sense for the command.

Codex has no wait call: it holds the thread for any command still running when the turn ends. For Codex, T3 Code would detect common formats (N/M, NN%) itself, which also covers Claude tasks without a hint.

Why it's cheap

• Codex already streams background command output after the turn ends (CodexAdapterV2.ts).
• The Claude adapter already tails Claude's output files for foreground commands (ClaudeTaskOutputTail.ts); it would keep tailing backgrounded ones.
• Live output already bypasses the database and the event stream, and clients subscribe per command (CommandOutputHub.ts). The strip would subscribe only to the tasks it shows, only while visible, and update every few seconds. Bars are static between updates.

Providers

Claude and Codex first. Grok and Muse list background tasks but don't stream their output yet. Background tasks don't work on Cursor today. Background commands aren't among the capabilities in docs/user/cursor.md, and the Cursor adapter doesn't report pending background work through tests.

The UI doesn't check the provider: it shows progress whenever an adapter reports a background task and its output, so another provider gets this by reporting the same data.

Open questions

• Is it OK to keep tailing a backgrounded Claude task's output file after the turn ends? Its location is undocumented; if it can't be found, the strip falls back to today's.
• Would you take this in two steps: output lines first, then bars and the hint?
• Should the ⓘ popover always appear when tasks have progress, or only when the line is cut off?

Possible follow-ups

• Blocking commands: the same bar on a running command's timeline row, using detected formats (or OSC 9;4, though most tools only emit it to a real terminal).

• A provider-neutral hint tool, so Codex agents can pass hints too. Codex's processId on a command matches the session_id the model sees, so the tool can map the agent's ID to the task.
• Open the full output: tapping a task's output line expands its command row in the timeline.

Related

• #28899: Claude background commands show no timer in the waiting strip.
• #27700: background commands a subagent waits on aren't shown.
• #29714: Working overview, where this progress could also appear.

progress-mockup.html