Count subagents, and keep a batch from looking free

Corrected from the previous commit, which had it backwards. When a batch
is running the session is working, not waiting: the main agent will pick
the results up and consolidate them itself, so sending you to that
terminal wastes the trip. That is the common shape of the work here --
ask for a batch, let it run.

Simply letting subagent tool calls set "busy" would mostly work and was
tempting, but it leaves a hole. Stop fires before the batch finishes, so
the session shows as free from the moment the turn ends until the first
subagent tool call lands -- and longer whenever the subagents are thinking
rather than calling tools. So subagents are counted instead:

  PreToolUse, matched to ^(Agent|Task)$   +1
  SubagentStop                            -1
  UserPromptSubmit                        reset to 0

While the count is above zero the session cannot read as waiting; Stop and
an idle_prompt nudge both leave it working. The session is freed by the
last subagent leaving, and only if the main agent has stopped by then.

The matcher is anchored because it is a regex: a bare "Task" also matches
TaskCreate and friends, which are not subagents. The hook re-checks the
tool name itself in case a future matcher behaves differently, and the
reset on UserPromptSubmit bounds a count that leaks because a subagent
died without its SubagentStop.

Measured, not assumed: a matched PreToolUse fires only on agent launches,
SubagentStop arrives once per subagent carrying agent_id, and a real
three-subagent run walks the count 0-1-2-3-2-0 before Stop frees it.

The menu shows the number, as asked. The panel does not: a batch of eight
is still one line saying "working 40 min", which is the right line.
This commit is contained in:
av
2026-08-09 19:26:25 +03:00
parent 09b9aae2eb
commit 5398f32826
6 changed files with 153 additions and 34 deletions
+31 -12
View File
@@ -142,20 +142,39 @@ gnome-extensions enable claude-code-status@git.vakhrushev.me
всё ещё позволяет хуку, прочитавшему старое состояние до `Stop`, записать своё
устаревшее решение после него.
Сабагенты не показываются, и это не про экономию строк. Их вызовы инструментов
**долетают** до хуков родительской сессии — как `PostToolUse` с полями
`agent_id` и `agent_type` (проверено запуском). Учитывать их нельзя: при фоновых
сабагентах основной агент заканчивает ход первым (`Stop`, то есть `waiting`), а
сабагенты продолжают работать, и их события перебили бы состояние обратно в
`busy`. Панель показывала бы «работает» у сессии, которая на самом деле ждёт
вас, — ровно та подмена, ради предотвращения которой всё и затевалось.
## Сабагенты
Поэтому любое событие с `agent_id` игнорируется. Кроме `Notification`: она
означает, что нужен человек, и это одинаково верно, в каком бы агенте ни
заклинило.
Типичный сценарий: вы просите запустить батч, основной агент разворачивает его и
**заканчивает ход**, а сессия ждёт результатов, чтобы свести их воедино. Звать
вас туда не надо — она занята.
Батч из восьми задач остаётся одной строкой «работает 40 мин», и это правильная
строка: пятый воркер из восьми ни о чём не просит.
Но `Stop` при этом приходит раньше, чем сабагенты закончат. Если верить ему
буквально, сессия покажется свободной ровно тогда, когда в неё лезть бессмысленно.
Поэтому сабагенты считаются явно:
| Событие | Что делает |
|---|---|
| `PreToolUse` с матчером `^(Agent\|Task)$` | +1 к счётчику |
| `SubagentStop` | −1; последний освобождает сессию, если ход уже закончен |
| `UserPromptSubmit` | сбрасывает счётчик в 0 |
Пока счётчик больше нуля, состояние `waiting` невозможно: и `Stop`, и напоминание
`idle_prompt` дают `busy`. Освобождает сессию только уход последнего сабагента —
и лишь если основной агент к тому времени остановился.
Матчер якорный не для красоты: это регулярка, и голое `Task` поймало бы
`TaskCreate`, `TaskUpdate` и прочее. Хук проверяет имя инструмента ещё раз, сам.
Сброс на `UserPromptSubmit` ограничивает ущерб, если сабагент умрёт, не прислав
`SubagentStop`: счётчик не переживёт следующего вашего сообщения.
Собственные вызовы инструментов сабагентов игнорируются — они долетают до хуков
родителя как `PostToolUse` с `agent_id`, но счётчик уже всё сказал, а они добавили
бы только записи на диск. `Notification` — исключение: она означает, что нужен
человек, и это одинаково верно, в каком бы агенте ни заклинило.
В меню число сабагентов показывается строкой «работает · 3 subagents». В панели —
нет: батч из восьми задач остаётся одной строкой «работает 40 мин», и это
правильная строка.
## zellij