delegate_task: run the child in another project or worktree on the same environment

[niieani]

Problem

An orchestrating thread can't hand work to a nested child that runs somewhere other than its own checkout.

• delegate_task creates a proper child: it has a parent, wakes the parent on completion, and is hidden from the sidebar. But the child always inherits the parent's projectId, branch and worktreePath (makeSubagentChildThread in packages/provider-core/src/server/subagentProjection.ts spreads ...input.parentThread).
• t3_thread_launch can target any project and a new or existing worktree, but always creates a top-level thread (dispatchThreadCreate in apps/server/src/orchestration-v2/Orchestrator.ts writes parentThreadId: null). There's no wake-up, and the thread lands in the sidebar.

Our use case: an orchestrator thread in one repo (a notes vault) coordinates implementation work in other repos on the same machine. Each piece of work runs in its own worktree of the target repo and is reviewed before merging. Today every such child becomes a top-level thread, and the orchestrator has to poll for completion.

#16719 adds target.projectId for linked environments, but explicitly refuses a local target.projectId that names another project.

Proposal

Add optional projectId and workspaceStrategy to delegate_task, reusing OrchestrationV2ThreadLaunchWorkspaceStrategy:

• packages/contracts/src/orchestratorMcp.ts: add both fields to the input.
• packages/contracts/src/orchestrationV2.ts: add them to the delegated_task.request command.
• OrchestratorMcpService.delegateTask: resolve the project with resolveProjectTarget and assertLiveCallerForOtherProject.
• dispatchDelegatedTaskRequest and makeSubagentChildThread: override projectId, branch and worktreePath instead of copying the parent's.
• Reuse ThreadLaunchService's workspace preparation, and defer the agent start until the worktree is ready, as launches already do.
• Drop the local refusal from feat(server): delegate_task to a linked environment #16719 (or coordinate with it), so local and linked targets behave the same.

The child keeps everything that makes it a child: parent, completion wake-up, hidden from the sidebar, cancellation with the parent task.

Related: #17401 (sidebar filter by who started a thread) covers the other half of this workflow: the orchestrator's top-level launches crowd the sidebar today.

Happy to send a PR if the direction is agreeable.

[Goshujinsama]

Adding our use case and implementation notes here, per Julius's note on #18373 (closed as a duplicate of this one).

Use case. One logical change often spans an application repo, the repo that builds its runtime image, and an infrastructure repo (Ansible here) that deploys it, each with its own branch and PR. Our orchestrator thread lives in a non-git workspace above those repos and hands each piece to a child in a worktree of the right repo. Without this, those children are t3_thread_launch threads with no parent, so the orchestrator never hears they finished and someone has to poll. #17103, #9435 and #13390 look like the same layout.

Implementation notes. We implemented this proposal in our fork today, so these come from building it, not from long use yet:

• Reuse the launch preparation rather than duplicating it. The child is created in the target project, its first message uses defer_start with the strategy, and the existing ThreadLaunchService preparation (worktree, branch naming, setup script, release) runs it. We factored that into one function shared by launch, retryPreparation and delegation.
• Preparation failure. If preparation fails, the run fails, and the existing completion path delivers that to the parent as a failed task carrying the git or setup error. The completion code itself needed no change.
• existing_worktree validation. The check that the worktree belongs to the target project is shared with t3_thread_launch.
• Defaults. Without either field the child inherits as today. With projectId alone, it runs at that project's root.
• Clients. Web and mobile already read the child's own projectId for sub-agent rows and navigate by thread id, so they needed no change in our fork.
• Edges we noticed:
  • In Scratch, a delegated child shares the Scratch root, because t3_thread_launch claims a managed folder there and delegation doesn't.
  • Launch refuses a project that is still cloning; delegation should do the same.
  • mode: "wait" now spends part of its budget on preparation (fetch, worktree, setup script).
  • If the server dies between the request and scheduling preparation, the child sits in preparing until restart recovery interrupts it, which then wakes the parent as interrupted. t3_thread_launch has the same gap.

This fits alongside #16719: target.environmentId + projectId for a linked environment, and this proposal for another project or worktree on the same environment.

[pedrozimmermannsoares]

Adding a visibility angle from daily use: one orchestrator thread launches 5–10 workers with t3_thread_launch, because each needs its own worktree and PR.

The orchestrator's Lineage panel only lists subagents and forks, so none of its launched workers show up there. To answer "which threads did this orchestrator start, and which are still running?" I search the sidebar by a title convention.

The data is already recorded. On 0.0.46-nightly.20261013.3066, the first user message of a launched thread carries senderThreadId set to the launching thread (createdBy: agent, creationSource: mcp).

This proposal would solve it for workers that can become real children. For workers that should stay top-level and interactive, a smaller step could list threads whose first message came from this thread in its Lineage, e.g. a "Launched" group next to the subagent rows. Parentage, wake-up and sidebar placement would stay unchanged.

[artile]

+1. Without this, the sidebar stops working as an inbox.

I use T3 Code as an inbox: each row is a conversation that may need me. The orchestrator thread is the one I talk to. When it needs a worker in its own worktree, the only option today is t3_thread_launch. Each worker then becomes a top-level row next to my real threads.

What this causes in daily use:

• One orchestrator run adds 5–10 rows. After a few runs, the rows I must answer are hidden between worker rows.
• A worker row looks the same as a thread I started. I cannot see which orchestrator owns it, or if it is done and safe to ignore.
• The orchestrator does not get a wake-up when a launched worker finishes, so it polls, or I check each worker by hand.
• To clean up, I must find and archive each worker row one by one.

delegate_task already does the right thing for the UI: the child is hidden from the sidebar, shows in Lineage, and wakes the parent. The only gap is the workspace. So workers that need their own worktree must be launched as top-level threads, and their output is mixed with my threads.

Adding projectId and workspaceStrategy to delegate_task, as proposed above, closes the gap with no new UI concept. t3_thread_launch stays for threads that I really want as separate top-level conversations.

@juliusmarminge @t3dotgg I agree that launched threads and delegated tasks are different (from #15031). This proposal keeps that split. It only lets a delegated child run in its own worktree. Could you say if this direction is OK? I can help with the implementation.