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