[Feature]: Create top-level threads in another project (orchestrator thread tools are hard-scoped to the calling thread's project)

[joshoastler]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

The orchestration V2 orchestrator toolkit in #2829 lets an agent create top-level threads (t3_thread_start, create_threads), but every thread tool is hard-scoped to the calling thread's project. t3_thread_start "inherits this thread's project, checkout, provider, model, and runtime settings", t3_thread_list states that "threads from other projects are never exposed", and OrchestratorMcpTarget only carries providerInstanceId, driverKind, model and model options — there is no project or checkout field.

That means an agent cannot open a thread in a different project, even on the same machine. I work across roughly twenty repos that live side by side in one folder and share one backend. The work that most wants a new thread is almost always cross-repo: I'm in the dashboard repo, I discover the fix belongs in the intake repo, and I want to hand that off to a fresh thread already pointed at the right repo, then carry on with what I was doing. Today the agent has to stop and tell me to open that thread by hand, which is exactly the step the toolkit otherwise removes.

This is distinct from #6079, which asks for thread creation across machines. Same-machine, different-project is a smaller and more common case, and #6079's premise (that local top-level creation already works) is what makes this gap visible.

Proposed solution

Add an optional project selector to the thread-creating tools:

• OrchestratorMcpCreateThreadRequest and OrchestratorMcpThreadStartInput gain an optional projectId, and optionally a checkoutId or runtime target within that project.
• Omitted, behaviour is unchanged: inherit the caller's project and checkout.
• Supplied, the thread is created in that project, resolving provider and model against that project's configuration rather than the caller's.
• orchestrator_capabilities advertises which projects are addressable, so the agent discovers valid ids instead of guessing them.
• t3_thread_list and t3_thread_read gain an optional projectId filter, defaulting to the caller's project so the current isolation guarantee remains the default rather than disappearing.

Why this matters

Cross-repo handoff is the main reason to want a new top-level thread rather than a subagent: the work belongs to a different checkout, it needs different context, and it should outlive the current conversation. Restricting creation to the current project means the toolkit covers "more of the same work in parallel" but not "this belongs somewhere else" — and the second is where the manual step actually costs time.

Smallest useful scope

An optional projectId on t3_thread_start only, with the addressable project list exposed through orchestrator_capabilities. Batch create_threads, checkout selection, and cross-project reads can all follow later.

Alternatives considered

• Open the thread manually and paste the context in. This works, but it is the exact manual step the orchestrator toolkit exists to remove, and the context has to be re-explained from scratch.
• Use delegate_task for the other repo's work. Wrong shape: a subagent is nested under the parent thread, dies with it, and is not something I can return to later as its own conversation.
• Run the other repo's agent through a shell command. No thread, no history in the app, and nothing visible from mobile or another client.
• Wait for [Feature]: Create top-level threads across computers #6079 (cross-machine). Broader in scope, and it does not address the same-machine cross-project case that its own premise exposes.

Risks or tradeoffs

• Project isolation is currently a stated guarantee rather than an accident, so this should be opt-in per call, default-inherit, and probably permission-gated the same way the other destructive and open-world orchestrator tools are. An agent should not be able to quietly start runs in repos the user was not talking about.
• Provider and model inheritance gets more complicated when the target project has different provider instances configured. Failing clearly, with the target project's advertised options, seems better than silently substituting a model.
• Worktree and runtime-mode resolution has to happen against the target project, which is where I would expect the real implementation cost to sit.

Examples or references

• feat(orchestrator): introduce new orchestrator #2829 — orchestrator toolkit: apps/server/src/mcp/toolkits/orchestrator/tools.ts
• packages/contracts/src/orchestratorMcp.ts — OrchestratorMcpTarget, OrchestratorMcpThreadStartInput, OrchestratorMcpCreateThreadRequest
• [Feature]: Create top-level threads across computers #6079 — the cross-machine sibling request

Contribution

• I would be open to helping implement this.