T3 feedback — background CLI workers are invisible in the task list

[yozkan]

Area: task list / background task visibility
Severity: medium (trust and monitoring gap during long autonomous runs)

All names, paths, and project details below are dummy data.

Summary

When the assistant orchestrates work, it uses two kinds of workers:

1. Claude subagents (launched with the Agent tool). These show up in the task list with a
   name and status. Good.
2. External CLI workers (for example, a codex exec coding round launched as a background
   shell command with run_in_background). These show up NOWHERE in the UI. The process runs
   for 20-60 minutes, and the screen shows no sign that anything is running.

The host clearly HAS the data: the background command gets a task id, an output file, and a
completion notification is delivered to the model. Only the rendering is missing.

What happened (reconstructed with dummy data)

• Developer "J. Doe" runs an orchestrator session in repo C:\Projects\acme-assistant.
• The assistant launches two Claude scout agents. Both appear in the task list. Fine.
• The assistant then launches the main coder as a background shell command:
  echo '{...}' | node .../codex-exec.mjs with run_in_background: true, description
  "Launch Codex on milestone M1 (background)".
• The task list shows nothing new. The developer asks: "did you dispatch any agent? I don't
  see it" — and the assistant has to prove the worker is alive by reading a heartbeat file
  from disk (.claude/worktrees/codex-m1-widgets/.x-progress.md).

Expected

Background shell tasks render in the same panel as subagent tasks (or in a "Background
commands" section), each row showing:

• the description string the tool call already carries (e.g. "Launch Codex on milestone M1"),
• start time and elapsed time,
• status: running / exited (with exit code),
• optionally a click-through to the tail of the output file the host already writes.

Actual

Only Agent-tool subagents render. Bash/shell tasks with run_in_background: true are
invisible until they finish, and even completion is visible only to the model (as a
notification), not to the developer.

Why it matters

Orchestrator workflows increasingly route coding to external CLIs (Codex, other vendor CLIs)
while Claude plans and reviews. In these runs the LONGEST-running work item is exactly the one
the UI hides. The developer's natural conclusion is "nothing is running", which erodes trust in
the whole run and triggers unnecessary interruptions.

Reproduction (dummy)

1. Open a session in any repo, e.g. C:\Projects\acme-assistant.
2. Ask the assistant to run a long command in the background, e.g.
   "run node scripts/long-build.mjs in the background and keep working".
3. Observe: the assistant confirms a task id (e.g. bq7xk2abc) and an output file under
   %LOCALAPPDATA%\Temp\...\tasks\bq7xk2abc.output, but the UI shows no running task.
4. Compare: ask the assistant to launch any subagent — that one appears immediately.

Suggestion

Reuse the existing task-row component. The background shell task already has everything a row
needs: an id, a human-written description, a start timestamp, an output file to tail, and an
exit event. Rendering it would close the gap with zero new data collection.