[Feature]: Create top-level threads across computers

[ThinkSalat]

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

any t3 gui client

Problem or use case

I'm looking at the orchestration v2 docs and it looks like an agent can create a top level thread on the same computer, but not across environments. A use case I have pretty frequently is coordinating between my home server and my main pc. So far the only harness I know of that can do this is codex of all things. It looks like orchestration v2 has all the machinery in place to make this possible.

Proposed solution

Allow the threads related tools access and create threads across your configured machines.

Why this matters

Developing a backend and frontend in conjunction, where the backend is not hosted locally eg your local network, a vps, etc. Testing workflows across machines.

Smallest useful scope

Well I think the existing tools in the orchestration v2 are already the smallest useful scope.

Alternatives considered

Have the agents run ssh command to agents using harnesses on the remote computers ssh homelab pi "prompt".

Use codex desktop app.

Risks or tradeoffs

I imagine the machinery around accessing and creating threads from your phone to your computer may need changing. That said at least that capability does already exist in some fashion so I imagine it's better than starting from scratch.

Examples or references

Set up codex desktop gui, tell a thread on one machine to send a test thread to another machine.

Contribution

• I would be open to helping implement this.

[joshoastler]

Your premise here — that an agent can already create a top-level thread on the same computer — pointed me at a narrower gap next door, so I've filed it separately as #6150 rather than piling it onto this one.

The orchestrator thread tools in #2829 are hard-scoped to the calling thread's project: t3_thread_start inherits the caller's project and checkout, t3_thread_list never exposes threads from other projects, and OrchestratorMcpTarget carries only provider, driver kind, model and model options — there's no project or checkout field. So even on one machine, an agent can't open a thread in a different repo. #6150 proposes an optional projectId on the thread-creating tools, default-inherit, with the addressable projects advertised through orchestrator_capabilities.

Different axis to yours (project vs machine) but likely adjacent in the implementation, since both come down to letting the thread target resolve somewhere other than the caller's own environment. Happy to see them solved together if that's easier.

[ThinkSalat]

Your premise here — that an agent can already create a top-level thread on the same computer — pointed me at a narrower gap next door, so I've filed it separately as #6150 rather than piling it onto this one.

The orchestrator thread tools in #2829 are hard-scoped to the calling thread's project: t3_thread_start inherits the caller's project and checkout, t3_thread_list never exposes threads from other projects, and OrchestratorMcpTarget carries only provider, driver kind, model and model options — there's no project or checkout field. So even on one machine, an agent can't open a thread in a different repo. #6150 proposes an optional projectId on the thread-creating tools, default-inherit, with the addressable projects advertised through orchestrator_capabilities.

Different axis to yours (project vs machine) but likely adjacent in the implementation, since both come down to letting the thread target resolve somewhere other than the caller's own environment. Happy to see them solved together if that's easier.

Oh interesting, yeah I didn't realize that we couldn't make threads across projects either - yeah these seem like they're best solved together since they'll both be touching the same interfaces

[TechFeatured]

+1, I hit the same need: I want a thread on my laptop to hand a task to an agent on another machine I've connected to T3 Code, then get the answer back.

A stopgap works today. Every T3 server already exposes the HTTP API that t3 project uses, so a small script on the calling machine can do it:

1. On the remote machine, issue a token with t3 auth session issue --token-only.
2. GET /api/orchestration/shell to find the remote project.
3. POST /api/orchestration/dispatch with one thread.turn.start that carries bootstrap.createThread, plus bootstrap.prepareWorktree for a fresh worktree. This is the same command the app sends for a new thread's first message.
4. Poll GET /api/orchestration/threads/:id?turnLimit=1 until latestTurn.state settles, then print the last assistant message.

The local agent just runs the script as a blocking shell command. Follow-ups go through another thread.turn.start on the same thread id, and the remote thread shows up in the sidebar like any other, so you can watch it or answer approvals there.

It works, but the gaps show what a built-in version should solve:

