# Sandbox (/academy/sandbox)



A sandbox is a spare workbench in the garage. The [agent](/academy/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](/academy/docker), a VM, a restricted workspace: same wall. If it `rm -rf`s, it `rm -rf`s 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](/academy/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](/academy/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](/academy/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](/academy/mcp) tools already refuse a full shell. `ds_create_project` writes a [stack](/academy/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.