Provision sandbox environments from Settings (Boat, Daytona, Vercel, Upstash, Celesto + any driver)

[OmarAlex24]

Problem

Settings → Environments can only pair a T3 server that already runs somewhere. Using a cloud sandbox means creating the machine by hand, installing t3, exposing a port, minting a pairing link and pasting it back.

Proposal

Add environment → Sandbox provisions the machine with the user's own provider key, installs T3, runs t3 serve, exposes it and pairs it through the existing pairing path. Projects, threads, terminals and reconnects are unchanged.

• Pluggable: each backend is one driver (create, execute, expose port, stop, resume, destroy) plus a registry entry. Drivers today: Boat, Daytona, Vercel, Upstash Box, Celesto.
• Nothing bills silently: stop/resume/delete from Settings, a lifetime limit (8h default) backed by the provider's own auto-stop, a sweep that syncs machines changed outside T3, and cleanup when create fails halfway.
• Opt-in setup: git/gh/Claude install, GitHub sign-in, Tailscale join for private endpoints, templates. Tokens never go in command text.

Scope

• Per-thread local containers are a different layer, covered by feat: threads can run in Docker sandboxes with their own ports and services #15350.
• Local VMs (Multipass, Docker sandboxes, Lima) fit the same driver contract once credentials are optional and a driver can return a non-public URL. Not in this proposal, but the contract won't block it.

Status

Branch: OmarAlex24:feat/sandbox-environments. Every driver was tested live (details in this comment).

Questions for maintainers

1. Is provisioning sandboxes from Settings with the user's own key in scope for T3 Code?
2. One PR, or core first (create, pair, stop/resume/delete, lifetime limit) and the rest after?

[OmarAlex24]

Implementation draft: #27950

It includes the server-side driver contract, Boat and Daytona drivers, the Add environment → Sandbox flow, focused tests, and web captures. It is explicitly waiting on the direction approval this discussion asks for.

[matt-palmetto]

Live Daytona results for #27950, since the PR notes Daytona was only tested with mocks. I ran it against a real Daytona account from the dev web client.

What works as written: create (daytona-small/-medium snapshots start right away), toolbox process/execute (multi-line set -eu scripts run in a shell and report the right exit code), the install script, t3 serve surviving after the exec call returns, t3 pair output parsing, and the preview URL.

What broke: pairing. Daytona's preview proxy echoes the caller's origin for CORS and t3 serve adds *, so every response has two Access-Control-Allow-Origin values and the browser rejects it. Fix, with live end-to-end evidence, is on Omar's branch: OmarAlex24#2

Two more things, separate from that fix:

1. A client-side pairing failure leaves the sandbox billing. Cleanup in SandboxProvisioner.create only covers server-side steps. When the client fails after create returns, the sandbox keeps running, and Daytona's is created with autoStopInterval: 0 and autoDeleteInterval: -1. feat(environments): provision sandboxes from provider API keys #27950 has no UI caller for sandboxes.delete, so the only way out is the Daytona dashboard. I had to delete mine by hand.
2. Use case: one sandbox per task, killed when done. That's how I want to use this: spin up a Daytona box for a piece of work and have it go away after. Daytona can do that natively with autoStopInterval set to an idle window plus autoDeleteInterval: 0 (delete on stop). It also covers item 1. Pairing it with "delete the sandbox when I remove the environment" would make the lifecycle in feat(sandbox): stop, resume, and an eight-hour hard limit for provisioned machines #28238 cover the ephemeral case as well as the long-lived one.

Happy to help test Daytona as this moves. I have an account and can run whatever you need.

[OmarAlex24]

update: everything's on one branch now

the PRs got closed for not having approval first, fair enough. moved it all to one branch so we can agree on scope here before anything gets reopened:

branch: OmarAlex24:feat/sandbox-environments. commits are split by theme, so it can land as one PR or core first, whatever you prefer

what it does

add environment → sandbox spins up a cloud machine with your own provider key (boat, daytona, vercel, upstash box, celesto), installs t3 and pairs it like any other remote environment. projects, threads, terminals, browser all work the same. each provider is one driver file + a registry entry

nothing keeps billing in the background

• stop / resume / delete from settings, delete always works
• lifetime limit (8h default, extendable) enforced by t3 and backed by the provider's own auto-stop
• a sweep every minute syncs sandboxes stopped or deleted outside t3, plus boat's monthly cost
• boat plan limits (start windows, concurrency, paid starts) are checked before create/resume

