OpenAIは2026年3月4日、Windows向けCodexアプリの一般提供を開始した（macOS版は2月に公開されている⁠）⁠。複数のエージェントを並列で実行できるほか、タスクの管理や、ファイル変更の差分レビューに対応する。Windows版アプリは、既存の環境を維持したままOSネイティブのPowerShell環境で利用できるほか、必要に応じてエージェント自体をWSL上で実行させることもできる。Codexアプリの利用には、ChatGPTのPlus以上の有料プランまたはAPIキーが必要となる（無料プランやGoプランでも期間限定で試すことはできる）[1][2]。

• Codex app for Windows - OpenAI Developers

Windows環境へのCodexを提供するにあたって、Windows上で動作するCodexのサンドボックスを新しく構築するために、リリースに数週間かかったとのこと。このサンドボックスは、制限付きトークン、ファイルシステムのアクセス制御リスト、専用のサンドボックスユーザーといったOSレベルの制御を利用している。これによってmacOS版と同じように、Windowsネイティブの開発環境におけるエージェント動作の安全性と自律性の適切なバランスが得られるという。

注意点として、このサンドボックスを利用すると、デフォルト設定では作業フォルダ外へのファイルシステムの書き込みはできなくなる。さらに、コマンドによる外部へのネットワークアクセスも制限される（ユーザーが明示的に承認した場合にのみ、外部ネットワークへアクセスできる⁠）⁠。

なお、このWindowsサンドボックスはRust言語で実装されており、GitHub上のリポジトリでオープンソースとして公開されている。

Codexアプリには統合ターミナルが備わっており、デフォルトで使うものをPowerShell、Command Prompt、Git Bash、WSLの中から選択できる。さらに、CodexアプリはIDEや別のアプリへワークフローと行き来するための機能も搭載されているが、macOSで既にサポートされていたアプリに加え、Windows向けのアプリにも対応している。

Windows版CodexアプリはOpenAIのCodexサイトで案内されており、Microsoft Storeからダウンロードできる。

Codexアプリの使い方については、OpenAI Developersのドキュメントに記載されている。以下、簡単に取り上げる。Windowsネイティブ環境をベースにして進める。

• Codex app - OpenAI Developers

Codexアプリのインストールと起動

Codexアプリは現在、macOS版とWindows版が提供されている（Linux版も今後提供予定⁠）⁠。macOS版の場合はOpenAIのサイトからインストーラーをダウンロードする。Windows版はMicrosoft Storeからダウンロードするか、またはターミナルからWinGetを使ってインストールを行う。

$ winget install Codex -s msstore

Codexアプリを起動したいところだが、Codexでエージェントが効率的に作業を行えるように、Git、Node.js、Python、.NET SDK、GitHub CLIなどの一般的な開発ツールのインストールが推奨されている。もしWinGetを使う場合には以下のようなコマンドでインストールできる。

$ winget install --id Git.Git
$ winget install --id OpenJS.NodeJS.LTS
$ winget install --id Python.Python.3.14
$ winget install --id Microsoft.DotNet.SDK.10
$ winget install --id GitHub.cli

Codexアプリをインストールして初めて起動すると、最初にChatGPTアカウントでログインするか、APIキーで認証するダイアログが表示される。認証後に、Codexアプリの画面が表示される[3]。

Codexアプリの左側に、プロジェクトとチャットセッションのスレッドが並ぶ。左上には「新しいスレッド」の作成、作業の自動化をスケジュール化するための「オートメーション⁠」⁠、インストールしているスキルや推奨されたスキルが掲載されている「スキル」の3つの項目があることも確認できる。

Windows版におけるサンドボックスの設定

記事冒頭でも触れているとおり、エージェントを自律的に動作させる場合を考えると、エージェントにプロジェクトフォルダ以外へのアクセスを許可しないほうがよいため、Windows版のCodexアプリではサンドボックスが提供されている。

はじめてCodexアプリを起動したときに、プロンプト入力欄のすぐ上に「エージェントモードでサンドボックスを有効にする」という表示とともにSet upボタンがあるので、これをクリックすればサンドボックスが利用できるようになる。このサンドボックスを設定しないと、デフォルト権限でプロンプトが送信できない（フルアクセスの権限を与えればプロンプトは送信できる⁠）⁠。

サンドボックスの指定は3月8日時点では、設定ファイルのconfig.tomlに以下が追加されるかたちになる。

[windows]
sandbox = "elevated"

sandbox_mode = "workspace-write"

[windows]
sandbox = "unelevated"

[sandbox_workspace_write]
network_access = true

テーマ機能

3月12日のCodexアプリの更新で、Codexアプリにテーマ機能が付いた。設定画面の「Apperance」から設定する。

