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

[husseinraoouf]

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/

[galengreen]

Strong +1. I'd go further and say this is the feature currently holding T3 Code back.
The tools I see people moving to, especially Amp with Orbs, treat a fresh cloud machine per task as the default. You kick off a task, close your laptop, and check in from your phone. T3 has a great mobile app and remote architecture, but without on-demand environments it still depends on a machine you have to keep alive.
I'd happily pay for this as a first-party feature, and I suspect a lot of users would too. Amp has shown there's real demand for usage-billed cloud agents, and it could be a clear path to making T3 Code profitable while keeping the client fully open source. If a fully managed service is too much right now (#14620), the broker hook proposed here would be a great first step. A paid T3-hosted provider could plug into it later.
Would love to hear whether this is on the roadmap at all.

[Teebor-Choka]

This would not only have to be limited to Clouds, but also ideally some interface would be in the middle so that custom/in-house/private deployments would be possible.

[Teebor-Choka]

I propose to define the interface only for now... and the implementations could start rolling in as plugins.

[LouisDeconinck]

Yes, support for cloud sandboxes would be a big unlock for T3 Code. My laptop constantly goes OOM due to memory from running builds. boat.dev and daytona.io are good first candidates that I support.