Remote project picker defaults to symlinked $HOME while threads are stored under resolved realpath

What issue are you seeing?

In Codex Desktop, adding a remote project from a devbox-like remote host defaults the folder picker to the symlinked home path (/home/$USER). However, Codex stores remote thread cwd values using the resolved realpath (/data00/home/$USER/...).

Because the Desktop project list appears to match projects by raw path string, a project added through the default picker path can show no conversations even though the remote threads exist. Manually entering the resolved /data00/... path makes the conversations appear.

This looks related to #18483, but this report is specifically about the remote project picker defaulting to the symlink path while the remote app-server/session metadata uses the resolved path.

Environment

• Codex Desktop: 26.623.141536 (CFBundleVersion 4753)
• Remote Codex CLI/app-server: 0.143.0
• Platform: macOS desktop connecting to a Linux remote app-server/devbox via remote control
• Remote user home 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

Steps to reproduce

1. Use a Linux remote host where the passwd home directory is /home/$USER, but /home/$USER is a symlink to a real persistent directory such as /data00/home/$USER.
2. Start Codex remote-control/app-server on that host.
3. Create or continue a Codex thread from a project under the real path, for example:

/data00/home/$USER/repos/project

1. In Codex Desktop, choose New remote project for that host.
2. Observe that the folder picker defaults to:

/home/$USER

1. Select /home/$USER/repos/project through the picker and add it.
2. The project may appear empty or incomplete.
3. Add the same project by manually typing the resolved path:

/data00/home/$USER/repos/project

1. The expected conversations are visible.

Observed behavior

Remote threads are present in the remote Codex state database, with cwd values under the resolved path:

/data00/home/$USER/repos/project

But the Desktop UI's remote project picker defaults to the symlink path:

/home/$USER

When the saved project path uses the symlink spelling, project/thread matching can fail or split the same project into separate visible entries.

Expected behavior

Codex Desktop should treat symlink and realpath equivalents as the same project identity for remote projects, or the remote project picker should default to the same canonical path representation that remote threads use.

At minimum, one of these would prevent the confusing empty-project state:

• canonicalize remote project paths with realpath before saving/matching;
• canonicalize remote thread cwd and saved project paths consistently in the same layer;
• store both the display path and canonical path, using canonical path for matching;
• make the remote picker display or suggest the resolved path when the selected directory is a symlink.

Additional notes

Restarting the remote Codex app-server did not change the picker default, because the remote process still has HOME=/home/$USER from the system account configuration. Starting the daemon with HOME=/data00/home/$USER did not persist either; the managed daemon still ran with HOME=/home/$USER.

This means the reliable workaround today is to manually type the resolved /data00/... project path, but the default picker flow leads users toward a path that does not match existing remote thread metadata.