l0ng-ai 27c0c6c399 docs(cli): --orphans kills a run that is still going, not just an interrupted one ...

The warning on `pane close --orphans` said an orphan "can still be doing real
work — an interrupted `run` leaves the command running". True, and it stops one
step short of the case that costs someone work.

A `run` that is executing *right now* is an orphan too. `run --ws W` stamps its
pane with `W` as the owner and files it into no tab until `--keep` does, so for
the whole length of the command the pane reads exactly like a leftover.
Confirmed against a live server: `tty7 run --ws W -- sleep 45` shows up as
`orphan=true, owner=<W>`, the same shape a leaked pane has, and
`pane close --orphans` duly reported `closed 2 panes` — one of which was the
running command.

So the old advice — "look at `pane ls --all` first" — cannot be followed:
nothing in that listing tells the two apart. The docs now say that, and say
what to do instead (close by id when anything might be running).

This also rules out the reaper people will reach for when they meet the pane
leak in `ui::tree_sync`: the daemon's own `spawn_orphan_sweep` already computes
this exact set and deliberately only reports it, and an in-flight `run` is why
acting on it would be wrong. `orphan_panes` now carries that reasoning.

The distinction that would work is whether a client is still attached — an
interrupted `run` has none, a running one does. The daemon knows and
`PaneInfo` does not say; adding the field is backward compatible, since every
other field on it is already `#[serde(default)]`, but it is a wire change and
wants more than a doc pass.

2951 tests pass.

2026-08-15 19:24:21 +08:00

..

src

docs(cli): --orphans kills a run that is still going, not just an interrupted one

2026-08-15 19:24:21 +08:00

tests

fix(cli): stamp panes with the workspace that holds them, not the client's name (#425)

2026-08-09 20:08:03 +08:00

Cargo.toml

fix(cli): submit send enter outside paste bursts (#322)

2026-08-03 16:55:48 +08:00