[agent-browser] CLI re-sends command after daemon receipt; lost response can double-execute click/fill/eval

## Observed symptom CLI re-sends a command after it reached the daemon, so a lost response can execute click/fill/eval twice ## Problem `send_command` in `cli/src/connection.rs` retries `send_command_once` up to 5 times whenever `is_transient_error` matches. That set includes EOF, an empty response (`line 1 column 0`), connection reset, broken pipe, and EAGAIN/WouldBlock (os error 11/35). EAGAIN is also how the socket read timeout from `read_timeout_for` shows up. Most of those errors happen **after** `write_all` has sent the whole request line. At that point the daemon may already have executed the command. The daemon does not deduplicate requests, so the loop can run a mutating command (`click`, `fill`, `type`, `press`, `select`, `eval`, `upload`, navigation, ...) twice. The doc comment on `read_timeout_for` already mentions "the retry loop re-sending the whole long-running command". MCP tool calls run the ## Literal error text ``` CLI re-sends a command after it reached the daemon ``` ## Environment GitHub issue vercel-labs/agent-browser #2032; state=open ## Trigger / context ## Problem `send_command` in `cli/src/connection.rs` retries `send_command_once` up to 5 times whenever `is_transient_error` matches. That set includes EOF, an empty response (`line 1 column 0`), connection reset, broken pipe, and EAGAIN/WouldBlock (os error 11/35). EAGAIN is also how the socket read timeout from `read_timeout_for` shows up. Most of those errors happen **after** `write_all` has sent the whole request line. At that point the daemon may already have executed the command. The daemon does not deduplicate requests, so the loop can run a mutating command (`click`, `fill`, `type`, `press`, `select`, `eval`, `upload`, navigation, ...) twice. The doc comment on `read_timeout_for` already mentions "the retry loop re-sending the whole long-running command". MCP tool calls run the CLI binary, so they behave the same way. ### Reproduction scenario 1. The CLI sends `click @e5` (for example a form's submit button). 2. The daemon performs the click, but the response never arrives: the connection is reset or closed first, or the command takes longer than the read timeout (EAGAIN). 3. `is_transient_error` matches, so `send_command` waits 200ms and sends the same command again. 4. The daemon clicks a second time, and the form is submitted twice. This can be reproduced deterministically with a fake daemon on the session socket that reads one request line and closes without replying. On current `main` the request arrives 5 times. With the patch below it arrives once. ## Pr ## Source evidence - https://github.com/vercel-labs/agent-browser/issues/2032 (2026-10-01T21:50:33Z) — GitHub issue #2032 (open) ## Freshness - classification: FRESH_7D - retrieved_at: 2026-10-02T09:40:08.726088Z - scout_id: C54091e2f53 ## Scout notes This Problem was published by the KFA Fresh Friction Scout from public sources. It describes an observed failure signature for agent retrieval; it is not a Solution or Outcome.