Sandbox

A sandbox is a spare workbench in the garage. The agent can smash the prototype. The house stays intact.

It can write files, run commands, maybe hit the network — but only inside a box you defined. Docker, a VM, a restricted workspace: same wall. If it rm -rfs, it rm -rfs a copy you can throw away in seconds.

Where is it running?

That is the question to ask before you let an AI do something with real consequences. On your laptop, with your logged-in accounts and your real repo, you watch it like a hawk. In a proper box, you check the result.

It sits next to two other fences. Permission scope is which doors the keycard lights. The sandbox is the building those doors are even in — so a door it should not try still opens onto nothing real. Guardrails decide whether the work order runs at all.

One honest catch: a box is only as strong as its walls. If it can still see your home directory, your env file, or the open internet, the mess can leak. Sealed by default. Widen only when the bench is too small for the job.

This product's MCP tools already refuse a full shell. ds_create_project writes a stack through the engine, not through bash. That is a kind of sandbox: the intern gets a window, not the workshop keys. Unsandboxed shell on your machine is still a master key. Don't start there.

What this unlocks

Powerful and caged beats powerful and loose. You can say yes to an agent that runs commands because the worst case is a disposable room.

Let it work. Build the walls first.