›_ Codex Issues
Codex Issues / #35733

Desktop auto-connects discovered SSH hosts at startup and blocks local chat loading when a host is unavailable

Open 💬 4 comments Opened Jul 28, 2026 by genzorr
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

Codex Desktop eagerly auto-connects every saved/discovered SSH host during application startup, even when I only want to open local conversations. If a discovered host is unavailable or its remote app-server is slow to bootstrap, local chat loading becomes blank/unresponsive.

The startup log shows this sequence:

load_completed savedRemoteConnectionCount=2 totalConnectionCount=2
refresh_completed autoConnectConnectionCount=2 discoveredConnectionCount=2
Starting app-server connection hostId=remote-ssh-discovered:<unreachable-host> transport=websocket
Starting app-server connection hostId=remote-ssh-discovered:<slow-host> transport=websocket

One host cannot resolve and retries indefinitely:

ssh: Could not resolve hostname <unreachable-host>
remoteConnectionMaxRetryAttempts=null
app_server_connection.reconnect_scheduled ... nextDelayMs=20000

The other host's app-server bootstrap initially times out after 60 seconds. While it is connecting, chat/sidebar requests fail and the five-slot request queue fills:

Request failed ... method=thread/list source=recent_threads
error="SSH: app-server bootstrap timed out after 60000ms"
durationMs=60948

app_server_client_request_queue_rejected
inFlightRequestCount=5
queueWaitMs=30000
reason=queue-expired
method=config/read

The same queue rejection then affects permissionProfile/list, app/list, skills/list, and plugin/list. When the slow remote eventually connects, Desktop attempts to recover the currently selected local conversation against that remote host:

websocket_reconnect_recovery_start ... hostId=remote-ssh-discovered:<slow-host>
websocket_reconnect_recovery_done
currentConversationExistsOnTargetHost=false
resumedCurrentConversation=false

At that point, local chats remain blank or fail to hydrate.

This does not appear to be local session-database latency. In the same run, local thread/list and thread/read requests completed in approximately 0–149 ms, and codex doctor reported healthy state databases and network/auth checks.

Steps to reproduce

  1. Configure or discover two SSH aliases in Codex Desktop.
  2. Make one alias unreachable through DNS and make the other slow to start its remote Codex app-server.
  3. Previously open or save these remote connections so Desktop remembers them.
  4. Fully quit and reopen Desktop.
  5. Do not intentionally select a remote workspace; try to open an existing local conversation.
  6. Observe that Desktop automatically starts both SSH connections and the local conversation view remains blank or fails to load.

Expected behavior

  • Opening Desktop for local work should not connect to every discovered SSH host.
  • SSH connections should start lazily when the user selects that remote, or run in isolation without blocking local chat hydration.
  • Request queues should be host-scoped so a remote bootstrap cannot exhaust capacity needed by the local app-server.
  • Failed SSH hosts should have bounded retries or a visible pause/disconnect control.
  • Desktop should not attempt to resume a local conversation against a remote host where that conversation does not exist.

Actual behavior

Desktop auto-connects both discovered hosts, an unavailable host retries indefinitely, queued requests expire, and local chats do not load.

Workaround

Disconnect/disable the saved SSH connections, switch the active host to Local/This Mac, fully quit with Cmd-Q, and reopen the app.

Environment

  • App: ChatGPT Desktop / Codex view 26.721.41059 (build 5848)
  • Bundled Codex app-server: 0.146.0-alpha.3.1
  • Remote app-server observed after eventual connection: 0.144.5
  • OS: macOS 26.5.2 (25F84), arm64

Related issues

  • #19608 — blank/unhydrated conversation with app-server queue pressure in Remote SSH
  • #20128 — repeated Codex Desktop SSH reconnect attempts worsen reliability
  • #22438 — persisted remote sessions missing after reconnect/restart

The important difference here is that the remote connection failure also prevents otherwise healthy local conversations from loading immediately after application startup.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35096

Powered by Codex Action

genzorr · 1 month ago

Thanks for the duplicate suggestion. I reviewed #35096 and its related report #33524. There may be subsystem overlap, but #35733 has a distinct reproduction and observable failure mode:

  • #35096: Windows; SSH connects successfully, then the renderer enters a CPU-heavy freeze while restoring remote threads. The reporter explicitly requires auto-connect.
  • #33524: Windows; local thread/resume and renderer/ResizeObserver stalls occur when switching or submitting in existing conversations. SSH failure is not required.
  • #35733: macOS; simply launching Desktop with discovered SSH aliases—one unresolvable and one exceeding the 60-second remote app-server bootstrap timeout—prevents otherwise healthy local chats from loading. The window remains open, but remote connection work fills the five request slots. thread/list fails first with DNS/bootstrap errors; queued config/read, app/list, plugin/list, and skills/list requests then expire after 30 seconds. When the slow remote eventually connects, Desktop attempts recovery of the selected local conversation on that remote and reports currentConversationExistsOnTargetHost=false. In the same run, local thread/list/thread/read completed in 0–149 ms.

