Add UI support to relocate a project folder and move its threads
What problem are you running into?
When a local project folder is moved or renamed, Codex keeps the old project entry in the sidebar and its previous chats/threads remain grouped under the old folder. There does not appear to be a simple UI action to relocate the project or move all existing threads to the new folder.
Example from my setup:
- Old folder:
C:\dev\.svelte\menu - New folder:
C:\dev\.svelte\menu-app
After opening the new folder, the sidebar showed both projects. The new menu-app project appeared separately, while older threads still appeared under menu. Moving them required manually updating local Codex metadata, including thread cwd values and persisted sidebar/project state.
What would you like to happen?
Codex should provide a supported UI flow for this, such as:
Relocate project folderfrom the project menuMove all threads to another project/folder- Automatic detection when a saved project path no longer exists and a likely replacement folder is opened
- A confirmation dialog showing how many local threads will be moved
Why this matters
Moving or renaming project folders is common. Having the thread history split across stale and new project entries makes it hard to find prior work and makes the sidebar look inconsistent. Manual metadata edits are risky and should not be necessary for normal project maintenance.
Current workaround
Manually updating local Codex state can work, but it is unsupported and easy to miss cached sidebar/project entries. A first-class UI action would be safer and clearer.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Noticed this after I sent feedback through the app. ID: no-active-thread-019f3e1e-6b08-74c3-a20d-8927f65ce884.
One important case is when a user asks Codex itself to rename or move an already-open project directory. Codex can successfully rename the folder and then strand its own thread history because persisted cwd/project mappings still point at the old absolute path.
This should be one atomic built-in workflow: record the old and new roots, perform the rename, migrate all affected thread cwd/index/sidebar/project mappings and durable rollout metadata, verify that history remains visible, and roll back safely if any step fails. The agent-facing procedure should also ship as a built-in Skill, so Codex automatically follows it whenever it performs a project rename/move rather than requiring users to know about hidden SQLite/JSON state.
As of current
main(58b4277228), I still do not see a supported atomic project-root migration/relink flow.thread/settings/updatecan update a loaded thread for subsequent turns, but it does not migrate every stored thread and Desktop project mapping under an old root.