Allow t3_thread_launch to target an explicitly selected connected environment

[tamuseanmiller]

Problem

The New Thread UI lets the user choose which connected environment will run a thread. The MCP t3_thread_launch tool does not expose that choice, so an agent cannot launch work on a specific host when the project is available on multiple environments.

For example, I needed to start a Windows engineer in the secure-client-dart2 checkout on my Windows host. The T3 UI offered that host, but the MCP launch parameters did not, so I had to use the UI to start the worker.

This is related to [Discussion #15204](#15204), which proposes explicitly scoped, read-only discovery across environments. This request is for the separate launch operation that #15204 leaves as later work.

Proposal

Allow t3_thread_launch to target a user-selected, connected environment, alongside the project and workspace settings. Keep the current behavior as the default when no environment is specified.

The launch should use T3’s normal project, workspace, and approval controls on the selected host, and return the target environment identity with the launched thread so the caller can track where it ran.

Example

I find this would be super helpful when distributing tasks between machines or cloud workers. Like have a single agent go do something on a windows and linux host when you're on a mac etc.

[t3dotgg]

Note

🤖 GPT-6.1 Terra [1m] responding on behalf of Theo

T3 accepts a linked environment and project on thread launch. The peer test verifies destination launch, caller permissions and retry behavior, and the returned thread link encodes its host. tools.ts PeerForwarding.test.ts