Codex Desktop App project display name can diverge from filesystem path, causing unrecoverable “Current working directory missing”
What version of the Codex App are you using (From “About Codex” dialog)?
26.506.31421 (2620)
What subscription do you have?
API Provider
What platform is your computer?
Darwin 25.4.0 arm64 arm
What issue are you seeing?
Related: #12679. I am opening this because the behavior still appears reproducible and the current UX does not expose a relink/recovery flow.
I can still reproduce this in Codex Desktop App on macOS.
Scenario:
- Create/open a project in Codex Desktop App.
- Rename the project folder on disk, for example:
/Users/xxx/Documents/New project 2
to:
/Users/xxx/Documents/Obsidian-Codex
- Return to the existing Codex thread.
- The app shows:
Current working directory missing
This thread's working directory no longer exists
- The thread remains bound to the old path and there is no visible UI action to relink it to the new folder.
Workaround:
Creating a symlink from the old path to the new path fixes the current thread:
ln -s "/Users/xxx/Documents/Obsidian-Codex" "/Users/xxx/Documents/New project 2"Why this matters:
The current behavior is especially confusing when the project name has already been renamed in the Codex UI but the underlying filesystem path still points to the old folder name. Users can end up with a project whose display name and actual bound path diverge, and the only practical workaround is a filesystem symlink.
What steps can reproduce the bug?
- Create/open a project in Codex Desktop App.
- Rename the project folder on disk, for example:
/Users/xxx/Documents/New project 2
to:
/Users/xxx/Documents/Obsidian-Codex
- Return to the existing Codex thread.
- The app shows:
Current working directory missing
This thread's working directory no longer exists
What is the expected behavior?
When the working directory is missing, Codex Desktop App should provide a recovery action such as:
Relink Folder...Change Project Path...Choose Existing Folder...
This should update the existing thread/project binding while preserving conversation history, project memory, permissions, and local metadata.
Additional information
_No response_
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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.