OpenClaw Sandbox:让代理接触代码前先隔离

OpenClaw Sandbox:让代理接触代码前先隔离 — OpenClaw sandbox 实战指南:按任务创建 worktree、使用限权 token、VPS 隔离、网络限制,以及由 Office Claws 管理的 Codex 工作流。
2026年6月17日2 分钟阅读
Share with

为什么 OpenClaw sandbox 应该成为默认安全模式

OpenClaw 风格的编码代理很强,因为它们能运行命令、编辑文件、安装依赖,并在后台持续工作。也正因为如此,在它们接触真实仓库、共享 .env 或生产部署路径之前,必须先进入 sandbox。

Office Claws 不是原生 OpenClaw runtime。但安全运营模型仍然适用:控制平面留在本地,高风险工作放进可丢弃 runner,Codex-backed 代理只在受限 workspace 内执行。如果你还在选择执行层,先看 OpenClaw vs Codex。本文关注代理外层的 sandbox。

从本地密钥库到一次性 runner 的 OpenClaw sandbox 信任边界

sandbox 里应该包含什么

好的 OpenClaw sandbox 应该比开发者电脑更小,也比普通 VPS 更严格。

层级Sandbox 规则为什么重要
源码每个任务一个新分支或 worktree避免一个代理破坏另一个任务
密钥使用限权 token,不给 operator vault降低 prompt injection 后的影响面
网络允许包仓库和 GitHub;其他流量需审查减少外泄和意外回调
文件系统可写 repo、临时 cache,不污染 home清理更可靠
RuntimeCPU、内存、时间和花费限制阻止失控命令和 API 循环
输出PR、patch、logs 和测试结果让人工 review 可读

这就是 OpenClaw security best practices 的落地版本:代理有价值,但它的环境可能被不可信代码影响。

实用架构

安全结构包含四部分:本地操作机器、credential broker、一次性 runner 和 review gate。

Office Claws desktop
  ├─ 本地保存长期 provider 与 GitHub credentials
  ├─ 审批任务、分支、预算和 runner 策略
  └─ 回传 logs 与 status


credential broker
  └─ 为一个任务签发短期 repo token


VPS sandbox
  ├─ 全新 checkout 或 worktree
  ├─ Codex-backed 执行
  ├─ 磁盘上没有 production secrets
  └─ 完成后销毁或重置


PR / patch review

远程执行可参考 OpenClaw on VPSOpenClaw desktop manager。Office Claws for OpenClaw users 在这里是本地优先的管理层:协调 runner、集中可见性,避免把某个终端窗口变成控制平面。

sandbox 应该限制哪些故障

OpenClaw sandbox 故障模式与控制

  1. 来自仓库内容的 prompt injection。 Issue、README、package scripts 和 fixtures 都不能默认可信。
  2. 被污染的依赖。 runner 可以安装包,但必须是可丢弃的。
  3. 失控成本。 对模型调用、运行时间、队列和重试设置预算,避免昂贵循环。
  4. 脏 workspace。 一个任务对应一个分支、一个 worktree、一个 review 表面。

因此 OpenClaw monitoring 必须和 sandbox 放在一起:logs 与恢复机制本身就是安全控制。

最小可用 checklist

  • 每个重要任务创建新的 worktree 或 VM。
  • 使用 repo-scoped、短有效期 GitHub token。
  • provider keys 留在本地或 broker 中。
  • 不让 production credentials 进入 runner。
  • 在 sandbox 中运行测试,并随 patch 发布结果。
  • 让人不用 SSH 挖日志也能查看 logs。
  • 任务完成后删除或重置 runner。

目标不是削弱代理,而是让错误变得便宜、可见、可回滚。

Office Claws 的位置

Office Claws 让这种模式更容易运营:desktop management、VPS runner provisioning、queue visibility、log review 和更安全的本地密钥处理。它今天是 Codex-first;诚实的说法不是“Office Claws 原生运行 OpenClaw”,而是 OpenClaw 用户需要一个稳定的运营层来管理同类自主编码工作流。

继续阅读 Office Claws for OpenClaw usersOpenClaw vs Codex,以及 OpenClaw secrets management

建议

把 sandbox 设为默认:本地控制、远程隔离、可见 logs、限权 tokens,并在任何重要变更前进行 review。

作者

Office Claws Team

在 Office Claws 构建 AI 智能体管理的未来。分享关于基础设施、安全和开发者体验的见解。

保持关注

获取关于 AI 智能体、基础设施和产品更新的最新文章,直达你的收件箱。

无垃圾邮件。随时退订。