›_ Codex Issues
Codex Issues / #33879

SSH remote connection fails with "socket hang up" on Cloudways despite successful SSH and working codex-cli

Open 💬 6 comments Opened Jul 17, 2026 by orgworx

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

Version 26.707.51957

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

When attempting to connect to a remote server using the ChatGPT Desktop app's SSH connection feature, the connection consistently fails with:

socket hang up

The remote server is accessible over SSH, and the Codex CLI is installed and executable.

The issue appears to occur during the desktop app's remote connection/bootstrap process rather than during SSH authentication itself.

No additional diagnostic information is shown in the application, making it difficult to determine the underlying cause.

What steps can reproduce the bug?

  1. Install the latest Codex CLI on a remote Cloudways server.
  1. Verify that SSH key authentication works.
  1. Verify that the Codex CLI is installed:
/home/master/codex --version

This returns:

codex-cli 0.144.5
  1. In ChatGPT Desktop, go to:

Settings → Connections → SSH

  1. Create a new SSH connection using:
  • Hostname: user@host
  • Identity file: ~/.ssh/id_ed25519
  1. Save the connection and attempt to connect.
  1. The connection immediately fails with:
socket hang up

Additional observations:

  • Interactive SSH sessions work normally.
  • Running /home/master/codex --version over SSH succeeds.
  • Running codex --version over SSH fails because the remote environment does not expose the Codex executable on PATH during non-interactive SSH sessions.

What is the expected behavior?

The desktop app should establish a remote Codex session successfully when the remote Codex CLI is installed and executable.

If the connection cannot be established because the executable cannot be located, the app should report the underlying bootstrap or SSH error rather than only displaying:

socket hang up

Ideally the app would also:

  • allow specifying the full path to the remote codex executable,
  • search common installation locations when codex is not found on PATH, or
  • include the failed remote command and exit status in the error message to simplify troubleshooting.

Additional information

We spent approximately an hour isolating this issue before opening this report.

The following were verified during troubleshooting:

  • SSH key authentication works.
  • Interactive SSH sessions work normally.
  • Non-interactive SSH sessions work normally.
  • The remote Codex CLI is installed correctly.
  • /home/master/codex --version succeeds locally and over SSH.
  • codex --version fails only because the remote environment does not expose the Codex executable on PATH for non-interactive SSH commands.
  • The desktop app consistently reports only socket hang up with no additional diagnostic information.

We intentionally avoided making further changes to the server once it became clear the issue was likely occurring during the desktop app's remote bootstrap process.

If additional logging or a debug build would help, I'd be happy to test it and provide results.

View original on GitHub ↗

6 Comments

Wyatthy · 1 month ago

+1

mmiladinov · 1 month ago

+1

putixiaosheng · 1 month ago

+1

csrqli · 25 days ago

+1

lihas · 23 days ago

+1

tradew1nd · 21 days ago

Thanks to this issue, I found the Codex Desktop application logs and identified a possible cause of the socket hang up error in my environment.

The logs showed that SSH authentication completed successfully. The failure occurred while Codex Desktop was bootstrapping the remote Codex CLI. Specifically, it invoked:

/home/<user>/.local/bin/codex

That executable was an older, incomplete installation and failed with:

Error: Missing optional dependency @openai/codex-linux-x64
Reinstall Codex: npm install -g @openai/codex@latest

A complete Codex installation also existed under the Node version manager directory, but /home/<user>/.local/bin/codex appeared earlier on PATH, so Codex Desktop always selected the broken executable. The remote Codex process exited immediately, and the desktop app reported the resulting WebSocket disconnect only as:

socket hang up

The issue was resolved by reinstalling Codex in the active Node/npm environment and replacing the stale executable:

export PATH="$HOME/.nvm/versions/node/<node-version>/bin:$PATH"
npm install -g @openai/codex@latest

type -a codex
codex --version

I then removed or replaced the old ~/.local/bin/codex entry so that it pointed to the complete installation.
After that, the logs showed:

Codex CLI initialized
state=connected