›_ Codex Issues
Codex Issues / #32524

Windows Desktop SSH project composer routes turns to local host and loses remote conversation mapping

Open 💬 0 comments Opened Jul 12, 2026 by pingy47-eng

What version of the Codex App are you using (From “About Codex” dialog)?

Codex/ChatGPT Windows Desktop 26.707.3748.0

Bundled local CLI reported by Desktop: 0.144.0-alpha.4

Remote CLI/app-server: 0.144.1

What subscription do you have?

Pro

What platform is your computer?

Windows Desktop connecting through Windows OpenSSH to a Linux x86_64 remote host.

What issue are you seeing?

A saved SSH project is discovered correctly and shown as online. The composer displays the remote project and remote host, but submitting a message can route the turn to the local app-server instead of the selected SSH app-server.

This is not an SSH reachability, remote PATH, authentication, or remote CLI problem:

  • Non-interactive SSH resolves codex successfully.
  • codex --version returns codex-cli 0.144.1.
  • codex app-server --help succeeds.
  • The managed remote daemon reports both CLI and app-server version 0.144.1.
  • A remote thread created through the Desktop thread API runs in the remote project and completes in about 3.8 seconds.
  • Remote CPU, memory, disk capacity, and I/O wait are healthy.

However, when sending from the normal Desktop composer, the log records:

codex-home request hostId=local

The resulting session is persisted under the local Codex home with the local Windows cwd, while no corresponding thread is created on the selected remote host.

When a remote test thread is created through the thread API, the remote rollout contains the expected response:

SSH remote chat is working.
task_complete ... duration_ms=3840

but Desktop then loses the mapping and logs:

Received turn/completed for unknown conversation

The conversation ID in that completion event differs from the thread ID Desktop is displaying/tracking. Subsequent reads can hang for roughly 60 seconds, then the Desktop terminates the SSH proxy and reports:

app_server_connection.closed code=1006
ssh_websocket_v0.proxy_command_failed ... signal=SIGTERM
Codex app-server is not available

The UI remains stuck on “Loading” / “Unable to send message,” even though the SSH indicator is green.

An earlier prewarm attempt also returned:

deferred dynamic tool must include a namespace: fork_thread

After restarting the remote daemon this changed into a thread/start timeout, but the local-vs-remote routing mismatch remained.

What steps can reproduce the bug?

  1. On Windows Desktop, add an SSH connection to a Linux host.
  2. Install Codex CLI on the remote and ensure it is available to non-interactive SSH commands.
  3. Save a remote project, for example /home/user/workspace.
  4. Confirm the remote host has a green/online indicator.
  5. Open the saved remote project and start a new chat.
  6. Confirm the composer header displays the remote project and SSH host.
  7. Send a short prompt such as hi.
  8. Observe “Loading” or “Unable to send message.”
  9. Inspect Desktop logs:
  • the submit path may use hostId=local;
  • remote completion events may be reported as an unknown conversation;
  • the SSH app-server proxy may later be terminated with WebSocket code 1006.

A second reproduction path:

  1. Create a thread explicitly against the saved remote project through the Desktop thread API.
  2. Verify the remote rollout completes successfully.
  3. Open/read the created thread in Desktop.
  4. Observe conversation mapping loss and eventual Codex app-server is not available.

What is the expected behavior?

When the composer shows an SSH project/host:

  • thread/start and turn/start must be routed to that host's app-server.
  • The thread must be persisted under the remote Codex home and remote cwd.
  • Desktop must retain the authoritative remote thread/conversation ID.
  • A remote turn/completed event must attach to the displayed thread.
  • The app should not silently fall back to the local app-server.
  • A healthy remote app-server connection should not be terminated merely because the renderer lost conversation mapping.

Additional information

The problem was reproduced after:

  • fixing the remote non-interactive PATH;
  • validating the remote CLI and app-server commands;
  • replacing an old unmanaged daemon with a current managed daemon;
  • fully restarting Desktop;
  • creating a fresh remote chat;
  • verifying the SSH host key;
  • confirming the remote host was not resource-constrained.

This appears to be a Windows Desktop remote-host routing / renderer-thread reconciliation bug rather than a remote CLI failure.

Possibly related, but not exact duplicates:

  • #23919 — Windows Desktop remote SSH sessions freeze during app-server reconnect/list/resume
  • #21167 — reconnect loop caused by turn events for an unknown conversation

I can provide sanitized Desktop logs and the matching remote rollout if maintainers need them.

View original on GitHub ↗