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
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:
/Users/xxx/Documents/New project 2to:
/Users/xxx/Documents/Obsidian-CodexCurrent working directory missingThis thread's working directory no longer existsWorkaround:
Creating a symlink from the old path to the new path fixes the current thread:
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?
/Users/xxx/Documents/New project 2to:
/Users/xxx/Documents/Obsidian-CodexCurrent working directory missingThis thread's working directory no longer existsWhat 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