Move a thread into another project

[jonathanperis]

A chat often starts under No project and then turns into work that belongs in a real project. Today that chat stays where it started. The same gap shows up the other way: a thread in one project cannot be filed under another.

The proposed scope is one operation, reached from the CLI, MCP, and the app:

• t3 thread move <thread-id> <project> and t3_thread_update with move_project
• Move to project… in the thread context menu and the command palette

An idle thread can move. A running turn has to stop first. A subagent stays with its parent, and a thread that still has a subagent cannot move. When the thread has its own checkout, the move keeps that checkout and the next turn still runs there. When it does not, the provider session ends and the next message starts in the destination project. The branch and any linked pull requests stay.

The implementation is in #23706. This discussion is the request for direction and scope. It is not an approval.

[joshka]

I ran into this today. I'd started a thread under No project, and it turned out to be about my home infra, so I wanted to move it into my project for that (similar to the fleet project Theo has mentioned). I searched, found #23706, and suggested a discussion to get the direction agreed.

I'd like to see this land, especially the Move to project… item in the context menu and the command palette. That's where I notice a thread is in the wrong place. Thanks @jonathanperis for adding the UI entry points so quickly.

🤖 Claude Opus 5.5

[jonathanperis]

@joshka That is the case the menu is aimed at. A thread that started under No project can be moved into the home-infra project from the thread menu or the command palette. A running turn has to finish first. If the thread already has its own checkout, that checkout stays where it is.

The direction still needs a maintainer to approve it here before the pull request is eligible for review.

[joshka]

yup! just echoing that what you implemented is what I really want so that there's more than one person asking for this.

[jonathanperis]

Thanks. That confirmation is on the discussion for a maintainer to see. The pull request still needs their approval of the direction before it is eligible for review.

[Artic0din]

+1, this matches how I use T3 Code.

I often start a chat under No project to research, plan or troubleshoot something before I know where it belongs. Partway through, it turns into real work for an existing repo, or into something that should become a new project. Right now the useful context stays stuck in the No project thread, and my only option is to start a fresh thread in the right project and summarise the old one by hand.

The scope proposed here would cover that for me: move an idle thread into an existing project from the thread menu or command palette. Being able to create the destination project in that same step would also help, since the project often does not exist yet when the chat starts.

[Dunky13]

+1, this matches a workflow I run into: I start under No project with a general technical question, and the conversation gradually turns into planning and building an application. By the time it clearly belongs in a project, there may already be source files in the scratch workspace.

I'd like to explicitly assign that existing thread to a project while keeping the conversation history and existing work. Assigning a thread that currently has no project would already cover my main use case.

Move to project… in the thread menu or command palette would fit well. The important detail for this workflow is that assignment works after files have been created in the scratch workspace.

[chekdotdev]

+1, with a case where the agent is asked to do the move, not me.

A chat under No project had been researching a homepage idea. Partway through, I asked the agent to "add our theme as a T3 project and see if you can move this thread there." In the same turn it registered the theme folder with t3_project_create. Then it couldn't find any tool that would put the thread in that project:

• t3_thread_update only renames, regenerates the title, and links or unlinks PRs
• t3_worktree_handoff moves the thread into a new worktree of its current project
• t3_thread_launch and t3_thread_fork start a new thread rather than re-filing this one

So it offered to start a fresh thread in the new project with a summary, which is the same hand-written summary @Artic0din describes.

Two things from this case that might help settle the scope:

1. Let the agent ask for the move during its own turn. The proposal says a running turn has to stop first, which makes sense. An agent calling t3_thread_update with move_project is always mid-turn, though. t3_thread_organize already handles this for settle with settlesWhenTurnEnds: the request is recorded now and applied when the turn completes. If the move worked the same way, "create the project, then move this thread into it" could finish in one request. It would also cover what @Artic0din asked for, creating the destination project in the same step.
2. Files in the scratch folder. The scratch folder had screenshots and an HTML file I wanted to keep. I agree with @Dunky13 that assigning the thread shouldn't lose them. Even just a note in the moved thread with the old scratch path would be enough for me.

[jonathanperis]

Thanks @joshka, @Artic0din, @Dunky13 and @chekdotdev for the detailed cases. I've folded all three suggestions into #23706, each as its own commit:

• Moving mid-turn (@chekdotdev). t3_thread_update with move_project no longer fails as busy. It checks the move right away, returns movesWhenTurnEnds: true, and applies it when the turn completes, the same way settlesWhenTurnEnds works. A failed or stopped turn drops the queued move. So "create the project, then move this thread into it" now works in one request.
• Scratch folder files (@Dunky13, @chekdotdev). Moving a No project chat now really moves it. The session ends, the next turn runs in the destination project, and nothing in the scratch folder is deleted. The thread gets a note with the old scratch path, and the CLI and MCP results return it as scratchFolder.
• Creating the destination (@Artic0din). Move to project… now ends with New project…, which creates the project and moves the thread into it in one step.

Testing turned up one more case: an ACP agent that supports neither session/load nor session/resume failed on its next turn after a move. That turned out to be an existing bug that also hits after worktree changes and restarts. The existing fresh-session fallback now applies, so the next turn starts clean in the new folder with the thread's history carried over, including when the agent's new session reuses the stored id. The CLI's worktree refusal also now names the --keep-worktree flag.

I checked every scenario end to end with Playwright against a throwaway server, and all eleven passed. That covers the menu, the palette, scratch chats, New project…, the mid-turn move, keeping a real worktree, and agents without session resume. Here's the run (with sound):

pr-23706-move-to-project-narrated.mp4

The direction still needs a maintainer's approval here before the PR is eligible for review.

[jonathanperis]

@t3dotgg @juliusmarminge #23706 was closed because this discussion doesn't have maintainer approval yet, which is fair (cc @UtkarshUsername). Could one of you give a yes or no on the direction and scope here?

The proposal is a single operation to move an existing thread into another project. It's available as t3 thread move in the CLI, as move_project on t3_thread_update for agents, and as Move to project… in the thread menu and command palette. Moving a running thread waits until its turn ends, a thread with subagents can't move, and a thread that has its own checkout keeps it. Four people above have described needing this, mostly to move a chat out of No project.

If the scope is too broad, I'm happy to narrow it. For example, the first step could be just moving a thread out of No project into an existing project, from the UI only. Once there's an approval here, I'll link it on the PR and ask for it to be reopened.

[jamesalmeida]

Yeah this would be helpful. I ran into this issue today.