テーマとして、「⁠ライト」「⁠ダーク」を明示的に指定したり、そして「システム」のテーマに合わせたりできるようになった。また、「⁠ライト」「⁠ダーク」のテーマはさらに細かくカスタマイズできる。

スレッドとプロジェクト

Codexアプリでは、チャットはスレッド単位で管理され、スレッドはプロジェクトフォルダごとにまとめられる。

デフォルトプロジェクトのPlayground

はじめてCodexアプリを起動したとき、左メニューのスレッドにはPlaygroundフォルダがある。画面右側のチャット欄でもこのPlaygroundが選択されている状態になっているのが、中央の「始めましょう」の直下にその名前が表示されていることで確認できる。なお、このPlaygroundのプロジェクトフォルダは、Windowsではユーザープロファイル直下のDocuments/Playground/フォルダが使われる。

この状態でプロンプトを送信すると、Playgroundフォルダ内にスレッドが作成されて、チャットが開始される。もし新しいスレッドを作成してプロンプトを送信すると、スレッドが増えていく。

プロジェクトやスレッドの配置を調整する

なお、左メニューに追加されたプロジェクトやスレッドの並びは、「⁠スレッド」の見出しの右側にあるフィルターボタンを押すことで調整できる。

ピン留め

継続して確認したいスレッドは、ピン留めできる。左メニューでスレッドの左側に出現するピン留めボタンを押すか、右クリックして「Pin Thread（ピン留め⁠）⁠」を選択する。

それにより、スレッドの見出しにピン留めのスレッドが表示されるようになり、見失いにくくなる。ただし、異なるプロジェクトのスレッドを同時にピン留めすると、どのプロジェクトのスレッドがピン留めされているのかがわかりにくいので注意が必要になる。

なお、ピン留めされたスレッドでWorktreeを使っている場合、Codexアプリ内で作成されているWorktree環境が増えたときに自動削除されるWorktreeの対象外となる。

プロジェクトの追加

Codexアプリにプロジェクトフォルダを追加するには、左メニューの「スレッド」の見出し右側にあるフォルダアイコンをクリックするか、または中央のプロジェクト名をクリックして「新しいプロジェクトを追加」を選択すればよい。

プロジェクトを選択して新しいスレッドを開始するには、左メニューの各プロジェクトの右側にある「新しいスレッドを開始する」アイコンをクリックするか、画面左上の「新しいスレッド」を選択してから画面右側の中央に表示されているプロジェクト名をクリックして該当のプロジェクトを選択することになる。

プロジェクトやスレッドの名前の変更

プロジェクト名は変更できる。左メニューのプロジェクト名の右側にある詳細メニューから操作できる。

スレッドの名前も変更できる。左メニューでスレッドをダブルクリックするか、またはスレッド上で右クリックしたときに表示されるコンテキストメニューから操作できる。コンテキストメニューからは他の操作も可能になっている。

WSL環境での利用

WindowsではWSL環境を利用できる。CodexアプリからWSLファイルシステム上のプロジェクトを追加するには、プロジェクトを追加するときのファイルエクスプローラーで「\\wsl$\」と入力したあとに対象のLinuxディストリビューションとフォルダを記述するようなかたちになる（たとえば\\wsl$\Ubuntu\を入れると、さらにその下のフォルダへアクセスするためのドロップダウンが表示される⁠）⁠。

なお、Windowsで直接動作するエージェントを使う場合は、プロジェクトをWindows側のファイルシステムに配置して、WSL上で操作するときに「/mnt/<drive>/...」経由でアクセスする構成が推奨されている（エージェントがgitを認識できないなどの問題を起こさないようにするため⁠）⁠。

WSL上でエージェントを動作させる場合は、設定のAgent environmentを「WSL」に切り替えてCodexアプリを再起動すればよい[5]。

プロンプトを書く前に知っておきたいこと

次に、プロンプトを書く前に、知っておきたいことをまとめる。

プロンプトの実行場所

プロンプト入力欄の左下に、エージェントが作業を行う場所を「ローカルプロジェクト（ローカル環境；Local⁠）⁠」⁠「⁠クラウド（Cloud⁠）⁠」から選択できる。また新規スレッドを作成する際には「新しいWorktree」も選択でき、Detached HEADでエージェント作業を進めることもできる。

一般的にはデフォルトで選択されている「ローカルプロジェクト」を選択してプロンプトを送信する。すると、ローカルのプロジェクトフォルダでエージェントが作業を開始する。

クラウド環境とWorktreeについては後述する。

エージェントの権限

