Add ability to update/migrate thread references when projects are moved to new locations

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

• #11019

Powered by Codex Action

Just moved my project to a new directory as a result of a Codex recommendation to rename my volume. Would love to see a feature that allowed me to update the Codex thread to point to the new location.

Moving directories around is common during project development, especially during early stages or big refactors. I agree that an option to change the project directory on the Codex app preferences would be very useful.

Very surprised there is no way to do this. would be trivial

desperately need this feature as well

Hitting this issue

Same just encountered this issue. At the moment I just prompted the new path location, my process still works, but the message "Current working directory missing. This thread's working directory no longer exists" is still present.

Additionally, I found that using the "Hand Off" button to create a worktree for the thread will use a path like ~/.codex/worktrees/6138/yourproject without a chance to give a preferred path. Then if you use git worktree move to move it to a nicer path (if I'm going to work for days on a refactor, I want it somewhere nice and visible) codex will not follow the git command and there is no way to tell it to look for the files in the new path.

What a pathetic joke. If you move your project, all history/context is detached? Really?

The ability to move project folders is a basic-level feature of every code (and non-code) tool on the planet of the past thirty years.

Turns out this can be done pretty easily by an agent with a single prompt. Here is an agent skill I made to get me by until they add this feature to Codex:

https://github.com/Adam-Bull/Codex-thread-toolkit

Any updates on this?

@Adam-Bull your skill worked great! I submitted a small PR to also re-add the updated chats under the sidebar folders/projects. Without it, existing sidebar folders show as having "no chats" since the project still points to the wrong path. 🙌

Has anyone tried manually pointing .codex/sessions files to the new folder path? The chat sessions should be portable along with the projects. When I installed Codex I set the default path to my Documents folder, and I wish to change to a more appropriate dev folder outside my windows user folder.

@Adam-Bull's https://github.com/Adam-Bull/Codex-thread-toolkit worked great for me! I just asked ChatGPT in a new browser window how best to run it, so that I could keep Codex completely quit while I was mucking about with its internals. Or I suppose you could use Claude Code as the doctor 😁

I still can't believe it's not a feature. You technically can do it manually (or possibly with a script), but having to fallback to not-native solutions in this era is so off-putting...

Thanks to @Adam-Bull s skill, I also have completed my migration to new folder as my project setup was totally broken due to iCloud sync that I had selected a wrong directory...

I ran into a similar local-project move problem and extracted my workaround into a small open-source CLI:

https://github.com/Blankdlh/codex-workspace-migrator

It is not an official Codex fix, but it may be useful as a temporary workaround for people who have already moved or renamed a local Codex project directory.

Fixing this would be especially nice if no one is going to fix #19913

I ran into this on Windows and published a small open-source workaround:

https://github.com/pacolaf/codex-project-path-migrator

It performs a dry-run, validates the current Codex state structure, backs up
the complete .codex directory, migrates structured path references, and rolls
back on failure. It is Windows-only, uses the Python standard library, and is
intended as an unofficial temporary solution until native path remapping is
available.

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/update can update a loaded thread for subsequent turns, but it does not migrate every stored thread and Desktop project mapping under an old root.

Additional Windows + iOS Remote reproduction (project moved across drives)

I reproduced a related failure on Codex Desktop for Windows where moving a project does not delete the tasks, but breaks the separate task-to-project association used by the sidebar and mobile Remote view.

Environment:

• Codex Desktop 26.721.11231.0 (x64)
• Bundled/local codex-cli 0.144.4
• Windows x64, build 26200.8973
• ChatGPT iOS app using Codex Remote (exact mobile app version not captured)

Reproduction/state transition:

1. A Git project named APEX originally lived under C:\Users\<user>\Documents\APEX and had multiple existing tasks.
2. The project was moved to D:\AI项目\APEX and re-added/saved in Codex Desktop at the new location.
3. The old tasks remained readable and were not archived or deleted.
4. The task working directories were updated to the new path, but the tasks did not reappear under the saved APEX project.
5. Desktop showed APEX with No tasks. The connected iOS Remote view showed only one newer task under APEX, so desktop and mobile presented different project membership for the same host.

Local evidence (identifiers and private paths redacted):

• state_5.sqlite contained 12 active, unarchived APEX tasks, all readable, with the new cwd.
• The saved local project existed with root D:\AI项目\APEX and was detected as a Git repository.
• Listing the 12 tasks returned projectId: null even though their cwd matched the saved project root.
• The thread-project-assignments global-state map had no entries for those 12 tasks.
• The tasks were not marked projectless.
• The persisted saved-workspace roots still included the old C: path.
• Pinning/unpinning a task did not repair membership.
• There is no exposed batch relink/migration command; the only immediate UI workaround appears to be manually dragging each task into the new project one by one.

This suggests that project relocation has at least two independent layers: the core task cwd/session state and the Desktop renderer/global thread-project-assignments state. Updating or recovering the cwd alone does not atomically migrate the project membership map, and Remote can then display a different/stale projection.

Expected behavior:

• When a saved project is relocated, Codex should offer an Update project location / migrate existing tasks operation.
• That operation should atomically update task cwd, saved workspace roots, task-to-project assignments, and the Remote projection.
• If automatic matching is unsafe, the UI should provide a batch selector to relink all tasks from an old path to a confirmed new project.
• Desktop and connected mobile Remote should converge on the same project/task membership without requiring a full restart or manual per-task dragging.

Related symptoms also overlap with #24749 (stale mobile project-thread list) and #25084 (active project history hidden while tasks remain in local storage), but this reproduction is specifically triggered by a project-folder relocation across Windows drives.