Repository navigation
Codex desktop terminal uses stale workspace path after project directory is renamed #20934
Description
Summary
After renaming a project directory from within a Codex desktop session, the top-right terminal toggle can still try to open or cd into the old workspace path. The agent can use the new path explicitly, but the terminal/workspace context appears to remain stale, so the UI and agent context are out of sync.
What happened
Original workspace path:
/Users/mingqxu/Documents/New project
The folder was renamed to:
/Users/mingqxu/Documents/Scientific Research
After the rename, using the top-right terminal toggle still attempted to use the old path. In the terminal:
cd '/Users/mingqxu/Documents/New project'
# cd: no such file or directory: /Users/mingqxu/Documents/New projectThe renamed folder exists:
/Users/mingqxu/Documents/Scientific Research
Expected behavior
Codex desktop should keep the terminal/workspace path in sync after a project directory is renamed, or detect that the original cwd no longer exists and prompt the user to select/remap the workspace directory.
At minimum, the terminal toggle should not keep sending users into a deleted/stale cwd without a clear recovery path.
Actual behavior
The terminal still targets the old directory name after the project folder was renamed, causing cd: no such file or directory and leaving the user-facing terminal state inconsistent with the actual project path.
Reproduction steps
- Open a Codex desktop session in a project directory, for example
/Users/<user>/Documents/New project. - Rename that directory to a new name, for example
/Users/<user>/Documents/Scientific Research. - Use the top-right terminal toggle in the same Codex session.
- Observe that the terminal still tries to use the old path and fails with
cd: no such file or directory.
Environment
- Product: Codex desktop app
- Platform: macOS
- Shell: zsh
- Observed date: 2026-05-04
Activity
github-actions commentedon May 4, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
wang-jinbo commentedon May 18, 2026
I'm bothered by this issue as well.
sunjiajunsunjiajun commentedon Jul 24, 2026
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.