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.

[josh-andrews-dev]

+1 - both the ability to start threads in other environments plus the ability to filter the side bar based on who created the thread would be super helpful.

[kkolodziej7]

Note

Drafted by Claude Opus 5.5 (a coordinating agent running in T3 Code) and posted from the account owner's account with their consent.

+1, with a use case from daily use on 0.1.2 stable.

Layout. A coordinator thread lives in a docs-only repo. For each issue it starts a lead thread. The lead starts engineers (recon, build, verify) in a worktree of the product repo, which is a different T3 project. Each round is a fresh thread on the same checkout, and the verifier runs on a different provider than the builder. Every worker is therefore a t3_thread_launch thread with no parent.

What we run instead. A small local service beside T3:

• reads the shell snapshot and per-thread details to detect when each launched run ends;
• queues one message to the launcher per terminal run, with retry and dedup across restarts;
• moves those watches to a successor when a coordinator thread is replaced.

It works, but it re-implements what delegate_task already does for children. Its polling also puts a constant read load on the server, and we feel that when T3 is slow.

What this proposal (or the opt-in launch wake we proposed in #15148) would let us delete. Most of that service, provided that:

• the parent is also woken when worktree preparation fails, and when a run ends without a final message;
• pending child wakes can be moved to a successor thread when the parent hands off. Today native child wakes stay with the thread that delegated them, so a coordinator must collect every result before it hands off.

[seth-dixon]

Written with Claude Opus 5.5 in T3 Code (manually checked and posted).

+1, with one more use case.

When a subagent's work fails review, I want a second subagent to fix it. For that I need three things:

• the second subagent works in the same worktree and branch as the first (the code it has to fix only exists there)
• it can only write inside that worktree, with no network (like codex exec --sandbox workspace-write, or claude --settings '{"sandbox":{"enabled":true}}')
• it shows up in the thread like any other subagent, so I can watch it and stop it

Today I can't get all three. isolation: "worktree" always makes a fresh checkout from the parent's HEAD, and the first subagent's branch is already ahead of that. So the only way I've found is a subagent whose one job is to run codex exec -C <worktree> in a shell and wait for it. That works, but the actual work happens out of sight behind a wrapper.

What would fix it:

• an existing_worktree option on delegate_task (path and branch), like the one t3_thread_launch already has.
• a sandbox setting for subagents, so one can be held to its worktree the way workspace-write holds codex exec.

With both, I could drop the wrapper entirely.

[marcfargas]

Returning to the original cross-project request: could delegate_task select another registered project on the same environment, retaining its parent relationship, completion wake-up and cancellation?

This looks like a smaller, natural precursor to #16719. @juliusmarminge, the review there led to explicitly rejecting local project selection because it would otherwise be silently ignored. Was that simply keeping the PR scoped, or is there a reason to exclude this capability?

Could we agree on this increment independently of the sandbox and other additions above? Asking here because this is the existing discussion for that scope.

I’d be happy to work on a PR for this scoped increment if the direction is approved.

[mosobande]

Another case for workspaceStrategy on delegate_task, inside a single project.

The parent thread's checkout was on a long-running branch belonging to other work, and the children had to start from the remote default branch. With isolation: "worktree", each child's checkout started from the parent's current commit, on a generated branch named from its task (for example feat/checked-state-charts). In one session that meant:

• Every brief had to tell the child to fetch and create its own branch from the remote default before editing.
• The generated branches went unused and stayed behind after their tasks; three were left in that session. The cleanup side looks like [Bug]: Worktree cleanup never removes a worktree whose branch was renamed, switched, or detached #17813.
• One child whose brief named a branch matching the generated name found it already taken and stopped, which cost a relaunch.

The worktree{baseRef, branch, startFromOrigin} strategy that t3_thread_launch already has would fix all three: baseRef: "origin/main" (or startFromOrigin) and a branch name the caller chooses.

Seen on 0.1.6-nightly.20261030.3904, macOS (arm64).

[Thalrion]

Another use case for this proposal: a coordinator in a non-Git workspace needs to delegate a review to a separate registered Git project at an exact commit.

In the inspected source, a local delegate_task rejects a different target.projectId, while isolation: "worktree" resolves the base from the parent checkout and cannot resolve HEAD for a non-Git parent. This is a source inspection, not a new runtime reproduction.

Could an explicit target-project and commit binding support this case, with isolated worktrees and preserved parent/child completion semantics? Repository/commit mismatches should be rejected and retries should remain idempotent.

[Abdullah97128]

+1 for selecting another registered project on the same environment, with one more use case and a detail from testing.

Use case. I want both behaviours, chosen per thread. Threads started from outside, such as review threads from t3 thread start, should stay top-level. Other times a session should start a nested child, but the child has to actually run in another project, because that project's folder decides which MCP servers and rules it gets. Running it in the parent's project doesn't work, and t3_thread_launch loses the parent.

What I tested on 0.1.5 (the same check is in the 0.1.6 bundle):

• Local delegate_task with another target.projectId is refused: "A local task runs in this thread's project."
• t3_thread_launch accepts delegatedFrom, but it's only stored when the caller has a linkOrigin. From a thread started with t3 thread start, launching into another project, it was dropped. From a thread started over an environment link, it was kept, in both the same project and another one.
• parentThreadId stays null in every case above, so it can't be used to check whether a launched thread is nested.

Reading the client bundle (not seen in the UI), a stored delegatedFrom hides the thread from the sidebar and adds a row on the child to open its parent. The parent's row comes from a remote delegate_task record, so I wouldn't expect a bare launch to list the child on the parent.

So the display side already works across projects for linked environments, and the same-machine case is what's missing. The target.projectId proposal here would cover it, and keeps the completion wake-up and cancellation that a delegatedFrom launch wouldn't have.

[sfls1397]

Agent-authored engineering report, posted at the account owner’s request. Concrete same-environment provisioning blocker on installed T3 Code 0.1.7:

A coordinator lives in a non-Git workspace above multiple registered Git repository projects. A shared/read-only delegate starts correctly and has the expected parentThreadId. Implementation delegates need isolated worktrees in an explicitly selected registered repository, while remaining children of that same original job.

Observed supported-tool outcomes:

• delegate_task(isolation:"worktree", target:{projectId:""}) rejects the local target.projectId override. Explicitly naming the current environmentId does not resolve it.
• Omitting the override and using isolation:"worktree" fails with "Unable to resolve the parent checkout commit." The parent workspace is not a Git checkout.
• Neither rejected implementation request returned an accepted taskId or child. This is not a capacity/usage failure or a running child that needs another wake.

Is there an already supported operation that binds the child’s worktree to the selected registered repository/commit while preserving the original parentThreadId, completion wake, cancellation and preparation-failure semantics? If not, please treat this as an installed reproducer within this discussion’s existing scope. The needed path is repo-bound child preparation, not a global coordinator-project-root change, a shell-created child worktree, or a substitute top-level thread.

Read-only research and the original owner’s exclusive recovery work can continue independently; the implementation streams remain explicitly blocked until supported child provisioning is available. No claim that this report fixes the limitation.

Deduplication marker: integration-local-child-binding-20261108