Eight fixes, one root cause: the relay infers agent state from rendered output

[Danathar]

Eight fixes have gone into the same subsystem, and I think they share one root cause. I've just written the eighth, so this is as much a note on my own patch as anyone's.

The pattern

#4026  a finished agy turn could pin the relay to "working" forever
0159fb  complete finished Codex turns
#4064  a pane-stall failure misreported a task that finished moments later, with a real PR
#4080  recognize agy Gemini idle prompt
#4086  a confirmed pane stall Ctrl-C'd a LIVE agent CLI
#4128  let agy idle detection cross the input box's closing rule
#4182  agy prose in a finished summary no longer reads as WORKING
#4265  a finished codex turn no longer has to say "done"          (open)

Every one is the same question asked badly: is the agent still working? And every one answers it by reading rendered terminal output and guessing.

Two from the last few days show how narrow the failure surface is:

• 🐛 fix(relay): agy prose in a finished summary no longer reads as WORKING #4182 — agy finished a task and summarised it as "…Replaced inline token export instructions with writing HIVE_GITHUB_TOKEN…". isWorking matched the word writing. A finished agent looked busy.
• 🐛 fix(relay): codex completion detection — both directions #4265 — codex finished, opened a ready-for-review PR, and summarised "Opened ready-for-review PR 🧪 Podman: document Quadlet .kube compatibility spike #4259 … Branch is pushed and clean … Worked for 6m 22s". hasCompletionMarker needed completed|done|finished, none of which appeared. A finished agent looked unfinished.

Same root cause, opposite directions. Both were patched by adjusting the pattern. The ninth of these is already out there waiting — a model phrases a summary differently, or a vendor moves a box-drawing rule, and we write another regex.

Why this can't be fixed by better regexes

The patterns aren't matching a protocol. They're matching a presentation layer owned by someone else, which changes without notice and without a version bump:

• Model output is non-deterministic prose. writing/done/finished appearing is a coin flip on phrasing.
• TUI chrome is vendor-controlled. 🐛 fix(relay): let agy idle detection cross the input box's closing rule #4128 exists because agy started drawing a second box-drawing rule under its input line.
• Every backend needs its own hand-tuned set, so the work multiplies per backend and per CLI release.

The direction of error is asymmetric and both directions hurt. Reporting a busy agent as finished abandons real work. Reporting a finished agent as busy burns the task budget and books a failure — on tasks that shipped a green PR, in at least #4064, #4182 and #4265.

There is already a better answer in-tree

Headless mode decides completion from the process exit code.

"Headless task ${task_id} completed (exit 0)"  → task_complete
non-zero / ENOENT / timeout                    → task_failed

No prose. No chrome. exit 0 means the same thing in every model, every version, forever. One-shot specs already exist for six backends — claude -p, codex exec, copilot -p, goose run --no-session -t, agy -p, litellm -p.

Notably, none of the eight bugs above are in the headless path. It's less exercised, so that's suggestive rather than proof — but the structural reason holds: a one-shot process announces completion by exiting, while a REPL never announces anything, so the interactive path is reduced to reconstructing information the headless path gets for free.

And there's a second precedent: HIVE_VERDICT: no_work_needed. That isn't inference either — the prompt specifies the exact form and the relay anchors on it. It's a contract. It has held across backends because both ends agreed on it in advance.

Worth noting the contract approach demonstrably works on live agents: #4177 added a DCO sign-off instruction to the prompt, and on its first real run an agent planned and applied git commit -s unprompted. #4244 did the same for draft PRs.

Signals, ranked

	Signal	Owner	Breaks when
1	process exit code	OS	never
2	declared sentinel (HIVE_VERDICT:)	us, in the prompt	the agent ignores the instruction
3	TUI chrome (esc to interrupt)	the CLI vendor	they redesign
4	prose verbs (writing, done)	the model, per response	any phrasing change

The eight bugs are all tier 3 and 4. #4128 and #4182 moved agy from 4 to 3; #4265 does the same for codex. That's an improvement, and it's still standing on someone else's presentation layer.

What I'm not proposing

Not "switch everyone to headless." Interactive mode earns its place. Every diagnosis behind these eight fixes came from attaching to the pane and watching — including the two this week, where the captured pane was the reproduction. It's also how a contributor intervenes when an agent goes sideways, and agy is host-only regardless.

And not a redesign PR. This is an architecture decision spanning every backend, and the tradeoffs aren't mine to weigh.

The actual question

Should interactive mode stop deciding completion from rendered output?

Two directions, both already precedented in this repo:

A. Extend the sentinel contract. The prompt already asks for HIVE_VERDICT: no_work_needed when there's nothing to ship. It could equally ask for a completion marker when there is. Completion becomes a declared fact rather than an inferred one, and one contract replaces five backend-specific pattern sets. The weakness is honest: it depends on the agent complying, so the chrome heuristics stay as a fallback — but they'd stop being the primary signal.

B. Detect the CLI's return to idle structurally. The same instinct as paneForegroundCommand(), which already asks tmux what a pane is running rather than grepping its text. Harder for a REPL that never exits, but it's asking the OS instead of the vendor.

Happy to implement whichever direction, or neither — mostly I wanted the pattern written down somewhere, because eight fixes to one subsystem reads like a bug count and I think it's actually a design signal.

---

Context: found while running a contributor relay on agy and codex over the last two days. Every claim above is from the code or captured relay/pane output.

[Danathar]

So I ran into this issue and I'm not gonna open a PR for it until there's been some discussion because it changes a major way in which tasks are detected and completed. What are your thoughts on this?

[Danathar]

