list_agents: carry a last-activity age per child — bare [running] is indistinguishable from a stalled child

[LiveNathan]

The problem

A background subagent (continuable child) emits nothing to its parent between dispatch and final message — by design, and fine. But it means the parent's entire liveness view is list_agents' status word plus job_output's (no new output):

47f0d3fa-… [running] — Review bin script diff

(no new output)
[status: running]

These are exactly what a healthy, working child looks like. They are also exactly what a stalled child looks like. The model on the parent seat has no data to tell the two apart — and in practice it fills the gap with fabricated elapsed times.

A real incident (2026-09-10)

A manager session dispatched three cross-family review children. Reconstructed afterward from the children's own session transcripts:

Child	What the transcript shows	What the parent believed
glm-5.3-flash @ max	19 steps over 3m55s, every tool call answered	"has run ~28 minutes with no report" — killed
gemini-3.8-flash	worked continuously for 10m40s; last assistant message written the same second the job_kill landed	"ran ~15 min without returning" — killed
gemini-3.8-flash	8 steps in 47s, every tool call answered	"no output before interrupt" — killed at 47s

Every turn/end reads aborted by parent. Worse, the kills were self-fulfilling: interrupting a child mid-generation persists only the reasoning block, so all three kills produced an empty closing message that was then cited as further evidence of hanging. Every hypothesis the parent recorded (approval-prompt parking, provider outage, background-turn bug) was disproven by the transcripts. The root cause: a parent model judging liveness without a liveness signal.

Proposal

Give list_agents rows a last-activity age, so running and progressing and running and stalled are one glance apart:

60a47bc3-… [running] last-event=16s ago — Liveness probe child

The runtime already has the data — every session event carries a timestamp. Two shapes we can see:

1. Native (preferred): the subagent service's listChildren/listDescendants rows add lastActivity (epoch ms of the child's most recent session event — live children: last log event; cold observation: last observed event; projection-cache hit: omit), and the list_agents render surfaces it humanized. Roughly 30 lines across dsh-subagent and dsh-tool-subagent-control; the tool description should also teach the semantics (fresh = progressing, stale = last step hasn't returned).
2. Out-of-tree stopgap we shipped meanwhile: a small plugin listening to session/event (per-session last-append map) plus a tools/post-execute waterfall that rewrites list_agents content lines. Works unmodified on 0.1.5-rc.1.

Impact

Any workflow that dispatches background workers — reviews, research fan-out, long builds — hits the same decision point: kill or wait? Guessing wrong either throws away a child's completed work (the incident above lost ~15 minutes of finished review across three children) or parks the parent on a genuinely dead child. A per-row age turns a vibe call into a data read.

Happy to send the native change as a PR if the direction is welcome.

[laa1991]

Thanks for this — it is the closest description of our own wall that we have found, and we hit the same "two states look identical" problem from the other seat: the reader sitting in front of the window. Adding the one half I think this proposal cannot cover, plus the measurement that made us keep an external probe.

The half that goes blind exactly when you need it most. lastActivity is derived from the child's own session events — i.e. it is computed inside the same process. Take the moment when that process's event loop is occupied (#7115): the child stops writing its own events too, and the renderer stops rendering. When the block clears, the age is simply large — and it is exactly as large as for a child that never came back at all. The window in which you most need "working" told apart from "dead" is the window in which the input to that signal stopped moving. (Measuring the age outside the process does not dissolve the ambiguity by itself — an external probe sees "no answer", which is also what a dead process looks like. It is the threshold that separates the two; see below.)

Our rule has two halves, and both halves have been violated in public reports here.

1. Measure outside the process. Our probe is a separate process doing an HTTP round-trip, so the signal exists exactly when the inside is blind. It is deliberately orthogonal to a phase indicator: a phase answers what is it doing, the probe answers is it answering at all.
2. Take the threshold from a distribution, not from a feeling. Ours comes from 4,386 samples of the same watchdog call:

threshold	lights up	what that means
200 ms	4.85%	about once every 40 s — useless, it cries wolf
1000 ms	0.89%	about once every 3.7 min, while one turn lasts tens of seconds — rare enough to mean something

Baseline round-trip is ~1 ms; a deliberately induced stall produced 63 ms / 476 ms peaks — the ruler does move when the thing it measures moves.

The mirror failure, from the other side. #4989 is the same rule broken backwards: a monitor outside the process that treated "health check timed out" as "dead" and force-killed a busy server 8 times in one night, each kill losing in-flight tool calls. Measuring outside is necessary but not sufficient — without a threshold taken from a distribution, "busy" becomes "dead".

How this composes with the proposal — two axes, not competitors:

• lastActivity answers which step has not returned (fine-grained, per child, written by the child);
• the external probe answers is the host answering at all (coarse, per host, and it survives a blocked loop).

With only the first, a blocked loop freezes both views at once. With only the second, you know the host is alive but not which child is stuck. Ours has fired three times so far in this deployment (two "no answer", one "slow 1.1 s") — small numbers, and we treat them as small numbers.

Boundaries. One deployment (Windows + Chromium), 4,386 samples from our own watchdog, readings dated 2026-10-03. A threshold distribution is machine- and load-dependent, so please take the method — sample your own p50/p95/p99 and pick from the tail — rather than the constant.

If the shape of the probe is useful I am happy to describe it (~40 lines: an interval sampler, a sliding-window peak, and a sticky-clear rule so a spike does not stay lit after recovery). No patch offered — the repository does not accept external PRs.