[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