エージェントの実行場所として「ローカルプロジェクト」「⁠新しいWorktree」を選択した場合、そのすぐ右隣にエージェントの権限が表示される。エージェントの動作を「デフォルト権限」「⁠フルアクセス」「⁠カスタム（config.toml⁠）⁠」から選択できるようになる。config.tomlを調整すると、「⁠カスタム（config.toml⁠）⁠」がデフォルトで選択されるようになる。

なお、Codexアプリを起動中に設定ファイルであるconfig.tomlを更新した場合、既存のスレッド上でその設定をすぐに適用させるには、一度Codexアプリを再起動する必要がある。

モデルとコンテキストウィンドウ

GPT-5.4が利用可能に

OpenAIは3月5日、汎用型のGPT-5.2とコーディング特化型のGPT-5.3-Codexのよいとこどりを進めた汎用型のGPT-5.4をリリースしており、Codexアプリでもすでに利用できる。大部分の作業ではGPT-5.4が推奨のモデルとなるとのこと[6]。なお、引き続きGPT-5.3-CodexやGPT-5.2も利用可能となっている。

推論の労力は「低（low⁠）⁠」⁠「⁠中（medium⁠）⁠」⁠「⁠高（high⁠）⁠」⁠「⁠非常に高い（xhigh⁠）⁠」から選択できる。デフォルトでは「中」が設定されていて、日常の作業はこれを使うとよいとされている。複雑な設計や問題には、トークンが多く消費され、時間がよりかかるが「高」や「非常に高い」を選択するのがよい。

コンテキストウィンドウ

Codexアプリにおける内部的なコンテキストウィンドウは、デフォルトで272kトークンとなっている[7]。そのうち、システムプロンプトやツール呼び出し、出力のために5％を確保しており、残り95%にあたる258kトークンがユーザーが利用できるコンテキストウィンドウとなる。

スレッドでエージェントが作業を開始すると、プロンプト入力欄右下に円で表されたコンテキストウィンドウの使用量が表示されるようになる。この円をクリックすると、現在のスレッドで使用されているトークン数と、残りのトークン数が表示されるようになる（%の値は258Kに対する表示⁠）⁠。

コンテキストウィンドウからあふれないように自動圧縮機能があるが、圧縮がかかる内部的な閾値としてデフォルトはコンテキストウィンドウの90%に設定されていて、約245kトークンを超えると自動的に圧縮されるようになっている。

性格とカスタム指示

エージェントの回答スタイルを設定できる。設定画面の「パーソナライズ」から、エージェントの回答スタイルを「フレンドリー（friendly⁠）⁠」と「実用的（pragmatic⁠）⁠」から選択できる[8]。

設定画面の「パーソナライズ」では、グローバル設定のカスタム指示も設定できる。これはユーザープロファイルの.codex/AGENTS.mdに保存される。このカスタム指示は、どのスレッドでも読み込まれることになる。

CodexにおけるAGENTS.mdを使ったカスタム指示（カスタムインストラクション）の詳細は、「⁠Custom instructions with AGENTS.md」を参照のこと。

統合ターミナル

Codexアプリには直接統合されたターミナルが備わっている。Codexアプリの画面右上にあるターミナルボタン、またはCtrl+Jを押すと、プロンプト入力欄の下部にターミナル画面を表示できる。

Windows環境では設定画面で、統合ターミナルのデフォルトシェルをPowerShell、Command Prompt、Git Bash、WSLの中から選択できる。

この設定は新規のターミナルセッションにのみ適用されるため、すでにターミナルを開いている場合はアプリの再起動または新しいターミナルセッションが必要になる。

IDE連携

CodexはIDEと連携するための拡張機能を提供している。Visual Studio Code、Cursor、Windsurf、JetBrains IDEsについて、Codexのサイトで案内がされている。なお、公式のIDE拡張ドキュメントではWindows対応は実験的で、WindowsではWSLでの利用が推奨されている。

• Codex IDE extension - OpenAI Developers

Codexアプリで実行中のスレッドをIDEのCodex拡張側で確認でき、逆にIDE側のスレッドをCodexアプリで確認することもできる。

CodexのIDE拡張機能がインストールされており、CodexアプリとIDE拡張機能が同じプロジェクトで同期されると、Codexアプリのプロンプト入力欄に「IDEコンテキスト」オプションが表示される。さらにAuto contextを有効にすると、CodexアプリはユーザーがIDEで表示しているファイルを追跡できる[9]。

プロンプト

プロンプトを書く際に、知っておきたいことをまとめる。

ファイルの指定

プロンプト入力欄で@を入力すると、プロジェクト内のファイルを指定できる。ファイル名の一部を入力して絞り込むこともできる。

スラッシュコマンド

プロンプト入力欄でスラッシュ（/）を入力することで、様々な機能にアクセスできる[10]。

添付

プロンプト入力欄の左下には＋ボタンがあり、画像やファイルの添付が可能になっている。

