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.

[qveys]

+1, with a bulk case: an orchestrator agent filing the threads it launched, not its own.

I ran an overnight orchestration. One coordinator thread launched about 30 implementation and review threads with t3_thread_launch, and most of them landed under No project. They all belong to one repository project. By morning they were all idle, and I asked the coordinator to file them there. It couldn't, for the same reasons @chekdotdev listed, and ended up handing me the list.

I read #23706 to check it would cover this. It mostly does: move_project takes a threadId, so an agent can move another idle thread right away.

One gap, though. One of my review threads delegated to two subagents, and all three sit under No project. With #23706 none of them can ever move. The parent is refused while a subagent still belongs to the project, archived ones included. Each subagent is refused with "Move its parent thread instead". Could the move take the parent's subagents along with it, rather than refusing?

On narrowing the scope: moving an idle thread out of No project into an existing project would cover my case, as long as it is reachable from MCP and not only from the UI.

[lhagenmayer]

Additional use case: move an existing thread from Project A to an existing Project B, not just No project → project. Long-lived planning, operations or implementation threads can be filed under the wrong repository, and recreating them or carrying over a summary is not an equivalent move.

The key requirement is lossless reassignment:

• Preserve the thread ID, existing links/mentions, history, run/checkpoint records, lineage and attachment/artifact references.
• Preserve existing checkout/worktree contents, branch and linked PR identities. Filing a conversation under a different project must not silently move/delete files or relabel a PR as belonging to another repository.
• Make the next turn's effective working directory explicit. If changing it requires a provider-session restart, explain that before applying the move and preserve the conversation through the supported continuation path.
• For a running thread, defer to a safe turn boundary rather than interrupting it. Reject unsupported parent/child cases with a clear explanation.
• Expose the same operation from the thread menu and MCP/CLI, with a receipt that reports source/destination projects and whether the checkout or provider session changed.

Useful acceptance checks: the same thread ID appears exactly once in the destination, its previous links still resolve, history/WIP remain accessible, and no new run is started merely by organizing it.

This supports the direction of this discussion; it is not a request to bypass maintainer approval for #23706. A purely visual subgroup inside a project is a separate need from changing the actual project association.

Prepared with Codex; examples are anonymized.

[lhagenmayer]

Following up on my project-to-project use case and the scope decision requested when #28340 was closed: could maintainers explicitly approve or decline this first implementation scope before work starts?

Proposed first scope: move an idle, standalone thread between existing projects in the same environment, preserving its execution context.

• Keep the thread ID, conversation, links, attachments, run/checkpoint history, branch, linked PR identities, and existing files.
• Keep the effective working directory and worktree binding. Filing the thread must not silently change its provider session, permissions, project scripts, scheduled-task execution context, or the repository used by diffs and checkpoints.
• Reject a move while a turn, queued message, approval, question, or dependent child workflow makes it unsafe. Check eligibility again when applying the operation.
• Show the destination project and the actual working directory before confirmation. Expose one server-owned operation through the thread menu/command palette on web, desktop and mobile, and through MCP/CLI.
• Leave changing the working directory, moving files, cross-environment transfer, and automatic mid-turn moves outside this first scope.

The acceptance proof would cover persistence after restart, unchanged links/history and execution context, refusal of unsafe moves, and confirmation that organizing a thread starts no new agent run. It should also catch destination-project scripts accidentally running in the retained source workspace.

This is specifically a request to agree on the preserved-workspace semantics, not an implementation PR or an assumption that the existing discussion is approval. If accepted, would you prefer extending one of the existing closed implementations or a new focused PR?

Prepared with Codex (desktop harness) on my behalf.

[vilmerfrost]

+1 from a real case on 0.1.7-nightly.20261101.4035.

A long thread started as a question about one client repo, then turned into work on our agent setup. The agent could not move it: t3_thread_update says workspace and branch cannot change, and t3_thread_transfer forks into the same project. The only way out was a new thread in the right project with a hand-written summary, so the new agent loses the full context unless it reads the old thread.

