Codex Desktop thread list flips between symlink and realpath workspace projects

What version of Codex is running?

Codex Desktop / 0.122.0-alpha.1

What platform is your computer?

macOS / Darwin arm64

What issue are you seeing?

Codex Desktop appears to treat a symlinked workspace path and its resolved realpath as two different visible projects, while different code paths seem to update or filter threads using different path identities. This can make chats/threads appear to disappear from one project and reappear in the other when opened.

The chats are not deleted, but project/thread assignment becomes unstable and confusing.

Steps to reproduce

1. Have an existing Codex Desktop project rooted at a path like:

``text
/path/to/workspace-a
``

1. Move the contents of that folder to a different path, e.g.:

``text
/path/to/workspace-b
``

1. Replace the original folder path with a symlink to the new path:

``text
/path/to/workspace-a -> /path/to/workspace-b
``

1. Open Codex Desktop using the old symlink path and/or create/open a second Codex project at the resolved destination path.

1. Observe the thread list for both project entries.

Observed behavior

The thread list can appear to move between the two visible project entries:

• The old symlink-path project may initially appear to have lost its chats.
• Opening the realpath project can show the chats.
• Clicking/opening chats can cause them to disappear from one project list and reappear in the other.
• Reopening the same chats can cause another apparent reassignment.

Local state inspection suggests the underlying data is still present, but path identity is inconsistent:

• The mutable thread index can store affected threads under the resolved realpath.
• Desktop/global workspace state can simultaneously contain both saved workspace roots: the symlink path and the resolved realpath.
• The raw rollout/session metadata for an affected thread can still show the original symlink path as cwd, while the thread index shows the resolved realpath.

This suggests at least two Codex Desktop layers disagree about path identity:

• UI/project state keyed by the user-selected path string.
• Runtime/thread indexing keyed by canonical/resolved realpath.

Expected behavior

Codex Desktop should handle symlinked workspace roots consistently. Possible acceptable behaviors:

• Canonicalize workspace roots everywhere and avoid showing duplicate projects for symlink and realpath.
• Preserve the user-selected path everywhere and avoid rewriting thread/project assignment to the realpath.
• Detect that two saved project roots resolve to the same canonical directory and warn/merge/ask the user which identity to keep.

It should not allow two visible projects pointing to the same canonical directory to split, move, or reclassify the same chat/thread list when a thread is opened.

Additional information

This is probably an uncommon workflow, but it is easy to hit when moving an active workspace and leaving a symlink behind for compatibility with old paths. The current behavior can look like data loss at first because one project suddenly appears to have no chats, even though the transcripts still exist in Codex app state.