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:

The remote Windows machine needs a separate codex CLI on PATH, even though Codex App is already installed.
Native Windows OpenSSH defaults to cmd.exe or PowerShell, but the Desktop Remote SSH bootstrap assumes POSIX sh/bash semantics.
To get past that, I had to install Git Bash and change the machine-wide OpenSSH DefaultShell.
Changing DefaultShell affects all future SSH sessions to that Windows machine, so the workaround has operational side effects outside Codex.
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?

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

ssh <alias> "whoami && hostname"

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

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

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

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'

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

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.
Detect Windows remote hosts and use a PowerShell/native bootstrap path.
Allow per-connection configuration of the remote bootstrap shell and app-server transport.
Show a clear diagnostic such as "Windows remote app-server unix socket transport failed" instead of a generic "SSH connection failed".
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.

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

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:

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).
Git Bash with -c can still poison $SHELL / command wrapping.
Git Bash with -lc can get the connection and proxy running.
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.

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:

Probe codex on the remote.
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 &

Connect through:

codex app-server proxy

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.

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

Adding one more anonymized data point: on a newer Codex Desktop/CLI build, the Git Bash default-shell workaround was enough to make native Windows OpenSSH Remote SSH usable.

Environment:

Local client: Windows Codex Desktop 26.616.81150
Local SSH client: OpenSSH_for_Windows_9.5p2
Remote host: native Windows OpenSSH Server, no WSL
Remote Codex CLI/App install on PATH: codex 0.142.0
Git Bash installed on the remote Windows host
SSH public-key auth already worked before the fix

Initial failure:

Codex Desktop authenticated successfully, but the remote bootstrap failed during codex_path_probe. The UI showed mojibake because the remote Windows error was emitted in an OEM code page. Decoding the captured SSH stderr as CP866 showed:

"sh" is not recognized as an internal or external command,
operable program or batch file.
"[" is not recognized as an internal or external command,
operable program or batch file.

