Repository navigation
Codex Desktop: add project management for registering projects and moving threads between projects #25498
Description
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 projectMove thread to projectChange thread projectList 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
Related
This is related to #13836 but narrower: project registration and moving existing threads between projects.
Activity
github-actions commentedon Jun 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
rodolphomartins commentedon Jun 5, 2026
I am upvoting this one specifically on allowing to add standalone chats to projects.
Audacity88 commentedon Jun 20, 2026
For the thread-moving/relinking part, there is already a workable skill-level solution here:
https://github.com/EyrieCommander/codex-skills/tree/master/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_threadcan reject the target with:But in the session where this happened, the agent had
create_thread,read_thread, andsend_message_to_thread, while nolist_projectstool 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_threadrequires opaque saved project IDs, agents need a supported way to discover or address them. Any of these would make the flow work:list_projectswhenever project-scopedcreate_threadis exposed;projectIdto accept the current project, current workspace, or an absolute workspace path;ruslankha21 commentedon Jun 22, 2026
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 commentedon Jun 25, 2026
Adding a macOS remote-project variant of the same agent-driven delegation failure.
Environment:
26.616.811500.142.0Darwin 25.5.0 arm64 armObserved failure in the broken session:
create_threadavailable and needed to call it withtarget: { type: "project", projectId, environment: { type: "local" } }.create_threadrequired the opaque savedprojectId.list_projectstool was exposed in that session.list_threadsonly exposed thread-levelhostIdandcwd; it did not include the savedprojectId,projectKind, or saved-project label.Contrasting current-session evidence:
codex_app.list_projectsis exposed.projectId,projectKind: "remote", label, path,hostId, andhostDisplayName.The smallest fix that would make this reliable is to always expose
list_projectswhenever project-scopedcreate_threadis exposed.Other workable fixes:
projectIdto accept the current project, current cwd, or an absolute saved-project path;projectId,projectKind, label, and host display metadata inlist_threads;create_threadrequires 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_threadwithout also exposing a supported project-discovery path such aslist_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 commentedon Jul 1, 2026
+1 on allowing
create_threadto create a thread in new project. Somehow I think this used to work for me0okay commentedon Jul 15, 2026
Additional Windows Desktop evidence from a real project-intake workflow:
list_projectsmay 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.cwdremains the parent/Inbox path and the thread is grouped there.The desired zero-click flow is:
thread.cwd == project pathbefore reporting success.Please provide a supported API/UI path for this, ideally one of:
project/registerorproject/createfor an existing local folder;create_threadaccepting a local folder path and registering/awaiting it atomically;thread/project/setto 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 commentedon Jul 15, 2026
I ran into the same limitation in a common "start broad, specialize later" workflow:
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:
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.
tsagi2045 commentedon Aug 8, 2026
I am seeing a closely related workflow problem on macOS.
When I try to move one existing chat from a local project such as Sandbox to another existing project such as AJAE-CHEOLGEO, Codex shows a confirmation dialog that effectively says:
The move cannot continue unless I accept that project-wide folder access change. This is broader than the action I intended: I only want to rebind the selected chat to the destination project and update that chat’s working directory.
Expected behavior:
The current workaround mixes otherwise unrelated codebases and expands file access for every chat in the source project. A first-class Move thread to project action, as proposed here, would address this.
pchesnais-oai commentedon Sep 10, 2026
Adding a macOS Codex Desktop case where changing both the project binding and working directory is necessary for code-review correctness.
Scenario:
Requested behavior:
Adding the destination folder to the source project is not an equivalent workaround: that broadens access for every task in the source project while still leaving the selected task's cwd and review source misleading.
Environment: Codex Desktop on macOS; observed September 2026. App version was not captured.
NaturalMatchaKing commentedon Oct 3, 2026
Please include tasks created by a dot in a saved Codex Cloud environment in this project-assignment request.
In my case, task creation and a second message to the same task both work. Desktop displays the task under a workspace group rather than the project where I expected to find it. The creation controls available to the assistant allow choosing the saved cloud environment, but do not expose a separate Desktop project choice.
Is there a supported way to assign or move this kind of task to a Desktop project while preserving its conversation and cloud working files? If grouping by environment or workspace is intentional, please document that relationship.
NaturalMatchaKing commentedon Oct 3, 2026
A further comparison on October 3, 2026: the owner reports that cloud chats they create manually appear under the selected Desktop project, while tasks created by dot from a saved cloud environment appear only in Recents or a workspace group. The dot-created tasks' intended cloud environment/repository association has been checked; that does not establish their Desktop project association.
The sidebar comparison is owner-reported, not independently verified from a screenshot. No shared cause with the separate read-versus-send problem is established.
Please provide a supported Desktop-project choice or association check for dot-created cloud tasks, and a way to assign/move them while preserving their conversation and working files. If different grouping is intentional, please explain it in the creation flow. Private names, identifiers, paths, and screenshots are omitted.
dean1012 commentedon Oct 6, 2026
Task/project association comparison in Codex Desktop 26.930.41038 on Windows, with ChatGPT Pro 100:
Requested behavior: every task can start projectless or in a chosen project, then move into, out of, or between projects through either the user or dot.
Related local-task report: #49646.
supplefrog commentedon Oct 15, 2026
On Windows Codex Desktop 26.1007.2314.0, experimental project/create succeeds and project/read/list confirm the existing-folder project, but Desktop’s saved-project list still omits it. No files were moved. The same Codex home and matching CLI/Desktop binaries were used.
Please provide a supported, idempotent operation to adopt an existing native project into Desktop’s sidebar, with verifiable thread membership. Durable-task placement also needs a documented host-aware route; sending that task ID to the local server returns ‘thread not loaded.’ Backend registration alone should not imply Desktop setup is complete.