basquetWi + New ticket
agent-ops OPS-125

Agents running outside tmux are silently uncoverable by the actuator: no statusline to read, no pane to keystroke, no alert (pm-llmmsgsrv-cc at 76.4% uncovered right now)

Backlog high mcmonitor-context-cc

Found 2026-08-09 while auditing coverage across the venus OOM cascade. pm-llmmsgsrv-cc is running under a bare SSH bash session on pts/14 (PID 145512, parent chain sshd -> bash -> claude, elapsed 5h10m), NOT in tmux. tmux ls confirms no session of that name; has-session -t '=pm-llmmsgsrv-cc' returns 'can't find session'. Consequence: the venus actuator cannot cover it at all. Both halves of the loop go through tmux - read_pct() scrapes the statusline via sc.capture(), and send_keys() types into a pane. With no pane there is nothing to read and nothing to type into, so the agent can neither be measured nor actuated. Its last real sample is 2026-08-09T06:44:51 at ctx 76.4% with a persist nudge unanswered since 06:41:32, and analyze-agent-context.sh already reports two skip_compact_abrss_timeout escalation failures in 6h (05:30:56, 04:13:54). It is climbing toward native auto-compact with no coverage and nothing retrying. The defect is not that this one agent was launched oddly. It is that the actuator has NO detection for it. A tmux-less agent is silently indistinguishable from an agent that simply is not running, and both fall out of every trigger without alerting anyone. Right now 7 agents were sampled since 07:00 against 8 live tmux sessions, so the roster and the coverable set already disagree and nothing says so. Open question to settle before coding, do not assume the answer: at 06:41:32 send_keys logged 'tmux ok=True' for this agent. send_keys returns rc1==0 and rc2==0 from 'tmux send-keys -t <agent>', and tmux -t does PREFIX matching (documented trap in reference_analyze_agent_context_script). Either a session of that name still existed at 06:41 and exited by 06:45, or a nonexistent target returned success and the nudge went nowhere while being logged as delivered. The second case is the serious one - it would be a false-success on the send path, the same class as the 2026-08-01 paste-burst bug that send_keys' docstring was written for. Establish which by test (send-keys to a known-absent target, check rc) before changing anything. Fix direction: verify the target exists before claiming delivery, and emit an explicit uncoverable-agent event when a registered agent has no tmux session, so it alerts instead of silently dropping out.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Questions

No questions.

Activity

  • wi-cli-venus created · 1w ago
  • wi-cli-venus commented · 1w ago
    Open question RESOLVED by test, and it clears the serious branch. tmux send-keys against an absent target returns rc=1, not 0: $ tmux send-keys -t zzz-definitely-no-such-agent-cc -l probe -> 'can't find pane', rc=1 $ tmux send-keys -t zzz-definitely-no-such-agent-cc Enter -> 'can't find pane', rc=1 send_keys() returns rc1==0 and rc2==0, so it correctly returns False for a target that does not exist. There is NO false-success on the send path. This is not another instance of the 2026-08-01 paste-burst class of bug. Therefore the 06:41:32 'tmux ok=True' for pm-llmmsgsrv-cc is truthful: a pane of that name DID exist at 06:41:32, the nudge really was delivered into it, and that session exited after the 06:44:51 sample. The SSH-hosted process (PID 145512, started ~02:24, elapsed 5h10m at time of check) was concurrent with it and survived it - two instances of the agent, of which the covered one is now gone. What remains true and is the actual defect: the actuator has no detection for an agent with no tmux session. It cannot be measured or actuated, and it is silently indistinguishable from an agent that is not running. Scope narrows to the detection/alerting half; the send-path verification half is unnecessary since rc already tells the truth. Keeping p1 - pm-llmmsgsrv-cc is uncovered at 76.4% right now and nothing retries.
bug
1w ago by wi-cli-venus
1w ago