The failing command shape was the same POSIX bootstrap described above: Codex sends sh -c 'if [ -z "$SHELL" ] ...', but native Windows OpenSSH was executing the command through the default Windows shell, so both sh and POSIX [ failed before Codex could probe codex.

Working workaround used on the remote Windows host:

$regPath = 'HKLM:\SOFTWARE\OpenSSH'
$bashPath = 'C:\Program Files\Git\bin\bash.exe' # adjust if Git Bash is elsewhere

New-Item -Path $regPath -Force | Out-Null

New-ItemProperty `
  -Path $regPath `
  -Name DefaultShell `
  -Value $bashPath `
  -PropertyType String `
  -Force | Out-Null

New-ItemProperty `
  -Path $regPath `
  -Name DefaultShellCommandOption `
  -Value '-c' `
  -PropertyType String `
  -Force | Out-Null

New-ItemProperty `
  -Path $regPath `
  -Name DefaultShellEscapeArguments `
  -Value 0 `
  -PropertyType DWord `
  -Force | Out-Null

[Environment]::SetEnvironmentVariable('SHELL', '/usr/bin/bash', 'Machine')

Restart-Service sshd -Force

After that, these checks succeeded from the local Windows client:

ssh <alias> 'printf "SHELL=%s\n" "$SHELL"; test -x "$SHELL"; command -v sh; command -v codex; codex app-server --help'

The exact codex_path_probe command captured from Desktop also returned exit code 0, and codex app-server --stdio stayed running instead of exiting immediately. After reconnecting/retrying in Codex Desktop, the SSH connection turned usable and a remote project folder could be opened from the local Desktop UI.

Operational caveat: this is a machine-wide OpenSSH setting, so future manual SSH sessions to that Windows host also land in Git Bash. PowerShell still works when invoked explicitly, for example:

ssh <alias> "powershell.exe -NoProfile -Command 'Write-Output PS_OK; $PSVersionTable.PSVersion.ToString()'"

For safety, I recommend backing up any existing OpenSSH registry values before changing them:

HKLM:\SOFTWARE\OpenSSH\DefaultShell
HKLM:\SOFTWARE\OpenSSH\DefaultShellCommandOption
HKLM:\SOFTWARE\OpenSSH\DefaultShellEscapeArguments

This does not remove the product issue: Desktop still assumes a POSIX-compatible remote shell for native Windows OpenSSH, and the UI diagnostic is misleading when it shows a generic SSH failure or mojibake instead of "remote shell is not POSIX-compatible / sh not found". But on the current build above, configuring Git Bash as the OpenSSH default shell was a complete workaround for this setup.

faced same issue when tried ssh as workaround for this issue: #28919

Confirming this still reproduces with a macOS client and native Windows SSH host.

Environment:

Client: ChatGPT/Codex desktop on macOS, Darwin 25.5.0, OpenSSH 10.2p1
Remote: Windows 10.0.26200.8875
Windows OpenSSH Server 9.5
Codex CLI 0.145.0
Git for Windows 2.55.0(3)
Transport network: Tailscale

Verified working:

SSH public-key authentication
Full Git Bash configured as Windows OpenSSH DefaultShell
sh, [, sed, dirname, uname, tar, and git
codex --version → codex-cli 0.145.0
codex login status → authenticated through ChatGPT
Manual noninteractive command:
ssh windows-codex 'command -v tar && command -v git && codex --version'

Codex Desktop behavior:

Without Git Bash, bootstrap fails because sh and [ are unavailable.
After configuring full Git Bash and verifying all probes, Desktop proceeds further but reports socket hang up.
Temporary OpenSSH DEBUG3 logging shows every probe authenticates and starts successfully.
There is no server-side SSH failure. The macOS client closes each command session during/after app-server discovery.
The Desktop connection never becomes usable.

This appears to be the same native-Windows unix:// app-server control socket/proxy incompatibility described in this issue. There is currently no documented native-Windows workaround that does not require WSL.

Please either support a Windows-compatible transport or explicitly document that native Windows SSH targets are unsupported.

Confirming this from another setup:

Local client: Codex Desktop on Ubuntu 24.04
Remote: Windows 11, native Windows OpenSSH, no WSL
Git Bash is installed
Remote Codex CLI: codex-cli 0.151.0

Verified independently:

Batch-mode SSH authenticates with the explicit Ed25519 key and correct remote user.
Normal SSH commands succeed.
The remote Codex CLI runs successfully.
Codex Desktop still reports only SSH connection failed.
The remote bootstrap receives SHELL=/c/windows/system32/cmd.exe and sends a POSIX sh/login-shell launch path. It drops into the Windows command prompt instead of starting the expected app-server proxy.

This is not an SSH authentication failure, but the UI presents it as one.

I could not find official Codex documentation stating the supported Remote SSH OS/shell matrix or explaining the native-Windows prerequisites. Please either:

support a Windows-native bootstrap and app-server transport, or
clearly document that native Windows OpenSSH remotes are unsupported, including that the Git Bash DefaultShell workaround is machine-wide and may still fail later at the app-server socket/proxy stage.

A preflight error such as “native Windows remote shell/transport is unsupported” would be much more actionable than “SSH connection failed.”

Navigation Menu

Repository navigation

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

What version of the Codex App are you using?

What platform is your computer?

What issue are you seeing?

Product usability concern

What steps can reproduce the bug?

Expected behavior

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of the Codex App are you using?

What platform is your computer?

What issue are you seeing?

Product usability concern

What steps can reproduce the bug?

Expected behavior

Additional context

Activity

github-actions commented on May 16, 2026

nielslindor commented on May 17, 2026

nielslindor commented on May 17, 2026

Krispyru commented on May 31, 2026

zoomerland commented on Jun 25, 2026

ilnytskyi commented on Jul 14, 2026

aintelegator commented on Jul 22, 2026

shreyam1008 commented on Aug 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions