Codex Desktop Windows-to-Windows Remote SSH fails after authentication because bootstrap requires POSIX sh

Open 💬 3 comments Opened Jun 3, 2026 by CT4nk3r

What version of the Codex App are you using (From “About Codex” dialog)?

v0.136.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

The code you guys are giving is not working btw:

$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" }) ParserError: Line |    1 |  $([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Env …      |                                                             ~~      | Unexpected token '$(' in expression or statement. ----- 
Windows 11 25h2 BTW

What issue are you seeing?

Codex Desktop Remote SSH authenticates successfully to a native Windows OpenSSH host, but the connection fails during remote bootstrap.

SSH key authentication works correctly. Manual SSH login succeeds without a password. Codex discovers the host, authenticates, and begins remote setup.

However, the remote bootstrap appears to execute POSIX shell syntax on the Windows host's default shell. The connection then fails with errors similar to:

-sh: -c: line 2: syntax error:
unexpected end of file from `if` command

Earlier connection attempts also showed errors consistent with POSIX shell code being interpreted by Windows shells.

Environment

Local machine:

  • Windows
  • Codex Desktop
  • OpenSSH_for_Windows_9.5p2

Remote machine:

  • Windows 11
  • Native Windows OpenSSH Server
  • User: ct4nk3r
  • Public key authentication configured and working

What steps can reproduce the bug?

  1. Configure a Windows machine running OpenSSH Server.
  2. Configure SSH key authentication.
  3. Verify normal SSH works:

ssh -i C:\Users\MBosze\.ssh\codex_ed25519 ct4nk3r@100.121.5.113

ssh ct4nk3r@<host>
  1. Verify SSH key authentication works:
ssh -i <private-key> ct4nk3r@<host>
  1. Add the host in Codex Desktop Remote Connections.
  2. Enable the connection.
  3. Observe that authentication succeeds but the connection fails during bootstrap.

What is the expected behavior?

Codex Desktop should either:

  • support native Windows OpenSSH hosts using PowerShell/cmd,
  • automatically detect and use an appropriate Windows bootstrap path,
  • or display a clear message that only POSIX-compatible shells (WSL, Linux, Git Bash, etc.) are supported.

Additional information

The issue does not appear to be related to SSH configuration.

I verified:

  • SSH connectivity works.
  • Public key authentication works.
  • Codex uses the correct key.
  • Codex reaches the remote machine.

The failure occurs only after authentication when the remote bootstrap is executed.

This appears similar to other reports where Codex Remote SSH assumes a POSIX shell environment on Windows hosts.

What steps can reproduce the bug?

Create a public key for ssh connection.
Create an identity file.
SSH to the other windows machine -> works without a password now.
Add that identity file to codex's ssh connection's identity profile.
Connection is not working. It is trying to use Linux native commands on the windows host.

Additional information

Manual SSH authentication succeeds using the same host, user, and private key that are configured in Codex Desktop.

It works with phone. And it works if the host is a linux machine.

The first time this problem happened is now, when I tried to connect two windows machines.

I also tested the same Codex Desktop client and same SSH key against a Linux host.

Result:

  • Windows 11 OpenSSH host: SSH authentication succeeds, but Codex bootstrap fails with shell syntax error.
  • CachyOS Linux OpenSSH host: SSH authentication succeeds and Codex connects successfully.

This suggests the issue is specific to native Windows OpenSSH remote hosts, not my SSH key, network, or Codex client configuration.

Connection to my home server works correctly (It's running CachyOS):
<img width="779" height="380" alt="Image" src="https://github.com/user-attachments/assets/4c09c806-d55a-4a0b-8717-678c7d9a131e" />

Connection to my windows machine (Windows 11 25h2 x64):
<img width="672" height="193" alt="Image" src="https://github.com/user-attachments/assets/4b21484e-69cf-4d8d-969b-5ab2204fd268" />

View original on GitHub ↗

3 Comments

AemonYwj · 1 month ago

I can reproduce the same issue when connecting from the macOS ChatGPT/Codex desktop app to a native Windows OpenSSH host, so this is not limited to Windows-to-Windows connections.

Environment

Local client:

  • macOS, Apple Silicon
  • ChatGPT/Codex desktop app
  • Bundled Codex client observed as 0.145.0

Remote host:

  • Windows 11, build 10.0.26200
  • OpenSSH_for_Windows_9.5
  • Default OpenSSH shell: cmd.exe
  • Remote Codex CLI: codex-cli 0.136.0
  • codex, codex remote-control, and codex app-server are available on PATH

Verification

Normal SSH works correctly with the same host alias, user, key, and host key:

TCP/22 reachable
Public-key authentication succeeds
Minimal remote command completes in approximately 0.38 seconds

Codex Desktop also successfully authenticates:

Authenticated to <windows-host> using "publickey".

The failure happens afterward during remote_codex_lookup. The desktop app sends a POSIX bootstrap command beginning with:

sh -c 'if [ -z "$SHELL" ] || [ ! -x "$SHELL" ]; then ...'

Because Windows OpenSSH passes this to cmd.exe, it fails with errors including:

sh: -c: line 2: syntax error: unexpected end of file from `if' command on line 1
'tcsh)' is not recognized as an internal or external command

The application log identifies the failed stage as:

sshSetupStage=remote_codex_lookup
errorName=AppServerSshSetupError

I reproduced the same bootstrap failure over both a direct LAN address and a Tailscale address. Therefore, this is independent of the underlying transport, VPN/TUN configuration, host-key verification, and SSH authentication.

This confirms that the current remote bootstrap assumes a POSIX-compatible login shell even when the remote server reports OpenSSH_for_Windows.

Expected behavior would be one of:

  1. Detect native Windows OpenSSH and use a PowerShell/cmd-compatible bootstrap.
  2. Use a Windows-specific app-server lifecycle adapter.
  3. Clearly report that native Windows SSH targets are unsupported and recommend WSL/Linux, instead of surfacing a shell syntax error.

This also appears related to #29015.

mmiladinov · 1 month ago

+1

SunHuilong · 11 days ago

Still reproducible after updating Codex on 2026-08-16. The remote Codex CLI was updated from 0.144.1 to 0.147.0, but the behavior is unchanged.

Current environment

  • Codex Desktop package: 26.810.7004.0
  • Bundled Codex app-server: 0.148.0-alpha.9
  • Remote Codex CLI: 0.147.0
  • Windows 11 Pro 25H2 x64, build 26200.9168
  • OpenSSH_for_Windows_9.5p2 / LibreSSL 3.8.2
  • Native Windows OpenSSH default shell: cmd.exe
  • Target used for this reproduction: 127.0.0.1

Reproduction result

Manual SSH with the same host and key works, and the remote CLI is available:

~~~text
codex-cli 0.147.0
~~~

Codex Desktop also completes public-key authentication:

~~~text
Authenticated to 127.0.0.1 ([127.0.0.1]:22) using "publickey".
~~~

It then fails during remote_codex_lookup:

~~~text
'sh' is not recognized as an internal or external command.
'[' is not recognized as an internal or external command.
~~~

Assessment

The native Windows OpenSSH server passes remote commands to cmd.exe. Codex Desktop invokes sh -c before its later uname -s platform detection, so the Windows detection path is never reached.

This means the failure occurs after SSH authentication and before the remote Codex app-server can be started.

Expected behavior

Codex Desktop should either:

  • detect OpenSSH_for_Windows and use a PowerShell/cmd-compatible bootstrap; or
  • report clearly that native Windows OpenSSH targets are unsupported, instead of failing with POSIX shell errors.