File tree Flickers after project directory rename

I hit the same class of problem after renaming a working directory / repo.

After the directory was renamed, Codex Desktop reports the current working directory as missing, but there does not appear to be any UI affordance to re-associate the existing project/thread with the renamed directory.

Expected behavior: when the saved working directory path no longer exists, the app should offer a way to reassign/re-associate that project or conversation with a new directory path, such as a "Change working directory" / "Set project directory" action from the project context menu or the missing-directory warning itself.

I would also add that currently on mac the default start path is the Document folder(if you start new project it sets it in Document folder)....that needs to be a Codex setting we can change so that we can point it to any path for new projects that start in Codex. My workspace folder that houses thousands of projects lives on external drive for example....thats where i want new projects to be put

I’m seeing a related issue on Windows Codex Desktop.

A project was originally associated with:

C:\Users\<user>\Documents\New project

The actual project now exists at:

C:\Users\<user>\Documents\Codex Projects\Word Connect

But Codex Desktop still shows/uses the stale project path in the sidebar/project state. The global state contains stale mappings like:

• electron-saved-workspace-roots includes the deleted ...\Documents\New project
• project-order includes the deleted path
• electron-workspace-root-labels maps the deleted path to Word Connect
• another parent folder is labeled as a different project

Manually editing .codex-global-state.json and .codex-global-state.json.bak while Codex is running does not stick; the app rewrites the old in-memory state back to disk. A workaround is to fully quit Codex, patch both files, and then restart.

Expected behavior:
Codex should either update/remap project roots when a project folder moves/renames, or expose a “Change project directory” action in the project context menu. It should also not silently restore stale workspace roots from memory after state files are repaired.

Follow-up from the same Windows case: the stale path survived more cleanup than expected.

Additional details:

• The affected thread row in ~/.codex/state_5.sqlite still had cwd = \\?\C:\Users\<user>\Documents\New project.
• Updating that row to the real path and rewriting .codex-global-state.json / .codex-global-state.json.bak did not fully resolve the sidebar/project entry.
• After restarting, the global UI state was restored again with:
• electron-saved-workspace-roots containing the deleted ...\Documents\New project
• project-order containing the deleted path
• electron-workspace-root-labels mapping the deleted path to Word Connect
• state_5.sqlite no longer contained New project, so the sidebar project list appears to be restored from another persisted UI/app state path, not just the thread DB.

Current workaround:

I created a Windows junction:

New-Item -ItemType Junction `
  -Path "C:\Users\<user>\Documents\New project" `
  -Target "C:\Users\<user>\Documents\Codex Projects\Word Connect"

That stops Codex from treating the stale project root as deleted, because the old path now resolves to the real project. The UI may still display the stale path, but operations through it land in the correct project.

This suggests the app needs a durable way to remap or delete stale project roots from the sidebar/project model, not only thread cwd repair.

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.