• No public API. These are internal command shapes and can change in any release.
• Too much access. t3 auth session issue hands out a token with admin scopes, far more than "start and read threads" needs.
• Polling and timeouts. Completion is found by polling, and agent shell tools time out on long turns, so you end up with "start without waiting, check back later" by hand.
• One-way only. The remote thread has no idea it was delegated to, and the result never flows back into the calling thread on its own.

What a built-in version could look like, building on the orchestrator thread tools in #2829:

• Let t3_thread_start / t3_thread_send / t3_thread_wait / t3_thread_read take a target environment the client is already connected to, alongside the optional projectId discussed in [Feature]: Create top-level threads in another project (orchestrator thread tools are hard-scoped to the calling thread's project) #6945.
• Require an explicit grant the user sets, like the one proposed in Let a thread message threads in other projects, with a grant the user sets #13888, so an agent can't reach machines on its own.
• Deliver completion as an event, so the calling thread can wait without polling and without hitting shell timeouts.

[Lenoridev]

+1 — I’d use this to delegate work to another environment for its Computer Use or other machine-specific capabilities.

[rabesss]

+1. A concrete use case, and an update on @TechFeatured's comment above now that the MCP sign-in stack (#15219 → #15220 → #15222) is open.

Use case. I write code in a thread on my desktop and want review to run on a second environment: a secondary Linux box on T3 Connect with its own provider catalog. I want the reviewer threads to stay visible there and use a separate checkout. Within one environment, delegate_task already gives me async fan-out, children in Lineage, and a completion notification to the parent.

The HTTP stopgap isn't available in the current V2 nightly. In 0.0.46-nightly.20261003.2632 there is no POST /api/orchestration/dispatch. The /api/orchestration/* HTTP routes are GET-only, and the app dispatches orchestration commands over the WebSocket RPC orchestration.dispatchCommand.

What the stack would change. It addresses the API and access concerns in that comment: agents use MCP tools instead of internal command shapes, and sign in with user approval to an MCP-only session with a runtime-mode ceiling instead of an admin token. An MCP client used by a thread on A could sign in to B's /mcp and t3_thread_launch a coordinator thread in a project on B. That coordinator could then fan out with delegate_task on B's providers. For this cross-environment workflow, I'd still need completion delivery and parent lineage:

1. Completion. Completion on B doesn't automatically wake the thread on A. A's client can wait on B's runs with t3_thread_wait and retrieve the result with t3_thread_read.
2. Lineage. B's children are linked to the coordinator, but the coordinator has no parent link to the thread on A that asked for it.

A shape that would close both: let delegate_task take a target environment the user has explicitly authorized. The child would run on that environment's providers, stay linked to its parent in Lineage, and deliver its result the same way a local child does. That's TechFeatured's environment-target idea applied to delegate_task, which already handles delivery and lineage locally.

[shootingallday]

Posted a scoped proposal for this here: #15819

[EdmundLimBoEn]

+1. I hit this exact limitation while using T3 Code across an always-on Linux development server and my Mac.

The agent on the Linux server can create a new top-level thread on that server, but its available orchestration tools cannot discover my connected Mac or target a new thread there. My concrete use case is to keep coding, builds, and deployment work on Linux while handing browser/account setup to an agent running on the Mac: for example, opening Resend, handling sender-domain setup, and configuring the resulting API key as a Cloudflare Worker secret. Login or MFA could remain an explicit human handoff, and secret values should stay out of chat and git.

I'd like to tell the Linux thread: "Start a thread on my connected Mac to handle this setup, then report the result back here." The remote thread should be visible on the Mac, use that machine's available browser/computer-use tools, and return completion or a clear blocker to the originating thread. An explicit target environment and user-scoped authorization would make the destination and access clear.

The scoped delegation proposal in #15819 looks closely aligned with this workflow. Posting here to support the existing request rather than create a duplicate.

Written by GPT 6.1 Sol in Codex, on behalf of Edmund.