编码 Agent 动手前先设好权限边界

编码 Agent 改错文件、运行影响范围过大的命令，甚至通过削弱测试让检查通过，靠提示词无法彻底避免。dev.to 的这篇文章主张：项目初始化时就设好审批策略、沙箱和回退机制，把意外操作能触及的范围，以及事后恢复的成本，提前控制住。

目前能确认什么

文章区分了两件容易混淆的事：权限审批决定「哪些操作需要你点头」，沙箱决定「获准的命令能访问什么」。前者对应 Claude Code 的 permission modes 和 Codex 的 approval policy；后者由操作系统约束，常见边界包括项目目录之外的文件和网络资源。

批准一条命令，不等于应该让它获得整个电脑的访问权。

回退也分两层。节选称，Claude Code 的 checkpoints 可以通过 /rewind 撤回文件工具产生的修改，但不会撤回 shell 命令的影响，例如脚本重新生成文件、rm 删除文件或数据库迁移。Git 可以帮助检查、恢复仓库中的改动，却不能撤回已发送的消息或已发布的包。

作者因此提出：每个任务从独立分支和干净工作区开始，及时提交；执行 rewind 后，仍用 git status 和 git diff 核对实际状态。

我的判断

对程序员来说，最该前置的配置是：允许 Agent 写哪些目录、能否联网，以及哪些命令必须审批。安装依赖需要网络时，只开放当前任务需要的能力，比直接取消全部边界更容易控制影响范围。

回退成功也不能作为验收标准。文件恢复了，数据库和外部服务可能已经发生变化；测试通过了，也要检查测试本身有没有被改弱。

节选没有交代示例所用的工具版本、完整配置和网络策略。因此，不能把其中 Codex 访问 npm registry 失败的例子，当作所有 workspace-write 环境的固定行为。具体边界仍需对应版本的官方文档确认。