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

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.

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