CodexとClaude Codeの違いをソースで解剖。Codexは既定で通信と.gitを止める

CodexとClaude Codeは既定で何が違うのか？

最も大きな違いは、安全をどこで担保するかです。Codexは既定でOSのサンドボックスをかけ、通信や作業フォルダ外への書き込みを仕組みで止めます。Claude Codeはサンドボックスが任意で、既定のautoモードでは、危険な操作かどうかを分類器が判断します。同じ依頼を両方に3回ずつ出すと、結果ははっきり分かれました。

Codexの結果は「失敗」ではなく、設計どおりの動作です。Codexを非対話で動かす codex exec は承認を一切求めない設定で動くため、サンドボックスで止まった操作はそのまま失敗として返ります。対話モードでは、モデルが権限の拡大を求め、利用者が承認すれば実行できます。逆にClaude Codeも、サンドボックスを有効にすれば通信や書き込みを同じように制限できます。違いは、既定で閉じているか開いているかです。実際にClaude Codeでサンドボックスを有効にすると、通信とフォルダ外への書き込みは3回とも止まりました。ただしgit commitは3回とも通りました。Claude Codeのサンドボックスは.gitを特別扱いしないためです。

フォルダ外への書き込みについて、Codexはコマンドを試しもせずに断りました。Codexはモデルへの指示に、書き込める場所とネットワークの可否を毎回書き込んでいるためです。なお、親フォルダが /tmp の下にあると、Codexは書き込みに成功しました。/tmp と $TMPDIR は既定で書き込み可能な範囲に含まれるからです。

普通の作業では、速さや読み込む量は違うのか？

制限に当たらない普通の作業では、どちらも正しく答えました。10個のPythonファイルの関数の数を数える作業では、Claude Codeの方が速く、モデルに送った文脈も少なく済みました。Codexは最初に送る指示（基本指示、権限の説明、道具の定義）が大きいためと考えられます。

Codexのハーネスとは？全体の構成

ハーネスとは、モデルの外側でループを回し、道具を渡し、権限を管理する部分です。Codexのハーネスは codex-rs/ 以下のRust製で、134の項目（ほとんどがクレート）に分かれています。中心は core で、モデル呼び出し、ツール、サンドボックス、設定、拡張がそれぞれ別のクレートになっています。

非対話の codex exec も、VS Code拡張やデスクトップアプリも、内部では同じ app-server を通してcoreを動かします。画面が違っても、ループと安全の仕組みは共通です。

1回の依頼はどう処理されるのか？エージェントループ

Codexは、モデルがツールを呼ぶ限りリクエストを繰り返し、文章だけを返したらターンを終えます。この基本はClaude Codeと同じです。特徴は、通信がOpenAIのResponses APIだけに絞られていること、ツールをストリーミング中から実行し始めること、接続が切れても既定で無制限に再接続することです。

• APIはResponses APIのみ：接続方式の定義は Responses の1種類だけで、Chat Completionsには対応しません（model-provider-info/src/lib.rs 117〜121行）。リクエストは store: false で、推論の中身は暗号化された形で受け取って次に渡します（core/src/client.rs 1295〜1314行）。OpenAIにはWebSocketでつなぎ、だめならHTTPに切り替えます。
• 基本指示は「developer」発言として先頭に置く：モデルごとの指示文はモデル一覧（models-manager/models.json）に入っていて、リクエストの先頭にdeveloperロールのメッセージとして付きます（client.rs 1214〜1224行）。作業フォルダ、シェル、日付、書き込める範囲、ネットワークの可否は <environment_context> として渡します。
• ツールはストリーミング中に走り出す：モデルの出力でツール呼び出しが確定した時点で実行を始めます（core/src/stream_events_utils.rs 386〜405行）。並列に動かしてよいツールは読み取りロック、それ以外は書き込みロックを取る仕組みで、シェル実行は並列可、ファイル編集は1つずつです（core/src/tools/parallel.rs）。
• ターンの終わり方：ツール呼び出しも追加の入力もなければ終了です。Stopフックが止めれば、続きを促す文を足してもう一周します（turn.rs 805〜913行）。
• 中断と再接続：利用者が中断すると、「利用者が意図的に中断した。コマンドが途中まで実行されたかもしれない」という趣旨の文を履歴に残します。接続の失敗は既定で上限なく再試行し、間隔は5秒から最大60秒まで延びます（core/src/responses_retry.rs）。

