Codex App: Project threads broken after moving project folder to new path
What version of the Codex App are you using (From “About Codex” dialog)?
260206.1448 (565)
What subscription do you have?
Free (ChatGPT)
What issue are you seeing?
Issue Description
After relocating a project folder from ~/Desktop/Projects/ to ~/Projects/, the Codex App can no longer access the existing conversation threads that were created for those projects. The threads appear to be broken/inaccessible, and the app displays: "This project folder was deleted or moved"
What I've Tried
- Asked Codex in conversation (Codex suggested it's internal app data)
- Looked through Preferences for any option to update project paths
- Moved the folder using Finder (drag and drop method)
Current State
- Projects now located at:
~/Projects/[project-folders] - Previous location:
~/Desktop/Projects/[project-folders] - Error message shown: "This project folder was deleted or moved"
- Threads are still visible in the UI but cannot be accessed
- The "Ralph-Pure-Stacks" project shows "No threads" even though threads existed before
What steps can reproduce the bug?
Steps to Reproduce
- Create or open projects in Codex App from
~/Desktop/Projects/[project-name] - Create multiple conversation threads for these projects
- Move the project folder(s) to
~/Projects/[project-name]using Finder (drag and drop) - Open Codex App and attempt to access the previously created threads
- Observe the error message
Result
Error displayed: "This project folder was deleted or moved"
- Threads are no longer accessible
- Project shows "No threads" in the sidebar
- Codex cannot find the project at the new path
Expected Behavior
- Threads should remain accessible after project relocation
- OR Codex should prompt to update/relocate the project path
- OR provide a method to migrate existing threads to the new project location
What is the expected behavior?
- Ideal Solution: Threads remain accessible and linked to their projects even after the project folder is moved to a new location. Codex should be able to locate and access threads based on project content/identity rather than hardcoded file paths.
- Alternative Solution: Codex App should detect when a project has been moved and automatically update the path reference, or provide a UI option to "Update Project Location" to relink broken thread references.
- Minimum Solution: When accessing a project that has been relocated, Codex should provide a clear error message explaining the issue and guide the user on how to re-establish the project connection to restore thread access.
Additional information
Additional Context
Operating System: macOS 26.1 (25B78)
How folder was moved: Finder (drag and drop)
Error Message Received: "This project folder was deleted or moved"
Thread Storage: Appears to be stored in Codex's internal database, separate from the project folder itself. The app maintains references to the project path, and when that path changes, the thread references become invalid/inaccessible.
Impact
- Multiple projects affected (at least "Ralph-Pure-Stacks" confirmed)
- All conversation threads from those projects are now inaccessible
- No UI option to update project paths or recover threads
- Workaround: None found yet
Potential Root Cause
Codex appears to store thread references with absolute file paths rather than using a path-independent identifier (like project name, git repo URL, or content hash). This breaks when folders are relocated even if the project structure and contents remain identical.
7 Comments
Yes, threads are associated with the path of a project. If you move your project, previous threads will no longer be associated with the project.
Project names, git repo URLs and content hashes won't work for identifying projects because those are not unique. For example, you can clone the same repo (or create workspaces of the same repo) in multiple directories.
As a potential solution, we could add a way to update existing threads to point at a new location after you move your project. If that sounds like a solution you'd like to see, you could open a feature request.
I do think given the key path nature of this behaviour, that it's quite common to move directories around, it is closer to a bug that there's no way to update the file path. But sure I'll open a feature request as well.
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
ok lads what's happening why can't build robust software in 2026
sorry for non-professional / workplace approved aesthetics of writing but this is some _serious fuckshit_. store a UUID in .codex/ and don't be a silly. DO NOT allow no user to use the software unless that UUID is gitignored. hard check on launch. done. it's solved. 500% more useful software. wtf is the probs that we've still got gaping hole issues like these nearly a year later? this is literally the basic essential element of a harness, this is literally the difference between notepad and vim. boohoo can't use the harness without writing a file. well guess what this is industry standard, with .idea/, .vscode/, ... literally a non-issue, they're hidden directories. bruhh what is this 2026 ml import developer culture omg
All this vibe coding and you guys can't even make this most basic function happen.