Codex Desktop Remote SSH to native Windows host requires hidden CLI/Bash setup and still fails at app-server proxy

[PengdaoJiang]

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"

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

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

7. 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

8. 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'

9. In Codex Desktop, open Settings -> Connections -> SSH and select the discovered host.
10. 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:

• Codex Desktop Remote SSH to Windows OpenSSH fails when default shell is PowerShell #22757: native Windows OpenSSH with PowerShell default shell fails during POSIX bootstrap
• Codex App remote Windows project folder validation fails even though the folder exists #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.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Desktop Remote SSH to Windows OpenSSH fails when default shell is PowerShell #22757
• Codex App remote Windows project folder validation fails even though the folder exists #22255

Powered by Codex Action

[nielslindor]

I have a related native Windows OpenSSH repro that gets one step further than this report.

In my case, after configuring Git Bash as the Windows OpenSSH default shell with DefaultShellCommandOption=-lc, Codex Desktop/GUI gets past SSH auth, shell bootstrap, app-server startup, and proxy startup. The connection turns green, but adding a remote project still fails with:

Choose an existing folder on this remote host.

Remote host:

• Get-ComputerInfo: OsName=Microsoft Windows 11 Pro, OsVersion=10.0.26200, OsBuildNumber=26200, OsArchitecture=64-bit
• OpenSSH: OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2
• Git: git version 2.54.0.windows.1
• Git Bash: GNU bash, version 5.3.9(1)-release (x86_64-pc-cygwin)
• Node: v24.15.0
• npm: 11.12.1
• Codex CLI / npm package: codex-cli 0.130.0, @openai/codex@0.130.0

Windows OpenSSH config:

DefaultShell=C:\Program Files\Git\bin\bash.exe
DefaultShellCommandOption=-lc

The remote app-server and proxy are both running as native Windows Codex binaries:

...\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex\codex.exe app-server --listen unix://
...\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex\codex.exe app-server proxy

The control socket exists:

C:\Users\niels\.codex\app-server-control\app-server-control.sock

The app-server log does not currently contain "socket is already in use", "Directory not found", "workspaceRoot", or "directoryPath" errors around the failed folder validation.

The folder rejected by the UI exists from native Windows APIs:

C:/Users/niels/Documents/LLM revisited        exists=true, isDirectory=true
C:\Users\niels\Documents\LLM revisited        exists=true, isDirectory=true

There is also a path-semantics split across the boundary:

Git Bash/MSYS sees all of these as directories:

C:/Users/niels/Documents/LLM revisited
C:\Users\niels\Documents/LLM revisited
/c/Users/niels/Documents/LLM revisited

Native Windows Node sees only the Windows-style paths:

C:/Users/niels/Documents/LLM revisited        exists
C:\Users\niels\Documents\LLM revisited        exists
/c/Users/niels/Documents/LLM revisited        missing

So the native Windows remote flow appears to have multiple stages:

1. PowerShell/cmd default shell fails because the bootstrap assumes POSIX syntax (Codex Desktop Remote SSH to Windows OpenSSH fails when default shell is PowerShell #22757).
2. Git Bash with -c can still poison $SHELL / command wrapping.
3. Git Bash with -lc can get the connection and proxy running.
4. After that, remote project folder validation still rejects an existing native Windows folder.

This seems related to #22255, but in this case the app-server/proxy are live and there is no current stale-socket error. It also fits the broader hardcoded SSH bootstrap/proxy fragility described in #23102.

[nielslindor]

Additional implementation detail from inspecting the Desktop app bundle and matching it against the live remote command line:

The remote transport appears to be an SSH-backed websocket flow, not a generic interactive SSH shell session.

The flow is roughly:

1. Probe codex on the remote.

2. Start the remote app-server with:

umask 077
mkdir -p -- "${CODEX_HOME:-$HOME/.codex}/app-server-control"

nohup codex app-server --listen unix:// \
  >"${CODEX_HOME:-$HOME/.codex}/app-server-control/app-server.log" 2>&1 &

3. Connect through:

codex app-server proxy

4. The SSH command wrapper uses POSIX shell assumptions and then re-enters $SHELL:

sh -c '... CODEX_REMOTE_PAYLOAD="$1"; export CODEX_REMOTE_PAYLOAD; ... exec "$SHELL" -l -i -c '\''exec /bin/sh -c "$CODEX_REMOTE_PAYLOAD"'\'' ...'

That matches what is visible in the live Windows process tree.

For folder selection/validation, the Desktop code appears to call app-server filesystem methods such as stat, readdir, and platformPath() through the app-server client.

For a remote host, it does not look like the local WSL path conversion branch should apply. That means the path ultimately has to be valid to the native Windows app-server process.

This is why the case is interesting: the POSIX/Git Bash bootstrap succeeds, but project validation is later handled by the native Windows codex-win32-x64 app-server.

That creates a boundary where /c/... is valid to Git Bash but invalid to native Windows filesystem APIs.

However, in this repro the UI also rejects this path:

C:/Users/niels/Documents/LLM revisited

Native Windows APIs confirm that path exists, so the bug may be broader than only MSYS /c/... path normalization.

[Krispyru]

Same issue, not sure if it's because I am running the "optional feature" windows OpenSSH server which I believe is running an old version of OpenSSH server