Verboo Code 可以把代理自行决定执行的 Bash 命令放进一个操作系统级别的沙箱里运行，沙箱之外没有网络访问权限（除非在允许列表里），也不能写入未授权的文件夹。这个功能已经内置在 CLI 里，只是默认是关闭的，而大多数每天使用 Verboo Code 的人从来没输入过打开它的命令：/sandbox。
如何在 Verboo Code 中启用命令沙箱？
在你的用户配置里加上 sandbox.enabled: true（千万不要写在项目自己的配置文件里，原因见下文）。之后，Bash 以及其他会碰文件系统或网络的工具，都会先尝试在沙箱里运行，再决定要不要弹出确认。
{
"sandbox": {
"enabled": true
}
}
沙箱支持 macOS、Linux 和 WSL2，不支持 WSL1。在 Linux 和 WSL2 上，你还需要安装两个依赖：
sudo apt install bubblewrap socat缺少这两个依赖时，Verboo Code 不会假装命令已经被沙箱化，它会提醒你少了什么，并告诉你该装什么。
为什么不能直接在项目的 settings.json 里打开这个功能？
因为这恰恰是一个不受信任的仓库最容易预先写好的文件。sandbox.enabled 这个开关只会从你自己的用户配置或本地（不会被提交）配置里读取，绝不会从项目自带的配置文件里读取。一个恶意仓库没办法只靠你克隆下来的一个文件，就关掉你的沙箱，或者让你误以为它已经开着。
运行 /sandbox 会看到什么？
一个包含 4 个标签页的菜单，足够配置和诊断沙箱，不用手动改 JSON：
| 标签页 | 显示内容 |
|---|---|
| Mode | 当前模式（Auto-allow 或关闭）以及切换选项 |
| Overrides | 你已经标记为始终在沙箱外运行的命令 |
| Config | 允许访问的网络域名和其他细节选项 |
| Dependencies | 你的系统上还缺少什么，如果有缺失的话 |
沙箱打开后，命令的审批方式会有什么变化？
Auto-allow 模式下，命令会自动尝试在沙箱里运行，不会停下来询问你。如果某个命令因为某种原因没法沙箱化，就会退回到常规的权限流程，照常弹出确认。你已经设置好的明确 ask 或 deny 规则，在这两种情况下依然生效。
这改变了由谁来决定命令能不能运行。没有沙箱时，是你在每条 Bash 命令执行前亲自批准。开启 Auto-allow 后，做出批准决定的变成了沙箱本身的边界：只要命令被限制住了，它就直接运行。但这只能保护配置里真正限制到的部分。举个例子，如果某个敏感域名被列在 allowedDomains 里，被沙箱化的命令依然可以从沙箱内部访问它。在把一切都交给 Auto-allow 之前，值得先回头检查一遍这份列表。
如何限制网络访问，或者给个别命令开例外？
要限制被沙箱化的命令能连接哪些域名，使用 network.allowedDomains：
{
"sandbox": {
"enabled": true,
"network": {
"allowedDomains": ["registry.npmjs.org", "github.com"]
}
}
}
反过来，如果某个特定命令必须在沙箱外运行，直接在会话里用 /sandbox exclude：
/sandbox exclude "npm run test:*"这会把这个模式写进项目的本地配置（不会被提交的那个文件），从此这条命令就会一直在沙箱外运行，不用每次都重新确认。
让代理自己执行命令，本身就是拿控制权换速度。沙箱不会消除这笔交易，但会改变可能造成的损失有多大：与其只依赖人工审查每一行命令，不如在操作系统层面再加一道边界。如果你已经在让 Verboo Code 不经确认就运行命令，这项设置就能在不拖慢代理的情况下，把那扇门关上。