ready to work (all opt-in)

• installs git, gh and claude if missing (boat already has them)
• "use this machine's claude setup": if you run a CLIProxyAPI hub, each sandbox gets its own key on the hub (so you can see its usage separately), revoked on delete. no hub = copies the token
• if your endpoint is private (tailscale), the sandbox can join your tailnet as an ephemeral tagged node using a tailscale oauth client. key per sandbox, device removed on delete. nothing has to be exposed publicly
• github sign-in with this machine's token, so the agent can push and open PRs
• checklist after create with what's ready + the codex sign-in link

hardening

• tokens (claude, github, tailscale) never go in command text, so they don't show up in the provider's command history
• long setup commands no longer die at node fetch's 300s header timeout
• provider calls retry only when the provider says it's safe (5xx on idempotent calls, short 429s, boat's restoring/starting)
• if a create response gets lost, the half-made sandbox gets cleaned up instead of billing quietly

templates

• after create, the next step is setting up a project and saving the sandbox as a template, so new ones start ready
• t3 identity, credentials and tailnet state are scrubbed before the snapshot

smaller form: provider is one row, saved key shows "key saved · replace", provider settings live under advanced, and the "repository to clone" field is gone

tested live

• boat + daytona: create → pair → stop/resume → extend → delete
• vercel: same plus templates (save ~10s, create from template ~9s)
• hub keys minted and revoked against a real CLIProxyAPI hub
• boat + vercel joined a real tailnet and claude answered through a private endpoint (~30s create)
• upstash box: create from the ui (~90s), connected, joined the tailnet, pause/resume keeps the url, delete removes the box + device
• celesto: create (~55s), connected, joined the tailnet, stop/resume/delete
• daytona: a 320s setup command finishes fine now
• agent inside a boat sandbox cloned a private repo, pushed and opened a draft PR

not tested yet: daytona templates (my key lacks snapshot scope), vercel on a hobby plan, and upstash's idle auto-pause (it pauses after 1h without activity and t3 traffic doesn't count as activity, so long agent runs could get cut). railway sandboxes i left out for now, no stop/resume and free plans kill idle ones after 5 min

@matt-palmetto thanks for the daytona run, your CORS fix is cherry-picked with your authorship. both things you raised are covered: a sandbox can always be deleted from t3, and the lifetime limit + provider auto-stop catch anything pairing left behind. a per-task delete-on-stop mode would be an easy follow-up if wanted

questions for maintainers

