Darren Shepherd, Obot’s Chief Architect, has been quietly building something, and last Friday on Sept 25 he showed it off for the first time. It’s called Discobox, and the idea fits in one line:
Give every coding agent its own machine.
If you’ve followed Darren on X lately, you’ve probably wondered what he’s been up to. This is it. Discobox is fully open source, and it came out of his own frustration. He wanted to let agents run free and do many things at once, without handing over the laptop he does real work on.
We spent an hour live walking through it. Watch the full livestream here, or read on for the highlights.
Why agents need their own machine
Darren builds on two simple observations. The more access you give an agent, the more it can do. And you want many agents working in parallel. Both of those run straight into our justified worries about safety and control.
Most people doing agentic development today use one of two setups:
- One directory, one agent. The agent works where your code lives, on your desktop, with your tools.
- Git worktrees. Want to work in parallel? Spin up a new worktree, which is a new directory for a second agent.
That works fine until you want the agent to do more than write code. Darren wanted it to run the app, open a browser, test the thing, and install whatever tools it needed. “The only way I could figure out how to do that,” he said, “is basically just give it its own machine.”
I feel this pain as a heavy vibe coder. As soon as I let agents loose on my work laptop, I end up with random stuff installed and Chrome windows popping open. I really don’t want my fantasy football side project running on the machine I use for real work.
There’s also a naming problem. “Sandbox” means a lot of things now. In most desktop coding agents, it means a process on your laptop with restricted permissions. When Darren says sandbox, he means a completely isolated computer, with its own network, process space, and disk.
What Discobox actually does
Discobox is a client and server for creating and managing these isolated machines. You bring your own coding agent (Discobox calls them harnesses). Claude Code, Codex, and OpenCode work today. Here’s what Darren showed in the demo:
- Isolation by default. On a Mac, Discobox starts a VM in the background and runs each box inside it, fully walled off from your desktop.
- Code in, code out. Start a box from your local directory or a Git repo. When you’re done,
discobox applycherry-picks the agent’s commits back to your machine. Or you can have it open a PR. - It still feels local. When the agent starts a server, Discobox spots the open port and forwards it to your localhost automatically.
- Your tools, in the box. SSH into any box with one command, or launch an IDE like Zed as a remote dev environment. There’s also a built-in diff and file viewer.
- A full desktop. Every box has its own desktop and browser. The agent can click around your app without taking over your screen. You can watch, take a screenshot, and hand it back as feedback.
- Real parallelism. Every session is completely isolated from every other one. Darren typically has around 30 sessions open and actively works on four or five at a time.
Remote development has always been painful. Darren’s point is that it stops mattering when the agent does most of the work. What you need is visibility and control, not files sitting on your own disk.
The hard part: secrets
Everything is easy while the agent stays inside its box. The scary part is when it needs to reach out, for example to push code to GitHub. Darren has spent more time on this problem than on anything else.
A box starts with no secrets and no access. When the agent needs a credential, it has to ask for it in plain language. The request says what it needs, for which host, for how long, and why. You approve it, and here’s what happens next:
- The agent never sees the real token. It gets a sentinel, a fake value that only looks like a token.
- An AI judge checks the command. Does it match the purpose you approved? Would it leak the secret, say by writing it to a temp file? If so, it’s rejected.
- All traffic leaves through a proxy. A second check there asks whether the network request matches the approved use. Only then is the sentinel swapped for the real value.
- The host is locked. A token approved for github.com only ever goes to github.com. If the agent tries to send the sentinel anywhere else, it’s worthless.
The result is time-bound, purpose-bound access with no need to hand-craft fine-grained tokens. Policies are natural language in markdown, so you can keep them in Git. You can grant access ahead of time, for example “read issues and add these labels,” or approve requests as they come in. An audit log records every command and every HTTP request, down to the full request body. As a bonus, it shows you just how much telemetry the coding agents send home.
Wearing my Obot hat, this is the part I find most interesting. Giving agents credentials with a clear objective, a time limit, and AI enforcement is a pattern that reaches well beyond coding.
Where it’s headed
Darren is clear that Discobox is not just about writing code. The goal is to run your engineering process: triaging issues, investigating bugs, and all the small manual tasks in between, each one in its own box.
- Discobox running Discobox. A box can launch other boxes, with permissions delegated through the same natural-language system. They’re siblings, not nested boxes. Darren had one agent split a big feature into about 40 issues. A manager box then spins up a worker box for each issue and stops for a human when something like a design review (ADR) needs sign-off.
- Sessions that stick around. Idle boxes shut down and cost only storage, so you can reattach later. His triage box doesn’t just write a failing test. It sets up a running environment that reproduces the bug, ready for you to look at.
- Run it anywhere. The client can connect to several servers at once. Darren runs most of his boxes on a big Threadripper box rather than his laptop. Integrations with sandbox providers and Agent Substrate on Kubernetes are in progress. Each box will move to its own micro VM for stronger isolation.
On that last point, Darren is upfront about where things stand. Today it’s one VM with containers inside. That’s efficient on a laptop, but it isn’t the final security model yet. He chose to get the experience right first.
Try it
brew install discobox-ai/tap/discobox
Then run discobox from the directory you want to work in. The best way to learn it, Darren says, is to ask the agent inside a box about Discobox itself. Nothing you do in there can hurt your machine.
A fair warning: this is built for engineers. If you’re already at home running Claude Code or Codex from the command line, and you understand the basics of remote development, it’ll feel natural. If not, expect some rough edges while the onboarding and docs catch up.
- Site: discobox.ai
- Code: github.com/discobox-ai/discobox. Star it if you like it.
- Community: join the Discord and ask Darren questions directly.
Contributions are welcome, and that includes AI-written issues and PRs. “If you put in AI-generated slop, I’m using AI to consume it anyways,” Darren said. Just know his agent might find a better way and reimplement your idea itself.
This is the first in a series. Darren and I will be back live to go deeper on secrets, multi-agent orchestration, and running Discobox on remote sandbox providers. Catch the first episode here.
