Regression in 0.142.5: SSH remote projects opened through symlinks show “No chats”
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
- Add an SSH remote project using a path containing a symlink.
- Create or retain threads for that project.
- Update the remote app-server from
0.141.0to0.142.5and Desktop from26.623.9142to26.623.11225. - Restart Desktop.
- The symlink-path project shows No chats.
- 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.
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