Codex Security 架构:沙箱、审批、凭据、网络与项目边界
Codex 安全不是一个“安全模式”开关,而是多层边界的组合:项目范围决定代理能看见和改写什么,沙箱提供操作系统级限制,审批策略决定谁能授权越界动作,网络策略控制外联,凭据策略减少秘密暴露,托管配置锁定组织底线。任何一层放宽,都不应默认由…
专栏
工程实践参考,不是功能清单。51 篇文章覆盖 Codex 从单人使用、CLI 命令、权限安全、Web/Cloud/App 委派,到 Skills、Subagents、SDK、团队落地和上下文压缩的完整路径。 本系列面向已经开始使用 OpenAI Codex 的工程师和技术负责人。目标不是重复讲"AI 会写代码",而是回答一个更具体的问题:如何让 Codex 在真实仓库里受控、可验证、可复用地完成工程任务。 建议从 00-08(定位、上下文与任务工程)读起,再按需进入 CLI 命令、安全边界、委派与团队落地等章节。
Codex 安全不是一个“安全模式”开关,而是多层边界的组合:项目范围决定代理能看见和改写什么,沙箱提供操作系统级限制,审批策略决定谁能授权越界动作,网络策略控制外联,凭据策略减少秘密暴露,托管配置锁定组织底线。任何一层放宽,都不应默认由…
Auto review 改变的是“谁来处理权限升级请求”,不会扩大沙箱权限,也不会替代代码审查、CI 或最终合并责任。可靠的审批链至少要拆成五层:沙箱限制动作范围,审批策略决定何时申请,自动审查器判断单次请求,/review 检查代码风险…
本系列面向已经开始使用 OpenAI Codex 的工程师和技术负责人。目标不是重复讲“AI 会写代码”,而是回答一个更具体的问题:如何让 Codex 在真实仓库里受控、可验证、可复用地完成工程任务。
codex app server 是 Codex 为 VS Code 扩展等富客户端提供的双向协议。客户端先完成 initialize 握手,再创建或恢复 Thread,以 turn/start 提交输入,并持续消费 Item 和 Tur…
Skill 是可复用工作流的作者格式,Plugin 是把 Skills、MCP Servers、连接器和 Hooks 打包分发的容器,Record & Replay 是在 macOS 上把一次可观察操作转成 Skill 草稿的制作方式。三…
Remote Handoff 会把现有聊天与 Git 状态移到连接的目标 host,并在目标机创建或复用 worktree。目标机必须保存同一 Git 仓库;若项目是仓库子目录,两端还要保存同一子目录。
ChatGPT 桌面应用把 Codex、Browser、Computer Use、PR review、Sites 和 Visualizations 放进同一工作区,但它们不是一条权限相同的流水线。Browser 操作网页,Computer…
Goal 模式把一个可持久化目标绑定到线程,让 Codex 围绕完成条件持续选择工作。它支持暂停、恢复、编辑和清除,也会在需要审批、外部决策、额度或预算不足时停下。它不是后台守护进程,更不会绕过沙箱。
Codex Hooks 不是“放进 hooks.json 就会执行”的回调。一个非托管 Hook 要经过配置发现、来源合并、项目层信任、定义哈希审核、事件匹配和命令执行;定义发生变化后,原有信任失效,Codex 会跳过它,直到用户重新审核。
Multi agent V2 不是现行 Subagents 的同义词。Codex 0.145.0 已把 multi agent v2 标为 stable,但仍默认关闭;现行 Subagents 默认启用,支持自定义角色、每代理模型、推理强…
团队采用 Codex 不是“给所有人开工具”这么简单。个人场景关注效率,团队场景还要管理一致性、权限、成本、质量、审计和责任。可持续路线是:先选低风险高频场景试点,建立 AGENTS.md、Skill、模型分层和权限模板,再用真实任务评估…
模型选择不是“永远用最强”,reasoning effort 也不是“越高越好”。Codex 任务要按风险、上下文范围、动作破坏性、验证成本和响应时延分层。官方 Codex Models 页面截至 2026 06 22 推荐多数复杂任务从…
Codex 的 Thread History、持久名称、Memory 和导入功能解决的是四类问题。线程历史保存可恢复的工作记录,名称帮助人找到线程,Memory 从旧工作中提炼可复用信息,Import 把受支持的外部 Agent 设置和近…
Subagents 适合读多写少、可并行、需要多视角覆盖的工程任务。官方 Codex Subagents 概念页说明,Codex 可以通过启动专业代理并行探索、处理或分析工作,再把摘要返回主线程;但它不会自动生成 subagents,用户…
Codex SDK 的价值是让团队用代码控制本地 Codex agents:启动 thread、运行任务、继续同一 thread、恢复历史 thread、设置模型和沙箱、把结果接入内部系统。官方 SDK 文档说明,TypeScript S…
Automation 解决“什么时候运行、在哪运行、结果去哪”的问题,Skill 解决“按什么流程做”的问题。官方 Codex app Automations 文档说明,自动化任务可以在后台按计划运行;有发现会进入 inbox/Triag…
Skill 评测不是检查说明文档写得是否完整,而是检查三类可观察行为:应该触发时是否触发,不该触发时是否安静,触发后是否能在当前权限和资源条件下产出可验证结果。对应到工程指标,就是召回率、精确率和完成率。欠触发通常来自 descripti…
一个可维护的 Skill 至少要回答三件事:Codex 什么时候应该打开它,打开后按什么顺序执行,执行中需要哪些外部资源。官方要求 SKILL.md 必须包含 name 和 description;Skill 目录可以包含 scripts…
openai/codex action@v1 运行在无人值守的 CI 环境中,安全模型和本地 Codex 会话不同。官方 GitHub Action 文档明确提醒:Codex 在 GitHub hosted runner 上默认有较宽访问…
openai/codex action@v1 把 Codex 放进 GitHub Actions。官方文档说明,它通过 workflow 输入运行 Codex,并把这些输入映射到 codex exec 选项:可以用 prompt 或 pr…
Skill 是 Codex 的可复用工作流单元,不是更长的提示词收藏夹。官方文档把 Skill 定义为一个包含 SKILL.md 的目录,目录里可以放脚本、参考资料、模板资产,以及面向 Codex app 的 agents/openai.…
Worktree 是 Codex App 并行开发的隔离层。官方 Worktrees 文档把 Local 描述为前台,把 Worktree 描述为后台;Codex 可以在 worktree 中运行线程,也可以通过 Handoff 在线程的…
Codex 相关的“联网”至少有三层:模型使用 web search 查资料,本地 shell 命令访问网络,Codex cloud 环境中的 agent phase 访问互联网。三者不是同一个开关。官方 config 文档说明,本地任务…
Codex Web 的价值不是把本地终端搬到浏览器里,也不是让一个聊天框替你做所有决定。它更像一个云端工程执行入口:你把仓库、分支、任务目标、约束、验证方式交给 Codex,Codex 在配置好的 Cloud 环境里检查代码、执行命令、生…
Codex App 的定位不是“桌面版聊天框”。官方 App 文档把它描述为面向 Codex threads 的桌面工作台,支持并行处理线程,并内置 worktree、automations 和 Git 功能。对工程团队来说,它的关键价值…
Codex Cloud 环境不是开发者电脑的复制品。官方文档描述的执行路径更接近 CI job:为仓库创建环境,checkout 指定分支或 commit,运行 setup 脚本,设置环境变量和 secrets,按环境策略控制 agent…
Codex CLI 的 dangerously bypass approvals and sandbox,也就是 yolo,会让 Codex 在没有审批、没有沙箱的情况下运行每个命令。官方 CLI 文档写得很直接:只应在外部加固环境中使用…
Codex hooks 是本地客户端在特定事件发生时运行的命令。它适合做确定性、短耗时、可审计的检查,例如提交前格式化提示、命令前风险提示、文件编辑后局部 lint、会话结束摘要归档。它不适合承载复杂业务逻辑、隐式修改大量文件、绕过审批、…
Codex 的 profile 和 rules 解决的是两类问题。profile 选择一组配置覆盖,用来切换工作场景,例如只读审计、日常编辑、网络受限维护。rules 控制 Codex 请求在沙箱外运行命令时,哪些命令前缀可以允许、需要提…
config.toml 不是偏好设置文件,而是 Codex 本地客户端的行为契约。它决定默认模型、审批策略、沙箱边界、web search 模式、环境变量转发、日志、hooks、MCP、权限 profiles 等。官方文档给出的优先级是:…
并行工具调用的价值不在“更快跑命令”,而在缩短独立信息收集的等待时间。适合并行的工作通常是只读、彼此没有写入依赖、输出可控的动作,例如同时读取多个文件、同时查询不同目录、同时查看配置和测试入口。不适合并行的动作包括写同一批文件、安装依赖、…
Codex 能跑 shell,不等于模型真的“看见了终端”。一次工具调用会经历命令构造、沙箱和审批、stdout/stderr 收集、响应预算压缩、上下文注入几个环节。输出太长时,模型拿到的往往只是被截断后的片段;错误堆栈、测试摘要、真实…
Codex 的工程能力来自“模型加工具循环”,不是来自一次自然语言回答。文件编辑通常应走 patch 或受控编辑通道;搜索、构建、测试、Git 检查走 shell;外部系统和私有上下文通过 MCP、插件或连接器接入;只读信息收集可以并行,…
codex resume 用来继续之前的 Codex 会话,适合长任务中断后恢复上下文;codex fork 用来从已有会话分出新线程,适合在同一理解基础上尝试不同方案。二者管理的是 Codex 线程和 transcript,不管理 Gi…
codex exec 是把 Codex 放进脚本、CI、预合并检查、定时任务和批量处理的入口。它接收一条任务 prompt,非交互执行,完成后退出。官方文档说明:默认情况下 codex exec 运行在只读沙箱;运行过程中进度输出到 st…
Codex CLI 不是一个单一聊天命令,而是一组面向不同工程场景的入口。日常探索用 codex 进入交互式 TUI;脚本、CI、批处理用 codex exec;中断后继续用 codex resume;从已有会话分出新方向用 codex…
Best of N 不是“多点几次生成”。工程上可用的 Best of N 要满足四个条件:同一输入、同一基线、同一隔离环境、同一验证标准。Codex Cloud 官方支持通过 attempts 请求 1 到 4 次候选尝试;本地也可以用…
Codex 能读代码、改文件、运行命令,但“它改完了”不等于“工程上可合并”。验证循环的核心是把团队已经认可的质量门写成可执行协议:改动前确认范围,改动后依次运行 lint、typecheck、定向测试、必要的构建或集成测试,再检查 gi…
Codex 不应该永远直接执行。更可靠的团队策略,是在 Ask、Plan、Execute 三种授权节奏之间切换。Ask 用来只读理解和澄清事实;Plan 用来设计路径、暴露风险、列验证方式;Execute 用来在明确边界内修改文件、运行命…
Codex 适合多步工程任务,但多步不代表任由它自由发挥。团队应该把高频任务沉淀成工作流模板,让 Codex 知道先读什么、什么时候不改文件、什么时候给计划、什么时候执行、跑哪些验证、最后汇报什么。理解代码、重构、补测试、性能优化这四类任…
给 Codex 的任务描述,不应该停在“帮我改一下”。一个可执行的工程 brief 至少包含四个要素:Goal 说明要达到的最终状态,Context 说明理解任务需要从哪里开始,Constraints 说明不能碰的边界和必须遵守的规则,D…
安装 Codex 只是开始。真正需要团队认真设计的是认证方式、工作区信任、沙箱模式、审批策略、网络访问和密钥边界。Codex 不是普通命令行工具,它会根据任务读取文件、编辑文件、运行命令,并在权限不足时请求提升。第一次引入团队时,不要追求…
Codex 的入口选择不是个人习惯问题,而是工程边界问题。CLI 贴近本地终端和当前工作区,适合短反馈回路、需要你频繁介入的本地任务。App 适合在桌面环境中管理多个本地项目和多条任务线程。Web / Cloud 适合把边界明确、能异步完…
Codex 不应该按“更会补代码的聊天框”来理解。它更接近一个能进入仓库、读取项目规则、编辑文件、运行命令、请求权限、交付验证证据的工程代理工作台。补全工具的核心边界是当前文件和光标附近的代码;Codex 的核心边界是仓库、任务说明、AG…