Codex App hides existing threads when a project is reopened via a symlinked workspace path on macOS

[x3zvawq]

What version of the Codex App are you using (From “About Codex” dialog)?

26.318.11754 (1100)

What subscription do you have?

Plus

What platform is your computer?

macOS, Apple Silicon (M3)

What issue are you seeing?

After moving some projects to an external SSD and restoring them through symlinks, Codex App stopped showing the old threads for those projects in the sidebar/history UI.

The thread data was not actually lost. The local Codex data still existed under ~/.codex, including the thread database and session index. The issue only affected projects that had been moved to the external drive.

From local inspection, this appears to be a workspace path canonicalization mismatch:

• the desktop app persisted workspace roots using the symlink path, such as /Users/x3zvawq/workspace/...
• existing thread metadata stored cwd using the real path, such as /Volumes/SSD/workspace/...

Because of that mismatch, the app seems to treat them as different projects and does not show the old threads for the symlink-opened workspace, even though both paths resolve to the same location.

What steps can reproduce the bug?

1. Have an existing project with Codex App threads/history already created.
2. Move that project to an external SSD.
3. Create a symlink from the old path to the new location, for example:
   • old logical path: /Users/x3zvawq/workspace/my-project
   • real path on external drive: /Volumes/SSD/workspace/my-project
4. Open the project in Codex App using the symlinked path.
5. Observe that older threads for that project no longer appear in the app.
6. Inspect local state and thread metadata:
   • app state may still contain workspace roots under the symlink path
   • thread records may store cwd under the real path
7. Rewriting the saved workspace-root paths in ~/.codex/.codex-global-state.json from the symlink path to the real path makes the missing threads show up again after restarting Codex App.

What is the expected behavior?

Codex App should treat a symlinked workspace path and its resolved real path as the same workspace when grouping, matching, or displaying project threads.

In other words, if:

• saved workspace root = /Users/x3zvawq/workspace/my-project
• thread cwd = /Volumes/SSD/workspace/my-project

and both resolve to the same filesystem location, the existing threads should still appear normally in the app.

Additional information

I investigated the local state and found that the thread data itself was intact:

• ~/.codex/state_5.sqlite
• ~/.codex/logs_1.sqlite
• ~/.codex/session_index.jsonl

A manual workaround was:

1. close Codex App
2. back up ~/.codex/.codex-global-state.json
3. rewrite saved workspace-related paths from the symlink form to the real resolved path
4. reopen Codex App

After doing that, the missing threads reappeared.

This suggests the bug is likely in desktop-side workspace path persistence/comparison rather than data loss.

Possible fix direction:

• canonicalize or resolve realpath for workspace roots before persisting and before comparing them against thread cwd
• alternatively, compare both sides using a normalized/canonical filesystem path representation instead of raw path strings
• add a regression test covering symlink path vs resolved path for the same workspace

[github-actions]

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

• Support moving/remapping a workspace folder without losing thread history #15347
• Windows app: threads disappear after restart when project is on a mapped network drive (possible //?/unc/... path normalization issue) #13846

Powered by Codex Action

[x3zvawq]

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

• Support moving/remapping a workspace folder without losing thread history #15347
• Windows app: threads disappear after restart when project is on a mapped network drive (possible //?/unc/... path normalization issue) #13846

Powered by Codex Action

This looks closely related to, but not identical with:

• Windows app: threads disappear after restart when project is on a mapped network drive (possible //?/unc/... path normalization issue) #13846: Windows mapped-drive / UNC-style path normalization causing threads to disappear after restart
• Support moving/remapping a workspace folder without losing thread history #15347: enhancement request for remapping/moving a workspace without losing thread history

My case is on macOS and appears to involve a symlink path vs resolved real path mismatch:

• workspace opened as /Users/x3zvawq/workspace/...
• thread metadata / cwd associated with /Volumes/SSD/workspace/...

The thread data still exists locally, and rewriting the saved workspace path to the resolved real path makes the threads reappear.

So this seems closest to #13846 at the root-cause level (path normalization / canonicalization mismatch), while #15347 is a broader product feature request rather than the same bug.

[x3zvawq]

After applying the initial workaround and restarting the app, all missing threads became visible again in the desktop UI.

However, a second issue appeared:

• the restored threads were visible in the list at first
• after clicking one thread, that thread would disappear from the desktop thread list again
• the thread itself was still usable after opening it, and I could continue working in it
• but once I switched away, I could no longer switch back to it from the desktop UI

From local inspection, this did not look like actual data loss:

• the thread still existed in ~/.codex/state_5.sqlite
• it was not being marked archived
• its metadata still looked intact

So this seemed to be a second desktop-side UI/filtering issue triggered after opening a restored thread, rather than the thread actually being deleted or lost.

[varoudis]

Will this be fixed? Why are threads disappear?

[KevinAsher]

Same issue. It's the second time I update, recent-ish threads are kept, 2-week-ish ones are gone. Is there some type of default filtering going on by date? Or perhaps a reset per install?