E11｜Codex Security：找洞的产品，不是 CLI 的第四套沙箱
先别把 /codex/security 当成 Seatbelt 文档
docs/sandbox.md 和 TUI onboarding 里有链接指向 developers.openai.com/codex/security。点进去现在是 Codex Security 产品页：用插件或云端扫描 GitHub 仓库、验证漏洞、给补丁。沙箱和审批的文档在 Agent approvals & security（SECURITY.md:16-17）。两个「security」不要焊在一个 URL 上。
判断先说清楚：Codex Security 是独立应用安全 agent（前身 Aardvark），研究预览。 它找洞、在隔离环境里验证、给可审查的补丁。扫描循环、威胁模型、验证沙箱 不在本仓库。本仓库最多给插件一条 MCP 通道（测试里的 get_codex_security_daybreak_access），不是把漏洞生命周期写进 run_turn。
E 章到此为止。F 章抄 harness，不抄这套扫描器。
1. 它干什么：识别 → 验证 → 修补
官方三步（Codex Security、Help Center）：
- 识别： 连 GitHub 仓库，按仓库自己的威胁模型和提交历史找可能的漏洞，而不是通用签名扫一遍。
- 验证： 在短暂隔离容器里尝试复现，降误报，再给人看。
- 修补： 排序后的 findings + 证据 + 建议补丁，在 GitHub 工作流里人工接受。
两条产品面：Codex App 里的 Security 插件（在你的 thread 里跑一次本地向扫描）；Codex Security cloud 扫已连接的 GitHub（Codex Web）。可用性、套餐、研究预览范围以当时官网为准。
向 OpenAI 报告 Codex 自己的 漏洞，走 Bugcrowd（SECURITY.md），不是开这个产品的扫描任务。
2. 和 /review、Guardian 不是一层
E6 已经分过三种「再看一眼」。补上这第四条：
| 问题 | 产出 | 在哪 | |
|---|---|---|---|
/review | 这次 diff 作者会不会修？ | 代码质量 findings | 本仓库 ReviewTask |
| Guardian | 这次 tool call 允不允许？ | Allow / Deny | 本仓库同意链 |
| B3 沙箱 / ExecPolicy | 这条命令物理上能不能跑？ | OS 拒绝或前缀禁令 | 本仓库 |
| Codex Security | 仓库里有没有可复现的漏洞？ | 验证过的漏洞 + 补丁 | 独立产品 / 云端 |
@codex review for security vulnerabilities 仍是云端 PR 评（E3/E6），不是 Security 扫描器的 commit-by-commit 管道。不要给 ReviewTask 加上「验证 SSRF」的容器编排。
没有这层切开会怎样？你会把威胁建模写进 hooks.json，或把 Guardian 当成漏洞扫描。一个拦执行，一个评 diff，一个找可利用路径——寿命、隔离、输出格式全不同。
3. 本仓库不要混写
工程师在 openai/codex 里：
- 不要 搜
run_turn指望找到扫描循环。 - 不要 把
docs/sandbox.md的旧链接当成架构说明（F4：跳转文档以官网为准）。 - 可以 把 Security 插件当 D2/D3 的又一个包装盒：thread 里跑、过审批、结果仍是 Event 投影。
- 抄 harness 时 抄 B 章；抄「找洞产品」去官方 Security 文档和独立实现，不在这本电子书展开。
4. 结语：带走一句话
Codex Security 是找洞、验证、给补丁的独立产品线——和 /review、Guardian、Seatbelt 都不是一回事；这本电子书到 E11 只负责把它从 CLI harness 里请出去。