[Feature]: On-demand cloud task environments through an external sandbox broker #14793

Problem

I want T3 Code's graphical interface, extra tools, and existing native Codex and Claude Code integrations, with an isolated remote development environment created on demand for each task/worktree. Today an SSH environment must already exist; I would like to avoid maintaining an always-on development server.

Proposed solution

Support a user-configured external sandbox broker as an environment provider. The broker could run on Cloudflare Workers and provision environments through Boat, Daytona, or another provider. T3 would request a new environment for a task, wait for readiness, then connect using its existing remote-server/SSH or pairing flow. T3 would continue running the actual Codex and Claude Code harnesses inside the sandbox.

A minimal first version could be an environment provisioning hook/API that returns connection details, with visible provisioning progress, failures, cancellation, and retry. A native provider integration could follow later.

Expected workflow

1. Select a repository, base revision, and New cloud sandbox when creating a task.
2. T3 requests a sandbox from the configured broker, using a stable request ID to prevent duplicate provisioning.
3. The broker creates or forks an environment, prepares the repository/task branch and dependencies, and returns connection details once ready.
4. T3 connects and uses its existing chat, terminal, diff, Git, and native agent integrations.
5. Continue a task by resuming its existing sandbox. Explicit stop/archive controls and optional idle-stop policy preserve work and avoid unnecessary running compute.

Separate sandboxes can use separate checkouts/branches rather than requiring a Git worktree to span machines. Concurrent tasks should have separate environment identities.

Boundaries

Provider keys remain in the broker. Agent and repository authentication should be scoped, with explicit retention policy. Stop/resume must preserve files and conversation state; deleting an environment must be an explicit action. Provisioning and cleanup should survive client disconnects, and retrying a request must not create duplicate machines.

Related requests

• feat: Cloud Agents #6: broad cloud/remote agents, now closed.
• feat: Managed disposable cloud workers with budgets and independent cleanup #14620: managed disposable cloud workers, closed as not planned. This proposal asks specifically for an external provisioning extension point, allowing users to own infrastructure and lifecycle policy instead of requiring T3 to operate a managed cloud service.

Would a broker/provisioning-hook extension fit T3's remote-environment architecture? If not, guidance on the appropriate extension boundary would help those implementing it in a fork.

Providers considered: https://boat.dev/ and https://www.daytona.io/