Claude Code vs Codex CLI 2026：决策参考

我把 Claude Code 当作主力开发工具。这一点偏好值得先讲明，因为最有力的对比文章，往往出自对一个工具的深入了解，再去诚实地检验另一个。经过 36 场盲测对决（我把相同任务分别交给两个工具，在不知道结果出自谁手的情况下为输出打分 ¹），以及两个工具各自数百次会话之后，我发现”哪个更好？”的答案确实是”取决于任务”。

Claude Code 更擅长深度重构、代码审查，以及通过生命周期钩子系统实现可编程的治理；Codex CLI 则在内核级沙箱和借助 AGENTS.md 实现的跨工具可移植性上更胜一筹。 Claude Code 在应用层强制保障安全，提供两打以上需要您自行接线的钩子事件；Codex 则在操作系统内核层强制保障安全，模型无法绕过那里的限制。需要复杂的多文件推理和最深度的可定制工作流，就选 Claude Code。需要最大限度的隔离，以及在 8 个以上工具间通用的标准化代理指令，就选 Codex。

本文内容截至 2026 年 6 月 5 日。 两个工具都按周发布，因此此处的事实有保质期。截至本次修订，Claude Code 默认使用 Opus 4.8（CLI v2.1.165），Codex 默认使用 GPT-5.5（CLI v0.137.0）。自今春以来最大的变化是：Codex 上线了真正的生命周期钩子系统，缩小了过去 Claude Code 最明显的领先优势。这一变化改变了什么、又没有改变什么，请参阅各工具的优势所在。

一句话总结

Claude Code 和 Codex CLI 解决的是同一个问题（AI 辅助开发），但架构截然不同。Claude Code 主要通过钩子进行治理：两打以上的生命周期事件类型，在应用层以确定性的方式强制执行策略 ²。Codex 则主要通过沙箱进行治理：在应用层之下设置操作系统级的内核限制 ³，如今又配上了自己的生命周期钩子。两种思路谈不上谁绝对更优。

在盲测中，Claude Code 在代码审查和安全验证上始终优于 Codex。Codex 则在沙箱、借助 AGENTS.md 的跨工具可移植性，以及云端任务委派上具备实实在在的优势。

快速决策： 需要内核级沙箱或跨工具的 AGENTS.md？→ Codex。需要最成熟的可编程治理钩子或深度重构？→ Claude Code。两种安全模型都需要？→ 两个一起用。

两个都没用过？ 先从 Claude Code 指南或 Codex 指南入手。本文假定您至少熟悉其中之一。

两种思维模型

两个工具都是三层架构，但各层的用途不同。

Claude Code：

1. 推理。Claude Code 运行所选的 Claude 模型。自 CLI v2.1.154（2026 年 5 月 28 日）起，Opus 4.8 成为默认，默认采用高强度推理，并为最棘手的任务提供 /effort xhigh 档；Sonnet 4.6 和 Haiku 4.5 仍可选用于较轻量的工作 ²
2. 执行。Bash、文件操作、git 命令、MCP 工具调用
3. 治理。钩子在两打以上的生命周期节点拦截操作 ²；权限则约束作用范围

Codex：

1. 模型。GPT-5.5（2026 年 4 月 23 日发布）为默认：在 Codex 中提供 400K 上下文，在 API 中为 1M，价格为每 MTok 5 美元 / 30 美元，在 Terminal-Bench 2.0 上得分 82.7%（发布时为业界最佳）。GPT-5.5-pro 覆盖最高强度档；更小的 GPT-5.4 mini 仍负责低延迟的子代理工作 ⁴
2. 沙箱。操作系统级的内核强制（macOS 上为 Seatbelt，Linux 上为 Landlock + seccomp）³
3. 审批。三种策略（untrusted、on-request、never）在执行前对变更进行把关 ⁵

关键差异在于治理主要存在于何处。Claude Code 的重心在应用层；钩子是您编写的、用来拦截特定事件的程序。Codex 的重心在内核层；无论模型尝试什么，操作系统都会阻止不被允许的操作。如今两个工具都有了钩子，但其架构在默认侧重上依然不同。

为何这一区别重要： 应用层治理是可编程的。您可以编码业务逻辑、运行 linter、校验 schema，凡是能用代码表达的都行。内核层治理则无从逃逸。模型无法绕过限制，因为在系统调用抵达应用之前，操作系统就已将其拒绝。任何安全架构都是在表达力与强度之间权衡，而这两个工具恰好处在这一光谱的两端。

配置理念

Claude Code 使用 JSON，Codex 使用 TOML。两者都支持分层作用域。差别在于它们如何看待上下文切换。

Claude Code：分层配置

// ~/.claude/settings.json (user-level)
{
  "permissions": {
    "allow": ["Bash(git *)"],
    "deny": ["Bash(rm -rf *)"]
  }
}