また、プロンプト入力欄へファイルをドラッグしても添付できる。

なお、＋ボタンからプランモード、エージェントの動作速度が高速化するFastの利用、MCPショートカットも利用できる。

スキル

特定の作業を実行する際に、その指示やツールのセットをあらかじめ用意しておくことで、スキル（エージェントスキル）として利用できる。

スキルはエージェントが自律的に取得することもあるが、プロンプトで明示的にスキルの使用を指定できる。$を押してスキルを自動補完するか、スラッシュコマンドからスキルを選択する。

Codexアプリにはデフォルトで、スキルを作成するためのSkill-Creatorと、OpenAIのskillsリポジトリまたはその他のリポジトリにある厳選されたスキルをインストールするSkill-Installerが内蔵されている。3月12日の更新で、OpenAIの公式ドキュメントを参照できるスキル、OpenAI Docsが内蔵された。

Codexアプリの左メニューから「スキル」を選択すると、現在インストールされているスキルの一覧と、推奨されたスキルが掲載された画面が表示される。また、インストールされているスキルを無効にする設定やアンインストールも行える。

[sandbox_workspace_write]
writable_roots = ["C:\\Users\\ユーザー名\\.agents"]

MCP

外部のサービスやツールを利用するためのMCPを介したMCPサーバーも利用できる。Codexアプリの設定画面の「MCPサーバー」から推奨サーバーのインストールやカスタムサーバーの追加が可能になっている。

なお、MCPサーバーの設定内容はconfig.tomlに保存される。そのため、Codex CLIやIDEのCodex拡張機能とも共有されることになる。

プランモード

プランモード（/plan[11]）が搭載されている。プランモードを有効にするとプロンプト入力欄にプランモードであることが表示される（Shift+TABでも切り替え可能⁠）⁠。

大きな作業を行うときにはエージェントにいきなりファイルを編集させるのではなく、プランモードなどを使うことで、はじめに作業手順の計画ファイルを作成するのがよい（末尾のコラムも参照⁠）⁠。

あらかじめエージェントの方針を確認できることで、レビューもしやすくなる。なお、プランモードでは計画を立てる上でエージェントが確認したいことがある場合、追加の質問が行われることがある。

レビュー

変更したコードをレビューする機能（/review）が搭載されている。

スラッシュコマンドからコードレビューを選択すると、大元のブランチに対する現在の作業ブランチでの変更箇所をみる「ベースブランチを基準にしたレビュー⁠」⁠、最後のコミット後からの変更箇所をみる「未コミットの変更をレビュー」から選択できる。前者はWorktree環境での作業での利用に適している。

詳しくは、レビュー機能を説明している公式ドキュメントを参照のこと。

スレッドの活用

スレッドを便利に使うための機能をまとめる。

ステータス

スレッドの使用制限を確認できる。スラッシュコマンドから「ステータス」（⁠/status）を選択することで確認できる。現在のスレッドIDとコンテキストウィンドウの現在の使用量、5時間・7日ごとの使用制限（レートリミット）がわかる（日本語訳は、５時間制限が１時間制限に誤訳されている⁠）⁠。

コマンドの出力の表示

Codexアプリではデフォルトで、エージェントがコマンドを発行した際の出力はチャット上で表示しない。もし気になる場合には、設定画面の「一般」にある「スレッドの詳細」で調整できる。

アクション

対象プロジェクトのローカル環境を設定すると（ローカル環境については後述⁠）⁠、よく使うテストやビルドのコマンドを「アクション」として登録できる。

フォーク

スレッドのやり取りの途中で、スラッシュコマンドから「フォーク」を選択すると、新規のスレッドで別の作業を続けることができる。フォークした新規のスレッドでは、それまでの会話が引き継がれて元のスレッドへのリンクが表示される。

なお、フォークを行うとき、「⁠新しいWorktreeにフォークする」または「ローカルにフォークする」のどちらにフォークするかを選ぶことになる。

新しいWorktreeにフォークすると、GitのWorktree機能を利用して、新しいスレッドを開始する。元のプロジェクトフォルダに変更を加えないため、「⁠A案とB案のアプローチを同時に実装させて比較したい」「⁠今の状態をキープしたまま、大胆なリファクタリングの実験をしたい」といった、ファイルの変更が伴うタスクに向いている。

ローカルにフォークすると、ローカルのプロジェクトフォルダの環境で、エージェントとの会話履歴（コンテキスト）だけが枝分かれする。このことを利用して、たとえば、長いログや仕様書を読み込ませた直後の状態でフォークすることで、エージェントの読み込み作業を繰り返すことなく、複数の異なる作業を並行して指示できるようになる。

オートメーション

