Windows では、ネイティブの ChatGPT デスクトップアプリ、CLI、または IDE 拡張機能から Codex を利用できます。
Windows 版 ChatGPT デスクトップアプリは、複数のチャットの並行実行、Worktree、スケジュール済みタスク、Git 操作、アプリ内ブラウザ、ファイルのプレビュー、プラグイン、スキルなど、主要な機能に対応しています。
Windows サンドボックスを使えば、WSL や仮想マシンを用意せずに、PowerShell 上でアプリをネイティブに実行できます。普段の Windows 環境で Codex を使いながら、ファイルシステムとネットワークへのアクセスを許可された範囲に制限できます。
企業でのインストールについては、Windows 展開ガイドを参照してください。
Codex は、次の 3 種類の Windows サンドボックスに対応しています。
mxc：対応する Windows デバイスで推奨されるサンドボックスです。ネイティブのプロセス分離を利用するため、管理者の承認を伴うセットアップ、追加の Windows アカウント、ローカルのファイアウォール規則は不要です。elevated：MXC が利用できない場合や無効になっている場合に、優先して使う従来方式です。セットアップには管理者の承認が必要です。サンドボックス内のコマンドは管理者権限なしで実行されます。unelevated：管理者権限でのセットアップができず、組織のポリシーが許可している場合に使える従来方式です。ネットワークの分離はelevatedより弱く、パスを指定して読み取りを拒否することはできません。
Windows サンドボックスの設定
Windows サンドボックスは、コマンドとその子プロセスに、現在有効なファイルシステムとネットワークの権限を適用します。読み取りや書き込みが可能なパスと、ネットワークアクセスの可否は、権限プロファイルで決まります。より広い権限でコマンドを実行するために Codex が承認を求めるタイミングは、別途、承認ポリシーで制御します。サンドボックスと承認を参照してください。
MXC の有効化
個人向けアカウントでデスクトップアプリを使う場合、対応デバイスでは MXC が自動的に優先されます。企業での展開時や CLI を単体で使う場合も、次の設定で MXC を優先できます。
config.toml に次の設定を追加します。
[features]
prefer_mxc = trueprefer_mxc = true の場合、デバイスが MXC に対応し、ポリシーでも許可されていれば、Codex は Windows コマンドを MXC で実行します。それ以外の場合は、従来の手順でサンドボックスを選択し、セットアップします。
デバイスによって対応状況やポリシーが異なる企業では、windows.sandbox に組織が許可する従来方式（elevated または unelevated）をフォールバックとして設定しておきます。
管理者はこの設定を既定値として配布するか、features.prefer_mxc = true を requirements.toml で必須にできます。どちらの場合も、従来方式へのフォールバックは可能です。既定値と必須設定の違いについては、管理対象の設定を参照してください。
MXC の無効化
組織内で MXC の使用を禁止するには、管理対象の requirements.toml に次の設定を追加します。
[windows]
allow_mxc = falseこれにより、MXC の自動選択と windows.sandbox = "mxc" による明示的な指定の両方が禁止されます。従来のサンドボックスに対する既存の設定や要件は引き続き適用されます。
MXC の互換性
ホストには、Microsoft Execution Containers（MXC）によるプロセス分離に必要な機能があらかじめ備わっている必要があります。Microsoft はこれらの機能を Windows 11 デバイスに順次提供しています。Microsoft は Windows 11 24H2（ビルド 26100.9278） と 25H2（ビルド 26200.9278） で MXC によるプロセス分離を導入しました。次のコマンドで、お使いのデバイスが MXC に対応しているか確認できます。
Codex CLI 0.162.0 以降では、保存済みのサンドボックス設定を変更せずに、1 つのコマンドだけを MXC で試せます。プロジェクトディレクトリから次のコマンドを実行します。
codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE期待される出力は MXC_OK、終了コードは 0 です。これで、ワークスペースの権限プロファイルと管理者が定めた要件を適用した状態でコマンドを起動できるか確認できます。
windows.sandbox = "mxc" を明示的に指定した場合、必要なネイティブ機能が利用できないか、ポリシーで MXC が禁止されていると、起動に失敗します。
互換性については、次の制約に注意してください。
- 管理対象のネットワークを使うには、実効設定が
allow_local_binding = trueである必要があります。MXC は、ホストのループバック上のサービスとの双方向の接続を許可します。プロキシ経由の通信には引き続きプロキシのドメイン規則が適用されますが、プライベートネットワーク上の宛先に対してプロキシが行う追加のチェックは適用されません。 - フォアグラウンドのコマンドが終了すると、残りの子プロセスも停止します。切り離して起動した開発サーバーに依存するワークフローは、動作を確認してください。
- Linux や WSL と同様に、読み取り拒否の glob パターンは、サンドボックス内の各プロセスが起動した時点で一致するファイルに適用されます。後から作成されたファイルは、パターンに一致しても、ほかの権限でアクセスが許可されていれば、実行中のプロセスから読み取れます。長時間動作するシェル、スクリプト、監視プロセス、開発サーバーでは、起動時に確定した対象ファイルの一覧が各プロセスの終了まで使われます。この一覧の有効期間は Codex セッション全体ではありません。読み取り拒否の glob パターンを評価するタイミングを参照してください。
従来方式へのフォールバック設定
config.toml でフォールバックに使う方式を選択します。
[windows]
sandbox = "elevated" # or "unelevated"elevated は、フォールバックとして推奨される従来方式です。サンドボックス内でコマンドを実行するために、権限を抑えた専用のサンドボックスユーザーを使用し、ファイルシステムのアクセス制限、ファイアウォール規則、必要なローカルポリシーの変更を適用します。
MXC と同様に、elevated はサンドボックス内の各プロセスが起動した時点で、読み取り拒否の glob パターンに一致するファイルを列挙します。後から作成されたファイルは、パターンに一致しても、ほかの権限でアクセスが許可されていれば、実行中のプロセスから読み取れます。長時間動作するプロセスへの影響については、読み取り拒否の glob パターンを評価するタイミングを参照してください。
unelevated もフォールバックに使える従来方式です。現在のユーザーから生成した制限付き Windows トークンでコマンドを実行し、ACL に基づいてファイルシステムへのアクセスを制限します。オフライン専用ユーザー向けのファイアウォール規則の代わりに、実行環境側でオフライン制御を適用します。ネットワークの分離は elevated より弱く、パスを指定して読み取りを拒否することはできませんが、ローカルポリシーや企業のポリシーによって管理者の承認を伴うセットアップが禁止されている場合に利用できます。
デバイスが対応し、ポリシーで許可されている場合は MXC を使用してください。それ以外の場合は elevated を優先し、第 2 の選択肢として unelevated を使用してください。
企業の管理者は、requirements.toml で、Codex が使用できる従来のサンドボックス方式を制限できます。
[windows]
allowed_sandbox_implementations = ["elevated"]この例では、elevated を許可し、unelevated へのフォールバックを禁止します。MXC が利用できる場合、mxc の使用は制限されません。管理者が定めたほかの権限要件やネットワーク要件は引き続き適用されます。従来方式をどちらも許可するには、両方の値を指定してください。モードが指定されていない場合、Codex は elevated を優先します。
指定できる値については、requirements.toml リファレンスを参照してください。MXC も禁止するには、別途 windows.allow_mxc の要件を設定します。
どちらの従来方式も、既定では専用のプライベートデスクトップを使用して UI の分離を強化します。
IT 部門による従来の elevated サンドボックスの事前セットアップ
従業員にローカル管理者権限がない場合は、従業員が Codex を起動する前に、IT 部門が CLI をインストールし、elevated サンドボックスを準備できます。管理者権限で動作する展開プロセスから次のコマンドを実行します。
codex sandbox setup --elevated --user 'DOMAIN\alice' --codex-home 'C:\Users\alice\.codex'ユーザー名とパスは、対象の従業員の Windows アカウントと CODEX_HOME に置き換えてください。このコマンドは、そのユーザーの設定を読み込み、サンドボックスを準備して、windows.sandbox = "elevated" を保存します。その後、従業員は通常のターミナルから Codex を実行できます。
サンドボックスの権限
フルアクセスモードで Codex を実行すると、操作対象がプロジェクトディレクトリの外にも広がります。意図せず破壊的な操作を行い、データが失われるおそれがあります。より安全に自動化するには、サンドボックスの制限を維持し、個別の例外にルールを使用してください。または、承認ポリシーを never に設定すると、Codex は権限の拡大を求めずに、承認とセキュリティの設定の範囲内で問題の解決を試みます。
Windows バージョン別の対応状況
| Windows のバージョン | サポートレベル | 備考 |
|---|---|---|
| Windows 11 | 推奨 | Windows 上で Codex を利用する際の標準環境として最適です。企業で展開環境を統一する場合は、このバージョンを使用してください。 |
| 最新の更新をすべて適用した比較的新しい Windows 10 | ベストエフォート | 動作する場合もありますが、Windows 11 に比べると安定性は劣ります。Windows 10 では、Codex は ConPTY などの新しいコンソール機能に依存します。実際に使用するには Windows 10 バージョン 1809 以降が必要です。 |
| 古いビルドの Windows 10 | 非推奨 | ConPTY などの必要なコンソールコンポーネントが不足している可能性が高く、企業環境でのセットアップにも失敗しやすくなります。 |
環境については、次の点も確認してください。
wingetが利用できる必要があります。見つからない場合は、Codex をセットアップする前に Windows を更新するか、Windows パッケージ マネージャーをインストールしてください。- 従来の
elevatedサンドボックスのセットアップには管理者の承認が必要です。 - 企業が管理するデバイスでは、OS のバージョンが要件を満たしていても、セットアップに必要な操作が禁止されている場合があります。
- MXC には、MXC の互換性で説明したネイティブ機能も必要です。この表だけでは、個々のデバイスで MXC が利用できるかどうかは判断できません。
サンドボックスの読み取り権限の確認
コマンドでディレクトリを読み取れない場合は、現在有効な権限プロファイル、管理者が定めた要件、Windows のファイルアクセス許可を確認してください。CLI では、/status と /debug-config で現在のセッションと設定を確認できます。管理ポリシーによる制限がある場合は、サンドボックスを無効にせず、管理者に制限内容の確認を依頼してください。
通常は Windows ネイティブのサンドボックスを使用してください。Linux ネイティブのツールが必要な場合、すでに WSL2 で作業している場合、または利用可能な Windows ネイティブの方式が要件を満たさない場合は、WSL を選択してください。
トラブルシューティングとよくある質問
管理対象の Windows マシンで問題を調べるときは、まずネイティブサンドボックスのモード、Windows のバージョン、Codex に表示されたポリシー関連のエラーを確認してください。MXC の場合は、互換性と実際に適用されているネットワークポリシーを確認します。従来のサンドボックスでは、セットアップ、ログオン権限、ファイルシステムのアクセス許可が問題の原因になることがあります。