Codex Desktop Remote SSH to Linux fails after successful SSH/version probes: bootstrap cannot find mkdir, then websocket closes with code=1006

Open 💬 0 comments Opened Jun 6, 2026 by KoukiHama

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

26.527.3686.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows x64

What issue are you seeing?

Codex Desktop Remote SSH fails when connecting from a Windows client to a Linux SSH remote.

The SSH host is discovered correctly, SSH public-key authentication works, and Codex Desktop can run the remote codex --version probe successfully. However, the connection fails during the remote app-server bootstrap/proxy phase.

The UI only reports:

Codex app-server websocket closed (code=1006)

The desktop log shows a more actionable error before the websocket failure:

/bin/sh: 1: mkdir: not found

The failure is followed by:

[AppServerConnection] Transport start success
[AppServerConnection] app_server_connection.websocket_error message="socket hang up"
[AppServerConnection] app_server_connection.closed code=1006
[AppServerConnection] app_server_connection.connection_failed_before_ready errorMessage="Codex app-server websocket closed (code=1006)"

This does not appear to be an SSH authentication, Codex CLI installation, or Codex login problem. The failure appears to occur after successful SSH/version probes, during the automated remote app-server bootstrap/proxy path.

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows x64.
  1. Configure an SSH host in ~/.ssh/config that points to a Linux remote host using public-key authentication.
  1. Verify outside Codex Desktop that SSH and the remote Codex CLI work:
ssh <ssh-alias> "echo SSH_OK; whoami; hostname; command -v codex; codex --version; test -f ~/.codex/auth.json && echo AUTH_JSON_EXISTS || echo NO_AUTH_JSON"

Sanitized result:

SSH_OK
<remote-user>
<remote-host>
/usr/local/bin/codex
codex-cli 0.137.0
AUTH_JSON_EXISTS
  1. Also verify that manually starting the app-server works:
codex app-server --listen ws://127.0.0.1:4500

A /readyz probe returns:

HTTP/1.1 200 OK
  1. In Codex Desktop, open Settings -> Connections -> SSH.
  1. Add or select the discovered SSH host.
  1. Enable the SSH connection.
  1. Codex Desktop reports:
Codex app-server websocket closed (code=1006)

The desktop log shows that SSH authentication and the remote codex --version probe succeed, but the later app-server bootstrap/proxy phase fails:

[AppServerTransportSshWebsocket] ssh_websocket_v0.remote_login_shell_command_completed code=0 operation=codex_version_probe stdout="codex-cli 0.137.0\n"

/bin/sh: 1: mkdir: not found

[AppServerConnection] Transport start success
[AppServerConnection] app_server_connection.websocket_error message="socket hang up"
[AppServerConnection] app_server_connection.closed code=1006
[AppServerConnection] app_server_connection.connection_failed_before_ready errorMessage="Codex app-server websocket closed (code=1006)"

Session id, token limit usage, and context window usage are not applicable. This fails during Remote SSH connection setup, before opening a coding session.

What is the expected behavior?

After SSH authentication and the remote codex --version probe succeed, Codex Desktop should complete the Remote SSH connection by bootstrapping the remote app-server successfully.

At minimum, if the remote app-server bootstrap fails, the UI should expose the actionable bootstrap error, such as:

/bin/sh: 1: mkdir: not found

instead of only showing:

Codex app-server websocket closed (code=1006)

Additional information

This looks related to, but not exactly the same as:

  • #20636: Remote SSH app-server bootstrap fails and manual codex app-server --listen unix:// works around the issue.
  • #20617: Remote SSH bootstrap command fails, but the UI only surfaces the generic websocket code=1006 error.
  • #19744: SSH/version probes can pass, while app-server launch fails later because the non-interactive SSH environment differs from the expected shell environment.
  • #22965 and #24090: Remote app-server/proxy failures where SSH and codex --version work, but Desktop Remote SSH still fails with socket hang up / code=1006.

Environment, sanitized:

Local client:
OS: Windows x64
Codex Desktop: 26.527.3686.0
OpenSSH client: OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2
Connection type: Codex Desktop -> Settings -> Connections -> SSH
SSH host entry: configured through ~/.ssh/config
Authentication: public key

Remote host:
OS: Ubuntu 24.04.x LTS
OpenSSH server: OpenSSH_9.6p1 Ubuntu
Remote codex path: /usr/local/bin/codex
Remote codex version: codex-cli 0.137.0
Remote auth state: ~/.codex/auth.json exists

Workaround:

Starting the Unix-socket app-server manually on the remote host makes Codex Desktop show the SSH connection as healthy:

mkdir -p "$HOME/.codex/app-server-control"
chmod 700 "$HOME/.codex/app-server-control"

nohup codex app-server --listen unix:// \
  > "$HOME/.codex/app-server-control/app-server.log" \
  2>&1 < /dev/null &

After this, the remote app-server process is visible:

pgrep -af '[c]odex app-server'

Then Codex Desktop can connect.

This suggests that the remote Codex CLI, authentication state, app-server binary, and socket path are valid, while the Desktop automated bootstrap/proxy sequence fails in this environment.

Usernames, host aliases, local Windows account names, remote hostnames, concrete home-directory paths, private-key names, and host key fingerprints have been intentionally redacted.

View original on GitHub ↗