forgejo-admin/herdrmastr
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

send-keys enter does not flush already-parked input on a pane showing ※ recap: #6

New issue
Open
opened 2026-07-31 22:19:26 +00:00 by forgejo-admin · 0 comments
forgejo-admin commented 2026-07-31 22:19:26 +00:00
Owner
Copy link

Corrected 2026-07-31. This was originally filed as "a recap pane swallows
Enter, so doorbells never submit." That overstated it. A fresh herdr agent prompt does submit normally into a recap pane — verified since. What fails
is using herdr pane send-keys <pane> enter to flush input that is already
parked in the line.

Symptom

When a pane is displaying a ※ recap: block and text is already sitting
unsubmitted in its input line, herdr pane send-keys <pane> enter does not
submit it. Repeated attempts do not help.

Observed 2026-07-31 across three panes, three manual attempts each, none of which
submitted:

w1D:p1   ❯ yes, send it
w26:p1   ❯ watch CI and fix anything red
w27:p1   ❯ push the branch and open a PR

Verified against the live screen with herdr agent read <pane> --source visible,
not a cached snapshot. Each pane reported idle/done with the text plainly
visible in the prompt.

What is NOT affected

herdr agent prompt submits fine in this state. Confirmed by delivering mail to
w2D:p1 while it displayed a recap block — the doorbell submitted immediately,
no nudge required. So herdr-mail delivery is not broken on recap panes, and
the --wait --until working stall detection works there.

The five stalls that motivated the original filing were on panes without a
recap, and were flushed by a single send-keys enter on the first try. Those are
fixed by the delivery change (see Related).

Why it still matters

The affected case is a human (or an agent) typing into a pane and the text not
going anywhere — which is how three queued instructions sat unexecuted for the
better part of an hour here. It is silent: the pane looks idle and the text looks
submitted-in-progress.

Suspected cause: the recap render holds input focus or consumes the keypress. Not
diagnosed — needs someone inside herdr.

Acceptance

  • Root cause identified in herdr (recap render vs. input handling).
  • herdr pane send-keys <pane> enter submits a pending input line while a
    ※ recap: block is displayed.
  • Reported upstream to herdr — this is a herdr defect, not a plugin one.

Related

  • herdr-mail delivery no longer depends on the broken path for its own
    recovery: it prompts with --wait --until working and lets herdr report
    agent_prompt_stalled. See herdrmastr#7.
  • mail selftest pins the CLI contract that recovery depends on.
**Corrected 2026-07-31.** This was originally filed as "a recap pane swallows Enter, so doorbells never submit." That overstated it. A fresh `herdr agent prompt` **does** submit normally into a recap pane — verified since. What fails is using `herdr pane send-keys <pane> enter` to flush input that is *already parked* in the line. ## Symptom When a pane is displaying a `※ recap:` block and text is already sitting unsubmitted in its input line, `herdr pane send-keys <pane> enter` does not submit it. Repeated attempts do not help. Observed 2026-07-31 across three panes, three manual attempts each, none of which submitted: ``` w1D:p1 ❯ yes, send it w26:p1 ❯ watch CI and fix anything red w27:p1 ❯ push the branch and open a PR ``` Verified against the live screen with `herdr agent read <pane> --source visible`, not a cached snapshot. Each pane reported `idle`/`done` with the text plainly visible in the prompt. ## What is NOT affected `herdr agent prompt` submits fine in this state. Confirmed by delivering mail to `w2D:p1` while it displayed a recap block — the doorbell submitted immediately, no nudge required. So `herdr-mail` delivery is **not** broken on recap panes, and the `--wait --until working` stall detection works there. The five stalls that motivated the original filing were on panes *without* a recap, and were flushed by a single `send-keys enter` on the first try. Those are fixed by the delivery change (see Related). ## Why it still matters The affected case is a human (or an agent) typing into a pane and the text not going anywhere — which is how three queued instructions sat unexecuted for the better part of an hour here. It is silent: the pane looks idle and the text looks submitted-in-progress. Suspected cause: the recap render holds input focus or consumes the keypress. Not diagnosed — needs someone inside herdr. ## Acceptance - [ ] Root cause identified in herdr (recap render vs. input handling). - [ ] `herdr pane send-keys <pane> enter` submits a pending input line while a `※ recap:` block is displayed. - [ ] Reported upstream to herdr — this is a herdr defect, not a plugin one. ## Related - `herdr-mail` delivery no longer depends on the broken path for its own recovery: it prompts with `--wait --until working` and lets herdr report `agent_prompt_stalled`. See herdrmastr#7. - `mail selftest` pins the CLI contract that recovery depends on.
forgejo-admin changed title from A pane showing a ※ recap: block swallows Enter, so doorbells never submit to send-keys enter does not flush already-parked input on a pane showing ※ recap: 2026-07-31 23:32:25 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
plan-gastown-herdr-port
fix-mail-nudge-and-brief-rules
mail-agent-labels
guard-reap-dirty-worktree
fix-spawn-agent-start-race
fix-mail-doorbell-stall
improve-spawn-brief-guidance
add-project-agent-spawn
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo-admin/herdrmastr#6
No description provided.