PWA send renders in the pane's input box but never reaches the input buffer (silently lost)

[maikschuheida-spec]

Summary

Text sent from the Collie composer intermittently never reaches the harness: the sent text renders inside the harness's input box in the terminal mirror, but the harness itself never receives it - the message is silently lost (no send, no error surfaced in the PWA). Happened 6+ times in a single day across different panes.

Environment

• Collie 0.14.0 (all occurrences); per changelog review, 0.14.1/0.14.2 contain no related fix, so presumably still present in 0.14.2 (now running it, no long-term data yet)
• Herdr 0.7.4
• Bridge host: macOS (Apple Silicon), bridge behind tailscale serve (README Variant A)
• Client: iOS PWA installed to the home screen
• Harness in the affected panes: Claude Code

Steps to reproduce (as observed; intermittent)

1. Open a pane running Claude Code in the PWA.
2. Type a message in the composer and tap Send.
3. The terminal mirror shows the text rendered in the harness's input box - looks like a successful hand-off.
4. The harness never processes it: nothing is submitted, and checking the terminal directly shows the input buffer does not actually contain the text.

Expected

Either the text lands in the harness input buffer (and submits), or Collie surfaces a failure so the user knows the send was lost.

Actual

The mirror renders the text as if delivered, but the input buffer never received it. No error, no retry hint - the message silently disappears. From the phone this is indistinguishable from a successful send until you notice the agent never responded.

Notes

• Intermittent: most sends work; on the affected day it failed 6+ times.
• Happy to pull bridge/audit logs for a failing occurrence on request.

[AltanS]

Reproduced, root-caused, and fixed in 0.17.0. Thanks for this — it turned out to be more serious than the report, so I'll lead with that part.

It isn't only losing your message. It's answering dialogs.

I reproduced it on a real Claude pane in manual mode. With a Bash permission prompt focused and 1. Yes highlighted, I sent a message through the same path the phone uses:

• the bridge returned {"ok":true}
• the dialog was dismissed and the command ran
• the message appeared nowhere

The submit key answered the prompt. Claude highlights Yes by default, so a reply typed at the wrong moment can approve a tool call you never saw. That's the part worth knowing about if you've been driving agents from your phone.

Why it looked intermittent. Sending while the agent is merely busy works correctly — I checked, it queues and delivers. The trigger is specifically a dialog holding focus, which is why it hit you 6+ times in one day and not at all on other days.

Your exact symptom — text rendering in the input box — is a second channel. A message that lands in the input box unsubmitted shows in the mirror, and is then wiped by the next send's pre-clear sweep. So one message gets stuck, you retype and send again, and that second send destroys the first. Both are fixed.

Why nothing was surfaced. Not an error-handling gap: both Herdr RPCs genuinely succeeded. An ack means "herdr took the bytes", never "the TUI acted on them", so the bridge cannot detect this. Only a client that can read the input box can.

The fix. Every other path that types into a live terminal already refuses to send a key it hasn't verified the pane is ready for. The reply path was the one exception. Now it refuses outright while a dialog is up, and otherwise types first, confirms the text is actually sitting in the input box, and only then submits. If the text never arrives, no key is sent at all and your draft is kept — so you get exactly what you asked for: either it lands, or Collie tells you it didn't.

One limitation, stated plainly: this needs a harness grammar, so today it covers Claude Code. Other harnesses keep the old one-shot send, because guessing from the raw mirror would strand a no-echo input (a shell's sudo prompt) with the submit key withheld forever. They get this the moment they get an adapter.

Details in #39. No need for the logs — the repro was enough.

To pick it up:

herdr plugin action invoke update --plugin herdr.collie