Codex Desktop: Recents threads disappear after deleting and recreating a Project with the same folders

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

26.721.3404.0 (CLI/app-server 0.146.0-alpha.3)

What subscription do you have?

API key (pay-as-you-go)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64, using WSL execution mode

What issue are you seeing?

Threads created from Recents / Start from scratch can disappear from the sidebar after they are dragged into a Project and that Project is later deleted and recreated with the same physical folder(s).

This appears to be an interaction between the newer multi-folder Project model and thread working directories:

• A Project is a virtual grouping with its own generated identity and one or more physical root paths.
• A projectless thread starts in a generated workspace directory under Documents/Codex/....
• Dragging that thread into a Project changes its organizational Project association, but its execution working directory remains the generated projectless workspace.
• Deleting the Project removes the virtual grouping. Re-adding the exact same physical folder(s), even with the same Project name, creates a different Project identity.
• The dragged thread remains associated with the deleted Project identity. Because its working directory does not match any of the re-added Project roots, it is not recovered under the new Project or returned to Recents.

The underlying thread/session data still exists locally, so this is apparent data loss caused by an orphaned sidebar association rather than deletion of the conversation.

Threads originally created from a physical project directory behave differently: their working directory matches a Project root, so they may be rediscovered after the folder is re-added. This makes the drag operation look like it establishes the same relationship when it does not.

What steps can reproduce the bug?

1. In Codex Desktop, create a new thread from Recents / Start from scratch. Use a disposable thread for this test.
2. Observe that Codex creates a generated workspace directory for it under Documents/Codex/....
3. Create a Project that contains an existing physical folder. The same issue also applies to a Project containing multiple folders.
4. Drag the projectless thread from Recents into that Project.
5. Confirm that the thread is shown under the Project while its execution working directory remains the generated workspace from step 2.
6. Delete the Project from the sidebar without deleting the physical folder(s).
7. Add the exact same physical folder(s) again and optionally give the Project the same name.
8. Observe that the dragged thread is absent from both the recreated Project and Recents, although its session data remains on disk.

What is the expected behavior?

Deleting a Project should not make its threads inaccessible. At least one of the following should happen:

• Move all threads associated with the deleted Project back to Recents.
• Preserve or migrate the association when a Project with the same root paths is recreated.
• Warn before deletion and offer a destination for affected threads.
• Provide a UI action to reassign an orphaned thread to another Project.

The UI should also distinguish between:

• moving a thread into a Project as an organizational classification; and
• changing/rebinding the thread's execution working directory to a Project folder.

Additional information

Sanitized local-state inspection suggests the relevant relationship is conceptually:

• Project metadata: projectId -> rootPaths[]
• Sidebar organization: threadId -> projectId
• Execution environment: threadId -> cwd

For a projectless thread dragged into a Project, only the second relationship changes. When that Project is deleted, the stale projectId cannot be reconstructed from cwd because cwd still points to the generated projectless workspace.

Related issues cover adjacent parts of the problem, but not this exact deletion/recreation case:

• #11022: migrate thread references when a project directory moves
• #20115: associate an existing conversation with a project folder/workspace
• #26157: project/sidebar mappings lost while sessions still exist

No local state files, real project names, paths, or conversation contents are attached to this report.