モデルにはどんな道具が渡されるのか？

Codexがモデルに渡す道具の中心は、PTY上でコマンドを動かす exec_command と、独自形式でファイルを書き換える apply_patch です。さらに、同梱のモデル一覧12件のうち11件は「code mode専用」に設定されています。この場合、モデルはJavaScriptを書いて、その中から道具を呼び出します。

道具の出力は、既定で1万トークンを超えると中央を切り詰め、「出力を切り詰めた（元のトークン数）」という注記を付けてモデルに渡します。切り詰めるのはモデルに渡す履歴だけで、保存される記録（rollout）は全文のままです。

code modeは、Claude Codeとの設計の違いが最も大きい部分です。Claude Codeではモデルが道具を1つずつ呼びますが、Codexのcode modeでは、モデルが書いた1つのプログラムの中で道具を何度も呼べます。プログラムの中から呼んだ道具も、通常の呼び出しと同じ承認とサンドボックスを通ります（core/src/tools/code_mode/mod.rs）。

サンドボックスと承認はどう組まれているのか？

Codexの安全は3層です。OSのサンドボックスで物理的に閉じ、承認ポリシーで人に聞くかを決め、Starlarkで書くルールで個別のコマンドを許可・禁止します。既定のサンドボックスはフォルダの信頼状態で決まり、信頼済みなら作業フォルダへの書き込みだけを許す「workspace-write」です。

.aws が保護対象に入っているのは、AWSのプロファイルが資格情報を取り出すプログラムを指定でき、それが実行されうるためだとコメントに書かれています。.codex は、まだ存在しないうちから保護されます。エージェントが自分の設定フォルダを作り、自分の権限を広げることを防ぐためです。

注意したい点が2つあります。1つは、承認ルール（execpolicy）で allow にしたコマンドは、承認だけでなくサンドボックスも外れて実行されることです（core/src/exec_policy.rs 492〜506行）。もう1つは、「安全なコマンド」の一覧を持たないことです。危険と判定する仕組みは rm -f 系を見る程度で、それ以外の守りはサンドボックスに任せています。Claude Codeが読み取り専用のコマンド一覧を持ち、autoモードでは分類器が判断するのとは考え方が逆です。

承認をAIに任せる「auto review」もあります。承認が必要になったとき、専用のサブエージェントが文脈を集めてリスクを判断します。ただし approvals_reviewer = "auto_review" を設定したときだけ動き、既定では人が承認します（core/src/tools/approvals.rs 690〜760行）。

AGENTS.mdと文脈はどう管理されるのか？

CodexはAGENTS.mdを、プロジェクトの根元（既定は.gitのある場所）から作業フォルダまで順に読みます。合計の上限は32KiBで、超えた分は捨てます。実測でも、34.6KB地点に書いた指示は2回とも無視され、8KB地点の指示は2回とも守られました。Claude CodeのCLAUDE.mdは、60KB地点の指示まで3回とも守りました。

• 読む順と優先：各フォルダで AGENTS.override.md、AGENTS.md、設定した代替ファイル名の順に、最初に見つかった1つを読みます（core/src/agents_md.rs）。全体用は ~/.codex/AGENTS.md です。
• 上限：DEFAULT_PROJECT_DOC_MAX_BYTES = 32 * 1024（config/src/config_toml.rs 77行）。project_doc_max_bytes で変えられます。codex exec の出力には、打ち切りの警告は出ませんでした。
• 信頼：明示的に「信頼しない」としたフォルダではAGENTS.mdを読みません。信頼の記録がないだけのフォルダでは読みました（実測）。
• 自動圧縮：文脈が上限の90%に達すると圧縮します。OpenAIのモデルではサーバー側で圧縮し、それ以外は要約用の指示文（「別のLLMに引き継ぐための要約を作る」）で手元で要約します（core/src/compact.rs）。
• 記録：会話は ~/.codex/sessions/年/月/日/rollout-*.jsonl に保存し、7日を過ぎるとzstdで圧縮します。会話から学んで覚えるmemories機能もありますが、既定ではオフです。

