### Feature request Codex Desktop should provide first-class project management capabilities, especially: 1. Register/add an existing local folder as a saved project from the sidebar or command palette. 2. Move an existing thread from one project to another. 3. Change a thread's project binding after creation. 4. Expose the same capability through the app-server / thread management API so agents can create threads under the correct project reliably. ### Current behavior At the moment, a thre

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #25385 - #24519 - #24222 - #25252 *Powered by [Codex Action](https://github.com/openai/codex-action)*

Codex Desktop: add project management for registering projects and moving threads between projects

Open 💬 8 comments Opened Jun 1, 2026 by 0okay

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Feature request

Codex Desktop should provide first-class project management capabilities, especially:

Register/add an existing local folder as a saved project from the sidebar or command palette.
Move an existing thread from one project to another.
Change a thread's project binding after creation.
Expose the same capability through the app-server / thread management API so agents can create threads under the correct project reliably.

Current behavior

At the moment, a thread can only be created under a project if that folder already exists in the Desktop saved project list.

If a local folder is not yet registered as a saved project, background thread creation fails with Unknown projectId. The workaround is to create a thread under a parent workspace and tell the agent to cd into the desired subfolder, but the thread still appears under the wrong project in the Desktop sidebar.

There also appears to be no safe way to move that thread into the correct project afterward. The available thread tools support creating, renaming, sending messages, pinning, and archiving threads, but not changing the project binding.

Why this matters

For project-heavy workflows, especially legal/patent/client work, each matter is organized as its own local folder. Users often create the folder first and then need Codex to create a visible project thread for that exact folder.

If the thread is placed under the parent workspace instead:

the sidebar becomes confusing;
later retrieval is harder;
project-specific context/rules may not be obvious;
handoffs between threads become unreliable;
users are tempted to edit internal SQLite/JSON state, which is risky and should not be necessary.

Requested behavior

Please add a supported UI and API flow for project management:

Add existing folder as project
Move thread to project
Change thread project
List saved projects
optionally Create project from local path

Ideally, the app-server API could support something like:

{
  "method": "project/create",
  "params": {
    "path": "E:\\...\\ProjectFolder"
  }
}

and/or:

{
  "method": "thread/project/set",
  "params": {
    "threadId": "...",
    "projectId": "E:\\...\\ProjectFolder"
  }
}

Example scenario

A user has a saved parent workspace:

E:\...\YAYI\2026\工作区

Inside it, a new project folder is created:

E:\...\YAYI\2026\工作区\中国-实用新型-检索-未分配案号-未获申请号-B22防水灯座灯头

Trying to create a thread directly under the new folder fails because it is not yet a saved project. Creating the thread under the parent workspace works, but the thread appears in the wrong sidebar group and cannot be moved.

Environment

Codex Desktop on Windows
Local project folders
Project-heavy workflow with many nested client/matter folders

This is related to #13836 but narrower: project registration and moving existing threads between projects.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#25385
#24519
#24222
#25252

Powered by Codex Action

rodolphomartins · 1 month ago

I am upvoting this one specifically on allowing to add standalone chats to projects.

Audacity88 · 1 month ago

For the thread-moving/relinking part, there is already a workable skill-level solution here:

https://github.com/EyrieCommander/codex-skills/tree/main/skills/thread-workspace-relink

That handles the “existing thread is attached to the wrong workspace/project path” case by safely relinking the local thread workspace state.

However, a different Codex-side gap remains for agent-driven thread delegation. When an agent tries to create a new follow-up thread in a specific saved project, create_thread can reject the target with:

Unknown projectId: <workspace path>. Call list_projects to find available projects.

But in the session where this happened, the agent had create_thread, read_thread, and send_message_to_thread, while no list_projects tool was exposed. Retrying with the visible project name failed the same way. The only available fallback was creating a projectless thread, which landed outside the intended workspace/sidebar grouping.

So the narrower Codex fix is: if create_thread requires opaque saved project IDs, agents need a supported way to discover or address them. Any of these would make the flow work:

expose list_projects whenever project-scoped create_thread is exposed;
allow projectId to accept the current project, current workspace, or an absolute workspace path;
include saved project IDs/paths in thread or project metadata available to the agent.

ruslankha21 · 28 days ago

I ran into this exact limitation in the Codex Desktop app on Windows. Existing threads cannot be moved from one project to another without losing their conversation history.

