File tree Flickers after project directory rename

[daskabe]

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.422.30944 (2080)

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

i started a project, then i renamed the project folder manually.

Codex said it cant find the Project folder, so i told gpt where the new path is by giving it a full path.
it found it and i asked to add files - and it added files fine to the new path.

The issues is Codex App still shows "Current working directory missing" message above the input box and the file tree is flickering like shown. I restarted Codex thinking it will propagate the new path to all parts of the app but it didnt.

Screen.Recording.2026-04-27.at.12.18.34.PM.mov

What steps can reproduce the bug?

Create new Project > Add working directory > rename directory > Codex says it cant find working directory > open File Directory , Notice the message above the chat input.

What is the expected behavior?

On the left side bar - in the context menu of the project - add option to Set/Change Project directory.

Additional information

No response

[ohcedar]

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.

[daskabe]

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

[JinduSama]

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.

[JinduSama]

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.