Regression in 0.142.5: SSH remote projects opened through symlinks show “No chats”

Open 💬 5 comments Opened Jul 1, 2026 by philipp-fischer

Environment

  • Windows 11 Enterprise 24H2 (build 26100.8655)
  • Codex Desktop 26.623.11225.0
  • Local and remote Codex app-server 0.142.5
  • Linux SSH remote with a Lustre-backed repository

Issue

A remote project saved with a stable symlink path shows No chats after the recent update:

saved project: /home/<user>/source/<repo>
resolved path: /lustre/fs1/.../<user>/source/<repo>

The remote thread database still contains all conversations, but their cwd is the resolved /lustre/fs1/... path. In my case, 13 active and 2 archived user threads remained intact and were still discoverable through cross-host thread search.

Reproduction

  1. Add an SSH remote project using a path containing a symlink.
  2. Create or retain threads for that project.
  3. Update the remote app-server from 0.141.0 to 0.142.5 and Desktop from 26.623.9142 to 26.623.11225.
  4. Restart Desktop.
  5. The symlink-path project shows No chats.
  6. Add a second remote-project entry for the resolved canonical path and restart. The missing chats appear under that project.

All app-server handshakes and thread/list requests succeeded; this is project grouping, not data loss. I did not perform a rollback, so the exact introducing version is not proven.

Expected behavior

Symlink and resolved paths that identify the same remote repository should not split or hide thread history. Preferably, threads should retain a stable remote-project ID or logical path rather than deriving project membership solely from canonical cwd.

The symlink is intentional: it keeps the project path stable if the backing filesystem changes from, for example, fs1 to fs3.

Possibly related: #15448 and #18483. This report adds a current Windows Desktop + Linux SSH remote reproduction observed after the 0.142.5 update.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