Verboo Code can run the Bash commands the agent decides to execute inside an OS-level sandbox, with no network access outside an allowlist and no writes outside the folders it's allowed to touch. The feature already ships in the CLI, but it's off by default, and most people who use Verboo Code every day have never typed the command that turns it on: /sandbox.
How do you enable command sandboxing in Verboo Code?
Add sandbox.enabled: true to your user settings (never to the project's settings file, more on why below). From then on, Bash and other tools that touch the filesystem or the network try to run inside the sandbox before asking for confirmation.
{
"sandbox": {
"enabled": true
}
}
Sandboxing works on macOS, Linux and WSL2. WSL1 isn't supported. On Linux and WSL2 you also need two dependencies installed:
sudo apt install bubblewrap socatWithout them, Verboo Code doesn't pretend the command was sandboxed: it tells you the dependency is missing and what to install.
Why can't you turn this on in the project's settings.json?
Because that's exactly the file an untrusted repository could ship pre-filled. The sandbox.enabled flag is only read from your user settings or your local (untracked) settings, never from the settings file that comes inside the project itself. A malicious repository can't turn off your sandbox, or make you believe one is on when it isn't, just by editing a file you're about to clone.
What shows up when you run /sandbox?
A menu with 4 tabs, enough to configure and diagnose the sandbox without hand-editing JSON:
| Tab | What it shows |
|---|---|
| Mode | the current mode (Auto-allow or off) and the option to switch |
| Overrides | the commands you've already marked to always run outside the sandbox |
| Config | allowed network domains and other fine-grained options |
| Dependencies | what's missing on your system, if anything is |
What changes in command approval once the sandbox is on?
In Auto-allow mode, a command tries to run inside the sandbox automatically, without stopping to ask. If it can't be sandboxed for some reason, it falls back to the regular permission flow, with the usual prompt. Explicit ask or deny rules you've already set still apply either way.
This changes who decides whether a command runs. Without sandboxing, you approve every Bash command before it executes. With Auto-allow on, the sandbox boundary itself is what approves it: if the command is contained, it runs straight away. That only protects what the configuration actually restricts. A command with access to a sensitive domain listed in allowedDomains, for example, still has access to that domain from inside the sandbox. It's worth reviewing that list before relying on Auto-allow for everything.
How do you restrict network access and add a one-off exception?
To limit which domains a sandboxed command can reach, use network.allowedDomains:
{
"sandbox": {
"enabled": true,
"network": {
"allowedDomains": ["registry.npmjs.org", "github.com"]
}
}
}
For the opposite case, a specific command that needs to run outside the sandbox, use /sandbox exclude right in the session:
/sandbox exclude "npm run test:*"That writes the pattern to your project's local settings (the untracked file), and that command runs outside the sandbox from then on, without asking again every time.
Letting an agent run commands on its own is already a trade of control for speed. Sandboxing doesn't remove that trade, but it changes how much damage is possible: instead of relying only on human review of every line, there's a second boundary at the operating system level. If you already let Verboo Code run commands without confirming each one, this is the setting that closes that door without slowing the agent down.
