[Feature]: Rehome an existing thread to another project

[LunarRed]

Problem

I sometimes start a substantial fix under the wrong T3 Code project. Once the conversation has accumulated useful investigation, decisions, and context, there is no way to move it to the correct project. The current workaround is to start a new thread and manually summarize or copy the previous conversation.

Desired behavior

From a thread's context menu, select:

Move to project… → <target project>

The thread should then:

• appear under the target project
• preserve its title and conversation history
• use the target project's workspace for future turns
• continue working without requiring manual conversation transfer

Proposed initial scope

• projects within the same T3 environment only
• idle threads only
• no cross-server transfer
• clear confirmation showing the source and target workspace paths
• filesystem changes are not automatically copied between unrelated repositories

Open implementation questions

A project determines the agent working directory, so this is more than a sidebar metadata change:

• Should the existing provider session be resumed in the new directory, or should T3 Code start a fresh provider session using the preserved history?
• Should checkpoint history be reset when the projects use different Git repositories?
• What should happen to an associated worktree, branch, terminals, and pending approvals?
• Should moving be restricted when the source contains uncommitted changes?

My preference is to preserve the visible T3 conversation while safely starting future work in the target project's workspace, even if that requires resetting provider/checkpoint state.

I’m willing to implement this after the desired semantics are confirmed.

[PrivateVictories-Main]

Adding a use case, and a slightly broader angle on why this matters.

I'm a longtime Codex user and a big fan, and what I love most about it is that projects never get in the way. I start a chat, and when the conversation turns into real work, I point the agent at where it lives: an existing repo, a new one, or sometimes two at once. Whether the chat started "in" a project basically stops mattering.

T3 is now where I run Codex and Claude side by side, and most of this already works here. I start almost everything in a No project chat (questions, research, planning), and the agent handles the rest well by path. It works out whether the project exists, whether it needs to create one, and whether the task needs a project at all.

What doesn't follow is T3's side. The thread stays under No project, and the diff panel and checkpoints keep tracking the scratch folder instead of the repo that's actually changing. So the one place where "which project is this chat in?" still matters is the one thing I can't update after the fact.

What would close the gap for me:

1. Move to project… as proposed above (idle threads, same environment, confirmation showing both paths).
2. The same move available to the agent through the orchestrator MCP tools, behind a setting or a per-move approval, so a chat can re-home itself once it's clear which project the work belongs to. Today t3_thread_update explicitly excludes workspace changes, while t3_worktree_handoff can already re-point a thread's workspace within a project.

Choosing a project up front would still be useful, especially for anyone who relies on the project folder as a permission boundary. The idea is that it becomes optional, and the project follows the work.

A lot of people come to T3 from Codex or Claude Code, so I think matching that flow would make the switch feel familiar right away. Totally understand if it doesn't fit the roadmap; I just wanted to share the use case.

Work that spans several repos in one thread is the other half of this, tracked in #7041.

[thomasbek3]

Adding a variant of this request: let the agent start the move itself.

In Claude Code's desktop app, a chat can start with no project folder. When the work turns out to belong to an existing project, the agent calls a tool to move the session there. The user sees an approval prompt with the exact folder path (Allow once / Deny), and the chat keeps going in the new folder with its history intact.

T3 Code already has most of the pieces: "No project" chats, and t3_worktree_handoff, which re-points a thread at a new folder and queues a continuation prompt. A t3_thread_rehome (or similar) tool that targets another project, with a user approval step, would cover this request and make "No project" chats much more useful.

[hugotomita1201]

+1, with daily use behind it. I use this flow in my own agent app: every chat starts with no folder, and before doing any work the agent reads the request and moves itself into the right project. Two details made it work well:

• When the agent can't tell which project fits, it asks me instead of guessing.
• The same move can create a fresh worktree on a branch named for the task, so the main checkout is never touched.

Most of my chats no longer need a folder picked first. If the direction is approved, I'd be glad to help build or test it.

[soumen02]

This is a high-priority workflow gap for me, including for completed chats that mainly need organizing.

Concrete use case: I started a standalone / No project chat to research and submit a T3 Code feature request. After it finished, I created a project to keep related product requests together and wanted to move the original chat into it. Attaching the old thread as reference to a new chat lets the agent read its history, but the original still lives outside the project. Starting another conversation fragments the record and leaves the original in the wrong place.

Requested behavior: Move to project… on an existing thread, including No project → an existing project and one project → another. Preserve the original conversation, title, and thread links, make it appear in the destination project, and clearly show the workspace used for future turns. An idle/completed-thread, same-environment version would already be very useful.

Please account for any files generated in the scratch workspace: make their location and fate clear, preserve access to existing artifacts, and avoid silently discarding or overwriting them. Worktree-bound threads can have separate restrictions if necessary.

This matters because the right project often becomes clear only after a conversation starts. Organizing that conversation should not require copying its history, maintaining a second chat, or editing T3's database manually.

Comparison checked: Official OpenAI documentation confirms that Codex supports handing an existing chat between Local and Worktree while moving the chat and code safely: https://learn.chatgpt.com/docs/environments/git-worktrees. That is a related workspace-move capability; I could not verify arbitrary cross-project reassignment in Codex's current official documentation, so I am not claiming exact feature parity here.

[alizss]

Same, I normally start a thread alone first without a project, and then it suddenly develops into a real project and I don't want to lose the context or want to work in mutliple threads and suddently I am switching projects from no projects constantly to manage.

Can we add that feature by simply moving existing No project thread -> to spesifc project.