AGENTS.mdとCLAUDE.mdを1つのファイルで共有している場合、32KiBを超えた部分はCodexには届きません。重要な指示はファイルの前半に置き、長い資料はスキルや別ファイルに分けると、両方で同じように効きます。

フック・スキル・プラグインはClaude Codeと互換なのか？

かなり寄せてあります。Codexのフックは14種類のイベントを持ち、設定の書式はClaude Codeとほぼ同じです。プラグインは .claude-plugin/plugin.json も読みます。大きな違いは、フックの信頼の扱いです。

• フック：PreToolUse、PostToolUse、SessionStart、Stopなど14種類で、hooks.json の書式、matcher、終了コード2での停止などがClaude Codeに合わせてあります（hooks/src/lib.rs、protocol/src/hooks.rs）。既定のタイムアウトは600秒です。
• フックの信頼：Codexは、フックごとに定義のSHA-256を ~/.codex/config.toml の [hooks.state] に記録し、一致したものだけを動かします。実測でも、プロジェクトに置いた起動時フックは、Codexでは3回とも動かず、Claude Code（claude -p）では3回とも動きました。ただしこのハッシュには鍵がなく、設定ファイルに書き込めるプログラムなら誰でも正しい値を作れます。Postmanのデスクトップ版が、Codexにフックを入れたうえで承認の記録まで書き込もうとしていた件は、この仕組みに関わるものです。
• Claude Codeの場合：フックごとの承認記録はなく、フォルダ単位の信頼確認のあとで設定ファイルのフックが動きます。claude -p では信頼確認が出ず、フォルダを信頼済みとして扱います。
• スキル：.agents/skills（プロジェクトの根元から作業フォルダまで）と ~/.agents/skills を探し、名前と説明の一覧を文脈の2%以内で渡します。SKILL.mdで読む項目は name と description だけです。
• 企業向けの統制：/etc/codex/requirements.toml で、使えるサンドボックスや承認方式、フックを管理者のものに限るかなどを決められます。Claude Codeのmanaged settingsに相当します。

Claude Codeの利用者は何を持ち帰ればよいのか？

Codexのソースから学べるのは、エージェントの安全を「モデルの判断」ではなく「OSの仕組み」に置く設計の具体例です。Claude Codeでも同じ考え方を取り入れられます。どちらが優れているかではなく、既定でどちらに倒れているかを知ったうえで設定することが大切です。

• Claude Codeでサンドボックスを使う：通信や書き込みを仕組みで止めたい作業では、サンドボックスを有効にします。Codexの既定に近い状態になります。
• .gitや設定フォルダを守る：Codexが .git や .codex を保護している理由は、エージェントが履歴や自分の権限を書き換えられないようにするためです。Claude Codeでも、これらへの書き込みを権限ルールで禁止できます。
• 両方で使う指示ファイルは32KiB以内に：AGENTS.mdとCLAUDE.mdを共有するなら、Codexの上限に合わせて短く保ちます。
• allowルールの重さを知る：Codexでは許可ルールがサンドボックスの外での実行を意味します。Claude Codeでも、「次回から確認しない」で増える許可ルールは定期的に見直します。

今回の実測は各2〜3回の小さな作業で、Codexは非対話の codex exec、Claude Codeはautoモードでの比較です。対話モードの承認の流れや、長い作業での振る舞いは比べていません。ソースは開発中のmainブランチで、リリース版0.167.0と細部が異なる可能性があります。

まとめ