ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Codex Harness 审批×沙箱×AGENTS.md 12 种组合怎么选

2026/9/25 21:31:33 拓冰建站 浏览量
Codex Harness 审批×沙箱×AGENTS.md 12 种组合怎么选 原文链接Codex Harness 审批×沙箱×AGENTS.md 12 种组合怎么选上一篇里Codex 完成了第一次真实修复也从「一次性命令」走到了「多轮结对」。但它凭什么敢在你的机器上直接跑命令、改文件、删东西答案不在模型有多聪明而在 Codex 给每个动作都套了三道闸。本文一次讲清这三件套审批管「做之前问不问」、沙箱管「能碰哪里」、AGENTS.md 管「按什么约定干」。读完你能自己配出一套既能放手、又不会翻车的默认组合。一、三件套Codex 的「权力开关」Codex Harness 里有一层叫 Policy专门回答一个问题允许做什么。它由三个彼此独立的旋钮组成。审批决定要不要点头沙箱决定动作范围AGENTS.md 则把团队约定写进指令让 Agent 一开始就按你的规矩办。一句话记住你给它多大权力它就用多大权力。二、审批 4 模式做之前问不问截至 0.153.x审批策略是四档on-request正常自跑、越权才问on-failure先跑、失败才问never从不打扰、失败直接回模型granular按命令类别细分被设为 false 的类别直接拒绝、不再弹窗。先记一个版本坑早期版本的untrusted默认只放行 ls/cat 这类可信命令在 0.153 已被移除老的--ask-for-approval开关也废弃了现在统一走approval_policy字段。所以别再照抄旧教程里的 untrusted。多数人的日常答案是中间那档 on-request。在配置文件里换一档只改一个字段就够了# ~/.codex/config.tomlapproval_policy on-request # on-request / on-failure / never / granular一次性任务也可以用命令行临时覆盖codex exec -c approval_policyon-failure 跑通测试并修复失败的用例避坑把 never 当默认等于把审批门拆了。它只适合外部已经隔离的环境比如 Docker 或 CI。三、沙箱 3 级别能碰哪些文件和网络审批管「问不问」沙箱管「碰不碰得到」。Codex 把沙箱做在操作系统内核层macOS 走 SeatbeltLinux 走 Landlock seccompWindows 走 Restricted Token。限制发生在系统调用层它不是「劝你别做」而是「物理上做不到」。这也是它和「靠钩子、自担安全」方案的根本差别。先看一段实拍确认参数不是编的三种边界read-only禁止写入、禁止联网适合代码审查workspace-write允许在工作目录内写、默认禁网是日常开发默认danger-full-access任意读写联网只该给隔离容器或一次性虚拟机。更关键的是保护路径无论哪种模式.git/、.codex/、~/.ssh/、~/.aws/都不会被 Agent 触碰——它再大胆也删不掉你的密钥和版本库。补充一个真相如果你本就跑在 Docker/CI 里用external-sandbox告诉 Codex「外层已隔离」它就不会再叠第二层沙箱性能更好。四、核心认知审批与沙箱是两个正交维度这是本文最想让你带走的一点审批和沙箱不是一道选择题而是两个互不替代的维度。审批控制「要不要问你」沙箱控制「就算你不管它、它能走多远」。两者可以任意组合。审批 × 沙箱 速查矩阵12 组合一眼选审批 / 沙箱read-onlyworkspace-writedanger-full-accesson-request读分析·最稳日常开发默认仅隔离容器内on-failure放手读·禁写高信任自跑危险·慎用于容器never只读 CI仅容器批量极危险·仅外部沙箱granular按类细分读按类细分写按类细分·容器专用再往深一层Hooks 是第三个正交维度——它管「动手之前/之后要做什么」和审批、沙箱互不替代后面单独拆解。落到 Codex 权限配置还有一条容易踩的规则——配置优先级栈优先级来源信任要求高命令行-c keyvalue无中项目.codex/config.toml需先 trust 该项目低用户~/.codex/config.toml无为什么项目级要 trust这是一条安全底线openai_base_url、model_provider这类字段只能写在用户级写进项目级会被静默忽略。目的是防止你 clone 一个陌生仓库后API Key 被悄悄导流到攻击者服务器。五、AGENTS.md要目录不要百科全书三件套里最容易被写废的是 AGENTS.md。很多人的第一反应是「把团队规范全塞进去」结果适得其反。Codex 的做法是路径层叠从全局到项目根、再到当前子目录逐级读取 AGENTS.md越具体越优先整条链路还有 32 KiB 上限超出部分会被忽略。这等于在系统层面强制你做信息分层通用约定放全局、项目规则放仓库根、模块细节放子目录而不是堆一个大文件。那 AGENTS.md 怎么写才不浪费这 32 KiB记住一句写「约定」别写「教程」。一份够用的项目级文件其实只要几行# AGENTS.md项目根## 约定- 测试跑 bun test必须全绿才算完成- 改动最小 diff不顺手重构无关代码- 提交一次一个逻辑单元写清动机六、一套敢放手的默认配置把三件套拼起来就是一份可以直接抄的团队默认# ~/.codex/config.tomlapproval_policy on-request # 越权才问sandbox_mode workspace-write # 只写工作目录注sandbox_mode是真实配置键需要更细的权限走sandbox_permissions列表例如[disk-full-read-access]。再配一份项目级 AGENTS.md上一节那份即可。日常开发就按这个组合改得动、问得少、跑不飞。需要只读分析时临时切-s read-only只有在容器里跑批量任务时才考虑 never full-access。对企业来说这三道闸正是「敢不敢让 Agent 上生产」的前提权限可调、边界清晰、约定可复制——缺一道团队就只能停留在「试用」阶段。七、真实踩坑清单本机 0.153.4 实测版本漂移untrusted已移除、--ask-for-approval废弃统一改走approval_policygranular才是当前最细一档别照抄旧教程。32 KiB 静默截断AGENTS.md 超出部分直接忽略、不报错——长文件会被悄悄砍掉排错时极易误判。默认不是「放开」on-request仍会对陌生/越权命令弹确认别误以为默认就免审。项目级 trust 是安全底线openai_base_url等只能写用户级否则静默忽略——这不是 bug是防投毒。一键命令全集均为本机 0.153.4 验证过的真实开关# 审批codex exec -c approval_policyon-request npm install bun test # 日常codex exec -c approval_policyon-failure 跑通测试并修复失败用例 # 高信任codex exec -c approval_policynever 容器内的批量重构 # 仅隔离环境# 沙箱codex exec -s read-only 审查 src/ 下的改动 # 只读分析codex exec -s workspace-write 实现并自测新接口 # 日常开发codex exec -s danger-full-access 一次性数据迁移 # 仅容器# 组合codex exec -c approval_policyon-request -s workspace-write 实现新功能真实终端记录本机codex-cli 0.153.4deepseek-v4-flash在approval_policyon-request与workspace-write沙箱下执行写到工作区外的 shell 命令时弹出的审批确认框。小结三件套的本质是把「信任」拆成三道可调的闸审批问不问、沙箱碰哪里、AGENTS.md 怎么干。它们合起来就是 Codex 的权限底座。留个问题在你的项目里你更愿意把哪一道闸拧到最松——审批、沙箱还是 AGENTS.md 的约束评论区聊聊。如果这篇帮你把权限配明白了点个「在看」。【欢迎访问我的个人博客主页这里有我的精选文章和AI大模型日报专栏。