结论先说
如果你的真正阻碍是先过安全和合规评审，用 Codex。如果你的真正阻碍是先让一个工程团队在 worktree、devcontainer 或隔离仓库里安全试起来，用 Claude Code。
截至 2026-05-09，两者的差异更像 rollout 模型的差异，而不是“谁绝对更安全”。在这次核验过的公开资料里，Codex 的优势是更清晰的一方合规路径：managed network policy、绑定到 workspace 的身份认证，以及 Compliance Platform 可见性。Claude Code 的优势是更清晰的本地控制面：明确的路径规则、可读的 permission mode、OS 级 sandboxing，以及已写明的 OpenTelemetry 到 SIEM 监控路径。
对大多数团队来说，判断可以先压缩成四条：
- 如果安全和平台团队希望在广泛铺开前先拿到集中可见性和一方合规路径，优先选 Codex
- 如果开发团队需要一个可以按 repo 或按机器细调文件系统与网络边界的 agent，优先选 Claude Code
- 不要把任一产品默认视为“在含有大量 secret 的生产仓库里也足够安全”
- 无论选哪一个，第一轮 pilot 都应优先在 worktree、throwaway clone 或 devcontainer 里做
快速判断表
| 如果你的优先级是… | 选谁 | 原因 |
|---|---|---|
| 集中式合规日志和 agent 级可见性 | Codex | OpenAI 已公开写明 OpenTelemetry 导出和 Enterprise / Edu 可用的 Compliance Platform，这在本次核验信源里是更 turnkey 的合规路径 |
| 更细的本地 sandbox 路径控制 | Claude Code | Anthropic 文档明确写了 allowWrite、denyRead、allowRead、denyWrite，以及在 OS 层生效的 managed sandbox 设置 |
| 面向已知安全目标的 managed network policy | Codex | OpenAI 公开描述了 managed outbound policy：允许预期目标、对陌生域名触发审批，并绑定 workspace 身份认证 |
| 让开发者自己看懂并调整的 permission model | Claude Code | Anthropic 公开了 plan、acceptEdits、auto、dontAsk、bypassPermissions 等 mode，以及 allow / ask / deny 规则 |
| 安全团队主导的 rollout | Codex | 在当前公开资料里，OpenAI 对 Compliance Platform、workspace-bound control 的叙述更 turnkey；Anthropic 的对应路径更像 managed settings、settings audit logs 与自建 OTel telemetry |
| 在隔离 worktree 或 devcontainer 里先做开发团队 pilot | Claude Code | 当前文档对 sandbox mechanics、escape hatch 和 per-path restriction 的解释更清楚 |
这周真正变了什么
这篇比较的直接触发点，是一次明确的文档更新。
在 2026-05-08，OpenAI 发布了详细的安全文章，解释它在内部如何运行 Codex。这件事重要，不是因为“AI coding 很热”，而是因为此前很多 Codex 文章更偏能力层面，而不是治理层面。这篇新文章给出了四个对团队评估很有用的操作级结论：
- sandboxing 和 approvals 是两层不同机制
- network access 是 managed 的，不是开放式的
- requirements 可以跨 Codex 多个 surface 做 admin-enforced
- agent-native telemetry 可以导出并审阅
Anthropic 当前的 Claude Code 文档也应该一起放进这场采购或试点讨论里，因为它描述的是一套已经成形的控制面，覆盖本地执行和团队落地两侧：OS 级 sandboxing、路径级读写规则、域名 allowlist、permission modes、managed settings、OpenTelemetry 导出，以及对 broad Bash access 或弱网络过滤这类 bypass 风险的明确警告。
把这两组文档放在一起看，才更接近团队真正会问的问题：到底该先让哪个 coding agent 去碰真实仓库？
Codex 现在更强的地方
1. 面向集中治理的公开叙事更完整
OpenAI 在 2026-05-08 的安全文章里，对企业控制面的描述相当具体。按文中写法，Codex 可以配合以下能力部署：
- admin-enforced requirements
- managed network policy
- 安全的 OS keyring credential storage
- 绑定到 ChatGPT workspace 的身份认证
- 对 sandbox 外 shell command 的 rule-based 处理
- desktop、CLI、IDE extension 的跨 surface 覆盖
这比“丢进 VM 里跑”更接近真实企业 rollout 里会被问到的控制问题。它指向的是一种定位：让组织在多个使用面上共享一套 baseline policy，同时保留 workspace-bound auth 和 Compliance Platform visibility。
2. 更 turnkey 的合规日志路径
这是 Codex 在这次比较里最明确的优势，但它的边界也比“Codex 有 telemetry、Claude Code 没有”要窄得多。
OpenAI 公开写明，Codex 支持 OpenTelemetry log export，覆盖 user prompts、approval decisions、tool execution results、MCP server usage，以及 network proxy allow / deny events。它还写明，Codex activity 可通过 OpenAI Compliance Platform 提供给 Enterprise 和 Edu 客户。
Anthropic 的 Claude Code 文档也已经公开描述了 OpenTelemetry metrics、logs、events，包括 user prompts、tool decisions、tool results、MCP activity 和 SIEM export；同时还公开了 server-managed settings 和 settings change audit logging。当前这组信源里的差异，不是“有没有 telemetry”，而是“打包方式是否是一条更 turnkey 的一方合规路径”。
如果你的真正瓶颈不是模型能力，而是 auditability，这个差异就很实际。多数安全团队不只想知道“文件被改了”。他们更想知道：
- 用户当时要求 agent 做什么
- agent 为什么调用这个工具
- 审批是自动放行还是人工批准
- 某个网络请求是被放行还是被拦截
OpenAI 现在公开给出的是，从这些事件走到 compliance review 的更短一方路径。
3. 对合规先行型 pilot 更容易讲清楚
如果你需要在 pilot 开始前就回答安全或合规团队的问题，Codex 目前能给出更短的说明路径：
- 有边界的 sandbox
- managed outbound policy
- approval flow
- centralized logs
这并不意味着 Codex 在所有环境里都“天然更安全”。它真正更强的地方，是当 rollout owner 是平台或安全团队，而不是单个开发者时，更容易被解释、被接受、被拿去做正式立项。
Claude Code 现在更强的地方
1. 本地 sandbox 控制更明确
在这次比较里，如果站在开发者视角，Anthropic 的 sandboxing 文档仍然是最容易看懂边界的那一组公开资料。
截至 2026-05-09，Anthropic 文档写明，Claude Code 的 sandboxing 可以强制实现：
- 默认只允许写当前 working directory
- 通过
sandbox.filesystem.allowWrite增加额外可写路径 - 针对读取行为配置 deny / allow 列表
- 通过外部 proxy 限制可访问域名
- 在 macOS 上用 Seatbelt、在 Linux / WSL2 上用 bubblewrap 做 OS 级强制执行
对 rollout 来说，这意味着开发者可以直接用“路径”和“域名”去理解边界，而不是只能接受产品化抽象说法。
2. Permission modes 更透明
Anthropic 的 permission model 写得很直白。当前文档公开了这些 mode：
planacceptEditsautodontAskbypassPermissions
文档还会把每个 mode 的 tradeoff 说清楚，包括对 bypassPermissions 的明确警告：它只适合隔离环境。
这让 Claude Code 更适合做“开发者自己控制 autonomy 节奏”的 pilot。团队可以先从 plan 开始，再进入常规交互，只有在任务边界已经稳定后才去试 auto。
3. 对失败模式的公开说明更到位
Anthropic 的文档在 failure mode 上写得更直接。它明确警告：
- sandboxing 必须同时覆盖 filesystem 和 network isolation
- 过宽的 allowed domain 可能形成 exfiltration path
- 内置 proxy 默认不做 TLS inspection
Read和Editdeny rule 不能阻止 Bash 用cat等 subprocess 继续读取- 如果不禁用 unsandboxed command，系统存在 escape hatch
这类文档的价值，在于它更不容易让团队产生“看起来有边界，所以应该已经够安全了”的错觉。
真正该比的是四个控制面
沙箱边界
| 问题 | Codex | Claude Code |
|---|---|---|
| sandboxing 是否是已文档化的安全模型一部分？ | 是。OpenAI 现在把 sandboxing 描述成写入、受保护路径和网络可达性的技术执行边界。 | 是。Anthropic 文档写明了带有 filesystem 和 network isolation 的 OS-enforced sandboxing。 |
| 团队能否集中管理这个边界？ | 可以，按 OpenAI 的说法，可通过 managed requirements 和 managed preferences 来做。 | 可以，通过 managed settings 来做；但公开文档更强调本地和 repo 级配置细节，而不是集中可观测性。 |
| 针对开发者的 filesystem 模型说明是否足够细？ | 部分是，主要分散在安全文章和相关 config 文档里。 | 是，路径语义和示例都更具体。 |
Codex 在治理叙事上更强。Claude Code 在边界可解释性上更强。
审批模型
| 问题 | Codex | Claude Code |
|---|---|---|
| 低风险操作能否更顺滑地继续？ | 可以。OpenAI 说 routine request 可以走 auto-review。 | 可以。Anthropic 提供 acceptEdits、auto 和常规 allow 规则。 |
| 更高风险动作能否强制进入 review？ | 可以。OpenAI 描述了超出 sandbox 或 policy 边界时的 approval。 | 可以。Anthropic 通过 deny / ask / allow 规则处理，也可以对 Bash 或 file edit 继续要求 prompt。 |
| 开发者是否容易直接看懂 approval 系统？ | 公开细节相对少一些。 | 当前公开文档更具体。 |
Codex 对 managed approval workflow 更顺。Claude Code 更适合由开发者自己看懂并调规则。
网络控制
| 问题 | Codex | Claude Code |
|---|---|---|
| 推荐 setup 下的 outbound access 是否默认开放？ | 否。OpenAI 说它使用 managed network policy，并对陌生域名要求审批。 | 否，前提是你启用了 sandbox network control。Anthropic 文档写了 host allowlist 和可选的 managed-domain-only 行为。 |
| 文档是否明确提醒 network policy 的局限？ | 是，但相对高层。 | 是，而且更细，包括 domain fronting 和 TLS inspection caveat。 |
| 文档是否包含 custom proxy 逻辑？ | OpenAI 在安全文章里提到了 managed proxy policy。 | Anthropic 明确写了 custom proxy configuration。 |
两者都能收紧网络边界。Claude Code 的文档更明确告诉你，网络层仍然证明不了什么。
审计与遥测
| 问题 | Codex | Claude Code |
|---|---|---|
| 是否公开文档化了 agent-native telemetry export？ | 是。2026-05-08 的 OpenAI 文章写了 OpenTelemetry export。 | 是。Anthropic 公开写了 Claude Code 的 OpenTelemetry metrics、logs、events、可选 traces，以及 SIEM export。 |
| 是否公开文档化了一方企业合规日志路径？ | 是。OpenAI 明确提到 Compliance Platform。 | 部分有。Anthropic 写了 SIEM export 和 server-managed settings 的 audit logging，但在这次核验信源里没有与 Compliance Platform 对等的一方平台。 |
| 对“安全团队需要还原意图”这种场景，哪个更顺？ | 如果你要的是一方 compliance surface，Codex 更顺。 | 如果你已经愿意把 OTel event 接进自己的 SIEM，并自己拼装 pipeline，Claude Code 也能成立。 |
当前信源里最大的差别，是打包路径，不是 telemetry 是否存在。
哪些团队更适合先试 Codex
如果下面大多数描述都成立，先从 Codex 开始更合适：
- 你的安全团队希望在大规模 rollout 前拿到集中 telemetry，并更偏好一方 compliance surface
- 你需要一套跨 desktop、CLI、IDE 的统一 policy baseline 和 workspace-bound auth
- 你的网络出口必须被限制在 managed allowlist 里
- 你的组织本来就按 compliance logs、SIEM ingestion、admin-enforced control 的思路工作
- pilot owner 是平台或安全团队，而不只是某个单独工程组
一个更像样的 Codex 首轮 pilot，通常长这样：
- 一个低风险仓库，或 disposable worktree
- 一类边界清楚的任务，例如 test fix、文档更新、review comment follow-up
- 一套 managed network policy
- 一条针对 approval exception 的 review 流程
- 每类 session 结束后做一次 log review
哪些团队更适合先试 Claude Code
如果下面大多数描述都成立，先从 Claude Code 开始更合适：
- 你的开发者希望自己理解并调节 sandbox
- repo 级路径规则和本地机器边界，比一方 compliance surface 更重要
- 你愿意先在 worktree、devcontainer 或其他隔离的本地环境中做 pilot
- 你的核心目标是减少 approval fatigue，但又不想直接放开 unrestricted Bash
- 你希望 permission model 是 allow / ask / deny 这种开发者一看就懂的规则类型
一个更像样的 Claude Code 首轮 pilot，通常长这样：
- 一个 throwaway branch 或 worktree
- 先跑
planmode - 在开
auto前先启用 sandbox - 对
.env、deploy path、git push写明 deny rule - 只保留一条 narrow verification command
两者通用的最小安全 pilot
不要被产品名分散注意力。对这两类工具来说，pilot shape 往往比“选哪家”更重要。下面五条，基本对两者都成立。
1. 先从隔离出来的仓库副本开始
用 worktree、throwaway clone 或 devcontainer。不要一上来就在仍然保留 live secret、release script、以及一堆无关半成品改动的 checkout 上试。
2. 先把允许路径写清楚
好的 policy 语言通常都很无聊，而且很具体。
Allowed paths:
- src/api
- tests/api
- docs/api-migration.md
Forbidden paths:
- .env*
- deployment/
- infra/
- scripts/release/
- package.json
- lockfiles
3. 在 autonomy 开始前先设 stop rule
可以先写一份这样的 stop list：
Stop and ask before:
- pushing or merging
- changing secrets or auth config
- opening billing or admin settings
- installing new dependencies
- contacting a new external domain
- touching more than 5 files outside the allowed paths
4. 只留一条 verification command
在第一轮 pilot 里，一条聚焦的 verification command 就够了。比如：
npm test -- api-client
pnpm lint src/api tests/api
如果 agent 需要更大范围的一堆 command 才能证明变更没问题，通常说明 pilot scope 已经放得太松。
5. 最终 diff 仍然要由人来审
不要把任一产品当成 merge gate。pilot 真正成功的标准，是人能快速回答三件事：
- 改了什么
- 为什么改
- 实际验证了什么
按 rollout 场景给建议
场景 1：安全评审先于开发者便利性
选 Codex。
OpenAI 的安全文章加上 Compliance Platform 相关说明，能更直接回答 approval flow、workspace-bound auth、network policy、telemetry export 这些治理问题。它不能替代真正的内部审查，但对安全相关 stakeholder 来说，这条公开叙事更 turnkey。
场景 2：一个工程团队想先跑起来，不想等企业级 rollout 全部到位
选 Claude Code。
sandbox 和 permissions 文档已经足够具体，小团队可以在 worktree 或 devcontainer 里做纪律化 pilot，而不必假装工具比它实际更封闭。
场景 3：现在先做本地实验，未来再考虑公司级默认方案
先用 Claude Code 做本地实验；如果后续扩张的真正瓶颈变成“一方 compliance path 不够顺”，再重新评估 Codex。
场景 4：你想用最短路径接入 compliance review
选 Codex。
基于这次核验到的公开信源，Codex 的一方 compliance path 更清楚，因为 OpenAI 把 telemetry 和 Compliance Platform 放在了一起。Claude Code 已经不能再被描述成“auditability 弱”，但它更像是 OTel + SIEM 取向的公开路径。
常见问题
面向企业安全，Codex 和 Claude Code 哪个更合适？
如果你的安全评审是从一方 compliance logging、workspace-bound auth 和 managed network policy 开始，Codex 更容易先被推荐。Claude Code 仍然可以用于企业环境，但它的公开叙事更偏自建：managed settings、OpenTelemetry events、SIEM export，而不是类似 OpenAI Compliance Platform 这种一方平台。
对一个小工程团队的首轮 pilot，哪个更合适？
通常是 Claude Code。它的文档让本地边界更容易看懂：plan、acceptEdits、sandbox path rule、deny rule、明确的 network-domain control。对于想先让一个团队跑起来、而不是整家公司马上定标准的场景，它更顺手。
平台团队应该先把哪个当作标准化候选？
如果标准化工作先从一方 compliance plumbing、workspace-bound auth 和 managed network policy 开始，Codex 是更顺手的第一推荐。如果标准化工作先从本地开发体验，以及自建 OTel / SIEM workflow 开始，Claude Code 更适合先在纪律化 sandbox 里试起来。
总体来说，Codex 一定比 Claude Code 更安全吗？
不一定。更安全的选项取决于你到底在优化什么。按当前公开文档，Codex 在一方合规工作流上更强；Claude Code 在本地 sandbox 细节和 policy explainability 上更强。真正决定风险的，往往还是 rollout shape，而不是品牌名字。
任一工具能不能安全地直接碰含有生产 secrets 的仓库？
默认应该假设不能处理。Anthropic 的文档明确警告 file-tool deny rule 不能阻止 Bash subprocess 继续读取；OpenAI 的 Codex 指南也仍然把 approvals 和 sandboxing 视为防护模型的一部分。把 secrets 从当前 working tree 里移走，或者把 pilot 挪到更干净的隔离环境中，再谈自动化。
核验说明
核验时间：2026-05-09。
核验项：
- OpenAI 的 Running Codex safely at OpenAI，用于核对 managed configuration、approvals、network policy、secure credential handling、OpenTelemetry log export，以及 Compliance Platform 相关说明
- Anthropic Claude Code Sandboxing 文档，核对 filesystem / network isolation、OS-level enforcement、allow / deny path control、unsandboxed-command escape hatch，以及 network policy limitation
- Anthropic Claude Code Permissions 文档，核对 mode 定义、allow / deny rule、Bash 规则行为，以及 file-tool deny rule 不会限制 Bash subprocess access 的警告
- Anthropic Claude Code Monitoring 文档，核对 OpenTelemetry metrics / logs / events、SIEM export，以及 prompt、tool decision、tool result、MCP activity 的事件模型
- Anthropic Claude Code Server-managed settings 文档，核对 centrally managed policy delivery 和 settings change audit logging
主要信源：
- OpenAI: https://openai.com/index/running-codex-safely/
- Anthropic Claude Code sandboxing docs: https://code.claude.com/docs/en/sandboxing
- Anthropic Claude Code permissions docs: https://code.claude.com/docs/en/permissions
- Anthropic Claude Code monitoring docs: https://code.claude.com/docs/en/monitoring-usage
- Anthropic Claude Code server-managed settings docs: https://code.claude.com/docs/en/server-managed-settings