知道“Codex 为什么会请求权限”之后，下一步就该进入真正实用的部分：

``

什么能批

什么要停

什么必须先问清楚

`

这篇不追求背规则，而是帮你形成一套稳定判断。

> 前置教程：Codex 为什么会请求权限

> 如果你还不清楚批准弹窗本质上在确认什么，先完成前置教程。

> 依据来源：OpenAI Codex 官方手册中关于 approvals、sandbox、command execution、file edits、network access 的说明。

学习目标

学完后，你应该能做到：

  1. 识别低风险批准和高风险批准。

    2. 2. 知道什么时候可以直接放行。

    3. 知道什么时候必须先解释。

    4. 知道什么时候必须先缩小范围。

    5. 知道什么时候应该直接拒绝并改写任务。

    核心判断原则

    判断是否批准，不是看它“像不像技术操作”，而是看它和当前任务是否匹配。

    同一句话，你以后可以反复拿来用：关键看这一步是不是当前任务合理且必要的一步。

    1. 哪些通常可以直接批准

    下面这些场景，通常可以直接通过，前提是它们和你的当前任务一致。

    只读分析 (Read Only)

    • 读取项目文件
    • 搜索关键词
    • 查看 Git 状态
    • 查看某个配置

    适用场景：第一次阅读项目、定位问题、找入口文件、判断技术栈。

    必要检查 (Validation)

    • 运行构建检查
    • 运行类型检查
    • 运行测试
    • 查看 diff

    适用场景：任务已经改完、你要求它做验收、它正在确认改动是否影响现有项目。

    最小修改 (Minor Edits)

    • 改一个页面文案
    • 修一个样式问题
    • 新增一篇教程
    • 修改一个已确认的问题文件

    前提是：任务明确要求、变更范围一致、没有顺手扩大范围。

    2. 哪些要先看一眼再批准

    下面这些不是说绝对不能批，而是不能“不看就批”。

    安装依赖 (Install)

    • 安装 npm 依赖
    • 下载系统工具
    • 拉取额外组件

    先问清楚：为什么现有依赖不够、是否真的需要、安装后影响哪些文件。

    修改配置 (Config)

    • 改 config.toml
    • 改模型配置
    • 改构建脚本
    • 改 CI 配置

    先问清楚：为什么必须改配置、是临时调试还是长期配置、会不会影响原有流程。

    访问网络 (Network)

    • 下载依赖
    • 请求远程接口
    • 推送代码
    • 拉取外部资源

    先问清楚：要访问哪个域名、为什么不能在本地完成、会不会带出敏感信息。

    3. 哪些必须先暂停确认 (Stop & Review)

    下面这些属于高风险动作。不是绝对不能做，而是必须暂停确认。

    删除与覆盖 (Delete/Overwrite)

    • 删除文件
    • 覆盖现有目录
    • 重置 Git 工作区
    • 回滚未提交改动

    先确认：是否在范围之内、有无更小替代方案、是否会丢失自己的未提交改动。

    正式提交与推送 (Commit/Push)

    • git commit
    • git push

    在你没明确说“现在可以提交”之前，不应该默认放行。

    处理密钥与隐私 (Secrets)

    • 读取 .env
    • 写入 API Key
    • 修改账号配置
    • 输出令牌内容

    必须极度谨慎，避免敏感信息进入聊天记录、日志或提交记录。

    范围失控 (Scope Creep)

    • 只修一个按钮，开始顺手重构页面
    • 只改文案，开始整理整个目录
    • 只修一个报错，开始修历史遗留问题

    这种情况要先停下来，要求它解释为什么要扩大范围。

    判断三问

    看到批准时，先把当前动作套进下面 3 个问题：

    1. 这是当前任务的必要步骤吗？

      2. 2. 这是最小必要步骤吗？

      3. 这一步做完后，影响会不会超出当前任务？

      如果三个答案分别是 是、是、不会，通常就可以批。只要有一个答案不明确，就先问，不要急。

      典型场景实操

      场景 1：第一次让 Codex 阅读项目

      此时通常合理的批准有：读取文件、搜索入口、查看脚本。不该批准的有：修改文件、安装依赖、提交 Git。

      场景 2：让 Codex 改一个小问题

      此时通常合理的批准有：读取相关文件、修改目标文件、查看 diff、最小检查。要停一下的有：改动超过预期文件、顺手重构、安装新依赖。

      场景 3：配置模型环境

      此时通常合理的批准有：读取配置说明、修改必要配置、验证。要非常谨慎的有：输出完整密钥、写入可提交文件、覆盖原有可用配置。

      进阶技巧：通用追问模板

      `

      先不要继续执行。

      请先说明：

      1. 你现在申请的这一步具体要做什么。

        2. 2. 为什么这一步是当前任务必须的。

        3. 为什么这是最小必要操作。

        4. 会影响哪些文件、命令或外部服务。

        5. 有没有风险更低的替代方案。

        `

        预防技巧：任务开头写明禁令

        `

        本次任务的安全限制如下：

        1. 不要删除文件。

          2. 2. 不要覆盖无关改动。

          3. 不要安装新依赖，除非先说明原因并得到我确认。

          4. 不要提交 Git，除非我明确说“现在提交”。

          5. 不要读取或输出 .env、token、密钥等敏感信息。

          6. 如果你发现需要扩大修改范围，请先停下来说明。

          ``

          总结

          做到这里，如果你已经能稳定判断下面几类情况，就说明本篇已经起作用了：

          1. 只读分析通常可以放行。

            2. 2. 最小必要检查通常可以放行。

            3. 安装依赖、改配置、访问网络不能不看就批。

            4. 删除、覆盖、提交、推送、处理密钥必须先停一下。

            5. 看不准时先让 Codex 解释，任务太大时先拆任务。

            下一篇建议看：如何保护 .env、密钥和隐私信息

            这篇会专门讲用户最容易忽视的敏感信息边界。