Claude Code 對決 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，預設採高強度（high effort），並提供 /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.4 在推進期間仍為後備選項，而 GPT-5.4 mini 則負責對延遲較敏感的子代理工作 ⁴
2. 沙箱層。作業系統層級的核心強制（macOS 上為 Seatbelt，Linux 上為 Landlock + seccomp）³
3. 核准層。三種政策（untrusted、on-request、never）在執行前控管變更 ⁵

關鍵差異在於治理主要落在哪一層。Claude Code 的重心在應用程式層；掛鉤是您撰寫、用以攔截特定事件的程式。Codex 的重心在核心層；無論模型嘗試什麼，作業系統都會阻止不被允許的操作。如今兩項工具都有掛鉤，但兩者的架構在預設設計上仍各有側重。

這項區別為何重要： 應用程式層的治理是可程式化的。您可以編寫商業邏輯、執行 linter、驗證綱要，凡是能以程式碼表達的都行。核心層的治理則是無從逃脫的。模型無法繞過限制，因為作業系統在系統呼叫（syscall）抵達應用程式之前就已拒絕。每一種安全架構都是在表達力與強度之間做取捨，而這兩項工具恰好位於這條光譜的兩端。

設定哲學

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：可明確切換的設定檔（Profile）

# ~/.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 時，請搭配 read-only 沙箱使用 Codex。無論模型嘗試什麼，核心都會阻止檔案被修改。
• 可信程式碼，政策強制： 當您信任這套程式庫，但需要強制執行組織標準時——commit 訊息格式、憑證掃描、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 搭配實現大規模的代理擴散。若您需要強制品質關卡、在 commit 前偵測憑證外洩，或跨多種事件類型自動注入脈絡，Claude Code 的掛鉤架構是更成熟的選擇。

Codex 補上的缺口： 掛鉤不再是 Claude Code 的專利。社群在 2025 年大半時間都在要求擴充掛鉤事件 ¹⁸，而 Codex 也交出了成果：一套真正的生命週期掛鉤系統，具備 AfterAgent 與 AfterToolUse 事件、一個可在會話中途發掘並切換掛鉤的 /hooks TUI，以及一個讓擴充功能能觀測子代理啟動／停止、工具執行與回合中介資料、並支援非同步核准的擴充 API ⁹。舊有的說法（Claude Code 有掛鉤，Codex 只有單一的事後通知）已經過時。誠實的 2026 年版本是：兩項工具都有可程式化的治理掛鉤；Claude Code 的更廣、更成熟，Codex 的則與同類最強的沙箱並肩運作。

Codex 的領先之處： 跨工具可攜性與介面廣度。AGENTS.md 是由 Linux Foundation 旗下的 Agentic AI Foundation 治理的開放標準 ¹³，已有 6 萬以上專案採用 ⁸。同一份指令檔可在 Codex、Cursor、GitHub Copilot、Amp、Windsurf 與 Gemini CLI（須設定）中運作 ¹⁴。CLAUDE.md 雖然強大，卻綁定於 Claude Code。Codex 同時橫跨五種介面（CLI、桌面 App、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 的引導（steer）模式讓您能在任務中途以 Enter 注入指令（立即生效），或以 Tab 排入後續指令（下一回合）¹⁵。Claude Code 支援後續訊息，但不支援回合中途的注入。
• 介面涵蓋面。 Codex 橫跨五種介面：CLI、桌面 App（macOS 上可跨並行工作樹與浮動視窗進行多工）、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 採用以詞元計價的方式。Claude Code 跑在 Anthropic 的價格體系上；Codex 則跑在 OpenAI 的點數系統上。Composio 的獨立基準測試發現，在可比較的結果下，Codex 消耗的詞元少了 2 到 4 倍。在一項 Figma 外掛任務中，Claude Code 用了 620 萬個詞元，相較之下 Codex 只用了 150 萬個 ²²。詞元效率並不會直接換算成成本（每詞元的價格不同），但對於預算受限的工作流程而言，Codex 較低的詞元消耗是一項可量測的優勢。

AGENTS.md 能搭配 Claude Code 使用嗎？

目前不行。Claude Code 讀取 CLAUDE.md；Codex 讀取 AGENTS.md。兩種格式相近到內容可以輕易互譯，但沒有自動的交叉讀取。由於內容多有重疊，兩份都寫並不費什麼工夫。

哪一項的 IDE 整合比較好？

Codex 的涵蓋面較廣：一個具備多工與浮動視窗的 macOS 桌面 App、一個支援 VS Code、Cursor 與 Windsurf 的 IDE 擴充功能，以及一個 Chrome 擴充功能，全部共用同一套會話模型 ¹⁶。Claude Code 透過擴充功能整合 VS Code，並透過外掛（beta）整合 JetBrains ¹⁷。兩者都運作良好；選擇取決於您偏好以 CLI 為先（Claude Code），還是偏好 GUI／多介面的覆蓋（Codex）。

參考資料