SSH Connect Timeout Configurable

Open 💬 3 comments Opened Apr 21, 2026 by jdcaperon

What variant of Codex are you using?

App

What feature would you like to see?

Codex Desktop currently seems to use a fixed SSH ConnectTimeout for remote connections. In my setup, the effective timeout is too short and causes connection failures for hosts that do eventually connect successfully.

This shows up most often when the SSH path includes things like:

  • ProxyCommand
  • ProxyJump
  • bastions
  • VPN startup
  • remote brokers such as coder ssh
  • waking a remote workspace before it becomes reachable

A fixed timeout around 10 seconds is too aggressive for these cases. Regular SSH often succeeds if given 15-30 seconds.

Requested change

Please make the SSH connect timeout configurable in Codex Desktop.

Ideally:

  • expose it as a user setting
  • support a global default, and optionally per-host overrides
  • respect ~/.ssh/config where possible, or provide a Codex-specific override if Codex must pass explicit SSH flags

Example

A timeout of 30s would already be much more practical than the current fixed behavior in environments where the first connection can legitimately take longer.

Additional information

_No response_

View original on GitHub ↗

3 Comments

jdcaperon · 4 months ago

I dug into the current repo state and found that the timeout behavior appears to be fixed in code today, with two different values depending on the path:

  • codex-rs/exec-server/src/client.rs defines CONNECT_TIMEOUT and INITIALIZE_TIMEOUT as 10s, and RemoteExecServerConnectArgs::new(...) uses those defaults.
  • codex-rs/exec-server/src/environment.rs does not use that helper. It constructs RemoteExecServerConnectArgs directly and hard-codes both connect_timeout and initialize_timeout to 5s.

Relevant references:

  • codex-rs/exec-server/src/client.rs
  • codex-rs/exec-server/src/environment.rs

If the Desktop remote connection flow goes through Environment::create(...), then the effective timeout is currently 5s, not 10s.

jdcaperon · 3 months ago

@etraut-openai would it be possible to patch this quickly by bumping the timeout to something like 30-60 seconds?