[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.

[DragonSenseiGuy]

+1 for amp orbs since you can self host them now too!
https://ampcode.com/docs/orbs/self-hosted

[BasixKOR]

Amp allows users to bring other compute providers but they do not provide compute by themselves.

[Teebor-Choka]

A plugin style interface would be ideal, so that arbitrary implementations could be contributed by the community, to support also various in-house solutions. I'd like to contribute time and resources for this if there's a consensus about what the interface should look like by the maintainers.

[Teebor-Choka]

Update: I was able to go around this a little bit, now being blocked on the T3 pairing being too complicated and requiring manual approvals for the ephemeral sandboxes instantiated. Will try to figure out a better mechanism.

[faridelaouadi]

+1, and here is the other half of this: once tasks run on other machines, you need to see them apart from the work on your laptop.

I already send long agent runs to boat.dev VMs. In T3 those threads look exactly like local ones, so I can't tell at a glance what is running off my machine, which one is waiting on me, or which one lost its connection. I've been using a patched build for this every day. It does two things:

A VMs section at the bottom of the sidebar. One row per task, with its status and how long it has been running:

• Needs you: a pending approval or question
• Working
• Connection lost: the thread was still running when its environment disconnected
• Failed or Done

Above the rows, each task is a small boat that moves along a strip of water as it runs and docks when it finishes, so you can see the whole fleet in one look. You can collapse the section, or hide it so it shrinks to a "2 VMs running" pill. Those threads leave the main list, so local work stays readable.

A Run on VM button next to Send. Your message folds into a paper boat and flies to the VMs section, and a "Starting VM…" row waits there until the remote thread shows up.

run-on-vm-animation.mp4

The screenshots and recording are from my design prototype, with made-up task names.

Every status comes from data T3 already has: pending approvals and input, whether a thread is running, and whether its environment is connected. The rough part is how my build finds the tasks. It matches a title prefix that my VM launcher sets, and Run on VM sends my own slash command. A real version would use each thread's environment, and the sandbox broker proposed here, to know what is remote. Run on VM would then become this proposal's "New cloud sandbox", or the move in #31077.

I'm not asking you to merge my patch. I'm sharing it in case it helps shape how cloud tasks look once they exist, and I'm happy to share the code if it's useful.

[Teebor-Choka]

I am working on a version of integration with T3 Code's backend. My biggest limitation right now is the likely missing ability to fully automatically use the T3 pairing. How did you approach that for the boat.dev machines? I now do mint it using ssh on the host machine for the guest VMs, but that is unlikely to scale well. Or are you missing that as well?

[jtatum]

I'd like for these environments to be ephemeral - maybe one per thread, and automatically stopped/killed after some timeout. Providers like agent37 already support wake-on-ssh/sleep-on-inactivity for pets, but I want efficient concurrency with cattle.

[jonatansberg]

A few additional sandboxing options could be:

Local / self hosted:
https://boxlite.ai/oss
https://docs.docker.com/ai/sandboxes/

Commercial:
https://www.cloudflare.com/products/sandboxes/
https://fly.io/sprites/

A T3 managed version (like Orbs) would be a pretty decent way to monetize this as well :)

[djgilcrease]

NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease.

This now has a working external plugin: Sandboxes, released as v0.1.1.

The implementation post in the plugin-system discussion has screenshots of launching from the composer, automatic pairing to a real Docker sandbox, the thread-pane status, and a stopped sandbox with its conversation retained.

Docker and Boat are built in, with an external executable/HTTPS driver for other providers. The controller owns provisioning and the first send, and manages stop/resume, idle and cost limits, and guarded deletion. Rehome is optional; transcripts are retained without it.

It requires the shared plugin-system prototype host, rather than upstream T3 Code. Guest images need the matching host, agent tools, and Git access. The screenshots use the free Replay (dev) fixture; native mobile UI has not been exercised.

[kjj6198]

I built the per-task flow this discussion asks for, with boat.dev, and I'd like a maintainer's call on direction before opening a PR.

What it does

• In a new thread, Run on → New boat.dev sandbox… opens boat's create options: size, snapshot, boat environment, auto-stop hours, setup script. T3 creates the sandbox, connects it, clones the project over HTTPS with its .env files, and moves the draft there with its text. This takes about 30 s.
• When every thread on that sandbox is settled or archived, T3 switches the environment off, which stops the sandbox. Its disk stays as boat's snapshot. Reconnect on the thread resumes it.
• The same sandboxes can also be added from Settings → Environments → Add environment → boat.dev as long-lived machines. Switching one off stops it.

Why SSH, not pairing

The sandbox is a desktop-managed SSH environment, so T3 runs on it the way it runs on any SSH host and nothing listens on a public URL. The desktop authorizes its own key through boat's sshkey API and pins the host key boat returns, so nothing is written to ~/.ssh. The cost is that creating a sandbox is desktop-only. #27949 pairs over a public URL instead, which also works from the web and mobile clients.

How it differs from #27949 and #31898

Those create machines from Settings and bound their cost with a lifetime timer. This ties the sandbox to its threads, so it stops when the work settles, as asked above for one ephemeral sandbox per thread.

Questions

1. Is a per-thread sandbox started from the composer in scope?
2. Should one provider (boat.dev) land first, or should this wait for a driver contract like the one in Provision sandbox environments from Settings (Boat, Daytona, Vercel, Upstash, Celesto + any driver) #27949?

Demo (65 s) & Code: https://github.com/kjj6198/t3code/blob/boat-assets/boat-thread-sandbox.mp4

t3code-boat-thread-sandbox.mp4