Claude Media
Claude CodeとCodex appの違い — デスクトップ版の並列実行と承認を比較

Claude CodeとCodex appの違い — デスクトップ版の並列実行と承認を比較

Claude Code DesktopとOpenAIのCodex appを、並列セッション・worktree・承認・手元を離れた実行で比べます。Codex appの公式ページがChatGPTデスクトップアプリに移った点も押さえます。

Claude Code DesktopとCodex appは、どちらも「コーディングエージェントを複数並べて走らせるデスクトップアプリ」です。違いが出るのは、アプリの作りより、並列作業の隔離方法と承認の粒度にあります。

先に押さえたいのは、Codex appの公式ページの行き先が変わっている点です。developers.openai.com/codex/appを開くと「ChatGPT desktop app」のページに移り、Codexはそのアプリの中で選ぶ一つの使い方になっています。Claude側は、Claude DesktopのCodeタブがClaude Code Desktopにあたります。

先に結論: 同じ立ち位置のアプリではない

Claude DesktopにはChat、Cowork、Codeの3つのタブがあり、コーディング用のリファレンスはCodeタブだけを扱います。Codex appの側は、ChatGPTデスクトップアプリで最初のメッセージを送るときに「ChatGPTかCodexか」を選ぶ構成です。

観点Claude Code DesktopCodex app(ChatGPTデスクトップアプリ内のCodex)
アプリの位置づけClaude Code DesktopClaude DesktopのCodeタブCodex app(ChatGPTデスクトップアプリ内のCodex)ChatGPTデスクトップアプリで選ぶCodex
並列作業の隔離Claude Code Desktopセッション単位でworktreeを選ぶCodex app(ChatGPTデスクトップアプリ内のCodex)新規チャットで「Worktree」を選ぶ
承認の単位Claude Code Desktop5つの権限モードCodex app(ChatGPTデスクトップアプリ内のCodex)権限プロファイル(ベータ)など
手元を離れる実行Claude Code DesktopCloud・SSH・DispatchCodex app(ChatGPTデスクトップアプリ内のCodex)モバイルから接続PCを操作
定期実行Claude Code DesktopスケジュールタスクCodex app(ChatGPTデスクトップアプリ内のCodex)スケジュールタスク(専用のバックグラウンドworktree)

並列実行とworktree: 隔離のしかたが違う

どちらも、同じリポジトリで複数の作業を同時に進めるためにGitのworktreeを使います。ただし作られ方が異なります。

くらべる

worktreeの作られ方

Desktop

Claude Code

セッションの入力欄でブランチ名の隣にあるworktreeを選びます。保存先は既定で<project-root>/.claude/worktrees/で、Settings > Claude Codeから変更できます。

ChatGPTデスクトップアプリ

Codex app

新しいチャットで、入力欄の下にあるWorktreeを選び、起点のブランチを決めます。保存先は$CODEX_HOME/worktreesで、チェックアウトはdetached HEADになります。

隔離の周辺にも差があります。

  • ブランチの扱い: Codexのworktreeはブランチではなくdetached HEADで始まり、「Create branch here」でブランチ化します。Claude Code Desktopは、Settings > Claude Codeで設定したBranch prefixを、worktreeのブランチ名の先頭に付けます。
  • フォアグラウンドとバックグラウンドの移動: CodexにはHandoffがあり、チャットをLocalとWorktreeの間で移せます。Claude Code Desktopの移動先は主にクラウドで、セッションメニューのOpen inからCloudへ引き継げます。
  • 掃除: Codexは既定で直近15個のCodex管理worktreeを残し、チャットをアーカイブすると削除します。Claude Code Desktopもサイドバーのアーカイブアイコンでworktreeを消せ、PRのマージやクローズ後に自動アーカイブする設定もあります。

共通点: .envを持ち込む.worktreeinclude

意外な共通点があります。どちらも.worktreeincludeというファイル名で、Gitに無視されているファイルを新しいworktreeへコピーできます。

# .worktreeinclude
.env
.env.local
config/secrets.json

Claude Code側は.gitignore構文で、パターンに合致しかつgitignore済みのファイルだけがコピーされます。Codex側も、無視されたパスやパターンを列挙し、Codex管理のローカルworktreeを作るときにコピーします。両方を同じリポジトリで使うなら、このファイルは共有できる設計です。書き方の条件はClaude Code worktreeincludeの記事にまとめています。

同じブランチは二重に取れない

Gitの制約で、1つのブランチは1つのworktreeでしか開けません。Codexのドキュメントは、worktreeで作ったブランチをLocalで開こうとするとfatal: 'feature/a' is already used by worktree at ...になると説明しています。Claude CodeとCodexを同じリポジトリで併用する場合も、片方のworktreeが握っているブランチをもう片方で開けない点は変わりません。

承認と権限: 段階モードかプロファイルか

Claude Code Desktopは、入力欄の横のモードセレクターで5つの権限モードを切り替えます。

モード設定キー挙動
Manual設定キーdefault挙動ファイル編集もコマンド実行も都度確認
Accept edits設定キーacceptEdits挙動編集とmkdir・mvなどは自動承認、他のコマンドは確認
Plan設定キーplan挙動調査のみで、計画を出して止まる
Auto設定キーauto挙動通常の確認なしで進み、バックグラウンドの分類器が依頼との整合を確認する
Bypass permissions設定キーbypassPermissions挙動確認なし(コンテナやVM向け)

新規セッションの既定は設定ファイルで決められます。デスクトップアプリはCLIと同じ設定ファイルを読みます。

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

フォルダごとにセレクターで選んだモードが優先され、Planだけは現在のセッション限りです。