定期的な反復作業をスケジュールして自動的に実行する、オートメーション（Automations；自動化）機能を搭載している。また、オートメーションは単なる定期実行だけでなく、最近の作業を振り返って改善点を見つけ、今後のプロンプトやスキルの見直しにつなげる用途にも向いている。

• Automations - OpenAI Developers

オートメーションはCodexアプリが起動していて、対象プロジェクトが手元のパソコンにある場合にのみ実行される。

オートメーションを作成するには、左メニューの「オートメーション」を選択して、Codexアプリの一番右上に「＋新規」ボタンがあるので、それを押す。

オートメーションの新規登録ダイアログが表示されるので、名前、プロンプト、ローカルプロジェクト／Worktreeのどちらで行うか[12][15]、プロジェクトの選択（複数のプロジェクトを選択可能⁠）⁠、スケジュールを指定する[13]。さらにダイアログの下部の詳細メニューから、モデルと推論レベルをカスタマイズできる。なお、スケジュールは「一時間ごと」「⁠毎日」「⁠平日」「⁠毎週」「⁠カスタム」から選択できる[14]。

オートメーションのプロンプトでもスキルを組み込めるので、詳しいワークフローはスキルに切り出しておき、オートメーション側ではそれを定期実行するかたちにするとよいだろう。

一つでもオートメーションを登録すると、オートメーション画面のトップページが、登録されているオートメーション一覧画面に切り替わる（新規のオートメーション登録方法は上記と同じ⁠）⁠。ここから、各オートメーションを確認するかたちになる。なお、各オートメーションにフォーカスを当てると、一番右側に詳細メニューが表示され、定期実行を一時停止するか、このオートメーションを削除するかを選択できる。一時停止したオートメーションもこの画面に掲載されて、アクティブに戻すことができる。

各オートメーション画面では、画面右上に、オートメーションの一時停止ボタン、削除ボタン、テストボタンが並び、画面中央の左側にはプロンプトが、画面右側には、オートメーションの状態（アクティブかどうか、次の実行日時、前回の実行日時）と、オートメーション設定の詳細パネル、実行一覧が縦に並ぶ。プロンプトの変更や詳細パネルでの各種設定の調整も可能になっている。

オートメーションの定期実行を行う前に、安定して動作することを確認しておくことが強く推奨されている。その際にはテストボタンを利用するといいだろう。このテストは、後述の通常のオートメーションの定期実行と同じように処理される。

オートメーションでスケジュールした時間になると、自動的に新しくスレッドを作成してそのオートメーションが実行される（そのため実行中のスレッドの確認も可能だが、基本的にはバックグラウンドで処理するかたちになるだろう⁠）⁠。

オートメーションの定期的な実行結果があると、左メニューの「オートメーション」の右側にその数が表示されるようになる。そして各オートメーション画面で定期実行されたものがあると、画面右下にある「Previous run（これまでの実行⁠）⁠」見出し以下にスレッドが表示されるようになる。

「Previous run」の一覧では、見ていないスレッドは左側に青色のマークが付く。このスレッド名をクリックすると、その内容を確認できる。

一度スレッドの内容を確認すると、青色のマークが灰色のチェックマークに変わる（この状態でもスレッド名をクリックすると、その内容を確認できる⁠）⁠。

その後、Codexアプリを一度終了したあとなどに、再度このオートメーション画面を開くと、このスレッドが薄い灰色のアーカイブマークに変わる。この状態になると、現在のところ、オートメーション画面からはアーカイブを解除できないため、スレッドが見れなくなる（設定画面の「アーカイブされたスレッド」から、アーカイブの解除はできる[A]⁠）⁠。

オートメーションでは、実行した要点や改善されているかなどをみるために、次回以降のためにメモ（Automation Memory）[16]を記録する。この記録は、次回以降の定期実行で参照されることになる。

Codexアプリには、オートメーション作成時に使えるテンプレートがいくつか用意されている。

