codex - 💡(How to fix) Fix Codex Desktop: Rename Project only changes display label, leaving backing folder as "New project N" [1 comments, 2 participants]

Product

Codex Desktop App on macOS

Version

Codex Desktop: 26.506.31421 (2620) macOS: 26.3, arm64

What happened

Codex created a local project with a placeholder backing folder such as:

~/Documents/New project 4

I renamed the project in the Codex UI to a real project name, for example:

Example Project

However, the rename only changed a display label. The underlying working directory and persisted project path remained ~/Documents/New project 4.

The UI then showed both concepts at once, roughly like:

Example Project New project 4

The model/session context also continued to receive the stale working directory. Local state confirmed this split:

• ~/.codex/.codex-global-state.json stored a display label mapping from ~/Documents/New project 4 to the renamed project label
• ~/.codex/config.toml still had a trusted project entry for the old absolute path
• ~/.codex/state_5.sqlite had thread rows whose cwd was the old absolute path
• the physical folder in Finder was still named New project 4

When I later organized Codex projects into a folder such as ~/Documents/codex/..., the current thread showed:

Current working directory missing This chat's working directory no longer exists

There was no obvious UI to relink the chat/project to the new folder path.

Expected behavior

Renaming a project should not leave the backing workspace in a placeholder New project N state without making that clear.

Codex should do one of the following:

1. During project creation, ask for the project name and create the folder with that name.
2. If “Rename Project” is intended to rename the project, update the backing folder/path and all persisted path references.
3. If the setting is only a display label, call it “Display name” and do not present it as a true project rename.
4. If the backing path is moved or missing, provide a “Relink folder...” / “Change path...” action.
5. Avoid using only absolute filesystem paths as project identity, or maintain a stable project id that survives folder renames/moves.

Actual behavior

The app allows the user to rename the project visually, but the actual project root remains New project N. This causes:

• confusing UI that shows both the display name and stale folder name
• stale cwd injected into new or resumed chats
• broken threads when the user tries to organize folders
• manual repair requiring edits to hidden Codex state files and SQLite records
• temporary symlink workarounds to keep existing chats alive

Why this matters

OpenAI’s own Codex getting-started guide says:

“A project is connected to a folder on your computer”

and recommends creating a Codex folder with separate project folders inside it.

That is exactly what users naturally try to do, but the current rename/path behavior makes it fragile and confusing. Users should not need to inspect ~/.codex/.codex-global-state.json, config.toml, or state_5.sqlite to recover from a project rename/organization operation.

Related issues

This appears related to, but distinct from:

• #11019: project threads broken after moving project folder
• #12679: cannot recover moved project / “Current working directory missing”
• #18186: “Current working directory missing” from path handling
• #19534: Desktop app stale state in ~/.codex/.codex-global-state.json

The distinction here is that the problem starts with Codex’s own rename UI: the user believes they renamed the project, but Codex only renamed a display label while leaving the backing folder and persisted path as New project N.

Requested fix

Please make project naming/path behavior coherent:

• ask for a project/folder name at creation time
• make “Rename Project” update the backing folder/path or explicitly label it as display-only
• add a first-class relink/change-path recovery UI
• update all local persisted references atomically when a project path changes