Codex Desktop Windows-to-Windows Remote SSH fails after authentication because bootstrap requires POSIX sh
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?
- Configure a Windows machine running OpenSSH Server.
- Configure SSH key authentication.
- Verify normal SSH works:
ssh -i C:\Users\MBosze\.ssh\codex_ed25519 ct4nk3r@100.121.5.113
ssh ct4nk3r@<host>
- Verify SSH key authentication works:
ssh -i <private-key> ct4nk3r@<host>
- Add the host in Codex Desktop Remote Connections.
- Enable the connection.
- 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" />
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