// .claude/settings.json (project-level, inherits user)
{
  "permissions": {
    "allow": ["Bash(npm test)"]
  }
}

Claude Code 从多个层级解析设置：托管设置（最高优先级）→ 命令行 → 本地项目 → 共享项目 → 用户默认值 ⁶。记忆文件（CLAUDE.md）有自己的作用域：用户 → 项目 → 本地。技能和钩子又会再加几层。这种灵活性很强大，但活动配置在任何单个文件中都看不全；您得通过阅读整个层级体系把它拼凑出来。

Codex：带显式切换的配置档

# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"

[profiles.deep-review]
model = "gpt-5.5-pro"
approval_policy = "never"

[profiles.careful]
approval_policy = "untrusted"

codex --profile careful "Review this PR"
codex --profile deep-review "Audit this module"

Codex 的配置档让您用一个标志即可在不同配置间切换 ⁷。无需推敲层级解析；活动配置始终一目了然。对于在审批策略上要统一标准的团队，这更便于审计。配置档已从实验性功能升级为一等的托管界面：--profile 如今是贯穿 CLI、TUI 权限与沙箱流程的主选择器，命名权限配置档支持继承、列出 API，并提供托管的 requirements.toml 用于组织策略 ⁷。

安全模型

安全是两个工具之间最深层的架构分歧。

Claude Code：应用层的确定性钩子

钩子在操作执行前进行拦截。一个作用于 Bash 的 PreToolUse 钩子可以检查每一条命令并拦截危险模式 ²：

# Hook: git-safety-guardian (PreToolUse:Bash)
if echo "$tool_input" | grep -q "push.*--force.*main"; then
  echo '{"decision": "block", "reason": "Force push to main blocked"}'
fi

优势在于：钩子就是程序。您可以编码任意复杂的安全逻辑：检查文件路径、校验 JSON、强制命名约定、运行 linter。我运行着 95 个钩子，涵盖从凭据检测到质量关口的方方面面。

劣势在于：钩子运行在应用层。2025 年，Check Point Research 披露了 CVE-2025-59536，演示了项目配置文件中的恶意钩子如何在 Claude Code 初始化期间、在用户看到同意对话框之前执行 shell 命令 ¹⁹。Anthropic 在数周内修复了该漏洞，但此次披露印证了那个架构层面的担忧：应用层强制与代理共享同一个进程边界。NVIDIA 的 AI 红队指南也得出相同结论：”钩子和 MCP 初始化函数往往在沙箱环境之外运行，从而给了逃逸沙箱管控的可乘之机”²⁰。

Codex：内核级沙箱

Codex 在操作系统层面约束代理。在 macOS 上，Seatbelt 配置档限制文件系统访问、网络连接和进程派生 ³。在 Linux 上，Landlock + seccomp 提供等效限制，并可通过配置启用可选的 Bubblewrap（bwrap）流水线 ³。

# Three sandbox modes
codex --sandbox read-only           # Agent can read but not write
codex --sandbox workspace-write     # Agent writes only in project directory (default)
codex --sandbox danger-full-access  # No restrictions (named to signal risk)

优势在于：内核级强制位于应用之下。模型无法通过精心构造命令来逃脱限制；操作系统会在系统调用执行前将其拒绝 ³。完全访问模式上的 danger- 前缀，正反映出解除沙箱限制是一种例外操作，而非日常设置。

劣势在于：内核限制是二元的。您可以允许或拒绝文件系统写入，但无法说”允许写入 src/，但除非变更通过 linter，否则禁止写入 config/“。那种细粒度的治理需要应用层逻辑。

这种权衡是实打实的。 钩子提供细粒度、可编程的安全，但边界较弱。沙箱提供更强的边界，但控制更粗。一个快速决策的经验法则：

• 内部可信、外部代码： 审查来自陌生贡献者的 PR 时，用 Codex 配合 read-only 沙箱。无论模型尝试什么，内核都会阻止文件被修改。
• 可信代码、策略强制： 当您信任代码库，但需要强制执行组织标准（提交信息格式、凭据扫描、linting 关口）时，用 Claude Code 钩子。
• 两种顾虑都有： 两个一起用。先用 Codex 设置初始的安全边界，再切换到 Claude Code 进行治理密集型的审查。

可扩展性

两个工具都支持定制，但各机制的成熟度参差不齐。

Claude Code 领先之处： 钩子的深度。生命周期系统涵盖 PreToolUse、PostToolUse、UserPromptSubmit、SessionStart、SessionEnd、Stop、StopFailure、SubagentStart、SubagentStop、PreCompact、PermissionRequest、PermissionDenied、TaskCreated、TaskCompleted、CwdChanged、FileChanged、MessageDisplay 等。这已是两打以上的事件，且仍在增加 ²。Codex 如今也有了钩子，但 Claude Code 的目录更宽、经受过更多实战检验，并能与 Stop 钩子的 additionalContext 配合用于引导，以及借助动态 /workflows 实现大规模代理扇出。如果您需要强制执行质量关口、在提交前检测凭据泄露，或跨多种事件类型自动注入上下文，Claude Code 的钩子架构是更成熟的选择。

