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

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

• #22757
• #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:

1. PowerShell/cmd default shell fails because the bootstrap assumes POSIX syntax (#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.

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.

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

1. Connect through:

codex app-server proxy

1. 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: https://github.com/openai/codex/issues/28919