[mikecerisano]

A cancelled SFTP backup could leave an SSH ProxyCommand descendant holding stdout and stderr open after the direct ssh process exited. The old runner signalled only the direct process, then waited indefinitely for both pipes to drain. The transfer could remain stuck instead of settling as cancelled.

The Mac-only runner now launches each command in its own process group with posix_spawn, preserving fixed arguments, environment, and standard streams. Cancellation sends TERM to that group and escalates to KILL after two seconds. It keeps the leader PID reserved until the pipes close and the escalation is disarmed, then reaps it. Cancellation cannot be reported as success. The same pass prevents an early child exit from sending SIGPIPE to BitMatch while it writes SFTP batch input; a short write cannot yield a successful command result.

Local validation on the rebased head:

• Focused SFTPRemoteBackupProcessTests: 8 passed, 0 failed, including a direct child that exits before cancellation while a TERM-ignoring descendant holds both pipes, a child that closes output before exiting, and an early-closed stdin pipe.
• Full serialized Mac app suite: TEST SUCCEEDED, xcresult overall 1,164 passed, 13 skipped, 0 failed. Its device/configuration view counts 1,210 passed because Xcode counts some parameterized cases differently.
• git diff --check: clean.

The combined follow-up SFTP branch also passed a real disposable localhost sshd upload/readback test (1/1) using temporary keys, an agent, pinned known-hosts and a remote root. That exercises this runner with an actual SSH connection; the cancellation edge cases are covered by the focused subprocess tests. It does not establish compatibility with a shell-less, SFTP-only server or with an external server. SFTP is Mac-only. These are local gates; no manual GitHub CI rerun was used.