confirm() opened /dev/tty to read the answer, which made it a second reader on the terminal. Under any wrapper that hands its child a pipe for stdin — pass-cli run does, and that is how every credential-touching script here is invoked — the wrapper is itself reading the terminal to fill that pipe. The two then race for each line: the first answer typed went to the wrapper and into a pipe nobody drains, and only the second reached confirm(). The prompt sat there looking ignored and had to be answered twice. The comment above the old code described this symptom and claimed a fix, which was to read from a fresh /dev/tty open rather than hold one descriptor open across both the prompt and the read. That addressed a different failure and left this one, because the competing reader is the wrapper, not the descriptor. The prompt still goes to /dev/tty, which is unrelated and still necessary: run_log_start routes fd 2 through an awk filter that emits only complete lines, and a prompt has no trailing newline, so a prompt written there is never seen. Five cases pin it. A pipe on stdin is exactly what such a wrapper supplies, so they exercise the real configuration rather than standing in for it — and unlike the /dev/tty path, a pipe is something a suite with no controlling terminal can produce. One of them asserts that exactly one line is consumed: a confirm() that drained stdin would leave the caller's own later read at EOF.