Native Windows Remote SSH without WSL needs an app-server lifecycle adapter #29015

What happened?

Codex Desktop Remote SSH appears to assume that the remote host has a POSIX-ish environment for app-server bootstrap/daemon lifecycle. On a native Windows OpenSSH host without WSL, this leaves a gap: the normal remote flow either tries to run POSIX shell bootstrap against PowerShell, or later reaches codex app-server daemon ..., which is not implemented on Windows.

This is not quite the same as "Codex cannot run on native Windows". The Windows app-server can be started manually if the remote flow supplies explicit socket/listen arguments. What seems missing is a Windows-native app-server lifecycle adapter/wrapper for Remote SSH.

Environment

• Remote host: native Windows OpenSSH server, no WSL
• Shell cases observed: PowerShell/pwsh default shell, and Git Bash/MSYS used as a workaround shell
• npm Codex: @openai/codex 0.141.0
• Codex Desktop bundled CLI observed separately: 0.142.0-alpha.1
• Target scenario: Codex Desktop Remote SSH to Windows host without WSL

Reproduction / observations

On the Windows host, npm Codex is current:

$ npm view @openai/codex version
0.141.0

$ C:/Users/Administrator/AppData/Roaming/npm/codex.cmd --version
codex-cli 0.141.0

The daemon lifecycle commands fail on native Windows:

$ codex.cmd app-server daemon version
Error: codex app-server daemon lifecycle is only supported on Unix platforms

$ codex.cmd app-server daemon start
Error: codex app-server daemon lifecycle is only supported on Unix platforms

However, explicitly starting app-server with a Windows path in a unix:// listen URL does work:

codex.cmd app-server --listen unix://C:/Users/Administrator/.codex/app-server-control/npm-test.sock

That starts the expected Windows process chain:

cmd.exe /c .../npm/codex.cmd app-server --listen unix://C:/Users/.../npm-test.sock
node.exe .../node_modules/@openai/codex/bin/codex.js app-server --listen unix://C:/Users/.../npm-test.sock
codex.exe app-server --listen unix://C:/Users/.../npm-test.sock

And proxying explicitly to the same socket can stay connected:

timeout 3s bash -lc "tail -f /dev/null | codex.cmd app-server proxy --sock C:/Users/Administrator/.codex/app-server-control/npm-test.sock"
# exits via timeout, rc=124, with empty stderr

As a sanity check, using a missing socket does fail immediately, so the previous proxy result is not just a false positive:

Error: failed to connect to socket at C:\Users\Administrator\.codex\app-server-control\definitely-missing.sock

Caused by:
    The target machine actively refused the connection. (os error 10061)

Expected behavior

Codex Desktop Remote SSH should support native Windows OpenSSH hosts without requiring WSL, or clearly report that this target is unsupported.

Concretely, for native Windows remotes, the bootstrap could avoid the unsupported Unix-only daemon lifecycle and instead use a Windows lifecycle path equivalent to:

codex app-server --listen unix://C:/Users/<user>/.codex/app-server-control/<socket>.sock
codex app-server proxy --sock C:/Users/<user>/.codex/app-server-control/<socket>.sock

Actual behavior

The Remote SSH flow appears to depend on POSIX shell behavior and/or codex app-server daemon ..., even though that daemon lifecycle command is explicitly unsupported on Windows.

Why this matters

There is a working lower-level path for the Windows app-server/proxy, but users currently need a custom wrapper to translate the Remote SSH daemon/socket expectations into commands that native Windows Codex can execute. Supporting this officially would make non-WSL Windows remotes possible and would also make failures more understandable when the host is not supported.

Related issues that seem adjacent: #22757, #22965, #26164, #28361.