• ［品質管理］最近のコミット（前回実行以降、または直近24時間）を走査し、バグになりそうな変更を見つけて最小修正案を出す
• ［要約］マージ済みプルリクエストから、リンク付きの週次リリースノート草案を作る
• ［要約］昨日のGit活動を朝会向けに要約する
• ［品質管理］直近のCI失敗と不安定なテストを要約し、有力な修正案を示す
• ［創作］最小構成の小さなクラシックゲームを作る
• ［提案］最近のプルリクエストやレビューをもとに、次に伸ばすべきスキルを提案する
• ［要約］今週のプルリクエスト、ロールアウト、インシデント、レビューをまとめて週報化する
• ［分析］最近の変更をベンチマークやトレースと比較し、劣化を早期検知する
• ［運用］依存ライブラリやSDKのずれを検出し、最小限の整合計画を提案する
• ［品質管理］最近の変更で未テストの経路を見つけ、重点的なテストを追加し、ドラフトのプルリクエストには$yeetを使う
• ［運用］タグ付け前にchangelog、migration、feature flag、テストを確認する
• ［運用］新しく見つかったワークフローやコマンドをAGENTS.mdに反映する
• ［要約］先週のプルリクエストを担当者別・テーマ別に整理し、リスクも明示する
• ［分析］新規Issueをトリアージし、担当者・優先度・ラベル案を出す
• ［品質管理］CI失敗を原因ごとに分類し、最小修正案を出す
• ［運用］古くなった依存関係を調べ、安全な更新案を最小変更で提案する
• ［分析］パフォーマンス悪化を監査し、効果の大きい修正案を出す
• ［運用］今週のハイライトと主要プルリクエストのリンクをもとにchangelogを更新する

差分パネル

Codexアプリには、差分パネルが搭載されている。この差分パネルを使うことで、エージェントがファイルを変更した際、その変更内容を確認できる。

この差分パネルは、Codexアプリ右上の差分パネルの表示切替ボタンをクリックすることで、スレッドの隣に表示されるようになる。なお、エージェントがファイルを変更すると、切替ボタンの横に、プロジェクトファイル全体の変更行数も表示されるようになる。

差分パネルを表示すると、プロジェクトの未コミットの変更ファイルすべてをスクロールで確認できる（.gitignoreに設定した、Git管理下ではないファイルは除外される⁠）⁠。

なお、3月10日時点で日本語の訳が間違っている。日本語環境でみると、ファイルを変更しただけですでにステージ済みなのか、と思うが、英語環境でみると、まだ未ステージであることがわかる。

差分パネルには、エージェントが変更したコードをきちんと見るための機能もある。差分パネルの右上にレビューボタンがあるので、これを押すと、スレッドが隠れてコード変更表示が広くなり、ファイルツリーも表示される。

レビュー画面では、各ファイルの変更行に限らず、行に対してコメントができる。行番号にマウスをホバーすると、ひととおりコメントをしたら、画面下にあるプロンプト入力欄でコメントに関する全体の指示を書いて送信することで、それをもとにエージェントが修正作業を行う。

なお、ファイルツリー上部の余白領域をマウスオーバーすると、詳細メニューが表示される（これは、レビュー画面を広げていない時にも表示される詳細メニューと同じもの⁠）⁠。

上のキャプチャ画像を見るとわかるとおり、レビュー画面の中央下部にある「すべてを戻す」「⁠すべてをステージする」の領域が大きく表示されてしまうバグがある。レビュー画面を拡げていないときや英語環境ではスリムなかたちで表示される。

Git操作

Codexアプリでは、Gitの主要な操作を行うための機能が付いている。

ステージング

差分パネルの項でも説明したが、差分パネルで変更された行にマウスをあわせると、変更内容をステージに移す（採用）するための＋ボタンや、変更を破棄するための戻すボタンが表示される。これにより、エージェントが提案した変更のうち、どの部分を採用するかを細かく制御できるようになっている。

特定のファイルをステージに移すには、ファイルのコードにカーソルがあるときにファイル名の右側に表示される＋ボタンを押す。また、ファイル内の特定のコードブロックをステージに移すには、そのコードブロックの変更行の右側に表示される＋ボタンを押す。

なお、下側に表示されている「すべてをステージする」を押すと、未コミットのファイルすべてがステージに移る。

ステージに移すと、差分パネルの「ステージ済」（⁠正しくはUnstaged）タブにあったファイルは消えて、差分パネルの「未ステージ」（⁠正しくはStaged）タブで表示されるようになる。

コミットとプッシュ

ステージに移したらコミットやプッシュを行うことになるわけだが、そのボタンがCodexアプリ上部に用意されている。コミットボタンを押すと確認ダイアログが表示される。未ステージでもコミットできるボタンが用意されていたり、コミットメッセージを自動生成したり[17]、プッシュまでひとまとめに行えたりする機能がある。

Worktreeの利用

Codexアプリで「新しいWorktree」を利用する一連の流れをまとめる。

Worktree環境の概要

プロンプトの送信先として「新しいWorktree」を選択すると、GitのWorktree機能を使って、作業開始時点のGit管理下にあるプロジェクトフォルダの状態をもとに、Detached HEADのWorktreeが別途作成される。

なお、ワークツリーはGitの標準機能を利用して構築されるため、プロジェクトフォルダがGitリポジトリになっている必要がある。

エージェントは、このWorktree環境の中にコピーされたプロジェクトフォルダのファイルを編集したり、テストを実行したりすることになる。つまり、もとのプロジェクトフォルダのファイルには一切影響を与えずに作業ができるようになる。また、ファイル変更が伴う作業を複数並行で行うことができるようになる。

