JailBee
Four projects come up whenever this one does. They are all good, and they sort into two families answering two different questions: how do I get the right toolchain, per branch? and how do I stop the agent from wrecking my laptop? JailBee answers both at once, which is exactly why it is heavier than either.
Pick Dev Containers if a shared toolchain is what you need, or if anyone on the team is on macOS or Windows. It is the standard, and JailBee has nothing to add.
Pick Docker Sandboxes if you need a hypervisor between the agent and your laptop. Its microVM is a genuinely stronger boundary than JailBee's.
Pick JailBee when the runtime is the hard part: a stack that
boots, listens, renders and occasionally wants /dev/kvm — several of
them at once, with an agent working behind the fence.
Note the two rows where JailBee is the one that can't. They are the trade, not an oversight.
| Dev Containers | BranchBox | nono | Docker Sandboxes | JailBee | |
|---|---|---|---|---|---|
| What it is | a toolchain in a container | a worktree + Compose per feature | a fence around one process | a microVM per agent run | a Linux machine per branch |
| Boundary | host Docker daemon | host Docker daemon | Landlock + seccomp | hypervisor, own kernel | Incus container, shared kernel |
Run the repo's docker-compose.yml without touching the host's
Docker daemon
|
partial — privileged docker-in-docker | no | no | yes | yes |
Two branches both listening on :3000 |
partial — each forwarded to a different host port | partial — a port range per feature | no | yes | yes |
| A browser and an IDE inside the boundary, on your own screen | partial — community noVNC only | no | not applicable — they run on the host | no | yes |
| Restrict what the code inside can reach | no | no | yes — per tool, HTTP | yes — HTTP(S) only, rest dropped |
yes — host:port, any protocol
|
| Keep an agent out of your real checkout | partial — opt-in clone into a volume | no | partial — per-path grants |
partial — --clone
|
yes — always its own clone |
| Snapshot before an agent runs, roll back after | no — rebuild | no | not applicable | no — recreate | yes |
| Hold up when the kernel is what breaks | no | no | no | yes — own kernel per sandbox | no — shared kernel |
| Work on macOS or Windows | yes | partial — macOS | yes | yes | no — Linux only |
| Licence | open spec (MIT) | MIT | Apache-2.0 | free CLI, sign-in required | GPL-3.0-or-later |
yes · yes, with the caveat named · no · the question doesn't apply. Scroll sideways for the full grid.
Most sandboxes work by enumeration. You declare which paths, which hosts, which syscalls, which tools — and everything the workload does has to fit through that list. It is precise, and it works beautifully when you know in advance what the workload will do.
Agentic development is the case where you don't. The agent decides it needs
docker compose up. Then an emulator. Then a headless browser, then a
real one. Then a package manager you have never installed. With an allowlist, every
one of those is a policy change, and each one widens the policy for everything else
— so the isolation degrades exactly as the work gets interesting.
JailBee moves the boundary instead of enumerating through it. The container is the boundary; what happens inside is your business. Adding a tool costs nothing, because nothing was enumerated in the first place.
privileged
docker-in-docker feature or bind-mounting the host's Docker socket, which is host
root by another name. devcontainer.json declares the tools a repo
needs; .jailbee/config.yaml declares the machine it needs.
gh, but
gh gets its own filesystem grants and a proxied token. It is the
allowlist model, and it cannot give you a second Postgres or a second port 3000,
because it is not an environment. Its own docs recommend running it inside a
container when you need guest/host isolation — running nono inside a
JailBee container is a sensible combination, not a contradiction.
sbx puts a stronger wall around one agent run; JailBee gives you a
whole machine per branch with a weaker — though still kernel-enforced — wall
around it.
git worktree plus docker compose -p is free and already
installed.
jailbee ide knows the JetBrains launchers, and there is no Dev
Containers integration. VS Code is not ruled out — the passthrough is generic, so
installing it into the golden image and starting it from a shell works — but
nothing ships to do it for you.
sbx) is the stronger design for those.
Read the full technical comparison — every row of the grid above with its caveats, how the repo's config spends the genericity, and the sources each claim was checked against.