Let MCP choose the environment for t3_thread_launch and delegate_task

[kaankolcu]

Request

Let an agent choose the environment for the threads and tasks it starts through MCP:

1. An optional environmentId on t3_thread_launch and delegate_task.
2. Cross-environment t3_thread_read, t3_thread_wait and t3_thread_send for those threads.
3. Optionally, the load balancer from Settings → Connections ("Auto balance") exposed to MCP, so an agent can ask for "any eligible machine".

Why

A coordinator thread on a laptop drives worker agents on cloud VMs (Boat sandboxes). Each VM can already be a T3 environment through the desktop's SSH route, which installs and starts the matching server by itself. But MCP tools act only on "this environment". So the coordinator cannot start a worker thread on a VM, read it, or be woken when it ends. Today the workaround is driving the VMs through their own CLI from background shell commands. Those workers are invisible in T3 and die with the coordinator's session.

With an environment target, a VM added once as an SSH environment becomes a normal, visible, steerable T3 worker. The user also sees every worker in the sidebar.

Related

• Adding and removing SSH environments from the CLI or MCP (t3 env add ssh <host>) would let a coordinator manage a VM fleet without a Settings click per VM.
• Cross-environment coordinator handoffs need an explicit durable return route #18675 (closed) covered a durable return route for cross-environment handoffs.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

This is in flight: #16684 adds an optional environmentId to t3_thread_launch, t3_thread_read, t3_thread_send and t3_thread_wait for linked environments, and #16719 (stacked on it) lets delegate_task target a linked environment and wake the parent when it finishes. Auto balance over MCP and adding SSH environments from the CLI aren't part of those; open a separate idea for either if you still want it once these land.