The specific bug isolated here is therefore host routing and failure isolation: an unavailable auto-discovered remote can starve startup requests and block local conversation hydration. Local work should remain usable regardless of remote SSH state, and local conversations should not be recovered against a remote host where they do not exist.

Disabling the remembered remote connections is a workaround, but it should not be required merely to open local chats. I suggest keeping #35733 separate unless maintainers confirm that #35096 and this macOS queue/routing path share the same root cause and fix.

GentaHashimoto · 13 days ago

Confirming the same underlying failure mode on Windows, with a remote Codex bootstrap failure rather than an unreachable host.

Environment

  • Windows 11 Pro 10.0.26200
  • Codex Desktop 26.810.4967.0
  • Five concrete SSH aliases auto-discovered from ~/.ssh/config
  • No remote project selected during the measurement

All five hosts are valid SSH targets used for ordinary infrastructure administration, but they intentionally do not have the Codex CLI installed. Desktop repeatedly transitions each connection between connecting and error with remote-codex-not-found.

Observed impact

Over 85.4 minutes:

  • 25,080 remote-codex-not-found events
  • Approximately 4.89 events per second
  • 34.8 MB of rotated Desktop logs
  • Desktop main process averaged 138% of one CPU core
  • One renderer averaged 48% of one CPU core
  • Total Desktop load was approximately 1.9 CPU cores
  • GPU utilization was approximately 1%
  • DPC and interrupt load were effectively 0%
  • Approximately 39.8 GB RAM remained free

Context7/MCP child processes were not present, ruling out a previously observed MCP-process accumulation case.

Disabling or removing normal SSH configuration is not an acceptable workaround. These aliases are needed for regular SSH administration and should not require a remote Codex installation.

Expected behavior

  1. Do not eagerly connect to every discovered SSH alias unless the user explicitly enables or selects it.
  2. Apply bounded retries with exponential backoff after remote-codex-not-found.
  3. Isolate failed remote connections from the local Desktop UI and renderer.
  4. Rate-limit repetitive connection-state logging.
  5. Provide a per-host pause/disable control without requiring changes to ~/.ssh/config.

Disclosure: This comment was drafted with assistance from Codex, which collected and summarized local process and application-log measurements under my direction. The observations and measurements come from my Windows machine. I can rerun the measurements and provide sanitized log excerpts if needed, but I may not be able to answer questions about Codex's internal implementation.

Dylan997S · 11 days ago

Additional macOS 26.810 data point: unrelated SSH failures and host selection mismatch still affect the renderer

I reproduced this on a newer macOS Desktop build and observed the same lack of host isolation.

Environment
  • ChatGPT/Codex Desktop: 26.810.52044 (build 6662)
  • Bundled Codex: 0.148.0-alpha.9
  • macOS 26.5 (25F71), Apple Silicon
  • ~/.ssh/config: 21 concrete aliases discovered by Desktop

Several aliases were valid for normal administration but were offline, unresolvable, or did not have Codex installed. Desktop repeatedly attempted them while restoring remote state. Logs showed reconnect attempts reaching at least 14 with unbounded retry configuration, followed by errors such as:

Thread catalog sync failed
Missing AppServer request message handler
No AppServerRequestClient registered for hostId: remote-ssh-discovered:<host>
Connection for host ID remote-ssh-discovered:<host> not found

During one startup, selected-project pointed at a Remote Control project while selected-remote-host-id still pointed at an unrelated SSH alias that lacked Codex. During another reproduction, an SSH project was selected while the persisted selected host remained the previous Remote Control host. The visible local/remote UI then became blank or permanently loading.

Direct checks showed that the intended SSH targets and their login-shell codex commands were healthy. A stuck primary renderer consumed about 46-48% CPU for several minutes. Switching the persisted startup target back to a local project, removing a duplicate same-path remote project, and bounding the active project set restored the UI.

This confirms the issue remains present in 26.810.52044 and adds a host-selection consistency failure:

  • discovery should not imply eager app-server connection;
  • retries must be bounded and isolated per host;
  • local renderer hydration must not depend on unrelated SSH connection state;
  • selected-project and selected-remote-host-id must be reconciled atomically before requests are dispatched;
  • a missing per-host request client must fail locally with a visible recoverable state, not an unhandled rejection.

Disclosure: this report was drafted with Codex assistance from sanitized Desktop logs and process measurements. Hostnames, credentials, transcript content, and private paths are omitted.