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

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #30737
• #29698
• #30288
• #29366
• #30520

Powered by Codex Action

Thanks — I reviewed all five suggestions:

• #30737 concerns Windows/WSL path representations.
• #29698 concerns multiple worktrees/clones sharing a Git identity and grouping by sidebar order.
• #30288 concerns a cold WSL timeout causing fallback to Windows path semantics.
• #29366 concerns local Windows projects whose thread cwd already matches the saved path.
• #30520 is the closest, but attributes missing remote history to reconnect/hydration not being refreshed.

I don't believe any is an exact duplicate. In this reproduction the Linux SSH host was fully connected, app-server handshakes and thread/list succeeded, and two project entries on the same host behaved differently at the same time:

/home/<user>/source/<repo>        -> No chats
/lustre/fs1/.../<user>/source/<repo> -> chats visible

The first path is a symlink to the second. Changing only the saved remote-project path, then restarting, restored the chats. This isolates the failure to symlink-versus-canonical-path project matching rather than reconnect state, WSL conversion, Git worktree identity, or general sidebar hydration.

This is related to the broader path-normalization family (#15448, #18483), but adds a current 0.142.5 Windows Desktop + Linux SSH remote reproduction.

Adding another reproduction that looks like the same underlying bug, from #31600.

Environment:

• Codex Desktop: 26.623.141536 (CFBundleVersion 4753)
• Remote Codex CLI/app-server: 0.143.0
• macOS Desktop connecting to a Linux remote app-server/devbox via remote control

Remote host layout:

$HOME=/home/$USER
getent passwd $USER -> /home/$USER
/home/$USER -> /data00/home/$USER   # symlink
readlink -f /home/$USER/repos/project -> /data00/home/$USER/repos/project

Additional behavior observed:

• The New remote project picker defaults to /home/$USER, because that is the remote passwd / $HOME path.
• Remote thread records are stored with cwd under the resolved realpath, e.g. /data00/home/$USER/repos/project.
• If the project is added through the default picker path (/home/$USER/repos/project), the project can appear empty / incomplete.
• If the same project is added by manually typing the resolved path (/data00/home/$USER/repos/project), the conversations appear.

So in this reproduction, the default remote-project creation flow itself steers users toward the symlink spelling that does not match thread cwd realpaths. A fix should ideally canonicalize saved remote project paths and thread cwd consistently, or store both display path and canonical path and use the canonical path for matching.

Additional datapoint from iOS: the same remote host can show duplicate project groups on the mobile app as well.

On the remote app-server state DB, there are no threads whose cwd starts with /home/:

PREFIX /home/% count 0
PREFIX /data00/% count 20

All real remote thread cwd values are under the resolved realpath, e.g.:

/data00/home/$USER
/data00/home/$USER/repos/project

However, the iOS app still displays separate project groups for the same remote directories using both spellings, for example:

project-a        home
project-a        data00/home
project-b        home/$USER/repos
project-b        data00/home/$USER/repos

So this is not only a local Desktop catalog issue. It looks like mobile/project-summary state can also retain or render the symlink spelling separately from the canonical realpath, even when the remote app-server's current thread metadata contains only /data00/... paths.

Feature request follow-up: configurable default remote project root

In addition to fixing symlink/canonical-path project matching, it would be helpful to make the New remote project picker configurable per SSH host.

A generic layout is:

remote login home:       /home/<user>
picker starts at:        /home/<user>
symlink shown by picker: /home/<user>/<workspace>
symlink target:          /storage/workspaces/<workspace>
desired project root:    /storage/workspaces

The reliable workaround is to manually paste the resolved path each time a remote project is added. Trusting the real path in config.toml does not affect the picker's starting directory, and there does not appear to be a documented per-host default-root setting.

Requested UX:

• Add Default project root under Settings > Connections > SSH > <host>.
• Start the remote project picker at that path instead of always starting at the remote login home.
• Optionally remember the last directory used for each remote host.
• Optionally support favorite/bookmarked remote folders.
• Resolve or validate the configured root with realpath, while keeping a friendly display path if needed.

A generic configuration could look conceptually like:

<remote-host> → /storage/workspaces

This would not replace canonical path matching—the app should still treat symlink and realpath equivalents as one project—but it would prevent the default picker flow from repeatedly steering users toward the problematic symlink path and remove the need to paste the real path for every new remote project.

Seems this is still not fixed in the latest ChatGPT App?

Additional regression: remote thread deep links are now local-only

This issue has become more critical because the external deep-link workaround for accessing the hidden remote threads no longer works after another Desktop update.

Environment:

• Windows 11
• Codex Desktop 26.715.8383.0
• SSH remote project/thread

I used a small external launcher as a workaround: it enumerates the intact remote threads and opens a selected one with:

codex://threads/<thread-uuid>

After the update:

• The same link still opens local threads.
• It no longer opens remote threads.
• The remote UUID is present in the remote app-server SQLite database and absent from the local database.
• Codex logs the failure as:

local_conversation_deep_link_lookup_failed
thread not loaded: <remote-thread-uuid>

Inspection of the installed Desktop bundle shows that codex://threads/<id> is classified as a localConversation and is read only through the local app-server connection. The current URL parser does not preserve a remote hostId, so adding a query parameter or another path component cannot route the request to the SSH host.

As a control test, I opened Codex's built-in chat switcher with Ctrl+K, searched for the same remote task by title, and selected it. That succeeded. The logs then showed a host-aware resume with:

hostId=remote-ssh-discovered:<ssh-host>
method=thread/read

This confirms that:

1. The thread data is intact.
2. The remote host is connected and readable.
3. Codex's internal combined task catalog can resolve and open the thread.
4. Only the public deep-link path is incorrectly restricted to local state.

This removes a useful workaround for the symlink/canonical-path sidebar bug reported here. When the sidebar shows no chats, users can now access remote tasks only through title-based global search; searching by the UUID does not return the task, and duplicate titles are ambiguous.

A robust fix would be for codex://threads/<uuid> to resolve the UUID through the combined host-aware task catalog, or for the URI to accept and retain an explicit host identifier, for example:

codex://threads/<uuid>?hostId=<encoded-host-id>

I could not find a public CLI command or another documented host-aware navigation endpoint that an external launcher could use.

It's become worse now. Cannot even open such a thread any more since last update. It renders remote agents useless now :(

Could a maintainer please apply the regression label and assess severity? The behavior worked before the cited updates, remains reproducible in current Desktop builds, affects multiple platforms/users, and the latest update also removed the remote-thread deep-link workaround.

I can reproduce this with two mount aliases on a shared Linux cluster, rather than a conventional symlink.

Environment

• Upstream Desktop app: 26.721.41059
• Local and remote Codex CLI: 0.145.0
• Linux Desktop package built by ilysenko/codex-desktop-linux from the upstream DMG, with no optional Linux features enabled
• Remote Linux host connected through Desktop Remote SSH

Reproduction

The same remote repository is available through:

/workspaces/<group>/<user>/sources/<project>
/import/<workspace-mount>/<group>/<user>/sources/<project>

readlink -f resolves both to the second path.

1. Save the remote project using the /workspaces/... alias and restart

Desktop. The project shows no tasks.

1. Re-add it using the /import/... alias. The tasks appear.
2. Clicking a task can remove it from the project list.
3. Switching back to /workspaces/... can make that loaded task remain visible

for the current session, but the association is lost after a restart.

Evidence

The remote database contains two active tasks that are intact, unarchived, and store the /import/... cwd.

Desktop simultaneously reports:

saved project path: /workspaces/<group>/<user>/sources/<project>
task cwd:           /import/<workspace-mount>/<group>/<user>/sources/<project>
task projectId:     null

Inspection of the installed renderer shows that remote project membership uses the host ID plus a lexical comparison between the saved project path and task cwd. Its normalizer handles separators and trailing slashes but does not resolve remote filesystem aliases. Project setup also persists the user-entered path verbatim.

Once a task is loaded, it is excluded from the paginated project query and must be grouped again through the same path matcher. This is consistent with the click-time disappearance also reported (maybe #22438 and/or #27284?)