Claude Code 和 Codex 怎麼分工？先看權限、執行環境與工作流
本篇是「Codex 和 Claude Code 雙修」系列的第 1 / 7 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
我一開始把 Codex 當成 Claude Code 額度不夠時的備用工具。真的兩邊一起用之後，才發現「備用」反而低估了它：兩套工具最有價值的地方，不是互相取代，而是讓我能依任務換一套工作方式。
所以我現在不太問「哪一個比較強」，而是先問三件事：
- 這個任務能碰哪些檔案、指令與網路？
- 專案規則要怎麼被讀取與覆寫？
- 我需要的是互動探索、自動化執行，還是第二個 reviewer？
這三題比模型排行榜耐用，也比較接近每天寫程式時真正會遇到的選擇。
這是「Codex 和 Claude Code 雙修」系列第 1 篇。下一篇會把兩邊常用能力整理成一張不容易過期的對照表。
先拆掉一個錯誤期待：雙修不是雙倍產能
同時裝兩個 CLI，不會自動得到兩倍產能。相反地，如果兩邊的規則、權限與工具各自長一套，維護成本會先加倍。
雙修值得做，是因為它多了三種選擇：
- 換一種工作介面：同一個任務在互動探索、背景執行或非互動腳本裡，體感差很多。
- 換一組執行邊界：依任務風險決定能否寫檔、能否連網、哪些指令需要確認。
- 換一個 reviewer：讓沒有參與實作的工具檢查 diff，但仍以測試與人工判斷收尾。
關鍵不是每次兩個都開，而是保留切換的能力。
心智模型一：把「允許做什麼」拆開看
Claude Code 與 Codex 都有權限控制和沙箱，但使用介面不完全相同。
Claude Code 主要用 permission mode、allow/deny rules 與 sandbox 來決定它何時詢問、哪些操作被允許，以及 Bash 指令可接觸的範圍。像 plan 適合先讀程式與規劃，acceptEdits 會放寬檔案編輯，但工具規則仍會疊加在模式上。完整行為應以 Claude Code permission modes 與 sandboxing 文件為準。
Codex 則把兩個問題明確分開：
- approval policy：什麼情況需要問你。
- sandbox mode：這個程序實際能碰到哪些檔案、程序與網路。
例如下面這個組合，適合讓 reviewer 讀取 repo，但不准它修改工作目錄，也不要在執行途中等人批准：
codex exec -s read-only -a never "Review the current uncommitted changes"可以把 Claude Code 想成「工作模式加規則」，把 Codex 想成「詢問策略乘上執行邊界」。這只是方便記憶的近似，不是一對一翻譯；兩邊功能都在持續演進。
不要把跳過確認當成同義詞
--dangerously-skip-permissions 和 --yolo 都會大幅降低護欄，但不能因此推論兩邊在相同環境下有相同風險。真正要確認的是：
- 寫入範圍是否只限工作目錄；
- 網路是否開放；
- secrets 是否存在環境變數；
- 指令會不會接觸 Docker socket、雲端憑證或家目錄；
- 是否還有容器、VM 或 CI runner 這層外部隔離。
這兩個選項只適合已經有外部隔離、而且你清楚失敗半徑的環境。
心智模型二：專案規則相近，但不是同一個檔名而已
Claude Code 主要讀取 CLAUDE.md，Codex 主要讀取 AGENTS.md。它們都能放建置指令、架構說明、測試要求和不可碰的範圍，但搜尋、分層與覆寫方式不同。
Claude Code 可以在 CLAUDE.md 中用 @AGENTS.md 匯入共用規則；Codex 會沿目錄結構尋找 AGENTS.md，並讓較接近目前工作目錄的規則覆寫上層內容。詳細行為分別見 Claude Code memory 與 Codex AGENTS.md。
所以我不再把兩份檔案完全複製。比較穩定的做法是：
AGENTS.md 共用的 repo 規則
CLAUDE.md 匯入 AGENTS.md，再補 Claude Code 專屬說明
.codex/config.toml Codex 專屬執行設定
.claude/settings.json
Claude Code 專屬權限與 hooks第三篇會把這套結構完整展開。
心智模型三：先按任務分工，不按品牌站隊
我目前用下面四個問題決定誰上場：
| 問題 | 判斷方式 |
|---|---|
| 需要哪個介面？ | 互動探索、非互動腳本、遠端控制或背景工作，選當下流程最順的工具。 |
| 能接受多大權限？ | 先設計寫入、網路與 secrets 邊界，再選對應模式，不從「全開」開始。 |
| repo 規則在哪邊維護？ | 優先共用核心規則，工具專屬設定分開。 |
| 如何驗證？ | 測試、型別檢查與靜態分析優先；第二個 agent 只補盲點。 |
遇到新專案時，我會把同一個小任務分別交給兩邊，例如修一個有測試的 bug。比較的不是誰講得更有自信，而是：
- 有沒有先讀對檔案；
- 是否遵守 repo 規則；
- 修改範圍是否克制；
- 測試失敗時能否找出真正原因；
- 最後的 diff 是否容易 review。
這種 repo 內的小型評估，比網路上的單一 benchmark 更能回答「哪個適合我現在的工作」。
雙修真正省下的是切換成本
如果共用規則、Skills 和 MCP 都整理好，你可以讓其中一個工具實作，另一個工具檢查；也可以在服務異常、額度不足或某種任務不順時切換，而不用重新解釋整個專案。
但不要把「不同模型」誤會成「一定獨立」。它們仍可能共享相似資料、工具限制與錯誤假設。第二個 reviewer 是額外訊號，不是正確性證明。
這個系列接下來會依序處理功能對照、共用專案規則、Skills、MCP，最後才把跨工具 review 串起來。順序很重要：沒有前面的基礎建設，雙修很容易只是開兩個終端機重複貼 prompt。