Codex 弥合差距之处： 钩子不再是 Claude Code 的专属。整个 2025 年，社区一直在呼吁扩充钩子事件 ¹⁸，而 Codex 兑现了：一套真正的生命周期钩子系统，带 AfterAgent 与 AfterToolUse 事件，一个可在会话中途发现并开关钩子的 /hooks TUI，以及一个扩展 API——扩展可观察子代理的启停、工具执行和回合元数据，并支持异步审批 ⁹。旧有的说法（Claude Code 有钩子，Codex 只有一个事后触发的通知）已经过时。诚实的 2026 年表述是：两个工具都有可编程治理钩子；Claude Code 的更宽、更成熟，Codex 的则与同类中最强的沙箱并肩运行。

Codex 领先之处： 跨工具可移植性与界面覆盖。AGENTS.md 是由 Linux 基金会旗下 Agentic AI Foundation 治理的开放标准 ¹³，已被 6 万以上项目采用 ⁸。同一个指令文件可在 Codex、Cursor、GitHub Copilot、Amp、Windsurf 和 Gemini CLI（需配置）中通用 ¹⁴。CLAUDE.md 很强大，但被锁定在 Claude Code 上。Codex 还横跨五种界面（CLI、桌面应用、IDE 扩展、云端，以及一个伴随正常浏览运行的 Chrome 扩展 ¹⁶），而 codex cloud exec 可把长时间运行的工作卸载到 OpenAI 基础设施并返回差异 ¹²——这是 Claude Code 没有原生提供的工作流。

各工具的优势所在

基于 36 场盲测对决（我把相同提示发给两个工具，在盲态下为输出打分）以及日常生产使用：

完整方法论与逐场对决评分见 The Blind Judge。这些结果早于 Opus 4.8 和 GPT-5.5，因此请把它们当作方向性参考，而非当下的实时记分牌：它们刻画的是各工具的形态（Claude Code 在审查与推理上更强，Codex 在 DevOps 与隔离上更强）——这一形态在模型升级中一以贯之，而非如今模型上的确切差距。我会在当前默认模型上重跑这些对决；在此之前，类别上的倾向才是经得起时间检验的信号。

Claude Code 的强项

• 代码审查与安全验证。 在审查类任务中，Claude Code 在 12 场已决出胜负的对决中赢了 8 场 ¹。其质量哲学体系和证据关口能抓出那些从 Codex 更偏流程化的做法中漏掉的问题。
• 治理密集型工作流。 如果您的工作流需要提交前检查、凭据扫描、输出校验，或在执行前拦截的质量关口，Claude Code 的 PreToolUse 钩子就是合适的机制。Codex 如今也有了自己的生命周期钩子（AfterAgent、AfterToolUse）⁹，但它们是事后观察；对于执行前的拦截，Codex 依靠的是沙箱和审批策略，而非可编程的前置钩子。论事件类型的广度与内联拦截逻辑，Claude Code 的目录仍是更完整的治理工具集。
• 复杂的多代理编排。 通过 Task 工具进行显式的子代理委派 ¹⁰，再结合在后台扇出数十至数百个代理的动态 /workflows 以及审议系统，可支撑起众多专门化代理在隔离上下文中协作的工作流。
• 深度代码库重构。 Opus 擅长在长会话中持续把握架构上下文。那套统御 Claude Code 钩子/技能/规则层级的上下文工程模式，可以直接映射到模型对大型代码库的推理方式上。

Codex 的强项

• 沙箱关键型环境。 如果您要让 AI 代理面对不可信代码、处理外部 PR，或在 CI/CD 流水线中运行，需要对文件系统和网络访问有硬性保证，那么 Codex 的内核级沙箱就是对的工具 ³。应用层钩子无法提供同等保证。
• 跨工具团队。 如果您的团队使用多种 AI 编程工具，AGENTS.md 让您用一个指令文件即可在 Codex、Cursor、Copilot、Amp、Windsurf 等中通用 ¹⁴。无需在 CLAUDE.md、.cursor/rules 和 Copilot 指令之间重复维护。
• 云端异步工作流。 codex cloud exec 把任务委派给云端基础设施并返回差异 ¹²。对于 CI/CD 集成或批处理，这是 Claude Code 没有原生提供的工作流。
• 实时引导。 Codex 的引导模式让您可以在任务中途用 Enter 即时注入指令，或用 Tab 把后续指令排入下一回合 ¹⁵。Claude Code 支持后续消息，但不支持回合中途注入。
• 界面覆盖。 Codex 横跨五种界面：CLI、桌面应用（macOS 上可跨多个并行 worktree 多任务处理，并支持浮动窗口）、IDE 扩展（VS Code、Cursor、Windsurf）、云端任务，以及一个与浏览并行、不会喧宾夺主的 Chrome 扩展 ¹⁶。Claude Code 集成了 VS Code 和 JetBrains ¹⁷，但以 CLI 为先。如果您想要一个能从终端跟随您到编辑器、再到浏览器、再到云端的代理，Codex 覆盖的范围更广。

