- Ya
- 5 Septemba 2026, 02:09 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 6658418
Every terminal in the listing now carries `state`: busy, or waiting. It is the one question somebody asks of a window they cannot see, and it is what a minimized hexhead's colour will answer. A SHELL is waiting when the foreground command is a shell — `pane_current_command` is what tmux already sees in the pane, so this needs no bookkeeping and cannot go stale. Anything else in the foreground is work the member started. thinking or idle. Its transcript answers instead, from the last thing anybody actually SAID: assistant, stop_reason end_turn -> it has answered and handed back: WAITING assistant, stop_reason tool_use -> it is running something: BUSY user -> just submitted, nothing back yet: BUSY The last LINE is nearly always bookkeeping — cost, latches, queue operations, file snapshots, all appended after the answer — so reading it would report every idle session as busy. The scan goes back to the last conversational record. Unknown reads as WAITING, deliberately: a wrong "busy" paints a window green and hides that it needs somebody, where a wrong "waiting" only draws the eye. That is the safer direction for a status light to be wrong in. The listing therefore asks tmux for an eighth field. The title stays LAST and the split stays bounded; `pane_current_command` is a bare command name with no arguments, so it cannot carry the separator. Verified on the machine, not just in fixtures: of twelve real sessions the seven that were working read busy and the five that had finished read waiting — and the shell case was checked against a live `bash` (waiting) and a live `sleep` (busy). 226 tests.