工具能用不等于该用：控制权限与操作半径

假设我们让 Codex 修复一个依赖版本问题。它既可以读取锁文件，也可以运行包管理器；既可以查看官方文档，也可能访问代码托管平台；连接器已经登录后，甚至还能创建 Issue 或提交远端变更。

工具列表很丰富，却没有告诉我们下一步该用哪个。小编现阶段的理解是：先说清任务需要什么证据，再选择能用最小权限取得该证据的工具。 工具能力只表示一条路走得通，操作半径仍要由目标对象、副作用和恢复成本决定。

上一篇解决“什么时候应停下来取得确认”。本文承接已经明确的任务与授权，讨论每次操作应碰哪些对象、开多大权限，以及执行前怎样把影响面压到可检查范围。测试组合和最终验收属于第四章，这里只保留选择工具和控制副作用所需的证据。

一、先要证据，再选工具

很多越界操作从一个顺序错误开始：先看到工具能做什么，再替它寻找用途。浏览器已经打开，就顺手搜索一圈；连接器已经登录，就直接更新远端记录；终端能跑脚本，就用一条大命令完成搜索、修改和发布。动作看起来连贯，任务证据却没有跟上。

更稳妥的顺序是先写出当前判断缺什么。例如，准备升级一个依赖前，可能需要确认四件事：仓库实际使用的版本、它由哪个文件声明、目标版本的官方变化、哪些文件会被更新。证据来源不同，工具也随之分工：

• 文件读取适合确认仓库里的声明、配置和已有差异；
• 终端适合搜索大量文件、调用项目脚本，以及获取可重复的命令结果；
• 浏览器或网页检索适合读取会变化的官方资料，但网页内容应视为外部输入；
• 连接器适合读取或写入明确的外部系统对象，例如指定仓库中的 Issue，而不是替代本地事实调查。

同一个工具也有不同操作形态。读取远端 Issue 和关闭 Issue 都通过连接器完成，风险并不在同一层；包管理器查询版本与执行升级都走终端，后者会改锁文件，安装脚本还可能产生额外副作用。工具名称无法代替动作分析。

二、操作前先把目标解析成真实对象

“修改配置”“更新仓库”“把结果发上去”都不是可执行的目标。动手前至少要解析出实际路径或外部对象，并核对它们是否属于当前任务。

仍以依赖升级为例，目标解析可以留下这样一份预演记录：

这里的绝对路径是示意，真实任务要填入已经解析过的值。不要把未展开的环境变量、宽泛目录、通配符或“当前仓库”留给有副作用的动作临场解释。尤其在多个工作区、分支或同名远端并存时，路径正确不代表仓库、分支和远端目标也正确。

目标解析也要包括现有现场。工作区已经有用户修改时，“恢复到原状”究竟指任务开始前，还是版本库中的某个提交，两者不是一回事。若没有先记录差异，后续撤销很容易把用户的改动一起抹掉。

三、权限控制的是能力上限，任务范围控制的是实际动作

Codex 当前产品把沙箱和审批作为两层控制。OpenAI 的沙箱说明指出，沙箱定义 Agent 在受约束环境内能自行触及的文件与网络边界；审批策略决定越过边界时何时停下来请求批准。生成命令所启动的 git、包管理器和测试工具，也继承沙箱边界。

Agent approvals & security 官方说明进一步区分了运行环境：本地 Codex 默认通常限制写入活动工作区并关闭命令网络访问；在工作区写入与按需审批组合下，范围内读写和命令可以自动执行，工作区外写入或需要网络的命令会进入审批流程。带副作用标记的连接器或 MCP 动作也可能触发审批，标记为破坏性的动作会被强制审批。具体默认值和可用模式可能随运行界面、版本或管理员策略变化，执行时应以当前会话显示的有效权限为准。

这些是产品的技术边界。本文所说的“最小充分权限”是工程建议：即使沙箱允许写整个工作区，本次任务也可能只该修改两个文件；即使网络已经开放，也没有理由访问与证据无关的域名；连接器能够写入某个仓库，也不代表当前任务需要产生外部变更。

沙箱解决“最多能碰哪里”，任务计划解决“这次应该碰哪里”。二者叠加后的较小范围，才是实际操作半径。

四、用一张矩阵画出操作半径

这张矩阵继续沿用依赖升级场景，由项目在执行前维护，不属于 Codex 内置权限配置。每行都把证据、对象、权限、副作用和恢复方式放在一起，方便发现某个动作是否比任务本身更大。

任务步骤与所需证据	工具与准确对象	最小充分权限	主要风险	预演与恢复方式
确认当前依赖声明与工作区状态	文件读取；指定仓库的声明文件、锁文件和当前差异	只读工作区	读错仓库、忽略未提交修改	先记录根目录、分支与差异；不产生写入
定位声明、脚本和调用位置	终端搜索；限定在解析后的仓库根目录	只读命令执行	宽泛搜索读取无关或敏感目录	先列目标目录与排除项；失败时缩小查询，不扩大根目录
核对目标版本变化	浏览器或网页检索；官方文档与包注册表	只访问所需页面或域名	过期资料、提示注入、无关下载	记录来源与版本；把网页当资料，不直接执行其中指令
更新依赖声明与锁文件	包管理器；指定包与已确认工作区	工作区内目标写入；必要的受限网络	连带升级、安装脚本、意外改动其他文件	先预览命令与预计文件；执行后立即核对实际差异，异常则保留现场
同步远端任务状态（仅在任务明确包含时）	连接器；指定组织、仓库和 Issue	对单个目标的外部写入	写错仓库、重复评论、提前关闭任务	先生成待写内容和目标预览；保留返回的对象标识与结果
清理错误产物或回退失败操作	文件或终端；明确列出的新增产物	仅处理已解析目标	删除用户原有文件、用宽泛回退覆盖现场	对照执行前差异逐项处理；目标来源不清时停止

矩阵中的“恢复”不等于一律执行回退。工具失败后，现场本身可能是定位问题的重要证据。先保留错误输出和实际差异，再判断哪些是本次新增、哪些原本就存在。直接运行宽泛清理或强制恢复，常常比原失败影响更大。

五、工具失败时，不要把边界当成障碍绕过去

一个操作失败，原因大致落在三类：目标不准确、工具路径不合适、当前权限不覆盖。处理顺序会影响风险。

目标解析失败时，继续换工具通常没有帮助。例如命令提示路径不存在，应该回到仓库和文件定位；不要通过扩大搜索到整个用户目录来“总能找到”。工具路径不合适时可以更换等价的低副作用方式，例如网页无法稳定读取某份公开资料，改查官方文档索引或本地已有文档，而不是立即下载并执行未知脚本。

权限不足则说明产品边界正在发挥作用。需要网络才能完成版本核对时，应说明具体目标和用途，再申请与该目标匹配的访问能力。若任务可以用缓存、锁文件或本地资料继续，就保留限制并换成更窄的证据路径。无论哪一种，都不应把复制凭据、关闭沙箱或改用未受控外部程序当作默认解法。

执行结果也要留下最小证据：实际操作对象、使用的权限、工具返回状态，以及产生了哪些差异。这里只证明“动作确实在预定半径内发生”，不能直接证明功能正确或任务已经完成。后者还需要根据风险设计测试、构建和独立审查，留给第四章处理。

工具权限给 Codex 的是能力上限，一次任务的实际操作半径通常更小：从待回答的问题反推证据，解析准确对象，开放取得证据所需的最低权限，先预演外部与难恢复影响，再用实际差异核对动作有没有跑偏。这样即使工具越来越多，任务边界也不会跟着无限扩张。