Idea: one-click Docker Sandbox (sbx) environments in Settings → Connections

[mdelapenya]

Hi! 👋

First, quick disclosure so there's no surprise halfway through: I work at Docker on the Docker Sandboxes team (sbx). I'm also a happy T3 Code user, which is how this idea came about. I'd love to hear whether you'd welcome a contribution here — and if the answer is "not a fit", that's a completely fine answer too.

What already works today (thanks to your architecture)

Docker Sandboxes run coding agents in isolated microVMs. Because sbx setup ssh writes a managed SSH config, every sandbox is reachable as an ordinary SSH host at <name>.sbx — and T3 Code's desktop-managed SSH launch handles it beautifully from there. No T3 changes needed at all. That's a real compliment to the "SSH is an access helper, not an environment type" design in docs/internals/remote.md; it made this work out of the box.

The friction is everything around that moment. Today a user has to:

1. sbx run --name t3sbx --kit docker.io/sbx/t3code-kit:latest ... claude . in a terminal
2. wait for the agent TUI, /exit it, close the terminal (the sandbox keeps running)
3. know to run sbx setup ssh once
4. go to Settings → Connections → SSH, type t3sbx.sbx, know the username is agent
5. and — the sharp edge — know that without the t3code kit, the remote t3 install fails silently because node-pty has no Linux prebuilds and fresh sandboxes ship no compiler

That's a lot of tribal knowledge for what is conceptually one action.

The idea

A Docker Sandbox card in the Add Environment dialog that does the machinery: detects the sbx CLI (offering a one-click install via Homebrew/winget, in the same spirit as the provider-update toast; copyable commands on Linux), runs the idempotent sbx setup ssh, creates the sandbox non-interactively with sbx create and the t3code kit always applied, then hands <name>.sbx to the existing SSH environment flow.

Design-wise I tried to follow the grain of the codebase: no new connection target kind. The persisted profile is a plain SshConnectionProfile; the integration is a thin, desktop-only provisioning adapter (apps/desktop/src/sbx/, ~2 files) plus one dialog card, hidden entirely when the bridge doesn't expose it. Nothing downstream — supervisor, resolver, catalog, mobile, web — knows sandboxes exist. The one sandbox-aware reverse path: removing a .sbx environment asks whether to delete the sandbox too, so no orphaned VMs.

Why I think T3 Code users would care

Your users drive agents all day, often with permissions cranked up. The sandbox model is a nice complement to that (all from the official docs):

• The agent gets full autonomy, safely. "The agent has full control inside the VM, including sudo access" — but "the VM boundary prevents the agent from reaching anything on your host except what is explicitly shared." Run --dangerously-skip-permissions without the dangerous part.
• Own Docker daemon per sandbox, so agents can build and run containers without touching host Docker.
• Deny-by-default network policy with proxied egress, and credential injection where "credential values never enter the VM."
• Workspaces mount at the same absolute path as on the host, so nothing about paths or git breaks.
• The CLI is free, including commercial use, on macOS (Apple silicon), Windows 11, and Ubuntu 24.04+.

The obvious question: sbx isn't open source

I want to be upfront about this rather than have it come up in review. The sbx CLI is freely available but not OSS. My honest read is that this sits in the same category as the provider CLIs T3 Code already integrates — Claude Code, Codex, Cursor aren't open source either, and T3 Code even one-click-updates them. The integration itself would be fully OSS in this repo, driving a CLI the user chose to install, and invisible when they didn't. But you may weigh this differently, and I'd genuinely like to hear how you think about that boundary.

Where things stand

I have a working PoC on a branch: contracts, the desktop adapter, the dialog card with install/login/create states, the removal flow, focused tests, and updates to docs/user/remote-access.md + docs/internals/remote.md. Happy to open a PR with screenshots and a short video if there's interest — and since I'm on the sbx team, you'd have a direct line to us for maintaining the integration as the CLI evolves (we'd also take fixes on our side if T3 Code needs something, e.g. stabler --json output; the PoC already caught one format wobble between releases).

No pressure at all — if you'd rather see this live as a fork, an external plugin pattern, or not at all, I'm glad to have learned this much about the codebase either way. Thanks for building T3 Code in the open. 🙏

[mdelapenya]

I actually have a working prototype — split into two branches so each stays one concern:

The sandbox integration itself — a "Docker Sandbox" card in Settings → Connections: it detects the sbx CLI (offering a one-click install when it's missing), creates the sandbox with the t3code kit preapplied, and hands the resulting <name>.sbx host to your existing desktop-managed SSH flow. 14 files, no new connection target kind — the persisted profile is just an SshConnectionProfile:

main...mdelapenya:t3code:feat/docker-sandbox-connections

Optional follow-on, stacked on the above — activating T3 Connect for a sandbox when it's connected, so it's reachable from mobile. Worth ignoring unless the first one interests you:

mdelapenya#1

@t3dotgg is this something you and your team are interested in discussing?

BTW thanks for this great OSS project, I'm enjoying it every time I use it since discovered 🙇

[ITBenko]

This would be very useful for benchmarks (avoiding contamination, fresh harness and security).

[mdelapenya]

@t3dotgg @juliusmarminge would you like to discuss about what I proposed here?

Cheers!

[KaKi87]

@maria-rcks This might be of interest to y'all !

[juliusmarminge]

Sorry for the delay. Bringing this up with Theo today

[mlk1278]

@juliusmarminge I would like to add this is the only reason I have not yet moved to T3 code; I need my agent containers :)

[mdelapenya]

@juliusmarminge any updates on this? 🙏

[LegandaryRa]

This would also be useful for keeping parallel agent sessions from interfering with each other. The devcontainer request in #2310 describes a similar goal: separate checkouts, dependencies and backing services for each agent.

Could the approach here eventually support allocating an isolated workspace per thread, with its own filesystem, processes, ports and development services? Ideally, reconnecting would reuse that workspace, and the agent, terminal, project scripts and previews would all operate inside the same boundary.

The provisioning could stay with an external backend such as Docker Sandboxes, a container manager or a microVM service. T3 would only need to associate the thread with the workspace and connect to it. That seems worth exploring without requiring T3 to manage a Docker or Kubernetes platform itself.

Would orchestration v2 (#2829) provide a suitable integration point for that, or is the intended model to keep isolation at the environment level, with a separate T3 server in each sandbox?

I realize this is broader than the initial Add Environment proposal; I’m asking about the direction and integration boundary, not suggesting it should block this smaller integration.