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
- Normal SSH can succeed quickly:
ssh <alias> 'whoami && hostname && pwd'
# root
# <remote-hostname>
# /root
- 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
-
Codex App remote connection can still be slow or fail while VS Code Remote SSH feels much faster in the same setup.
-
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.
- 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:
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:
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.
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
com.openai.codex, version26.422.71525codex-cli 0.125.0~/.ssh/config, using a concrete host alias and a non-standard SSH port behind a network load balancer / gatewayssh <alias>when the gateway is healthySymptoms observed
Codex App remote connection can still be slow or fail while VS Code Remote SSH feels much faster in the same setup.
During failures, SSH sometimes fails before authentication with messages like:
or:
The gateway and machine can recover shortly afterward, but repeated Codex App reconnect attempts appear to make the experience worse.
with a remote process listening on:
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:
codexmissing from PATHcodex app-serverprocess127.0.0.1:9234already in useIdeally 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:
Notes
The SSH config uses a concrete host alias, not a
Host *pattern, consistent with the remote connections docs.remote_connections = trueis enabled in~/.codex/config.toml.