Worktree上で作成されたこのコミットは、もとのブランチにマージして取り込んだり、直接リモートリポジトリにプッシュしてプルリクエストを作成したりすることで、プロジェクトのファイルに合流させることができるようになる。

ローカル環境の作成

「新しいWorktree」を利用するには、Codexアプリでローカル環境を作成する必要がある。

「新しいWorktree」を選択したときに、右側にローカル環境を選択する欄が表示されるので、そこから対象のプロジェクトのローカル環境を選択するのだが、対象プロジェクトのローカル環境を未作成の場合には「ローカル環境を作成する」を選択する。

Codexアプリの設定画面の「環境」が開く。この画面には、Codexアプリですでに追加しているプロジェクトが表示される。ローカル環境を作るには、対象のプロジェクト名の横にある＋ボタンを押す。次の画面で、ローカル環境の設定ファイル（ローカル環境ファイル）を作成する。ここでセットアップスクリプト（依存パッケージのインストールコマンドなど）を記述することになる。そして保存する[18]

ローカル環境を保存すると、設定画面の「環境」では、そのプロジェクトの名前の下に、作成したローカル環境が表示されるようになる。ローカル環境を編集するには、その隣に表示されている「確認する」ボタンを押すかたちになる。

対象プロジェクトのローカル環境を一度作成しておけば、別途、新規スレッドで「新しいWorktree」を使うときにもこのローカル環境を選択すればよい。

ノート：このローカル環境の設定画面の一番下で、コマンドショートカットのための「アクション」を設定できる。名前とスクリプトなどを記述して保存することで、プロジェクトのスレッドにおいてアクションが利用できるようになる。詳しくはアクションの項を参照のこと。

Worktree環境での操作

対象プロジェクトのローカル環境があれば、新規スレッドを開始するときに「新しいWorktree」選択して、そのローカル環境を選べばよい。そしてプロンプトを送信すると、対象プロジェクトのDetached HEADのWorktreeとローカル環境に設定したセットアップスクリプトが実行される。

その後、スレッドが作られ、エージェントがWorktree環境で作業を開始する。以降スレッドの使い方は、基本的に「ローカルプロジェクト」と同じになる。

ただ、ファイルの変更をプロジェクトに取りこむ場合、通常はまずコミットする流れになる。そのためにWorktree環境では、Codexアプリ上部に「ブランチを作成する」ボタンが表示される（ローカルプロジェクトでは「コミット」ボタンが通常表示されている場所⁠）⁠。このボタンを押すと、自動的にブランチ名が示されたダイアログが表示される（ブランチのプレフィックス（codex/）は、設定画面の「Git」で設定できる⁠）⁠。

ブランチを作成したあとは「ローカルプロジェクト」と同じようにコミットまで進める。そのあとは、このままプッシュしてGitHub上でマージリクエストを作成するか、またはローカルプロジェクト（元のブランチ）へ渡す（ハンドオフする）といった手段が考えられる。

Worktree環境からローカルプロジェクトに渡すには、ひとまずCodexアプリ上部にある「ローカルへ移動する（Hand Off⁠）⁠」ボタンを押す。このボタンを押すと、ローカルプロジェクトでこのブランチをチェックアウトするか、確認するダイアログが表示されるので、続行ボタンを押す。

するとWorktree環境でこのブランチを切り離して、Codexアプリ上で、ローカル（プロジェクト）に移動してこのブランチに切り替わる。

Codexアプリ上でこのブランチから元のブランチへ反映させる（マージする）には、統合ターミナルから通常のGitの操作で戻すことができる[19]。

マージするために、統合ターミナルを表示する（Ctrl＋J⁠）⁠。そして以下のようなコマンドを実行することになる。

# もとのブランチに切り替える。「main」は実際のもとのブランチ名を記述する
$ git switch main

# マージする。「codex/feature」は実際のWorktree環境で作られたブランチ名を記述する。
# 複雑な作業をしてなければ--ff-onlyオプションを使って、Fast-forwardマージで合流させる。
$ git merge --ff-only codex/feature

なお、ブランチの操作に関してはCodexアプリ上からも直接できる。プロンプト入力欄右下にある現在のブランチ表示から、ブランチを選択すればよい。

さらに、Worktree環境で作られたブランチを削除しておくには以下のようなコマンドになる。

# 作業ブランチを削除する。マージせずに強制的に削除する場合は-Dオプションを使う。
$ git branch -d codex/feature

作業ブランチを削除しても、作業に利用したスレッドは残る。ただし、そのまま会話を続けようとすると、異なったブランチで続けるか、という注意ダイアログが表示されるようになる。

