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

[hans43564334-pixel]

What happened?

When using Codex Desktop with a remote SSH project, the UI got stuck showing reconnect retries after the first message:

Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5

From the UI, this looks like a transport/WebSocket problem. However, the remote Codex logs showed the real error was a model/catalog/access error:

stream disconnected - retrying sampling request (1/5 ... 5/5)
Turn error: stream disconnected before completion: The model `gpt-5.5` does not exist or you do not have access to it.

The app-server WebSocket event also contained:

{"type":"error","error":{"type":"invalid_request_error","code":"model_not_found","message":"The model `gpt-5.5` does not exist or you do not have access to it."}}

The confusing part: running the remote CLI directly with the same model worked:

codex exec -C <remote-project> --skip-git-repo-check -m gpt-5.5 -s read-only 'reply OK'

Result:

OpenAI Codex v0.124.0
model: gpt-5.5
...
OK

While debugging, I found an old remote app-server process still listening on the remote host:

codex app-server --listen ws://127.0.0.1:9234  # started Apr 21

After killing the old app-server process, Codex Desktop spawned a fresh remote app-server:

codex app-server --listen ws://127.0.0.1:9234  # started Apr 24

This suggests the Desktop remote-SSH path may be reusing a stale remote app-server whose runtime/model catalog/auth state no longer matches the current CLI/Desktop configuration. It also suggests model_not_found is being presented to the user as generic Reconnecting..., which makes the root cause hard to diagnose.

Environment

• Codex Desktop client: 26.422.21637 from logs
• Remote host: Ubuntu 24.04.3 LTS
• Remote Codex CLI: codex-cli 0.124.0
• Auth mode: ChatGPT login
• Remote connection type: Codex Desktop remote SSH project
• Model configured/used: gpt-5.5
• Remote sandbox note: Ubuntu AppArmor/bubblewrap issue was already fixed; bwrap --ro-bind / / true succeeds and codex app-server </dev/null exits successfully.

Expected behavior

1. If an existing remote app-server is stale, Codex Desktop should detect that during handshake and restart it or refuse it with a clear diagnostic.
2. If the backend returns model_not_found, the Desktop UI should show a model/catalog/access error instead of Reconnecting....
3. The remote app-server handshake should probably include enough version/model-catalog/auth metadata for Desktop to know whether it can safely reuse the process.

Actual behavior

• Desktop UI only showed reconnect attempts.
• Remote logs showed model_not_found.
• Direct remote CLI with gpt-5.5 succeeded.
• A stale codex app-server --listen ws://127.0.0.1:9234 process was still running and appeared to be reused until it was manually killed.

Possibly related

• Desktop: first turn sometimes shows "Reconnecting... 2/5" even though app-server transport remains connected #18471: Desktop first turn shows Reconnecting
• Codex App restores stale discovered SSH host state on startup and crashes with "No AppServerManager registered for hostId" #18556: stale discovered SSH host state
• Linux sandbox fails on Ubuntu with AppArmor userns restrictions: bwrap loopback RTM_NEWADDR EPERM #15057: Ubuntu/AppArmor sandbox diagnostics for bubblewrap/user namespaces
• Bump phase-two default model to gpt-5.5 #19224: model catalog / gpt-5.5 default-model discussion

Suggested fix direction

• Add remote app-server preflight/handshake checks: server version, start time or generation, auth mode, and model catalog compatibility.
• Restart or invalidate an existing remote app-server when the current Desktop/CLI configuration no longer matches.
• Map backend model_not_found to a clear UI message instead of retrying as if it were only a connection problem.
• Optionally add a diagnostic command or log line for the exact remote app-server PID Desktop connected to.

[github-actions]

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

• remote connection displays gpt5.5 as custom model #19203
• VS Code Remote-SSH: Codex panel intermittently hangs before prompt submission; bundled CLI works; logs show Error: not-connected at Va.sendBroadcast #19225
• Mac Codex App remote SSH on shared Linux host attaches to another user's session / home directory #18547
• Windows Codex App remote connections fail when the remote machine's 127.0.0.1:9234 is already in use #18503

Powered by Codex Action

[justinTM]

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.

[dilsonlira]

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.

[hans43564334-pixel]

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.

[jayjunjieqiu]

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.

[jayjunjieqiu]

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

[jayjunjieqiu]

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.