Desktop remote SSH bootstrap times out after app-server starts

Codex Desktop can report a 60-second remote SSH bootstrap timeout even though the remote app-server has started successfully. In the observed case, retrying connected to the same running server.

Environment

• macOS Codex Desktop connecting to a Linux SSH host.
• Runtime observation: upstream Desktop version 26.903.61454.
• Static inspection of version 26.908.40834 found the same command structure. That newer version has not been retested at runtime.

Cause

The generated bootstrap command has this simplified structure:

preflight && nohup codex app-server ... >log 2>&1 &

The trailing & backgrounds the entire && list. In the reproduction, the background shell retained SSH's stdout/stderr pipes while waiting for the long-running command. Redirecting the app-server's output did not close the shell's copies of those pipes. SSH therefore remained open until Desktop's bootstrap timeout expired.

Minimal shell reproduction

Replace user@host.example with a disposable Linux SSH target. These commands run only a two-second sleep:

# Backgrounds the entire AND-list; SSH can wait for sleep to finish.
time ssh user@host.example 'true && nohup sleep 2 </dev/null >/dev/null 2>&1 &'

# Backgrounds only sleep; SSH can return without waiting for it.
time ssh user@host.example 'true && { nohup sleep 2 </dev/null >/dev/null 2>&1 & }'

Controlled SSH tests reproduced the delay with the first structure and removed it when only the final command was backgrounded.

Expected behavior and suggested change

Bootstrap should finish after successful preflight and app-server launch, without waiting for the app-server to exit. Keep preflight in the foreground and group the background command:

preflight && {
  nohup codex app-server ... </dev/null >log 2>&1 &
}

This correction was tested with a shell-only reproduction, not a patched Desktop build. It addresses the bootstrap timeout after server start;

Start by locating the generated remote bootstrap command in the Desktop SSH path and compare it with the two shell reproductions in the issue. Verify the corrected grouping in a controlled SSH test; done means preflight and app-server launch return without the 60-second timeout.