The t3_thread_update part of this proposal matters to me as much as the menu item, so an agent can do it when asked. Stopping a running turn first is fine.

Written with Claude Opus 5.5 in T3 Code.

[leonhoulier]

Note

🤖 Claude Opus 5.5 responding on behalf of leonhoulier

+1 for the narrow first step already offered in this thread: move an idle No project thread into a project that already exists. Turn into project (#26767) covers the case where the scratch folder should become the project. It does not cover an existing destination: thread.project.adopt-folder rejects any project whose root differs from the thread's folder.

My case: a long-running No project conversation in which the agent worked, by path, in an existing Git repository. That repository now has its own T3 project, but the conversation, with its history, attachments and links, still sits under No project. Starting over with a summary loses that record.

A concrete scope, in case it helps the decision (#6857 and #28287 ask for the same thing):

• Eligible: a top-level No project thread with no running turn, queued message or pending approval, moving to an existing non-scratch project in the same environment. Project-to-project moves and threads with subagents can wait.
• Kept: thread ID, title, messages, attachments, links and mentions, linked PRs, run history, and bound scheduled tasks (as in feat: turn a No project thread into a project #26767).
• Future turns: run in the destination project root, not in the scratch folder, with no branch or worktree carried over. Diffs and checkpoints then follow the destination repository. The confirmation names both folders. The restarted provider session must carry the conversation forward.
• Scratch folder: left in place, nothing copied or deleted. The thread keeps a visible note of the old path so earlier files stay reachable, and a move back to No project could reuse that folder.
• Surfaces: Move to project… in the thread menu and command palette on web, desktop and mobile. The same service method is exposed through MCP, so an agent can make the move when asked.

Would maintainers accept this direction and scope?

[N4M3Z]

I opened #29423 for a /cd command that'd move the thread (and its project changes) to another folder. Claude etc. stores transcripts per folder, so a move that changes the folder would have to carry the session over. I'll happily work on it, but opening up a discussion first.

[Fuucodi0X]

+1, with the reverse direction: moving a thread out of a project into No project.

I asked a general question about my desktop setup (whether a computer-use driver is available on my Linux distro's current release) while I happened to be in a repository project. The conversation has nothing to do with that repository, so I wanted to move it under No project. The agent couldn't do it: t3_thread_update only renames or regenerates the title, t3_thread_transfer forks into a thread with the same setup, and t3_thread_organize has no move action. So the thread stays filed under a project it doesn't belong to.

If the first step is narrowed to "No project → existing project," please consider including the reverse too, or at least keeping the design open for it:

• Destination: a new scratch folder for the thread, created the same way a new No project chat gets one.
• Source repository: left untouched. Nothing is copied into the scratch folder, and any worktree or branch stays with the project.
• Next turn: runs in the scratch folder, with the conversation history carried over.

Having it in the thread menu and through t3_thread_update with move_project would cover my case.

Drafted with Claude Opus 5.5 in T3 Code.

[demarant]

+1 — hit the same gap on 0.1.6 (2026-11-05), in the agent-initiated form:

A thread that started under a scratch project grew into a standalone repo (a claim-extraction pipeline, 2 commits). The user asked to file the thread under a new project. The agent checked the tool catalog and found no way: t3_thread_update only renames / regenerates titles (its description says "Workspace and branch cannot change here"), t3_thread_organize only has pin/snooze/settle/archive, and t3_thread_transfer only forks/merges within the same project.

The workaround ended up being: t3_project_create for the new project bound to the repo, then t3_thread_launch of a fresh thread in it with a handoff message telling the agent to re-read the old thread via t3_thread_read and page through with nextPosition. It works, but the new thread loses its thread id, links, and PR association, and costs a full re-ingest of ~217 items of history.

For agent-driven flows the move_project action on t3_thread_update is the part that matters most (as @chekdotdev and @vilmerfrost noted): with it, "create the project, then move this thread into it" finishes in one request, and the deferred-apply semantics proposed for mid-turn moves (movesWhenTurnEnds) make it safe to call from inside a turn.

The implementation in #23706 (CLI t3 thread move, MCP move_project, Move to project… in the thread menu and command palette, worktree/subagent/mid-turn guards, threadProjectMove capability flag) covers this case as-is. Happy to test once it lands.

Written with Qwen 3.8 in T3 Code on behalf of @demarant.

[giri256]

Note

Written by Claude Opus 5.5 in T3 Code, on behalf of giri256.

Could a maintainer give a yes or no on this narrower scope? It's implemented in #32163, which has no approval yet and says so.

Scope: one agent tool, t3_thread_move({ path, continuationPrompt? }). The user asks the agent to move the thread to a folder. There's no menu item or CLI command.

The two open questions from #28287:

• Grouping or working directory? Working directory. The thread lands in the project rooted at that folder, registering one if needed, and the next turn runs there. The branch and worktree are cleared, and files stay where they are.
• What about active runs? The move waits until the thread is idle. A failed or stopped turn drops it. Moving during the agent's own tool call failed the run with Workspace changed., so it can't apply immediately.

What I saw on real Claude Haiku turns: a thread moved to another folder and back. It reported the right pwd, read a file in the new folder and remembered a code word from its first message. Claude needs no transcript copying on CLI 2.1.316, which also answers the concern in #29423.

Not covered: other providers are untested, evals haven't been run, and diffs and rollback of turns from before a move weren't tried. A server restart during the turn drops a pending move. The PR has the details.

If you'd take this with changes, or want it narrower, tell me what to change and I'll update the PR. A no is useful too.

[binjamshid]

Could a maintainer give a yes or no on this scope? Here it is in one place, with how it answers the two open questions from #28287 and Theo's note on #26767.

Scope. Move an idle, top-level thread to an existing project in the same environment. Its next turn runs in that project's folder.

• Grouping or working directory? Working directory. The cwd moves with the thread, so the conversation and the folder the next turn runs in always agree. This is not a relabel, which is the "history will be wrong" problem Theo raised on feat: turn a No project thread into a project #26767.
• Active runs? A running thread moves only after it stops (from the app), or when its turn ends (when the agent moves itself, as feat(server): agents can move their thread to another folder #32163 does).

What it builds on.

• feat(server): agents can move their thread to another folder #32163's server-only thread.project.move command, unchanged in shape. It detaches the provider session, clears branch and worktree, and moves bound scheduled tasks.
• fix(server): checkpoints stay in their own worktree after a thread moves #30972 (per-workspace checkpoint scopes). Without it, diffs of turns before a cross-repository move resolve against the wrong repository, so it is a prerequisite.

Refused, before anything changes. Same project, archived or deleted thread, unfinished work, subagents, side chats and delegated threads, an open guest link, a destination that disables the thread's provider, and threads with their own worktree (clearing one would orphan it).

Kept. Thread id, history, attachments, linked PRs, pin and snooze state, and scheduled tasks. Files stay where they are.

Proposed follow-up, only if the above is a yes. A Move to project item in the web and mobile thread menus that calls the same command, with no new server path.

Working version. All of the above, on top of #32163 and #30972, is on my fork: binjamshid/t3code@feat/thread-move-project (diff against main). The menu is one commit, c924284802, so it can be split out or dropped. No PR is open; I'll open one only after a yes here.

[N4M3Z]

I opened #33342 for the composer side of this: /cd <path> and /no, from #29423.

It moves the working directory, not just the grouping. The next turn runs in the new folder, and earlier turns keep their links and diffs in the folder they ran in. It covers No project to a project, project to project, and back to No project. The PR has recordings, hopefully it doesn't just get closed.

For the agent side, see #32163.

[sprintthunder-dotcom]

Written by Claude Opus 5.5 on behalf of the user.

+1 for project to project, on 0.1.9-nightly.20261110.4491 (macOS).

My case: a session starts in one project, and by the end the work clearly belongs in a different existing project. I want to move it there and keep the conversation and context.

Today the only workaround is to have the agent write a handoff file and start a new thread in the destination project, which loses the real history and the provider session.

The narrow scope already proposed here would cover it: move an idle top-level thread to an existing project in the same environment, with its next turn running in that project's folder.