codex - 💡(How to fix) Fix Codex Desktop Remote SSH to native Windows host requires hidden CLI/Bash setup and still fails at app-server proxy

What version of the Codex App are you using?

Local Codex Desktop: 26.513.3673.0

Remote Codex CLI observed:

• npm global @openai/codex: codex-cli 0.130.0
• Codex Desktop cached CLI on the remote host: codex-cli 0.131.0-alpha.9

What platform is your computer?

Local client:

• Windows
• Codex Desktop
• OpenSSH_for_Windows_9.5

Remote host:

• Windows
• Native Windows OpenSSH Server
• Git Bash installed and configured as the OpenSSH default shell as a workaround
• No WSL involved
• SSH public-key authentication succeeds
• Codex App is installed and signed in on the remote machine
• A separate npm global Codex CLI was installed so codex is available on PATH

What issue are you seeing?

Codex Desktop Remote SSH discovers the Windows SSH host and authenticates successfully. Basic SSH and remote Codex checks work:

ssh windows-04 "whoami && hostname && codex --version && codex login status"

<redacted-user>
<redacted-windows-hostname>
codex-cli 0.130.0
Logged in using ChatGPT

The first failure was that Codex Desktop sends a POSIX sh -c ... bootstrap command, while native Windows OpenSSH normally defaults to cmd.exe or PowerShell. I worked around that by configuring Windows OpenSSH to use Git Bash as the default shell.

After that, the shell probe and codex --version probe succeed. The Desktop logs show successful remote bootstrap steps, including:

ssh_websocket_v0.remote_login_shell_command_completed code=0 operation=codex_path_probe
ssh_websocket_v0.remote_login_shell_command_completed code=0 operation=codex_version_probe stdout="codex-cli 0.130.0\n"
ssh_websocket_v0.remote_login_shell_command_completed code=0 operation=app_server_bootstrap

However, the connection still fails when Desktop starts:

codex app-server --listen unix://
codex app-server proxy

The proxy fails against the Windows remote control socket:

Error: failed to connect to socket at C:\Users\<user>\.codex\app-server-control\app-server-control.sock

Caused by:
    socket operation encountered a dead network. (os error 10050)

The UI reports this as a generic SSH connection failure / websocket closed:

socket hang up
Codex app-server websocket closed (code=1006)

Manual investigation suggests this is not an SSH authentication problem:

• ssh windows-04 works.
• codex --version works remotely.
• codex login status works remotely.
• codex app-server --listen ws://127.0.0.1:<port> works remotely.
• A manual SSH local-port-forward to codex app-server --listen ws://127.0.0.1:<port> works.
• The failure is specific to the Desktop Remote SSH path using --listen unix:// plus codex app-server proxy on a native Windows remote host.

Product usability concern

There is also a broader product usability issue here.

As a Windows Codex App user, I expected Remote SSH to work with another Windows machine that already has Codex App installed and is signed in. In practice, I had to discover and maintain several hidden prerequisites:

1. The remote Windows machine needs a separate codex CLI on PATH, even though Codex App is already installed.
2. Native Windows OpenSSH defaults to cmd.exe or PowerShell, but the Desktop Remote SSH bootstrap assumes POSIX sh/bash semantics.
3. To get past that, I had to install Git Bash and change the machine-wide OpenSSH DefaultShell.
4. Changing DefaultShell affects all future SSH sessions to that Windows machine, so the workaround has operational side effects outside Codex.
5. Even after doing this, the connection still fails later at the app-server unix:// socket/proxy step.

For ordinary Windows users, this makes the feature feel much less ready than the UI suggests. If native Windows remotes are not yet a supported target, the UI/docs should say that explicitly. If they are intended to be supported, Codex Desktop should either use the already-installed Codex App/runtime on the remote Windows host or provide an automated, reversible setup path that does not require globally changing the OpenSSH default shell.

What steps can reproduce the bug?

1. Use Codex Desktop on Windows.
2. Configure a native Windows OpenSSH remote host in ~/.ssh/config.
3. Verify normal SSH public-key auth works:

ssh <alias> "whoami && hostname"

1. Install/sign in to Codex App on the remote Windows host.
2. Install Codex CLI separately so codex is available on PATH, for example via npm.
3. Verify:

ssh <alias> "codex --version && codex login status"

1. Configure Windows OpenSSH on the remote host to use Git Bash as the default shell, for example:

New-Item -Path "HKLM:\SOFTWARE\OpenSSH" -Force | Out-Null

New-ItemProperty `
  -Path "HKLM:\SOFTWARE\OpenSSH" `
  -Name DefaultShell `
  -Value "C:\PROGRA~1\Git\bin\bash.exe" `
  -PropertyType String `
  -Force

New-ItemProperty `
  -Path "HKLM:\SOFTWARE\OpenSSH" `
  -Name DefaultShellCommandOption `
  -Value "-c" `
  -PropertyType String `
  -Force

Restart-Service sshd

1. Verify the remote POSIX shell path and Codex CLI:

ssh <alias> 'echo shell=$SHELL; [ -x "$SHELL" ] && echo SHELL_EXEC_OK; command -v sh; command -v codex; codex --version'

1. In Codex Desktop, open Settings -> Connections -> SSH and select the discovered host.
2. Observe that the connection still fails after app-server bootstrap.

Expected behavior

Codex Desktop Remote SSH should support native Windows OpenSSH hosts, or clearly document and diagnose that Windows remote hosts are not currently supported.

A product-level fix could be one of:

1. Use a Windows-compatible remote app-server transport instead of unix:// for native Windows SSH hosts, for example ws://127.0.0.1:<dynamic-port> with SSH forwarding.
2. Detect Windows remote hosts and use a PowerShell/native bootstrap path.
3. Allow per-connection configuration of the remote bootstrap shell and app-server transport.
4. Show a clear diagnostic such as "Windows remote app-server unix socket transport failed" instead of a generic "SSH connection failed".
5. Provide an automated, reversible setup flow for Windows remotes if extra CLI/shell setup is required.

Additional context

This appears related to but different from:

• #22757: native Windows OpenSSH with PowerShell default shell fails during POSIX bootstrap
• #22255: Windows remote app-server/socket issue during project folder validation

In this case, the POSIX shell requirement has already been worked around with Git Bash. The remaining blocker is the unix:// app-server control socket / proxy path on a native Windows remote host.