den gives every coding agent a sandbox of its own: a private microVM with its own filesystem, daemon, and guarded network. It works unattended in there. Your machine never stirs.
den is the app for Docker Sandboxes: a GUI for everything the sbx command can do, and then some. It's a map so you don't get lost, with no commands to memorize. Group your sandboxes and give each one a color and a name, so you can tell them apart at a glance. Find them, spin up new ones, and manage them live: stream logs, add kits, open ports, and shape network policy, all without leaving the map.
Each agent works sealed inside its own microVM, with its own filesystem. It installs tools and changes files freely, and your files stay untouched.
Private Docker daemon, filesystem and kernel for every session.
When a den has served its purpose, collapse it and dig a new one.
Clone from Git or GitHub and work on a branch. See every change before it lands, then commit or open a pull request, all without leaving den.
Native on macOS and Windows. No cloud round-trips.
Every sandbox reaches the world through a gate you control. Name what it may reach; everything else is turned away at the door.
Out of the box, the agent can't reach anything online. You decide what it's allowed to talk to.
Choose Allow all, Balanced, or Deny all, then open the exact domains it needs by name.
See everything it reached for, allowed or turned away.
Bundle the tools, connections and context a job needs into a kit, then drop it onto any sandbox. Stack a few, save them, reuse them everywhere.
Wire in services like Notion, Linear or GitHub, so the agent can use them straight away.
Pack the domains a job needs; they're allowed the moment the kit goes on.
Hand over the keys and settings a tool expects, kept to that sandbox.
Seed it with notes and files so it starts with the context, not a blank page.
A sandbox is a small, private computer that spins up in a couple of seconds. Inside it, an agent can build images, install tools and rewrite files as freely as it likes, because it has its own filesystem, its own Docker, and its own network.
None of that touches your machine. When the work is done you keep the changes you like and throw the sandbox away, or dig a fresh one for the next task. Think of it as a workbench you can conjure and collapse at will.
A kit is a small recipe, written as a short YAML file, that's applied the moment a sandbox is created. It can install tools, connect remote services, set environment variables, open up the domains a job needs, and drop in notes so the agent starts with context instead of a blank page.
There are two flavours. A mixin kit layers extras onto an agent you already use, and you can stack several on one sandbox. A sandbox kit goes further and describes a whole agent from scratch, down to its base image and entrypoint.
name: workspace-context kind: mixin mcp: [notion, linear] env: [NOTION_API_KEY, LINEAR_API_KEY] network: allow: [api.notion.com, api.linear.app]
Each sandbox is a full virtual machine, not just a container. It has its own kernel, filesystem, Docker daemon and network, separated from your host by a hypervisor boundary, and sandboxes don't even share images or layers with each other.
The only way out is through a proxy that runs on your machine and enforces your rules, and your project is mounted in on a controlled path rather than opened up. So whatever the agent does, mistakes included, stays inside the box.
Your secrets never enter the sandbox. They stay on your machine, and the host-side proxy injects them into outbound requests as they leave, so the agent can call an API with your key without ever seeing the key itself.
That means a leaked prompt or a rogue dependency can't walk off with your tokens. You decide which secrets each sandbox may use and where they come from, whether that's your shell, a .env file, or a password manager like 1Password.
Point a sandbox at your repo and let the agent work on its own branch. When it's done you review the diff like any pull request and merge what you want, or have it open the PR for you. Nothing lands in your working tree until you say so.
Because each sandbox is cheap and disposable, you can run several at once, one per task or experiment, without them stepping on each other. And when an agent starts a dev server, forward its port to open it in your browser.
The source is open: you can read it, build it, and run it yourself. den is fair-source, use and modify it however you like, for anything except repackaging den itself as a competing product.
That lets me keep stewarding the project, and maybe offer a hosted version down the road, while the code stays open and yours to run. Each release also turns fully open after a couple of years, so it can never be locked away, including by me.
Of course. I build den, and I use it every day for my own work: it's how I keep agents on a long leash without worrying about my machine. Safer YOLO sessions, basically.
If you give it a try, I'd genuinely love to hear how it goes, the good and the rough edges alike. Don't hesitate to reach out.