umputun / agterm / 33441402834

97%

push

github

fix(status): stop one split pane's agent status erasing the other's block (#523)

* feat(status): stop one pane's agent status erasing the other's block

While a session is blocked, a session.status write from a different pane that is
neither blocked nor idle is refused whole - no status change, no statusChangedAt
restamp, no control event, no sound - answering "blocked status owned by pane
<pane>". With an agent in each pane the installed PostToolUse hook's active
erased the other pane's block seconds after it was set, taking the session out
of the attention list and idle auto-follow with it.

A second pane's own blocked still replaces, idle always clears, and same-pane
writes are unrestricted, so a single-pane session behaves exactly as before.
Panes compare after AgentIndicator.normalizedPane, or a promoted survivor's
baked .right fails to match the .left its block is stored as. The rule lives in
applyControlStatus rather than setAgentIndicator, whose other callers are
internal clears and retags that must bypass it.

session.type now fires the same pane-scoped clear as keyDown, through
injectAsUserInput - the input a blocked agent waited for has arrived. An empty
payload queues no keystrokes and so clears nothing, and onUserInput stays
unfired: that stamps the user as present and defers auto-follow, which a script
typing into a background pane must not do.

Two simultaneous blocks in one session still collapse to one; only per-pane
status storage fixes that, tracked in discussion
https://github.com/umputun/agterm/discussions/517

* fix(status): drop the idle carve-out from the pane-precedence rule

The exemption rested on a false claim - that no installed hook emits idle.
Two do, both tagged with their own pane: Codex's session-start action
(agterm-codex-status.sh) and the shell integration's precmd, which fires at the
next prompt after any matched agent exits. So starting codex in the right pane,
or any agent there finishing, erased a left-pane bl... (continued)

20 of 20 new or added lines in 2 files covered. (100.0%)

9207 of 9433 relevant lines covered (97.6%)

4325806.07 hits per line