Desktop: chat disappears after restart when one host is connected through both SSH and Remote Control

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

26.810.52044 (build 6662)

The bundled local app-server/CLI was 0.148.0-alpha.9 when I collected the diagnostics below.

What subscription do you have?

Pro

What platform is your computer?

Local Mac:

Darwin 25.5.0 arm64 arm

Remote machine:

Ubuntu 24.04
Linux 7.0.0-28-generic x86_64

The SSH app-server on the remote machine reported 0.144.1 during the incident. It reported 0.147.0 after Codex Desktop restarted and updated the managed copy.

What issue are you seeing?

I use Codex Desktop on my Mac as the UI for a project stored on a Linux machine. I had added that Linux machine to Codex in two ways:

• as an SSH project;
• through Remote Control under Control other devices.

Both entries referred to the same physical machine and the same remote CODEX_HOME.

I created a chat while working in the SSH project. The next day I upgraded/restarted Codex on the Linux machine. When I reopened Codex Desktop on the Mac, the SSH project was still in the sidebar, but the chat was gone.

The chat had not actually been deleted. Its rollout file was still on the Linux machine. The file was about 1.15 MB, contained 342 valid JSONL records, and had no JSON parse errors. I could also read the complete chat directly from the remote app-server with thread/read and thread/turns/list.

While investigating, I found the same thread ID twice in Codex Desktop's local thread catalog:

host_id                                      thread_id          cwd
remote-ssh-codex-managed:<ssh-alias>         <same-thread-id>   /home/<user>/Repo/<project>
remote-control:<redacted-environment-id>     <same-thread-id>   /home/<user>/Repo/<project>

The two rows had the same title, timestamps, working directory, and source. The two copies also showed no project association (projectId: null) when listed through the Desktop task API.

The Desktop log shows both connections starting during the same launch:

Starting app-server connection hostId=remote-ssh-codex-managed:<ssh-alias> transport=websocket
Starting app-server connection hostId=remote-control:<redacted-environment-id> transport=websocket

It also contains this error while the SSH connection was starting:

Failed to load config requirements errorMessage="No AppServerRequestClient registered for hostId: remote-ssh-codex-managed:<ssh-alias>"

After I removed the duplicate Remote Control catalog data and restarted the app, the chat title came back. At first, opening it still showed a blank page even though the app-server could return the full chat. The content appeared only after the thread was explicitly opened/read using the SSH host identity.

What steps can reproduce the bug?

These are the steps that led to the problem on my machines. I have not repeated them with a clean profile because I do not want to risk my existing remote chat history.

1. Add a Linux machine to Codex Desktop through Connections > Control other devices.
2. Add the same machine as an SSH project.
3. Open a project through the SSH entry and create a chat.
4. Confirm that the rollout is stored under ~/.codex/sessions/ on the Linux machine.
5. Leave both connection methods configured for the same machine.
6. Upgrade or restart Codex on the Linux machine, then quit and reopen Codex Desktop on the Mac.
7. Open the saved SSH project.

In my case, the existing chat was no longer shown. During recovery, the title later appeared with an empty conversation body even though direct app-server reads still returned the messages.

I have redacted the affected thread ID from this public report, but I can provide it privately if it would help with diagnosis.

What is the expected behavior?

Restarting or upgrading either side should not make a persisted remote chat disappear or open as an empty conversation.

If SSH and Remote Control can be used with the same machine and CODEX_HOME, Codex Desktop should keep the host and project association when it lists and opens a thread. If that setup is not supported, the app should warn the user instead of adding the same thread under two host identities.

Additional information

My best guess is that the upgrade/restart exposed an existing identity conflict rather than causing data loss. The Desktop catalog uses (host_id, thread_id) as its key, so the same thread ID can exist once under the SSH host and once under the Remote Control host. Some later lookup or UI path appears to expect one result or to lose track of which host was selected.

I also found an old standalone app-server process on the Linux machine. It may have made the restart behavior worse, but I do not think it explains why the Desktop catalog had the same thread under two host identities.

The workaround I used was:

1. Back up the local and remote Codex databases and the affected rollout.
2. Disable Remote Control auto-connect for the Linux machine.
3. Stop the Linux Desktop/Remote Control process and the stale standalone app-server.
4. Remove the Remote Control copy of the thread catalog/sync data while keeping the SSH copy.
5. Restart Codex Desktop and reconnect through SSH.
6. Open the thread using the SSH host identity.

After this, the catalog contained only the SSH mapping for the thread and the complete conversation loaded again.

Related issues:

• #33750 - Allow SSH and Remote Control clients to share the same app-server
• #22438 - Codex Desktop remote SSH connection does not show persisted remote sessions after app restart
• #35733 - Desktop auto-connects discovered SSH hosts at startup and blocks local chat loading when a host is unavailable

This looks related to all three, but I am opening a separate report because I could confirm that one persisted thread was indexed under both the SSH and Remote Control host identities.

I can provide sanitized Desktop log excerpts, the relevant catalog rows, and the app-server read results. I will not attach the full rollout, state databases, credentials, SSH configuration, or unredacted host identifiers to a public issue.

Start by reproducing the SSH and Remote Control setup, then inspect the Desktop thread catalog and launch logs for duplicate (host_id, thread_id) entries. Use thread/read and thread/turns/list with the SSH host identity to compare catalog lookup and loading behavior. Done means a persisted remote chat is indexed once, retains its project association, and opens with its complete conversation after restart.