Reply guard stalls on busy panes — text accumulates unsubmitted, no recovery path

[djbclark]

Summary

The reply guard introduced in v0.17.0 (PR #39) correctly protects against answering dialogs, but has a UX gap when the target pane is busy streaming output: text arrives in the terminal but the submit key is never sent, the draft stays in the compose box, and retry accumulates duplicate text in the pane with no way to submit or clear it from the PWA.

Scenario

1. Agent pane (Claude Code) is actively streaming output (working on a response).
2. User types a message in Collie's composer and taps Send.
3. Guard step 1 — pane.send_text(text, submit: false) — succeeds: the text lands on the pane's input line.
4. Guard step 2 — polling the pane to verify the text appeared on the > prompt input line — fails, because the > prompt is scrolled off/obscured by streaming output.
5. Guard step 3 — Enter is withheld. The Collie compose box keeps the draft.
6. User taps Send again — steps 3–5 repeat — text accumulates multiple times on the pane's input line with no way to submit it.

Observed behavior

• The terminal mirror confirms the text IS in the pane's input buffer (it appears on the > line).
• The Collie compose box still shows the draft, implying the send "failed."
• Repeated sends type additional copies of the text in the pane but never add a trailing Enter.
• No PWA affordance to: send a bare Enter, clear the pane's input line, or retry the submit without retyping.

Related

• PWA send renders in the pane's input box but never reaches the input buffer (silently lost) #34 (original bug the guard was designed to fix) — text silently lost to dialogs
• Composer Send: messages accumulate on terminal input; Enter sometimes swallowed #7 (message accumulation) — old accumulation bug, different root cause

What makes this different from related issues

The guard was designed around a dialog-active scenario, where stalling is correct (you don't want to send Enter into a dialog). But the more common trigger (pane busy streaming) has the opposite UX: the text WAS delivered to the pane's input buffer, it just needs Enter to submit it. The guard treats both scenarios identically when it should distinguish them.

Suggested improvements

1. Clear the compose box on verified type regardless of submit outcome

Once send_text returns ok, the text is in the pane. The compose box should clear immediately — the draft was successfully transmitted even if Enter hasn't been sent yet. Keeping the draft is misleading because the user sees it and assumes "it didn't go through," then retries and accumulates.

2. Retry submit standalone

When the guard stalls (text verified, Enter withheld), offer a "Resend Enter" action. The user can tap it later once they visually confirm in the mirror that the prompt is ready. The original text is already in the pane — only the submit key is missing.

3. Pre-check pane state before typing

Before the guard types anything, check if the pane is in a readable state (output settled, > prompt visible). If the pane is streaming, wait for it to settle rather than typing blind.

Workaround (for documentation)

On the Mac/TUI: tap Cmd+K then Enter in the target pane to clear the accumulated text and start fresh.

From the PWA: tap Keys -> send Ctrl+C to cancel a stuck state, then try sending again when the pane is idle.

Environment

• Collie v0.20.2 (bridge herdr.collie)
• Herdr 0.7.4
• Bridge host: macOS (Apple Silicon), behind tailscale serve
• Harness: Claude Code panes
• Client: Android PWA (installed to home screen)

[AltanS]

Very likely fixed by 96df14f (PR #56, in main, shipping in 0.21.0) — and the mechanism turns out not to be streaming.

The premise doesn't hold. Probing a live pane with agent_status: "working" (spinner on screen, output streaming), the real adapter parses the input box fine mid-stream — locateInputBox succeeds and extractStatusLine returns. Busy alone does not make the box unreadable.

What actually breaks it is the number of rows under the input box's bottom border. locateInputBox allowed at most 3, and that run is your statusline plus its hint rows — arbitrary output from statusLine.command, and any row soft-wraps into two on a narrow pane. At 4 rows the walk never reaches the border, so extractInputDraft returns null permanently, and all three symptoms you reported follow from that one blind spot:

• the guard can never verify, so Enter is correctly withheld and the draft is kept;
• composer.tsx gates its pre-clear sweep on the input line being readable, so the next send doesn't sweep and send_text appends at the cursor — your duplicate stacking;
• the stranded-draft preview never appears either, which is why there was no recovery path.

Reproduced on a maintainer host, same real frame, only the row count changed:

statusline run	extractInputDraft
3 rows	"ship the release" ✅
4 rows, before 96df14f	null ❌ — stall, no preview, no sweep
4 rows, after 96df14f	"ship the release" ✅

That also explains the intermittency: statusline widgets are conditional (git state, a context meter), so a row appears and vanishes with no config change, carrying a pane over the threshold and back.

Please update and let us know. herdr plugin action invoke update --plugin herdr.collie once 0.21.0 is tagged. If it still reproduces, the single most useful thing you can send is one captured frame taken while it's happening: herdr pane read <pane> --source recent --format ansi.

On the three suggestions, since they deserve a straight answer:

1. Clearing the composer once send_text returns ok — no. That is the exact premise PWA send renders in the pane's input box but never reaches the input buffer (silently lost) #34 was filed against: an ack means Herdr took the bytes, never that the TUI acted on them. With a dialog focused the text is swallowed, and clearing the box would destroy your message in precisely the case the guard exists for. Your underlying complaint is fair though — a kept draft reads as "not delivered, retry me", and that misreading is what drives the accumulation. The fix for it is an explicit "delivered, not submitted" state with its own Submit action, not clearing on an ack.
2. A standalone submit — yes, in guarded form, and there's already an interim: Keys → ⏎ Enter in the nav tray sends a bare Enter. If accumulation survives the update, the planned fix is that a retry of the same text never re-types: it skips straight to the verify→submit half, so duplication becomes structurally impossible.
3. Waiting for the pane to settle before typing — no, and for a stronger reason than "unnecessary": Claude Code queues messages submitted while it's working, so typing ahead is a supported workflow. The gate stays "can I verify", never "is it idle".

Thanks for the report — the accumulation detail is what made the row-count cause findable.

[AltanS]

Fixed in 0.21.0 (96df14f).

herdr plugin action invoke update --plugin herdr.collie

Closing on the evidence above — the stall reproduces exactly when the statusline run exceeds the old 3-row bound, and no longer does past it. If it still happens after updating, please reopen with one frame captured while it's happening (herdr pane read <pane> --source recent --format ansi); that will tell us in one look whether the input box parses.

Also in this release, from your report: the strip above the composer now shows every row of the statusline rather than just the first, so you can see the pane's real state while you send.