Codex 操作项目时，权限、密钥和命令范围怎样管理？ - AIPlan

两件事要分开管：沙箱决定它能碰到哪些文件和网络，审批决定它什么时候停下来问你。改审批方式不会扩大沙箱，这一点是官方文档里写得最清楚的一句。截至 2026 年 10 月 18 日核对，桌面版、IDE 扩展和 CLI 都遵循这套模型。 沙箱和审批是两套独立开关 沙箱定义 ChatGPT 能访问哪些文件和网络资源。审批决定它是在执行前暂停，还是把请求送去自动复核。官方原话是：改变谁来复核请求，不会扩大沙箱。Approve for me 保持和 Ask for approval 一样的工作区边界，只是把跨越边界的请求交给自动审查。 这个区别值钱，因为很多人以为选了自动批准就等于给了全盘权限。实际不是：文件边界还是那条，只是越过边界时不再等你点按钮。 官方对大多数工作的建议是先从 Ask for approval 开始。它让 ChatGPT 在当前工作区内干活，一旦要越界就暂停。 三种模式怎么切换 桌面版和 IDE 扩展里，权限控制在输入框下方。CLI 里输入 /permissions。可见的模式取决于应用版本、执行环境、本地配置和组织要求，某个模式可以被禁用或直接隐藏。 Approve for me 如果找不到或者灰色，官方指向权限排障页面。管理端的强制要求也能限制 Ask for approval 本身，这种情况下你看到的是被裁剪过的选项集，不是 bug。 有一个坑要提醒：一个模式出现在列表里，不等于当前对话已经选中它。切换对话后回来看一眼当前选中项。 自动审查不计入额度 用 ChatGPT 账号登录时，自动审查的安全检查是免费的，不消耗套餐用量。这条对每天都跑代码的人有意义：你可以放心让它自动复核，不必为了省额度手动点每一处。 但免费不等于没有代价。自动审查不解除工作区限制，也不替代每一个审批提示。它批准一个动作，Codex 继续；它拒绝，Codex 可能换条更安全的路，或者回头问你。 密钥不该出现在提示词里 Codex 读的是你仓库里的文件。.env、config.yml、secrets.json 一旦进了工作区，它在探索阶段就可能读到并写进上下文。上下文会进入模型请求，等于把密钥往外送了一次。 实际做法有三条： • 仓库根目录放 .gitignore，把 .env、.env.*、*.pem、credentials* 写进去。这不防读取，但能防误提交。 • 本地开发用占位值。代码里读 process.env.STRIPE_KEY，.env 里写 sk_test_placeholder，真密钥放在系统环境变量或者密钥管理工具里。 • 给 Codex 的任务说明里明确写“不要读取 .env 文件，需要的变量名从 .env.example 看”。 第 3 条不是强制约束，模型的遵守程度取决于任务清晰度。前 2 条才是真正起作用的。.env.example 这个习惯几乎零成本，把变量名列全、值留空，模型照样能写出正确的配置读取代码，20 秒就能建好一份初版。 依赖安装是最容易被忽略的执行面 让它装依赖时，真正在跑的是第三方脚本。npm install 会执行 postinstall，pip install 会跑 setup.py，这些代码你没读过。Codex 有权限跑 npm install 的时候，等于把这些脚本的权限一起给了。 可操作的边界：新依赖先手动装并看一眼输出，把结果记进任务描述；批量升级不在自动批准模式里做；锁文件（package-lock.json、pnpm-lock.yaml）的变更单独审一次。 npm install -g @openai/codex 这类全局安装本身也是执行动作，装完确认版本符合要求。官方提到 Astra 需要 Codex CLI 版本 0.153.0 或更新，版本不够时某些模型选项根本不会出现。 一次运行能碰的文件范围 多仓库项目里，本地项目可以挂多个不同 Git 仓库的文件夹。审查面板能切仓库看差异，但“能看”和“能改”是两件事。挂进来一个仓库，就扩大了工作区边界。 最小化原则：临时给一个任务开工作区，任务结束后切回去。别为了省事把整个 ~/projects 挂成工作区。 Windows 上还有个细节。组织通过 MDM 管理应用更新时，管理员需要先部署批准过的版本，否则依赖新版本的功能用不了。这条在多设备办公的场景里会直接卡住。 最终差异才是验收标准 审查面板的 Last turn 只看上一轮助手的改动，这是最快的自查入口。但面板反映的是整个仓库状态，包含了你自己手改的部分。判断“它到底改了什么”，还得靠 git diff 和 git status。 一个能坚持的习惯：每个任务开始前打一个 Git checkpoint，结束后再打一个。官方在快速上手文档里就建议在任务前后创建检查点，理由很实在：改坏了能退回去。 /review 报出的发现不改工作区，这是它的设计。你决定修哪些、怎么修，动作走单独一轮。 企业环境还有一层 Agent Security 是管理控制台里管 agent 策略和配置的区域，替代了原来的 Policies & Config。策略迁过来以后，原有的云端策略会成为 Global baseline。Requirements 设的限成员改不了，Defaults 只设起始值。 工作区的云访问默认关闭，需要管理员开启。Codex Cloud 与 Codex Local 是分开控制的，开了云访问不影响本地，反过来也一样。 如果你在团队里推这套东西，先确认这三件事的状态：云访问开关、Codex Local 权限、插件是否对该角色可用。三者任一没配好，成员看到的就是功能缺失而不是权限不足，排查起来容易走偏。 最小可执行的配置 个人项目按这个顺序做一遍，20 分钟能完成： • 写 .gitignore，覆盖 .env、证书、私钥、本地数据库文件 • 建 .env.example，把需要的变量名列全 • 权限模式停在 Ask for approval • 开一次自动审查，确认它真的在拦动作 • 跑一个只改 1 个文件的任务，看 Last turn 是否只有那 1 个文件 如果你的工作主要是个人项目、偶尔让 Codex 帮忙，Plus 的量级够用；$20 按 1 美元 ≈ 6.69 元折算约 ¥133.80，菲区官充的 Plus 月卡定价 ¥115.50，区别在付款渠道而不在权限模型。团队协作里更值钱的是席位与 RBAC，这部分可以对照 第一次让 Codex 进入仓库要完成的第一步 一起看。 密钥管理的完整链路，包括兑换时为什么要交出 Session JSON、开通后怎样让它失效，写在 账号凭据与 CDK 的保管边界。两边是同一个原则：凭据只在必要的时刻、必要的范围内可见，完之后就能作废。 做完上面 5 步后，再检查一次 git status。如果里面有你没预期的文件，先搞清楚它是谁生成的，再继续下一个任务。 参考资料资料核对日期：2026-10-17 • Permissions • Codex CLI • Code review 延伸阅读• 第一次让 Codex 进入项目，先跑通一个最小任务 • API Key 怎么保存和使用？先确认密钥属于哪个服务 • 用 Codex 做代码审查：每个发现都要说明怎样触发 • Codex 工具调用计费:Bash、Read、Agent 扣多少额度:成本拆解