Codex Desktop: first-class local project management (create, edit, rename, roots, status)

What feature would you like to see?

Codex Desktop should provide first-class local project management instead of treating a project as a mostly fixed folder-derived sidebar entry.

Users should be able to create and edit local projects from the Desktop UI and through supported first-party project tools.

Requested capabilities

Create/register a local project

• Select one or more existing local folders.
• Assign a user-defined project display name during creation.
• Keep the display name independent from the folder basename and full path.
• Optionally create the first task immediately.

Edit an existing local project

• Rename the project display name without renaming the filesystem folder.
• Add, remove, or replace workspace root folders.
• Relocate a project after its folder moves while preserving task history.
• Set a project status such as In progress, Completed, Blocked, or Needs input.
• Assign a color/icon or tag so status is immediately visible in the sidebar.
• Remove only the project registration without deleting local files or task history.

Supported project-management tools

Expose the same lifecycle through supported first-party tools/API, for example:

• local_project/create
• local_project/update
• local_project/remove
• local_project/list

Updates should be atomic, persist across Desktop restarts, and use the same canonical project identity in Desktop, Remote, and task-management tools.

Why this matters

For users who manage many local repositories or case folders, path-derived project names quickly become too long to scan. Important status information is lost, and task titles become difficult to understand because the sidebar is dominated by folder naming conventions.

Today, the available project/sidebar operations mainly support listing, moving, pinning, and ordering existing projects. There is no complete supported flow for creating and editing local project identity, roots, and status. Workarounds such as hiding long project entries and grouping individual tasks into status sections do not solve project management itself.

Suggested sidebar presentation

Use the user-defined display name as the primary label and show the folder path as secondary metadata or a tooltip.

Example:

Bath AE · In progress with a yellow icon

instead of:

US-Design-Search-CaseNumber-ApplicationNumber-LongTechnicalTitle

Acceptance criteria

1. A local project can be created from the Desktop UI using an existing folder.
2. Its display name can be changed independently of the filesystem path.
3. Workspace roots and project metadata can be edited later.
4. Status/color/icon changes persist after restart.
5. Existing tasks remain associated with the same canonical project.
6. The same project name and metadata appear consistently across Desktop, Remote, and first-party project tools.
7. Supported project create/update/remove operations return actionable errors and do not require editing private local state.

Environment

• Windows 11
• Codex Desktop 26.825.6671.0

Related but narrower issues

• #41552 — creating and removing local projects fails
• #19673 — renamed project display name is inconsistently applied
• #28749 — relocate a project folder and move its tasks
• #41756 — project-name filter in the sidebar
• #27753 — sort projects by name
• #28127 — create/register a local project from mobile

This request is broader: it asks for a coherent local project create/edit lifecycle and a supported project-management interface.

No files, tests, or entry points are identified; start by locating the Desktop project/sidebar implementation and the existing project-management operations. Map how local project identity and task associations are stored before assessing the requested create, edit, remove, and tool/API flows. Done means the acceptance criteria are implemented consistently across Desktop, Remote, and supported project tools.