Remote SSH Desktop reuses stale app-server and masks model_not_found as Reconnecting

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

• #19203
• #19225
• #18547
• #18503

Powered by Codex Action

i tried killing the processes that didn't help but points to problem, but what worked for me was (a bit overkill):

• uninstalled node + npm

• had 18,20, 22

• (was simultaneously resolving system node issues)

• reinstalled node 22

• npm-installed codex at v0.124.0

• was on 0.121.0 during 5.5 failures

then the desktop app picked it up and indicators went green finally.

This might be related.

In my case:

• GPT-5.5 works in CLI (local and remote)
• Works in Codex App for local projects
• Fails only in Codex App remote projects (not selectable or missing)

Environment:

• Codex App (Windows): 26.422.21637
• Codex CLI: 0.124.0

Seems consistent with stale remote app-server behavior.

Additional finding from the same setup: this also affects the Add remote project flow, not only the first-turn Reconnecting... symptom.

After the remote SSH host had working ssh, codex, bwrap, and an existing remote app-server, Codex Desktop still showed only the local macOS project picker when trying to add a project. In other words, the user could add local Mac projects, but could not get the remote-project picker/path flow for ubuntu-dev.

Two state/config details looked relevant:

[features]
remote_connections = true
remote_control = true

• When only remote_control = true was present, the Desktop add-project UI still behaved as local-only.
• Re-adding the older/hidden remote_connections = true appears necessary for the remote-project UI path, even though codex features list does not surface remote_connections and codex features enable remote_connections previously returned an unknown-feature error.

There was also stale Desktop global state:

{
  "selected-remote-host-id": "remote-ssh-discovered:<stale-host>",
  "remote-projects": [
    {
      "hostId": "remote-ssh-discovered:ubuntu-dev",
      "remotePath": "/media/<user>/DATA/code"
    },
    {
      "hostId": "remote-ssh-discovered:ubuntu-dev",
      "remotePath": "/media/<user>/DATA/Pixelle-Video"
    }
  ],
  "remote-connection-auto-connect-by-host-id": {
    "remote-ssh-discovered:ubuntu-dev": true
  }
}

Both remote project paths existed on the remote host. However, while Codex Desktop was running, manually patching selected-remote-host-id back to remote-ssh-discovered:ubuntu-dev was overwritten by the app process and reverted to the stale selected host.

So there may be another related bug here:

1. The remote-project add flow appears gated by remote_connections, while newer config/UI guidance points users toward remote_control.
2. Desktop can retain and rewrite a stale selected-remote-host-id, causing the add-project flow to stay local-only or point at the wrong discovered host even when valid remote-projects already exist for ubuntu-dev.
3. The CLI and Desktop feature flags do not seem to expose the same source of truth for remote SSH project support.

Expected behavior: if valid remote projects exist and auto-connect is enabled for a host, the Add Project UI should expose the remote project/path picker for that host, or show a clear diagnostic explaining which feature flag or host state is blocking it.

Additional data point from macOS Codex Desktop on 2026-04-24: a remote host can appear to log in as the wrong Linux user even when the SSH alias has already been updated and resolves correctly.

What I observed:

• the local SSH config had already been changed so the host alias used the intended Unix user
• ssh -G <alias> resolved to the intended user
• direct SSH also confirmed the shell session was running as the intended user
• Codex Desktop logs showed it was using the updated discovered host and alias, not an old hardcoded user@host target

However, on the remote machine there was still a stale Codex app-server owned by the previous Unix user listening on the fixed local websocket port:

LISTEN 127.0.0.1:9234
<old-user> ... codex app-server --listen ws://127.0.0.1:9234
<intended-user> ... codex app-server --analytics-default-enabled

This made Desktop behave as if the remote session was still the old user, because the SSH tunnel connected to the already-running stale app-server on 127.0.0.1:9234 instead of forcing a clean per-user app-server lifecycle.

What fixed it:

1. Kill the stale remote Codex app-server processes, especially the one owned by the old user.
2. Reconnect from Desktop so it starts a fresh app-server under the intended user.

After that, the wrong-user symptom disappeared.

So this looks like a broader variant of the stale remote app-server bug: the stale server can leak not only model/runtime state, but also the previous remote Unix-user context, which is much more confusing because it looks like SSH user selection is being ignored.

Another likely-related remote failure mode on macOS Desktop, observed on 2026-04-25:

The same remote host had multiple Codex binaries installed at the same time, for example:

• older remote binary: 0.122.0-alpha.13
• newer remote binary: 0.124.0-alpha.2

Symptoms:

• SSH itself was healthy
• the SSH local tunnel to the remote localhost websocket port came up successfully
• but Desktop kept failing the remote websocket handshake with read ECONNRESET

What made this confusing is that the remote host had previously worked with a newer remote app-server version, but later Desktop began attaching to an older remote binary/app-server again.

Evidence pattern:

• earlier logs showed the same remote host reporting a newer app-server version and connecting successfully
• later logs showed the same host reporting the older binary version instead
• manual verification showed the newer app-server could be started successfully and its readyz / healthz endpoints were reachable through SSH port forwarding
• isolating the older installed binary and leaving only the newer one available made the remote app-server behave normally again

So this looks like another bug in the same area:

1. when multiple remote Codex binaries/extension versions coexist, Desktop or the remote launcher may pick the wrong binary/app-server
2. the resulting failure can surface only as websocket read ECONNRESET, instead of a clear version-selection / version-mismatch diagnostic
3. this makes the problem look like a network reset even though the tunnel and the newer remote app-server are both fine

Expected behavior:

• Desktop should deterministically prefer the newest compatible remote binary/app-server
• or, if multiple remote versions are detected, emit an explicit diagnostic instead of falling through to ECONNRESET

One more concrete failure mode in the same stale remote app-server area:

Codex Desktop starts the remote app-server with a fixed /tmp log path:

nohup codex app-server --listen ws://127.0.0.1:9234 >/tmp/codex-app-server-ssh-ws-v0.log 2>&1 &

If that file was previously created by another remote Unix user, the current SSH user cannot write it, so shell redirection fails before codex app-server starts. Desktop then only reports websocket read ECONNRESET, which hides the real cause.

Suggested fixes:

• Use a per-user log/runtime path, e.g. /tmp/codex-$UID/..., $XDG_RUNTIME_DIR, or ~/.codex/log/....
• Capture and surface remote startup stderr, especially Permission denied, codex not found, Address already in use, and version mismatch.
• Add a visible "reset/forget remote app-server state" action in Desktop.
• Preflight codex PATH, log writability, port ownership, and app-server health before showing a generic reconnect error.