Why not…?

byre is a thin layer over the Docker or Podman you already run, and every alternative below has a real answer. But one difference cuts across all of them: byre brings your environment with you, per folder. Your skills, templates, packages, agent logins, and creature comforts arrive in every box automatically – isolation is table stakes, and the comfortable half is what nothing else on this list does. With that said, the specifics:

…raw Docker? Nothing – and byre never takes it away. You’d just be hand-rolling what it generates: host-matched file ownership, per-project agent login that survives rebuilds, templates, a clean reset. If you want to stop using byre, byre dockerfile prints your exit.

…Docker Sandboxes™? Commercial product with a hosted control plane (you sign in) and paid tiers. Not open source. (But it gives you kernel-level microVM isolation, and we don’t.)

…your agent’s built-in sandbox? All-or-nothing file isolation, on your real machine, wearing your identity. Env vars and credentials come along by default, so a stray git push goes out as you. byre’s box contains nothing that you didn’t put in it.

…nothing – just keep YOLOing on the host? The host is the incumbent: zero setup, and nothing bad has happened yet. But the agent works as you, in your real home dir – byre exists because Claude went editing a sibling repository and did things with an ssh key it shouldn’t have. The box costs one command, so the host’s convenience argument is gone. (If you’ve never had the scare, you may not feel the need – byre is for after your first one.)

…devcontainers? You hand-write the Dockerfile and JSON per project, and wire up agent credentials yourself. byre generates the Dockerfile from config – byre config adds a package, mounts another repo read-only, or swaps agents in seconds. (But it’s the mature industry spec, and we’re young.)

…container-use? Explicitly experimental, and MCP-shaped: your agent manages a fleet of environments; you don’t sit inside one. byre does parallel the git way – one boxed session per worktree, sharing the repo’s image, volumes, and agent login.

…a cloud sandbox (e2b, Daytona, your agent’s web offering)? Account, usage billing, your code in their cloud – and they’re repo-shaped, built for shipping agent products or driving a GitHub repo. byre is for dropping into whatever folder you’re standing in.

…a cheap VPS (a Hetzner box)? A box per project doesn’t scale across many repos – and half of what you’d point an agent at isn’t a repo, just a folder. byre is a throwaway box per folder, on the machine you’re already sitting at, with your toolkit already inside. (But a remote box is real hardware isolation – if the agent must never share a kernel with your machine, rent one.)