两个一起用

这两个工具并不冲突。CLAUDE.md 与 AGENTS.md 可在同一个代码库中共存。这是我的配置：

my-project/
├── .claude/
│   └── settings.json     # Claude Code project config
├── CLAUDE.md              # Claude Code instructions
├── AGENTS.md              # Codex + Cursor + Copilot instructions
└── codex.md               # Codex project config (optional)

一个具体的双工具工作流： 我用 Claude Code 做日常开发：功能实现、代码审查，以及由钩子在每一步强制质量关口的多文件重构。当外部贡献者提交 PR 时，我切换到配合 --sandbox read-only 的 Codex，对照不可信代码审查其改动。当我需要就架构决策征求第二意见时，我把相同提示发给两个工具，并以盲测裁判的方式盲态对比输出。

这种双工具做法的实证支撑超出了我个人的测试。Milvus 的研究发现，多个 AI 模型之间的对抗式审查把缺陷检出率从 53% 提升到了 80% ²³。另一项研究发现，反复进行的 Claude-Codex 审查循环在 3 轮中抓出了 14 个任一工具单独都未发现的问题 ²⁴。两个工具谁也无法替代谁；它们覆盖的是不同的威胁模型和任务画像。

关键要点

如果您正在选工具：

• 从您的安全需求出发。需要内核级沙箱？选 Codex。需要可编程的治理钩子？选 Claude Code。
• 考虑您的团队。在用多种 AI 工具？AGENTS.md 可避免跨工具重复维护指令 ¹⁴。
• 决定之前，先在一个真实任务上把两个都试一遍。盲测裁判方法论同样适用于个人评估。

如果您已经投入其中：

• Claude Code 用户：无论如何也写一个 AGENTS.md。这只需 20 分钟，却能让您的项目对 Codex、Cursor 和 Copilot 用户开放。
• Codex 用户：钩子系统已经到位。用 /hooks 浏览它，接好 AfterAgent/AfterToolUse，并借助权限配置档加沙箱来实现执行前的控制 ⁹。您可能还停留在 2026 年早些时候的”Codex 没有钩子”的印象——它已经过时了。
• 两个工具都在飞速进步。本文中的对比，其保质期是以周而非以年计的——这正是它要附上一行带日期的修订说明的原因。

常见问题

我能在同一个项目里同时用两个工具吗？

可以。CLAUDE.md 与 AGENTS.md 是各自独立的文件，互不冲突。每个工具读取自己的指令文件，忽略另一个。我在自己的活跃项目里两个都维护。

哪个工具更适合新手？

Codex 的配置门槛更低：三种沙箱模式加三种审批策略，足以覆盖大多数使用场景 ⁵。Claude Code 的威力来自钩子和技能，而这些需要投入精力来搭建。从您已经用得顺手的那个模型（Claude 或 GPT）入手即可。

成本如何对比？

两者都通过各自的 API 采用基于 token 的计费。Claude Code 走 Anthropic 的定价；Codex 走 OpenAI 的额度体系。Composio 的独立基准测试发现，在可比结果下，Codex 消耗的 token 少 2 到 4 倍。在一个 Figma 插件任务上，Claude Code 用了 620 万 token，而 Codex 为 150 万 ²²。token 效率并不直接等同于成本（每 token 定价不同），但 Codex 更低的 token 消耗，对预算受限的工作流而言是一项可量化的优势。

AGENTS.md 能配合 Claude Code 使用吗？

目前不能。Claude Code 读取 CLAUDE.md；Codex 读取 AGENTS.md。两种格式足够相似，内容很容易在彼此之间转换，但没有自动的交叉读取。由于内容多有重叠，把两个都写出来花不了多少功夫。

哪个的 IDE 集成更好？

Codex 的覆盖面更广：一个带多任务和浮动窗口的 macOS 桌面应用、一个面向 VS Code、Cursor 和 Windsurf 的 IDE 扩展，以及一个 Chrome 扩展，全部共享同一套会话模型 ¹⁶。Claude Code 通过扩展集成 VS Code，通过插件（测试版）集成 JetBrains ¹⁷。两者都运作良好；选择取决于您更偏好以 CLI 为先（Claude Code），还是偏好 GUI/多界面的覆盖（Codex）。

参考资料