Skip to content

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

Open
Open
Codex Desktop Windows-to-Windows Remote SSH fails after authentication because bootstrap requires POSIX sh#26164
Labels
appIssues related to the Codex desktop appbugSomething isn't workingremotewindows-osIssues related to Codex on Windows systems

Description

@CT4nk3r
CT4nk3r
opened on Jun 3, 2026

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):
Image

Connection to my windows machine (Windows 11 25h2 x64):
Image

Activity

  1. CT4nk3r
    added
    appIssues related to the Codex desktop app
    on Jun 3, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    remote
    on Jun 3, 2026
  3. linear
    changed the title [-]Windows <-> Windows ssh connection for remote codex usage[/-] [+]Codex Desktop Windows-to-Windows Remote SSH fails after authentication because bootstrap requires POSIX sh[/+] on Jul 15, 2026

  4. AemonYwj commented on Jul 21, 2026

    @AemonYwj
    AemonYwj
    on Jul 21, 2026

    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.

  5. mmiladinov commented on Jul 24, 2026

    @mmiladinov
    mmiladinov
    on Jul 24, 2026

    +1

  6. SunHuilong commented on Aug 16, 2026

    @SunHuilong
    SunHuilong
    on Aug 16, 2026

    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:

    codex-cli 0.147.0

    Codex Desktop also completes public-key authentication:

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

    It then fails during remote_codex_lookup:

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

  7. saayeeem commented on Oct 5, 2026

    @saayeeem
    saayeeem
    on Oct 5, 2026 – with ChatGPT Codex Connector

    Additional Windows desktop log evidence from 2026-10-05 UTC:

    • The remote SSH connection authenticated successfully using public-key authentication.
    • Codex then recorded a connection failure with 'sh' is not recognized as an internal or external command and '[' is not recognized as an internal or external command.
    • The app recorded the remote connection entering state=error; this signature recurred in separate log sessions, including 19:35 UTC and 20:30–20:41 UTC.

    This is a further reproduction of the post-authentication bootstrap failure described here. The private host address and account identifiers are omitted; this evidence does not establish a different root cause.

  8. saayeeem commented on Oct 6, 2026

    @saayeeem
    saayeeem
    on Oct 6, 2026 – with ChatGPT Codex Connector

    Additional Windows desktop log evidence from 2026-10-06 UTC (2026-10-07 in Asia/Dhaka):

    • The remote SSH connection authenticated using public-key authentication to an OpenSSH_for_Windows 9.5p1 host.
    • Bootstrap then failed with 'sh' is not recognized as an internal or external command and '[' is not recognized as an internal or external command.
    • Codex recorded the remote connection in an error state repeatedly from 21:43:34 to 22:06:28 UTC.
    • The same app session identifies package 26.930.7945.0.

    This reproduces the post-authentication bootstrap failure in this report. Private host addresses and account identifiers are omitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingremotewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions