SSH bootstrap daemon binary upload via scp fails on sftp-chrooted servers

[arzafran]

Tracking upstream cmux manaflow-ai#6207 — applicable to our fork but needs a product/scope decision.

Assessment: Confirmed: uploadRemoteDaemonBinaryLocked at Sources/Workspace.swift:4712 uses /usr/bin/scp (line 4154). sshExec already accepts stdin: Data? (line 4139), making the stdin-pipe fix mechanically straightforward. However, this targets a specific sshd configuration (sftp subsystem chroot ≠ shell session root) that may affect few users. Needs a product decision on whether sftp-chrooted hosts are a supported configuration. Existing tests mock /usr/bin/scp and would need updating.

Upstream: manaflow-ai#6207

[arzafran]

Decision: Defer. The stdin-pipe fix (sshExec already accepts stdin: Data?) is mechanically straightforward, but this targets a niche sftp-chrooted sshd config and SSH-remote is unmaintained/unused. Bundle with the SSH-remote revival tracked in #15. Cleared needs-decision.

---

Generated by Claude Code

[arzafran]

Closing as deferred/wontfix-for-now. The failure isn't isolated to scp — the entire SSH bootstrap chain (remote state probe, mkdir -p, the scp upload, and chmod 755 && mv) all run via ssh exec and all fail on strict ForceCommand internal-sftp chroots. Supporting sftp-only chroot servers means rethinking the whole upload+probe path (an SFTP-native bootstrap), and the remote-daemon spec has no milestone scheduled for it. Reopen if a concrete need lands.