1. is this ok scope-wise for t3 code? (provisioning cloud sandboxes from settings with the user's own provider key)
2. one PR, or core first (create, pair, stop/resume/delete, lifetime limit) and the rest after?

if something should be out, i'll cut it before opening anything

[OmarAlex24]

follow-up idea for the "ready to work" part: #29777 proposes setup profiles, so a new sandbox (or devbox) gets the CLIs, agent config (instructions, skills, MCP servers) and sign-ins of the environment you already work on. applied on every sandbox create, first time + drift check on persistent ones. kept separate so it doesn't grow the scope of this one

[OmarAlex24]

quick update + a question on direction

• rebased feat/sandbox-environments onto today's main (0 behind). the sandbox code now lives in its own modules, and the shared files (ws.ts, server.ts, rpc.ts, settings.ts) only get a 2–3 line hook each, so it's cheap to keep current
• noticed t3code/docker-sandboxes (threads running in docker sandboxes). if that's the direction, these drivers could be the cloud side of the same idea: same lifecycle (create, stop/resume, delete, lifetime cap), just running on boat/daytona/vercel/upstash/celesto instead of local docker

would that fit better than a separate "add environment → sandbox" flow? happy to reshape it around whatever abstraction you're building, or to start small with just the driver contract + one provider

a few things i hit testing live that might save time either way:

• daytona's preview proxy adds its own CORS origin on top of t3's *, so browsers reject the response
• node fetch's 300s header timeout kills long setup commands
• a sandbox keeps billing if pairing fails after create (covered by provider auto-stop + the lifetime cap)

[codewarnab]

https://www.docker.com/c/sbx-promo/ docker cloud sandbox will also be nice

[gravitinos]

Any new considerations on this one with the news of Conductor retiring their Cloud feature?

I think it'd be worth maintaining this so there is an easy path of migration for companies that relied on Conductor Cloud before. https://www.conductor.build/announcement, and it doesn't require devs to learn a new mental model around where agents run (npx connect still requires devs to think about work tree cleanup, and a machine sharing resources).

[OmarAlex24]

update: one sandbox per chat

changed the model after using it daily. a sandbox config is now just a recipe, and every chat started on it gets its own sandbox:

• run on → sandbox from the composer, for any project with a github remote, even one that only lives on another machine. no per-config repo list anymore
• settling a chat asks: keep a snapshot (stops it, sending a message resumes it) or delete. there's a "remember" box, and a per-config default. providers bill for stopped disks, so it never keeps one silently
• tailscale joins automatically when your claude endpoint is private, with a guided oauth client setup. key per sandbox, device removed on delete
• boat inside the sandbox (opt-in): the agent gets a boat key scoped to its own sandbox, so it can fork itself or host ports, deleted with the sandbox
• official mobile app: sandbox chats show up as normal chats on the host, so you can send, approve, answer questions and stop from your phone without any app changes. starting a sandbox chat still happens on the computer
• smaller form: name + machine, everything else under advanced

if you want to try it without a fork, i made a small kit that builds the branch as a separate "T3 Code Custom" app next to the official one and rebases it on upstream every night: https://github.com/OmarAlex24/t3code-diy (unofficial, mac only)

same questions as above still stand for maintainers, happy to cut scope before anything gets reopened

[luzes-dev]

I've been working on a related implementation in my fork. I started before noticing the approval-first contribution policy, so I'd like to discuss the architecture here before proposing anything for upstream.

My approach differs in a few ways:

• Controller-owned orchestration. The user's existing T3 server manages provider credentials, VM lifecycle and SSH connections. Each sandbox runs its own T3 server and appears as a normal environment. Clients access it through the controller's SSH-backed proxy, without exposing the sandbox's T3 port publicly.
• Persistent lifecycle management. Lifecycle, power state and connection intent are tracked separately. Records survive restarts, reconciliation handles connection failures and external deletion, and provisioning uses stable request IDs. Budget and concurrency checks gate provisioning and resume, although the budget is not a hard spending cap.
• Agent workspaces. I integrated sandbox provisioning with delegate_task and t3_worktree_handoff. Agents can create isolated VMs, transfer projects or fork an existing sandbox's disk, including uncommitted changes, while reusing T3's existing peer-link orchestration.
• Provider capabilities. The driver contract separates core lifecycle operations from optional capabilities such as forking, snapshots, desktop streaming and port hosting. Only Boat.dev is implemented and tested so far.

I also like the newer one-sandbox-per-chat direction proposed here. My implementation currently favors reusable environments and agent-driven delegation, but the composer workflow and chat-level cleanup would make disposable sandboxes much easier to use. The multi-provider work here is also further along than mine.

I think provisioning an environment and deciding which chat or agent owns it should be separate concerns. That could let persistent environments, disposable cloud workspaces and local Docker sandboxes share the relevant infrastructure without forcing the same lifecycle on all of them.

Would maintainers be open to a smaller first contribution covering the provider contract, lifecycle and environment connectivity, with agent orchestration and advanced capabilities following separately? I'm happy to adapt the existing implementation to whichever direction fits T3's architecture.

[OmarAlex24]

nice, thanks for writing this up. agree that provisioning and ownership should be separate, and your lifecycle/reconciliation work and fork-with-uncommitted-changes are things this branch doesn't have.

one thing i'd push back on after using one-sandbox-per-chat daily: a sandbox showing up as a normal environment doesn't scale. with a few chats running, settings, usage and provider warnings filled up with "atlas on Boat sandbox" twice, each with its own config and its own "codex not authenticated" notice.

so on feat/sandbox-environments a sandbox is now a follower of the server that made it, not a machine you pick:

• it's hidden from environment pickers (settings scope, usage, provider notices), and its usage counts under the host
• on create it's seeded with the host's settings, from an explicit allowlist. secrets, host paths and project-id-keyed overrides stay on the host
• host saves repeat on live sandboxes without blocking the save

a persistent environment you keep (your model) would still be a first-class environment, so i think the split is: kept environments are picked, disposable workspaces follow their host. that fits your "smaller first contribution" idea too: provider contract + lifecycle + connectivity first, and ownership (chat, agent, or user) on top.