Codex側は、ローカルのコマンドに最小権限の境界をかける権限プロファイルが用意されています。組み込みは:read-only、:workspace、:danger-full-accessの3つで、ベータ扱いです。ファイルの読み書き範囲とネットワークの宛先をプロファイルで定義します。ネットワークのドメイン規則を効かせるには、features.network_proxy = trueなどの設定が別に要ります。

この違いを一言にすると、Claudeは「どこまで自動で進めるか」の段階を選び、Codexは「コマンドに何を許すか」の境界を定義します。Claude側にも許可ルールはありますが、Desktopの画面で最初に目に入るのは段階モードです。

ブラウザ操作の承認は、Codex側にサイトごとの設定があります。Agent permissionsでBrowse・Download・Uploadそれぞれに「Requires approval」「Always allow」「Block」を割り当てます。Claude Code Desktopは、外部サイトの操作に安全分類器をかけ、Bypass permissionsでもその確認は残ります。内蔵ブラウザの使い方はClaude Code Desktopの内蔵ブラウザの記事に詳しくあります。

画面を操作させる機能と、その条件

どちらのアプリにも、PCの画面を操作させるComputer Useがあります。Claude側の条件は明確です。

  • macOSとWindows向けのリサーチプレビュー
  • Pro・Maxプランが必要で、TeamとEnterpriseでは使えない
  • 既定ではオフで、Settings > This computer > Systemで有効化する
  • macOSではAccessibilityとScreen Recordingの許可が要る

Claudeは操作手段を使い分けます。コネクタ、Bash、Claude in Chrome、iOS Simulatorペインの順に精度の高い手段を優先し、どれも当てはまらないときだけ画面操作に降ります。ブラウザは閲覧のみ、ターミナルとIDEはクリックのみと、アプリの種類ごとに権限の上限も固定されています。

Codex側は、設定にComputer Useの項目があり、macOSではScreen RecordingとAccessibilityの許可をシステム設定から取り消せる、という説明です。ChatGPTデスクトップアプリの紹介ページには、Computer Useを使えるプランの条件が載っていません。導入前に、契約中のプランの設定画面で項目が出ているかを確かめられます。

開発の検証ループ: Claude側が詳しい領域

Claude Code Desktopには、Browserペインで開発サーバーを動かし、Claudeが自分の変更を確かめる流れが組み込まれています。編集のたびに自動検証するauto-verifyは既定でオンです。.claude/launch.jsonのautoVerifyで止められます。

{
  "version": "0.0.1",
  "autoVerify": false,
  "configurations": [
    {
      "name": "my-app",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "dev"],
      "port": 3000
    }
  ]
}

差分レビューも画面内で完結します。diffの行をクリックしてコメントを書き、Cmd+Enter(WindowsはCtrl+Enter)でまとめて送ると、Claudeがその指摘で直した新しい差分が返ります。PRを開いたあとは、CIの状態バーから失敗の自動修正やマージ待ちの自動マージを有効にできます(ghコマンドの認証が前提です)。プレビューの設定はDesktopアプリプレビューの記事で扱っています。

手元を離れる実行

手段Claude Code DesktopCodex app
クラウド実行Claude Code DesktopCloudを選ぶとアプリを閉じても続くCodex appCodex Cloudで実行できる
リモートマシンClaude Code DesktopSSHセッション(WSLも選べる)Codex appリモート開発環境にあるプロジェクトでもworktreeチャットを使える
スマホからClaude Code DesktopDispatchでPro・MaxのみCodex appChatGPTモバイルから接続PCを操作
定期実行Claude Code DesktopスケジュールタスクCodex appバックグラウンドworktreeで実行

Claude側のクラウドセッションは、使用量が契約プランの上限に数えられ、別の計算料金は発生しません。Dispatchも、Pro・Maxプランが条件でTeamとEnterpriseでは使えません。

Codexのモバイル連携は、スマホ上でコードが動くわけではありません。リポジトリとworktreeは接続したコンピューター側に残り、モバイルアプリはその操作役を務めます。

選び分けの目安

こういう状況向く側
Claude Codeの設定(CLAUDE.md・hooks・スキル)をそのまま使いたい向く側Claude Code Desktop
開発サーバーの検証、diffコメント、PR監視を1画面で回したい向く側Claude Code Desktop
ChatGPTのチャットや資料作りと同じアプリでコーディングも扱いたい向く側Codex app
コマンドごとにファイルとネットワークの境界を定義したい向く側Codex app(権限プロファイル)

Claude Code Desktopは、CLIと同じ設定ファイルを読みます。普段ターミナルのClaude Codeを使っているなら、同じ設定の延長でDesktopを開けます。ターミナルの会話をそのままDesktopで続けたい場合は、claude --desktopの記事の手順が使えます。

CLI同士の比較や料金の比較は、それぞれClaude Code vs Cursor vs Codex CLIの使い分けとClaude CodeとCodexの料金比較にあります。この記事で見たのはデスクトップアプリ同士の差です。

まとめ

違いの核は3つです。Codexはチャットごとにdetached HEADのworktreeを作ってLocalと行き来させ、Claude Code Desktopはセッション単位のworktreeに検証ループとPR監視をつなげています。承認は、段階モードで選ぶClaudeと、境界をプロファイルで書くCodexに分かれます。そしてCodex appは、独立アプリというよりChatGPTデスクトップアプリの一モードとして案内されています。

併用するなら、.worktreeincludeを共通にし、同じブランチを両方のworktreeで開かない運用にすると衝突を避けられます。

この記事を共有:XはてブLinkedIn