brev exec replays remote command after SSH reconnect

[iskandr]

Brev CLI v0.6.322 on macOS replayed a long-running remote command after its SSH transport dropped.

Observed on 2026-08-25:

1. Started brev exec INSTANCE "mhcflurry eval compare-models ...".
2. The remote evaluator began at 03:22:05 and completed one expensive inference phase.
3. At 03:26:38 the client printed Connection failed, checking instance status... followed by waiting for SSH connection to be available.
4. Once SSH returned, stdout restarted at the command beginning ([+ 0.0s] running components: processing).
5. Remote process inspection showed two simultaneous evaluators with identical argv and output directory: original PID 2025529 (PPID 1 after disconnect) and replay PID 2033852 (parented by the new exec shell).
6. The original later became defunct; the replay had already begun writing into the same output directory. I terminated only the replay and relaunched the job under an explicit detached/locked wrapper.

Expected: a reconnect may reattach to the existing remote process, or the client may fail and leave it detached, but it must never re-execute a non-idempotent remote command automatically.

This can corrupt output or duplicate costly/destructive work. Please make command execution at-most-once across reconnects, ideally using a remote execution ID/status marker rather than replaying argv.

[iskandr]

Reproduced again with Brev CLI v0.6.322 during the mhcflurry release postprocess. After the attached remote evaluator was intentionally terminated as scientifically invalid, the SSH transport reported a connection failure and the client re-executed the entire @script from the top. The replay created shell PID 2082370 and began the non-idempotent rm/extract setup again (tar PID 2082609) instead of returning the original failure. I terminated only that replayed process group and closed the local client; the 4xA100 instance remained intact.\n\nDownstream hardening in openvax/mhcflurry commit ad8e0f1d2 adds a remote one-shot state directory. A replay waits for the original invocation atomic exit marker and returns the same status without entering the body. Regression tests launch concurrent original/replay scripts for both status 0 and status 23 and prove the body runs exactly once. This contains the issue for the release workflow, but the CLI-level command replay remains surprising and unsafe for arbitrary non-idempotent @scripts.