Skip to content

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

Open
Open
Desktop auto-connects discovered SSH hosts at startup and blocks local chat loading when a host is unavailable#35733
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)remote

Description

@genzorr
genzorr
opened on Jul 28, 2026

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

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    remote
    app-serverIssues involving app server protocol or interfaces
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Jul 28, 2026

  2. github-actions commented on Jul 28, 2026

    @github-actions
    github-actionsBot
    on Jul 28, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. genzorr commented on Jul 28, 2026

    @genzorr
    genzorr
    on Jul 28, 2026 – with ChatGPT Codex Connector
    Author

    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:

    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.

  4. GentaHashimoto commented on Aug 15, 2026

    @GentaHashimoto
    GentaHashimoto
    on Aug 15, 2026 – with ChatGPT Codex Connector

    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.

  5. Dylan997S commented on Aug 17, 2026

    @Dylan997S
    Dylan997S
    on Aug 17, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)remote

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions