kami
f54fb0036d
Burn-in run 3 failed three times with prompt_not_submitted: the launch text reached the editor every attempt and the following Enter never took effect. Six isolated probes of the same code path, environment and worktree all submitted on the first Enter, so the submit is not deterministic and waiting for it to land is not enough. F17 first. pendingInput scanned every line beginning with the prompt marker, but a queued or already-accepted message renders with the same prefix. Only the editor that owns the pane cursor is unsubmitted input, so inputState asks tmux for the cursor row and reads the editor around it, joining soft-wrapped rows. On that footing ConfirmLaunch becomes an active submit protocol: resend Enter while the live editor still holds exactly what was submitted, at most three times and no closer together than two poll intervals, then observe until the deadline. Queued input confirms rather than fails. The evidence records confirmation kind, submit_attempts and both timestamps, so a harness that needs a second Enter is distinguishable from one that needs none. Verified live against a real Claude Code pane: confirmation=editor_cleared submit_attempts=1, no spurious resend. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>