Repository navigation
[Feature]: Create top-level threads across computers #6079
Description
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.
Activity
joshoastler commentedon Aug 11, 2026
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_startinherits the caller's project and checkout,t3_thread_listnever exposes threads from other projects, andOrchestratorMcpTargetcarries 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 optionalprojectIdon the thread-creating tools, default-inherit, with the addressable projects advertised throughorchestrator_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 commentedon Aug 11, 2026
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