Why I built Shed: running agents in sandboxes should be easier

I started running coding agents in dev containers because that was the shape VS Code and IntelliJ already understood, but it never quite fit. I didn’t want docker-in-docker, I didn’t want to mount secrets into an image, and I didn’t want to copy the same mounts and setup code into every project-specific container. Most of my agent use is CLI-first anyway, so the IDE was not the thing I wanted to optimize around.

What I wanted was closer to a standard base environment I could SSH into anywhere: my laptop, a Mac mini, a Linux laptop, or the mini-PCs on my network over Tailscale. It should have the usual mounts, work across macOS and Linux, and let an agent use the credentials it needs with an audit trail instead of just handing the VM my keys. The goal is to make running a coding agent in an isolated environment on any of my machines feel as easy as running one on my main machine. Shed is not all the way there yet, but the primitives are starting to feel right.

A shed is a VM, on whatever machine you point at

Each environment, a “shed”, is a real virtual machine: Apple Virtualization on macOS, Firecracker on Linux. That gives an agent a genuine kernel boundary to work inside, not a namespace shared with everything else on the box.

The part I lean on most is that a shed does not have to be local. A shed-server runs on each host, so the same shed CLI creates and manages environments on my laptop or on a server across the room, interchangeably. I run a few Linux mini-PCs over Tailscale and point work at whichever has capacity. macOS and Linux, local and remote, one workflow.

Keys it can use but never holds

This is the piece I care about most. An agent in a sandbox still needs to do real work: git push, pull a private Docker image, call AWS. The usual answer is to copy those keys into the environment, which is exactly what I did not want to do with an agent.

So Shed never mounts your SSH, AWS, or Docker credentials into the VM. Instead, shimmed helpers inside the shed forward each request over a vsock bus to shed-host-agent on your machine (it ships in shed-extensions). The host does the sensitive part: your SSH key signs there and never leaves, an AWS role is assumed to vend short-lived credentials, a Docker login is resolved. Every use, across all three, is audited and targeted, so you can see exactly what an agent reached for.

Approval is finest-grained for SSH, the one I most want eyes on: it supports detailed per-request approval, gated by Touch ID on macOS. AWS and Docker are allow-or-deny for now, which is an obvious thing to make richer later. On macOS the approval surface is the shed-desktop app.

There is one honest exception. The agent’s own login does get mounted into a shed, so I don’t have to re-authenticate Claude in every new environment and it can be reused across sheds on a host. The broker is about keeping cloud and infrastructure credentials out of the VM; the agent’s session is a convenience I chose to keep.

Reach it like any other box

Every shed has an SSH endpoint, so I connect to one the same way I would any remote machine. Cursor, VS Code, Zed, and JetBrains Remote-SSH all attach straight into a running shed, and the VM and its tmux session keep going after I disconnect, so reattaching lands me exactly where I left off. That is what makes a shed feel like a place to work rather than a container I have to babysit.

Hand it a plan and walk away

The newest piece pulls the threads together. shed attach <name> --plan plan.md -d ships a plan into a shed and starts a Claude session that executes it unattended, printing a claude.ai/code URL I can watch and steer from. With remote sheds, that means I can kick off a refactor on a mini-PC and let it keep running after I step away. The agent is sandboxed, working from my plan, using brokered credentials, on a machine in the other room.

Throwaway when you want, durable when you don’t

A lot of the time a shed is scoped to one thing: a branch, a refactor, a plan. I spin one up, let it work, and delete it when the feature lands, which is easy because a microVM boots in about a second. But nothing forces that. The VM and its session persist if I keep them, so the same shed can be a long-lived home for a project just as easily. Light enough to throw away between features, durable enough to live in.

Where it stands

Shed is one of my bigger projects and still moving quickly. It is single-user today, though auth landed recently as a first step toward more, and pieces like egress filtering, the desktop and mobile surfaces, extensions, and the plan workflow are still settling. I would call it alpha. But the core is the thing I set out to build: coding agents I can run anywhere I have a machine, reach from my editor, and trust with real work, while my cloud and infrastructure credentials stay on the host instead of the VM.