The desired flow is a supported “Move thread to project” action that preserves the full thread history, attachments/artifacts, working state, and context. Renaming threads, recreating them from summaries, or archiving the originals is not an adequate substitute. This would make long-lived project organization much more practical.

anipotts · 25 days ago

Adding a macOS remote-project variant of the same agent-driven delegation failure.

Environment:

Codex App: 26.616.81150
Codex CLI: 0.142.0
Platform: Darwin 25.5.0 arm64 arm
Project shape: saved remote projects on a Mac mini host, created through the Desktop app remote-project flow

Observed failure in the broken session:

The agent had create_thread available and needed to call it with target: { type: "project", projectId, environment: { type: "local" } }.
The target projects were already saved remote projects in the Desktop app.
create_thread required the opaque saved projectId.
No list_projects tool was exposed in that session.
list_threads only exposed thread-level hostId and cwd; it did not include the saved projectId, projectKind, or saved-project label.
Local app storage confirmed the remote host/cwd mapping, but there was no supported agent-facing way to resolve the saved project ids, so the agent could map remote hosts/paths/threads but could not safely create a new thread under the intended saved remote project.

Contrasting current-session evidence:

In another Codex App session on the same laptop, codex_app.list_projects is exposed.
That tool returns the saved remote projects with projectId, projectKind: "remote", label, path, hostId, and hostDisplayName.
So the saved project data exists and is sufficient when the discovery tool is present. The blocker appears to be conditional/inconsistent tool exposure, not missing project state.

The smallest fix that would make this reliable is to always expose list_projects whenever project-scoped create_thread is exposed.

Other workable fixes:

allow projectId to accept the current project, current cwd, or an absolute saved-project path;
include projectId, projectKind, label, and host display metadata in list_threads;
return an actionable error when create_thread requires saved-project ids but no project discovery tool is available.

Suggested regression test: a manifest/tooling test should fail if a session exposes project-scoped create_thread without also exposing a supported project-discovery path such as list_projects. For remote projects, the test should verify that the discovery response includes enough metadata to select the intended host/path without reading internal Desktop storage.

hoangbn · 19 days ago

+1 on allowing create_thread to create a thread in new project. Somehow I think this used to work for me

0okay · 6 days ago

Additional Windows Desktop evidence from a real project-intake workflow:

An agent creates a new matter folder under a saved workspace and archives the supplied files into that folder.
The user expects the next execution thread to be visibly grouped under that exact folder in the Desktop sidebar.
Immediately after folder creation, list_projects may not include the new folder yet. If an agent uses the parent workspace or an Inbox project as a fallback, putting the desired folder path in the prompt does not change the binding: read_thread.cwd remains the parent/Inbox path and the thread is grouped there.
A short time later the folder can appear in the saved-project list, but the wrongly bound thread cannot be reattached. The only safe repair is to create another thread, which makes the workflow noisy and forces user intervention.

The desired zero-click flow is:

create folder;
archive materials;
register or await registration of that exact folder as a saved project;
create the working thread directly in that project;
verify thread.cwd == project path before reporting success.

Please provide a supported API/UI path for this, ideally one of:

project/register or project/create for an existing local folder;
create_thread accepting a local folder path and registering/awaiting it atomically;
thread/project/set to repair an accidental parent-workspace binding.

A regression test should verify that a newly initialized folder can receive a project-bound thread without manual sidebar clicks, and that the resulting thread is displayed under that folder rather than the parent workspace.

Lyhtande · 5 days ago

I ran into the same limitation in a common "start broad, specialize later" workflow:

A task is initially created in a broad parent workspace because the conversation starts as general exploration.
During the conversation, it becomes clear that the task belongs to a more specific child project.
The child directory is registered as its own local project.
Moving the existing task to that project is rejected because the task retains the parent working directory and the destination project does not have access to it.

Starting a new task loses the value of keeping the original transcript, decisions, and context together. Keeping the task under the parent project makes project organization misleading.

A supported Move task to project flow should therefore handle both project binding and working-directory binding:

Let the user select a destination project.
If the current working directory is outside the destination scope, offer to change it to the destination project's root or another allowed directory.
Show the proposed access and working-directory change before confirmation.
Preserve the complete task transcript and metadata.
Expose the same operation through the app-server/thread API.

This scenario can arise naturally whenever exploratory work becomes project-specific after the task has already started; it is not limited to incorrectly created tasks.

Related sidebar organization request: #33304 proposes nested local projects so child projects do not all become top-level sidebar entries. Together, the two capabilities would make it practical to refine both a task's project assignment and the project hierarchy as work evolves.