{"id":4716,"date":"2026-08-03T13:11:56","date_gmt":"2026-08-03T13:11:56","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/03\/empty-sandboxes-break-developer-experience\/"},"modified":"2026-08-03T13:11:56","modified_gmt":"2026-08-03T13:11:56","slug":"empty-sandboxes-break-developer-experience","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/03\/empty-sandboxes-break-developer-experience\/","title":{"rendered":"Empty sandboxes break developer experience"},"content":{"rendered":"

I work on Docker Sandboxes<\/a>, so I spend a lot of time talking about isolation, microVMs, disposable filesystems, blast radii, all the good infrastructure things.<\/p>\n

But the Docker Sandboxes feature I keep reaching for in daily use is kits<\/a>.<\/p>\n

Kits sound like a packaging detail until you try to use a sandbox for real work. An empty sandbox is a good boundary. It\u2019s also (eventually) ephemeral and empty, and that combination means annoyance and repeated setup work.<\/p>\n

The agent gets a clean filesystem, a baseline restricted network, and a clean credentials environment. Then it immediately needs gcloud<\/code>, Java, Maven, some internal CLI, your package registry credentials, and that one skill where you distilled the tacit knowledge your team accumulated for years.<\/p>\n

Kits are the escape hatch from that ritual. A kit lets you describe what the sandbox needs, how it should get it, what it may reach, and which credentials it can use, then apply that description when the sandbox starts.<\/p>\n

Empty means setup work<\/h2>\n

The usual sandboxing story is security-shaped: put the risky thing behind a boundary and limit the blast radius.<\/p>\n

Developers rarely keep using tools because the architecture diagram has a nice boundary on it. They keep using tools when the workflow is less annoying than the alternative.<\/p>\n

A blank sandbox starts from a place developers rarely start from in practice. Real developer machines have: SDKs, package managers, cloud CLIs, shell setup, local credentials, project docs, cached tools, and configuration nobody wants to reconstruct from memory. Some of it is good engineering. Some of it is archaeology. Both affect whether the agent can complete the task.<\/p>\n

The failure is rarely dramatic. The agent spends a few minutes installing packages, hits a blocked registry, asks for an API key it should never see, and the sandbox starts to feel like the thing between you and the work.<\/p>\n

At that point, the developer has a choice: spend ten minutes preparing the isolated environment, or run the agent on the host and move on with their life.<\/p>\n

We all know which one will win.<\/p>\n

What is an sbx kit?<\/h2>\n

The kits docs<\/a> describe a kit as a spec.yaml<\/code> plus optional files. The useful mental model is simpler: a kit is the contract between the sandbox and the tool you want available inside it.<\/p>\n

A kit can install tools:<\/p>\n

\n
\nschemaVersion: \"1\"\nkind: mixin\nname: jq\n\ncommands:\n  install:\n    - command: \"apt-get update &amp;&amp; apt-get install -y jq\"\n\n<\/pre>\n<\/div>\n
That is the smallest version. Useful kits usually do more. They can drop files into \/home\/agent\/<\/code> or the workspace, set non-secret environment variables, run startup commands, start background services, and add agent context to files such as CLAUDE.md<\/code> or AGENTS.md<\/code>.<\/p>\n
They can also describe the outside world the sandbox is allowed to touch:<\/p>\n
\n
\nnetwork:\n  allowedDomains:\n    - api.example.com\n    - \"*.cdn.example.com\"\n  deniedDomains:\n    - telemetry.example.com\n<\/pre>\n<\/div>\n
And they can connect credentials without copying real secrets into the microVM. The standard pattern keeps the credential on the host, gives the agent a sentinel value, and lets the sandbox proxy inject the real header only when the request goes to an approved service.<\/p>\n
\n
\nnetwork:\n  allowedDomains:\n    - api.example.com\n  serviceDomains:\n    api.example.com: my-service\n  serviceAuth:\n    my-service:\n      headerName: Authorization\n      valueFormat: \"Bearer %s\"\n\ncredentials:\n  sources:\n    my-service:\n      env:\n        - MY_SERVICE_API_KEY\n\nenvironment:\n  proxyManaged:\n    # Agent sees \"proxy-managed\"; the host proxy injects the real token.\n    - MY_SERVICE_API_KEY\n\n<\/pre>\n<\/div>\n
Inside the sandbox the agent sees MY_SERVICE_API_KEY=proxy-managed<\/code>. The actual secret stays on the host. The proxy replaces the header on the way out.<\/p>\n
That distinction is why credential support belongs in the kit contract. If the sandbox exists to keep the agent away from host secrets, copying those secrets into the microVM would be a strange way to celebrate.<\/p>\n
\n                \"Screenshot\n        <\/div>\n
\n
Mixin kits are the norm<\/h2>\n<\/p>
There are two kit shapes in the spec. A kind: sandbox<\/code> kit defines a full agent runtime: image, entrypoint, policy, the whole thing. Use that when you are building an agent.<\/p>\n
Most integrations should be mixins.<\/p>\n
A mixin kit extends an existing sandbox with one capability. It installs the tool, opens the narrow network path, wires credentials, and gives the agent enough instructions to use the thing. The runtime stays with the agent kit.<\/p>\n
That is the shape I use for most of my own kits. For example, the kits I keep using daily are agy<\/code><\/a>, yt-transcript<\/code><\/a>, and tessl<\/code><\/a>.<\/p>\n
The YouTube kit is exactly what you think: give the sandbox the tools to fetch transcripts and media metadata without turning every new sandbox into a small dependency archaeology project. The Tessl kit is even more direct. It brings skills into the agent running inside the sandbox, so I do not need to inject them manually like a medieval peasant.<\/p>\n
The nice part of mixins is that they stack.<\/p>\n
A giant \u201cOleg\u2019s entire laptop, but in a microVM\u201d kit would be funny once and then become a maintenance incident. You want small kits with clear jobs:<\/p>\n