codex - 💡(How to fix) Fix Codex App Remote SSH is slow and fragile behind NLB compared with VS Code Remote SSH [1 comments, 2 participants]

What happened

Codex App remote SSH connections are noticeably slower and more fragile than VS Code Remote SSH when connecting to a Linux development machine through an SSH-accessible network load balancer / gateway.

In the same environment, VS Code Remote SSH usually reconnects quickly because it reuses its remote server. Codex App remote connections often spend much longer in setup/reconnect, and failures are surfaced as generic connection errors even when the underlying SSH host is otherwise reachable.

Environment

• Codex App: macOS app com.openai.codex, version 26.422.71525
• Local OS: macOS 26.4.1
• Local OpenSSH: OpenSSH_10.2p1, LibreSSL 3.3.6
• Remote OS: Ubuntu 22.04.5 LTS
• Remote Codex CLI: codex-cli 0.125.0
• Remote access: SSH host alias in ~/.ssh/config, using a concrete host alias and a non-standard SSH port behind a network load balancer / gateway
• Remote host is reachable by normal ssh <alias> when the gateway is healthy

Symptoms observed

1. Normal SSH can succeed quickly:

ssh <alias> 'whoami && hostname && pwd'
# root
# <remote-hostname>
# /root

1. Remote Codex is installed and authenticated:

ssh <alias> 'command -v codex && codex --version && codex login status'
# /usr/local/bin/codex
# codex-cli 0.125.0
# Logged in using ChatGPT

1. Codex App remote connection can still be slow or fail while VS Code Remote SSH feels much faster in the same setup.

2. During failures, SSH sometimes fails before authentication with messages like:

kex_exchange_identification: read: Connection reset by peer
Connection reset by <gateway-ip> port <ssh-port>

or:

kex_exchange_identification: banner line 0: Not allowed at this time
Connection reset by <gateway-ip> port <ssh-port>

The gateway and machine can recover shortly afterward, but repeated Codex App reconnect attempts appear to make the experience worse.

1. Separately, we also observed stale remote app-server state / fixed-port conflicts on the remote host:

Error: Address in use (os error 98)

with a remote process listening on:

127.0.0.1:9234

This appears related to the existing reports about the fixed remote app-server port and stale app-server/session behavior.

Expected behavior

Codex App remote SSH should feel closer to VS Code Remote SSH in reconnect behavior, or at least provide clearer diagnostics that distinguish:

• SSH gateway / NLB reset before authentication
• remote codex missing from PATH
• remote authentication missing
• stale codex app-server process
• fixed port 127.0.0.1:9234 already in use
• reconnecting to a stale/incorrect remote app-server

Ideally the app would reuse or clean up its remote app-server more robustly, avoid fixed-port collisions where possible, and show the exact failing layer instead of a generic connection failure.

Related issues

These look related but do not fully cover the observed performance/diagnostic angle behind an SSH gateway/NLB:

• #18503
• #18547
• #19300
• #10450

Notes

The SSH config uses a concrete host alias, not a Host * pattern, consistent with the remote connections docs. remote_connections = true is enabled in ~/.codex/config.toml.