Delegate a task to another environment you've connected (Tailscale, LAN, or T3 Connect)

[shootingallday]

The gap

delegate_task runs children only on the parent's own environment. I run T3 Code on a Mac and a Windows PC and want a thread on either one to hand work to the other, with the result coming back like a local child's. #6935 asks for this; @rabesss sketched the delegate_task shape there. This is a concrete scope for it.

Why the server can't do it today

Saved environments live only on clients (desktop saved-environments.json under safeStorage, web IndexedDB, mobile storage). No server holds a list of peers or calls another server.

Proposed direction

• Peers on the caller. t3 environment add <url> --pairing-code <code> exchanges the code at the target's /oauth/token (the existing bootstrapRemoteBearerSession path). It stores {id, label, httpBaseUrl, wsBaseUrl} in server settings and the token in ServerSecretStore. Each connection mints a fresh WebSocket ticket.
• Any reachable URL works: LAN, a Tailscale name, or a T3 Connect tunnel hostname. Connect needs no relay changes, because the tunnel is a plain hostname and the target still enforces its own auth. If the caller is linked with t3 connect, it re-resolves a Connect peer's hostname through GET /v1/environments when the tunnel is reprovisioned.
• delegate_task takes optional target.environmentId and target.projectId. The orchestrator records the task and turn item as it does now but skips the local provider. A small bridge calls orchestration.launchThread on the target and follows it with orchestration.subscribeThread. When the run settles, it feeds the result into the existing completion-delivery path, so the parent wakes without polling.
• The child is a normal thread on the target. It shows in that environment's sidebar on web, desktop, and mobile, and approvals are answered there. The parent works from any client, since delegation runs server to server.
• Scoped grant. The target issues the pairing code for a delegation session kind. It can launch, read, and interrupt delegated threads, has a runtime-mode ceiling, and is listed and revocable in Settings → Connections. It is not a full client session.
• Both directions and failure. Cancelling the task interrupts the remote run. An unreachable target fails the task with that reason after a reconnect window. The remote thread ID is saved so a restart re-subscribes. A version check against /.well-known/t3/environment refuses incompatible peers up front.

Out of scope

• Targets reached only through the desktop's SSH connection.
• Opening Connect peers through the relay's /connect flow, which would need a server client_id and DPoP on the relay.
• Copying the caller's checkout.
• Mirroring the child timeline on the caller.
• A Settings screen for adding peers (CLI only).

Why not the MCP sign-in stack

#15219 → #15222 lets outside agents use /mcp, but its OAuth flow needs a browser on a loopback redirect, which a headless server can't complete, and its mcp-client sessions can't use the WebSocket RPC. I'd borrow its runtime-mode ceiling for the delegation session.

Size and proof

Estimate: 900–1,300 lines including tests, mostly server and contracts, plus one CLI command. I'd test Mac ↔ Windows over Tailscale and over T3 Connect, with focused tests for settle, cancel, unreachable target, restart, and version mismatch.

Happy to build it as one PR, or hand over the design if you'd rather fold it into V2 yourselves.

Drafted with Opus 5.5 in Claude Code.

[Lenoridev]

Too similar to #6935. This can be added to the discussion as a comment.