また、Worktree環境の削除については、Codexアプリ側でWorktree環境が増えると古いものから自動で削除する機能がある。デフォルトでは直近15件のCodex管理Worktreeが保持され、設定画面の「Worktree」でこの上限変更や自動削除の無効化を行える。手動で調整したいときにも、設定画面の「Worktree」で管理する。

永続的なWorktree

CodexアプリのWorktreeは、数が増えたときに自動的に削除されることはこれまでも言及してきたが、長期利用向けには、左メニューのプロジェクトの詳細メニューから「永続的なWorktreeを作成する」を使って、永続的なWorktreeを作成できる。

永続的なWorktreeは独立した新しいプロジェクトとして追加され、自動削除の対象外となる。左メニューのプロジェクト右側にgit worktreeであることを示したアイコンも表示される。

この永続化されたWorktree環境は、設定画面の「環境」からも確認できる。

クラウドの利用

Codexアプリで「クラウド」を利用する一連の流れをまとめる。

クラウド環境の作成

プロンプトの送信先として「クラウド」を利用するには、ChatGPTアカウントでログイン後のCodexウェブページでの設定が必要となる。

最初に、CodexウェブページでGitHubと連携する。設定の「コネクター」を開いて、GitHubに接続すればよい。

その後、設定の「環境」を開いて、対象とするGitHubリポジトリを操作するためのクラウド環境を作っておく必要がある。「⁠環境を作成する」ボタンを押して、対象のリポジトリを選択し、他の項目も必要に応じて記述する。npmやpipなど一般的なパッケージマネージャーを使うプロジェクトであれば、セットアップスクリプトを記述しなくても依存関係やツールの自動インストールが行われるようになっている。それだけでは足りない場合には、セットアップスクリプトを使って整備できる。

もしクラウド環境が一つも作成されていない場合、Codexアプリでは「クラウド」が選択できず、「⁠Codexウェブ」の選択肢が表示されてCodexウェブページに誘導される。

クラウド環境を作ることで、Codexウェブページのプロンプト入力欄を使ってリポジトリに対して、エージェントに作業をさせることができるようになる。クラウド環境で変更されたファイル内容は、たとえば、GitHubリポジトリのプルリクエストにしてプロジェクトに反映できる。

クラウド環境の操作の流れ

Codexアプリでクラウド環境を利用してプロンプトを実行するには、プロンプト入力欄の左下で「クラウド」を選択し、その右側に現れる対象リポジトリのクラウド環境を選び、プロンプトを書いて送信する。

なお、クラウドを選択したときには、プロンプト入力欄の送信ボタンの近くに「Codexが同時に行う試行の回数」が表示される。これは、クラウド環境でプロンプトを実行する際に、同時に複数の手法で試行させることができる機能で、同じプロンプトから最大4パターンのコードを同時に生成できる。

プロンプトを送信すると、クラウド上で環境が起動して、エージェントによる作業が開始される。クラウド上で作業が終わると、Codexアプリのスレッドも更新されて、どのような作業をしたのか確認できる。ファイルが変更された場合、変更を適用してローカル環境で続行するかの確認がプロンプト入力欄上部に表示される。また、Codexアプリ上部には、同じく変更を適用する「Apply」ボタンと、クラウド環境のスレッドをCodexウェブページで確認するための「開く」ボタン、プルリクエストを作成するボタンも表示される。

ローカルに変更を適用してもよいのだが、ここではローカル環境で続行せずにCodexウェブページを見てみる。トップページのタスクの項目で、Codexアプリで送信したプロンプトを作業するスレッド名が表示されていることが確認できる。

該当のタスクをクリックすると、クラウド環境で作業されたスレッドとファイルの変更が表示される。Codexアプリのさきほどの「開く」ボタンを押すと、このページが直接表示されることになる。

ファイル変更を伴い、きれいに作業が終わっていれば、クラウド環境でコミットがされている状態で、プルリクエスト作成に進める状態になっていることをエージェントから報告される。

Codexウェブページ右上には、プルリクエストを作成ボタンがあり、このボタンを押すことで、GitHubのリポジトリにプルリクエストを作成できる。なお、このボタンの右側のドロップダウンメニューから、下書きプルリクエストを作成することもでき、その場合にはドラフトのプルリクエストが作成される。

プルリクエストが作成されると、Codexアプリの該当スレッドでも、プルリクエストページに移動するための「PR」ボタンが表示されるようになる。

なお、クラウド環境のスレッド（Codexウェブページでのタスク）とCodexのクラウド環境のスレッドは連動しており、どちらかで行った操作はもう一方にも反映される。アーカイブも連動しているため、どちらかでアーカイブしたタスクはもう一方でもアーカイブされることになる。