I took the steer and looked at how pluk is wired for claude in ClankeR before
proposing anything. Short version: the hook is the right shape, but pluk cannot
carry state for a claude pane as it stands, and I have numbers rather than a
reading of the code.

Setup: a real contributor relay task on claude (session hive-claude-c068,
about nine minutes, working a live queue item). Two measurements in parallel —
the relay's own classifyTmuxPane() verdict, and pluk 0.8.0 (the version
pinned in src/Dockerfile) fed the same pane.

Result 1 — pluk calls a working claude idle, in every sample

Feeding tmux capture-pane text — clean, newline-delimited, the friendliest
possible input — to pluk watch --cli=claude:

relay=working   pluk=idle      96
relay=unknown   pluk=none       7
relay=unknown   pluk=working    1

96 out of 96. Not a single agreement while the agent was working, and the agent
really was working — the pane showed Concocting... (6m 44s, 27.9k tokens),
esc to interrupt, running bin/test_hive_podman_cleanup.sh. There is no
window in the capture where pluk's claude state was correct.

The cause is one line. claude renders its input box while a turn is in
flight:

Concocting... (6m 44s, 27.9k tokens)
--------------------------------------------------
> 
--------------------------------------------------
  bypass permissions on (shift+tab to cycle) . esc to interrupt

pluk's claude.patterns has IDLE_PATTERN='❯\s*$|^\$ $', which matches that
prompt line. And classifier.js tests idle before working:

if (this.patterns.idle?.test(line))        newState = 'idle';
else if (this.patterns.working?.test(line)) newState = 'working';

so idle wins on any line matching both. The relay avoids this by keying on
bypass permissions and tool chrome instead; pluk treats bypass permissions
as its own event type in an earlier check, so it never reaches the state
machine at all.

Related: pluk's claude working glyphs are ◐◑◒◓◉◎○, but claude renders ✻✶✽✢.
The relay's own hasCompletionMarker already has the right set.

Result 1b — the one time it said "working", the agent was blocked

pluk emitted working exactly once in the whole run, on the first sample. That
pane was claude's startup trust dialog:

 Quick safety check: Is this a project you created or one you trust?
 > 1. Yes, I trust this folder
   2. No, exit

 Enter to confirm . Esc to cancel

The agent is stopped dead waiting for a keypress. pluk read it as working
because Esc to cancel is a literal entry in its claude WORKING_PATTERNS,
and that string is the dialog's footer. The relay returns unknown here
because it routes blocked panes through a separate blockingPatterns check
(Enter to confirm, numbered menus) rather than through classifyTmuxPane.

So across the run the classification was wrong in both directions: 96 samples
of a working agent read as idle, and the single working verdict was a pane
where the agent was blocked on human input.

Result 2 — over pipe-pane, the patterns never match at all

That was the charitable test — clean text, one line at a time. The real input is
the pane byte stream. Captured with tmux pipe-pane:

bytes:    42,244
LF (\n):  0
CR (\r):  463
ESC seqs: 4,612

Correction to something I said earlier in this thread: I first read this as
"nothing to split on". That is wrong — Node's readline splits on a bare CR
too, so pluk does get lines: 830 of them, 713 non-empty after stripANSI.

The problem is what those lines are. A cursor-addressed repaint delivers
fragments, not screen rows:

"✽"   "Concocting…"   "✻Concocting…9"   "●·2s"   "10s · ↓ 28.5k tokens)"

And none of them can match claude.patterns as written:

• The spinner glyphs claude renders are ✻ ✶ ✽ ✢. The pattern set is
  ◐ ◑ ◒ ◓ ◉ ◎ ○. No overlap.
• claude's working status row reads esc to interrupt. The pattern is
  Esc to cancel — a different string.

That second one is the sharp end. Across the 141 captured panes,
esc to interrupt appears in 127, and Esc to cancel appears in exactly
one — the blocked trust dialog from Result 1b. So the WORKING pattern matches
only the state where claude is not working, and misses every state where it
is.

Replaying the captured bytes gives 7 model_changed, 0 state_change, 0
raw_output, the model_changed events all from a relay status line matching
model.*claude-. Deterministic and reproducible from the capture.

What I think this means

Not that the pluk direction is wrong — the pipe-pane hook is a good shape and
LookPath keeps it optional. But "read pluk's state instead of scraping the
pane" cannot work for claude without changes on the pluk side: an idle pattern
that does not match a live input box, and a classifier that can cope with a TUI
that repaints instead of printing lines. Contributing codex.patterns and
agy.patterns would not have addressed either.

So I am not opening a PR to swap the relay's classifier over. What I would
suggest instead, in order:

1. Fix what is demonstrably broken today. While chasing this I found that the
   publisher writes no log file at all — manager.go's pipe-pane command has
   no >> <logfile> redirect, and pluk watch only ever writes to stdout — so
   hive-panes and the inception watcher are both reading files that are never
   created. Filed separately as 🐛 pluk publisher writes no log file — manager.go omits the shell redirect, so hive-panes and the inception watcher read files that never exist #4285; it is independent of anything in
   this thread and worth fixing either way.
2. Decide upstream in kubestellar/pluk whether the classifier should consume
   a rendered screen (capture-pane on a timer) rather than a byte stream.
   That is the change that would make it usable for TUI CLIs generally, not
   just claude.
3. Only then revisit having ClankeR read pluk state, per backend, where the
   data agrees.

Caveats

One backend, one session, one machine. The numbers are claude-specific and I
have not run the same comparison for copilot, whose patterns and TUI differ.

[Danathar]

Claude works now, so I'm not itching to get this done, but posting a change to pluk on if it should consume a rendered stream or byte stream is interesting.