This lesson's interactive features are locked, please to keep using them
Sandboxing
If you've ever thought,
Gee, maybe it isn't smart to allow a stochastic parrot to access all the data on my machine and execute arbitrary code...
rest assured, you're not crazy. That's where sandboxing comes in. You run OpenCode, or something even more autonomous like OpenClaw, in an isolated environment with limited access to your files, credentials, and network.
Then, if it does something dumb, you've at least limited the blast radius. The degree of protection depends on how heavily you locked down the environment.
When Should You Sandbox?
Sandboxing is especially useful when you're running unfamiliar code or dependency install scripts, working near sensitive data, or letting an agent run more autonomously with fewer approval prompts.
For a familiar project, you may choose to work directly on your dev machine and review any dangerous tool requests. But approving a command does not isolate the code it runs, and careful prompts don't guarantee safe behavior.
How to Sandbox
There are about as many ways to sandbox as there are to skin a cat.
- You can buy a separate machine and run OpenCode there.
- You can run OpenCode in a dedicated virtual machine locally or in the cloud.
- You can run OpenCode in a Docker container with access only to the project files it needs.
There isn't a right answer, but be deliberate about what you share with the model! A container can still change a host folder that you mount with write access. Credentials and network access can also let code inside the sandbox affect systems outside it.
One benefit of sandboxing that may surprise you is productivity. In a disposable environment with limited access, you can be much more permissive with your agent and let it run for longer without needing to babysit it the whole time.