Allow moving existing threads between projects

Open 💬 3 comments Opened Jun 16, 2026 by RickyFrost

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

Problem

Codex desktop supports working across projects and can hand off a thread between Local and Worktree within the same project. However, there does not appear to be a way to move a thread that was started under the wrong project into the correct one.

The current workaround is to open the old thread, ask for a handoff summary, start a new thread in the destination project, paste the summary, and archive the original. That fragments history, search results, and project organization.

Desired behavior

Add a "Move to project..." or "Reassign project..." action for existing threads.

Expected details

Available from the thread menu or command palette
Lets the user choose a destination project
Preserves the thread transcript, title, pin/archive state, and searchability
Clearly handles workspace state: either move only the conversation metadata or offer a safe handoff path when Git state is involved
Warns when a thread has project-specific files, worktree state, or sandbox permissions that will not transfer cleanly

Why this helps

It makes project organization more forgiving and keeps long-running Codex work discoverable in the right place without manual summarization or duplicate threads.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

#26872

Powered by Codex Action

creatornader · 1 month ago

One more concrete workflow belongs in this request: projectless to project.

I often start a task without choosing a project because I do not know what the project is yet. Once the idea takes shape, I want to create or select a folder and move the existing thread under it. Starting a replacement thread loses the reasoning and history that defined the project. This is a normal project lifecycle, not only recovery from choosing the wrong folder.

I checked the current main branch at 21db216. The open-source backend already seems to support most of the move:

ThreadSettingsUpdateParams accepts an optional cwd for subsequent turns.
The handler resolves that path, builds a new environment override, and submits Op::ThreadSettings.
The state extractor updates the persisted thread cwd from ThreadSettingsApplied, including a test for the changed workspace.

That suggests a fairly small desktop path: add "Move to project..." to the thread menu, send thread/settings/update with the destination path, wait for thread/settings/updated, then refresh the sidebar grouping.

The UI should block or warn when a turn is active, reevaluate trust and permissions for the destination, and explain what happens to worktree state or uncommitted changes. Projectless threads should be valid sources. If the experimental settings endpoint is not suitable for the production app, a narrow thread/project/move endpoint could wrap the same behavior.

pengusto · 9 days ago

I would also like a reliable alternative to drag-and-drop: add Move to project... to each thread context or overflow menu.

The destination picker could show:

recently used projects first
a searchable All projects list
the current project marked or omitted

This matters when moving a thread from far down the sidebar. Auto-scrolling during a long drag can make the visual drop position drift away from the cursor, so selecting the destination from a menu would be faster and easier to control. The same action should also be available from the command palette for keyboard use.