An agent can already create a worktree. It has a shell, and git worktree add works fine. It can even work inside it by using absolute paths everywhere. But everything T3 Code keys off the thread's binding still points at the original checkout: the session cwd, terminals, checkpoints and the diff view, git status, and worktree cleanup when the thread is deleted.
There's no way to fix that from the shell. The binding is a row in T3 Code's own orchestration state, updated by thread.meta.update, and no command the agent can run touches it. The only thing that talks to the agent on T3 Code's behalf is the t3-code MCP server, and it only exposes the preview tools. So the one step that matters, re-pointing the thread and restarting the session inside the worktree, is unreachable by definition, no matter what the agent does in the terminal.
That's the piece automation needs. For example, we have a workflow that does task intake in the chat (we pull tickets from our tracker), and a skill drives setup from there: name the branch, create the worktree, carry on inside it. Every step of that works today except the last one.
Proposal: add worktree tools to the MCP server. A worktree_handoff that creates a worktree (base ref, origin, and path as options) and re-points the calling thread at it, and a worktree_status so the agent can check whether it's already attached before trying. The machinery already exists server-side (worktree creation, thread.meta.update, session restart with resume on cwd change); everything downstream, including cleanup on thread delete, behaves correctly once worktreePath is set.
I have this working and tested. PR incoming; I kept it as focused and light-touch as possible.
An agent can already create a worktree. It has a shell, and
git worktree addworks fine. It can even work inside it by using absolute paths everywhere. But everything T3 Code keys off the thread's binding still points at the original checkout: the session cwd, terminals, checkpoints and the diff view, git status, and worktree cleanup when the thread is deleted.There's no way to fix that from the shell. The binding is a row in T3 Code's own orchestration state, updated by
thread.meta.update, and no command the agent can run touches it. The only thing that talks to the agent on T3 Code's behalf is thet3-codeMCP server, and it only exposes the preview tools. So the one step that matters, re-pointing the thread and restarting the session inside the worktree, is unreachable by definition, no matter what the agent does in the terminal.That's the piece automation needs. For example, we have a workflow that does task intake in the chat (we pull tickets from our tracker), and a skill drives setup from there: name the branch, create the worktree, carry on inside it. Every step of that works today except the last one.
Proposal: add worktree tools to the MCP server. A
worktree_handoffthat creates a worktree (base ref, origin, and path as options) and re-points the calling thread at it, and aworktree_statusso the agent can check whether it's already attached before trying. The machinery already exists server-side (worktree creation,thread.meta.update, session restart with resume on cwd change); everything downstream, including cleanup on thread delete, behaves correctly onceworktreePathis set.I have this working and tested. PR incoming; I kept it as focused and light-touch as possible.