CodexはWindowsでも使えます。始め方は、ChatGPTデスクトップアプリを使う、PowerShellでCodex CLIを使う、WSL2（Windows Subsystem for Linux 2）の中で動かす、の3つです。どれを選ぶかで、Codexがコマンドを実行する場所、守りの仕組み（サンドボックス）、リポジトリを置くべき場所が変わります。この記事では、3つの方法の違いと選び方、会社のPCで先に確かめること、うまく動かない時の行き先を説明します。
この記事は、OpenAIの公式資料（ChatGPT desktop app for Windows、Windows sandbox、WSL、Deploy the Windows app and Codex CLIなど）に基づく解説です。いずれも2026年11月6日に取得した版です。
CLIのインストール手順そのものは、Codex CLIのインストール方法と初回設定で説明しています。この記事は、Windowsでどの方法を選ぶかと、選んだ後の分かれ道に絞ります。
CodexをWindowsで使う3つの方法と選び方
3つの方法の大きな違いは、Codexのエージェントがどこでコマンドを動かすかです。アプリとPowerShellのCLIはWindowsのまま動き、Windowsのサンドボックスで読み書きと通信の範囲を区切ります。WSL2を選ぶと、CodexはLinuxの環境の中で動き、Linuxのサンドボックスを使います。
| 比べる点 | ChatGPTデスクトップアプリ | PowerShellのCLI | WSL2 |
|---|---|---|---|
| 使う画面 | アプリの画面で会話・差分の確認・並行作業 | ターミナル | WSLのターミナル。アプリのエージェントをWSLへ切り替えることもできる |
| コマンドを動かす場所 | 既定はPowerShell | PowerShell | Linuxの環境 |
| サンドボックス | Windowsのサンドボックス | Windowsのサンドボックス | Linuxのサンドボックス |
| リポジトリの置き場所 | Windowsのドライブが確実 | Windowsのドライブ（公式の記載はアプリのWindowsのエージェントについて） | Linuxのホーム（例：~/code）が速い |
| 向いている人 | 画面で結果を見ながら進めたい人、複数のプロジェクトや会話を並行して扱いたい人 | ターミナルで作業する人、スクリプトから動かしたい人 | Linuxの道具が必要な人、作業が既にWSL2にある人 |
公式資料は、Windowsでは基本的にWindowsのサンドボックスを使い、Linuxの道具が必要な場合、作業が既にWSL2にある場合、Windowsのサンドボックスでは要件を満たせない場合にWSLを選ぶよう案内しています。迷ったら、アプリかPowerShellのCLIから始めるのが公式の案内に沿った選び方です。
VS CodeなどのIDE拡張もWindowsで使えます。WSLの中のリポジトリでIDE拡張を使う場合、公式資料はVS CodeをWSLの中から開く手順を案内しています（下の「WSLの中でCLIとVS Codeを使う」）。使い始めはCodexをVS Codeで使う方法で説明しています。
3つの方法に共通するWindowsの版と前提
どの方法を選んでも、Windowsの版が条件になります。公式資料の対応表は次のとおりです。
| Windowsの版 | 扱い | 説明 |
|---|---|---|
| Windows 11 | 推奨 | Codexを使う基準の環境。会社で標準にするならこちら |
| 更新済みのWindows 10 | ベストエフォート | 動く場合もあるが、Windows 11より安定しない。ConPTYなどの新しいコンソールの機能が要るため、1809以降が必要 |
| 古いWindows 10 | 非推奨 | 必要なコンソールの部品が欠けやすく、会社の環境では失敗しやすい |
あわせて、wingetが使えることも前提とされています。無い場合は、Windowsを更新するかWindows Package Managerを入れてからCodexを準備します。
Windowsのアプリで始める：ChatGPTデスクトップアプリ
以前の「Codexアプリ」は、2026年7月9日にmacOSとWindowsでChatGPTデスクトップアプリに統合されました（公式のWhat's new）。既に使っていた人は通常の更新で移れます。統合の経緯はCodexのChatGPTデスクトップ統合の記事で説明しています。
Windows版のChatGPTデスクトップアプリでは、複数のプロジェクトをまたいだ作業、並行した会話、結果の確認を一つの画面で行えます。公式資料によると、worktree、定期実行のタスク、Gitの機能、内蔵ブラウザ、ファイルのプレビュー、プラグイン、スキルにも対応しています。
アプリを入れて最初に確かめる設定
- ChatGPTのWindows用インストーラーから入れます。コマンドで入れる場合は
winget install --id 9PLM9XGG6VKS -s msstoreです。会社のPCで利用者が自分で入れる場合、公式資料は管理者による承認が必要と説明しています。 - Codexに依頼を送る前に、入力欄の下でAsk for approvalを選びます。公式資料は、PowerShellとWSL2のどちらで動かす場合も、この選択でサンドボックスの守りがかかると説明しています。
- 設定で、Openに使う既定のエディタ（Visual StudioやVS Codeなど）と、内蔵ターミナルの種類（PowerShell、コマンドプロンプト、Git Bash、WSL）を選びます。ターミナルの変更は新しく開いたターミナルにだけ反映されるので、開いているものがあればアプリを再起動するか新しい会話を始めます。
公式資料は、フルアクセスで動かすとCodexがプロジェクトのフォルダの外にも手を出せるようになり、意図しない操作でデータを失うおそれがあると注意しています。特定の操作だけを許したい場合は、サンドボックスを外さずにルールで例外を作る方法が案内されています。
Windowsに入れておくとCodexが作業しやすい開発ツール
公式資料は、次の道具が入っているとCodexが作業を進めやすいと説明しています。Gitはアプリのレビューのパネルと、変更の確認・取り消しに使われ、GitHub CLIはGitHubに関する機能に使われます。
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.cliGitHub CLIを入れた後は、gh auth loginを実行するとアプリでGitHubの機能が使えるようになります。.NET SDKは、Windowsのアプリを作る場合に役立つ道具です。別の版のPythonや.NETが必要なら、パッケージのIDを変えて入れます。
WindowsのPowerShellでCLIを使う
ターミナルで作業したい場合は、PowerShellでCodex CLIを使います。WSLや仮想マシンを用意しなくてもWindowsのまま動き、既定ではコマンドがWindowsのサンドボックスの中で実行されます。今のセッションの権限と設定は、CLIの/statusと/debug-configで確かめられます。インストールは、公式のCodex CLIのページで、新しいPowerShellの窓から公式のインストーラーを実行する方法が案内されています。npmでも入れられます。上のアプリはwingetかインストーラーで入れるもので、CLIとは入れ方が別です。手順と初回の確認はインストールの記事を見てください。
Windowsのサンドボックスには3つの方式があり、どれが使われるかは端末と設定、会社の方針で変わります。CLIを単体で使う場合や会社で配る場合は、設定を書かないと新しい方式（MXC）は優先されません。方式の違いと有効にする設定は、CodexのWindows新サンドボックス「MXC」の記事で説明しています。
WSL2でCodexを動かす場合
WSL2を選ぶと、CodexはLinuxの環境の中でコマンドを動かします。WSL1は使えません。公式資料によると、WSL1はCodexの0.114までの対応で、0.115からはLinuxのサンドボックスの仕組みが変わったため、WSL2が必要です。
アプリのエージェントをWSLへ切り替える
アプリを使ったまま、エージェントだけをWSL2で動かせます。設定でエージェントをWindows nativeからWSLへ切り替え、アプリを再起動します。再起動するまで切り替えは反映されません。再起動後もプロジェクトはそのまま残る、と公式資料は説明しています。内蔵ターミナルの種類はエージェントとは別に選べるので、エージェントはWSL、ターミナルはPowerShell、という組み合わせもできます。
WSLの中でCLIとVS Codeを使う
WSLが入っていない場合は、管理者として開いたPowerShellでwsl --installを実行し、wslでLinuxのシェルに入ります。シェルの中では、macOS・Linux用の公式インストーラーでCLIを入れます。
curl -fsSL https://chatgpt.com/codex/install.sh | sh
codexVS CodeでWSLの中のリポジトリを開く場合は、VS CodeにWSL拡張を入れ、WSLのシェルからリポジトリのフォルダでcode .を実行します。画面下のステータスバーにWSL: ディストリビューション名と出ていれば、WSLにつながっています。
WindowsとWSLのどちらにファイルを置くか
リポジトリを置く場所は、エージェントがどこで動くかで変わります。公式資料のアプリのページとWSLのページは、それぞれ次のように勧めています。
- エージェントをWindowsのまま使う場合：リポジトリはWindowsのドライブに置き、WSLからは
/mnt/ドライブ名/...で読む方が確実です。WSLのファイルの場所（\\wsl$）から直接開いたプロジェクトでは、Gitが検出されないことがあると書かれています。 - WSLの中でCodexを動かす場合：リポジトリはLinuxのホーム（例：
~/code/my-app）に置きます。/mnt/cのようなWindowsのドライブで作業すると遅くなりやすく、シンボリックリンクや権限の問題も起きやすいためです。
WSLのファイルをアプリのプロジェクトに加える時は、Add new projectかCtrl+Oで開いたファイルの選択画面に\\wsl$\と入力し、ディストリビューションとフォルダを選びます。プロジェクトの準備用のスクリプトは、エージェントが動く環境（WSLならWSL、それ以外はPowerShell）で実行される点も覚えておくと、Windows用とLinux用のどちらを書けばよいかを判断できます。
WindowsとWSLで設定とログイン情報を共有する
アプリとWindowsで動かすCodexは、%USERPROFILE%\.codexを設定と記録の置き場所に使います。WSLの中でCLIを動かすと、Linux側のホームを使うため、アプリとは設定・保存済みのログイン情報・会話の記録が共有されません。共有したい場合は、WSLの~/.codexとWindowsの%USERPROFILE%\.codexを同期するか、WSLでCODEX_HOMEにWindows側の場所を指定します。
export CODEX_HOME=/mnt/c/Users/<windows-user>/.codex毎回の指定を省くには、この1行をWSLのシェルの設定ファイル（~/.bashrcや~/.zshrc）に書きます。ログインの方法そのものはCodexのログイン方法で説明しています。
会社のWindows PCで使う前に確かめること
会社のPCでは、OSの版が条件を満たしていても、会社の方針で準備の手順が止められることがあります。使い始める前に、次の点を社内の担当者と確かめておくと、途中で止まる時間を減らせます。
| 確かめること | 公式資料の説明 |
|---|---|
| アプリを入れる権限 | 利用者が自分で入れる場合も管理者の承認が要る。会社の配布はIntune・SCCMなどの手順がある |
| サンドボックスの準備 | MXCは管理者の承認を伴う準備が不要だが、使えるのはMXCの機能が入ったWindows 11の端末だけ。アプリが自動でMXCを優先するのは個人のアカウントの場合で、会社での配布では管理者がMXCを優先する設定を配る必要があり、会社がMXCを止めていることもある。MXCが使われない場合はelevatedになり、管理者の承認つきの準備が要る。ローカルのユーザー作成やファイアウォールの変更を会社が禁じていると失敗する |
| 管理者権限での実行 | 管理者権限が要るコマンドを動かすには、アプリ自体をRun as administratorで起動する。エージェントはその権限を引き継ぐ |
| PowerShellの実行ポリシー | Node.jsのnpmや、Codexが作ったPowerShellのスクリプトが止まることがある。RemoteSignedへの変更が一般的な対処だが、MicrosoftのExecution Policyの説明を読んでから判断する |
編集部としては、管理者権限での起動は、それが必要な作業の間だけにとどめることを勧めます。会社でアプリとCLIをまとめて配る担当者向けには、公式の配布の手順に、配布方法ごとの手順と、CLIを社員のアカウントで入れる時の確認項目がまとめられています。
Windowsでうまく動かない時の行き先
Windows特有の症状を、公式資料の記載をもとに表にまとめました。症状の分け方は編集部の整理です。Windowsに限らない止まり方はCodexのエラー・動かない時の対処を見てください。
| 起こり得ること | 最初に確かめること | 行き先 |
|---|---|---|
npm.ps1 cannot be loadedと出る | PowerShellの実行ポリシー | 上の「会社のWindows PCで使う前に確かめること」 |
インストールしたのにcodexが見つからない | 新しいターミナルを開いたか、PATHに入っているか | 導入の確認はインストールの記事 |
思っていたのと違う版のcodexが起動する | npmと公式のインストーラーなど、別の場所に入ったcodex | Get-Command codexで、実行される場所を確かめる |
| Gitの機能が使えない | WindowsにGitが入っているか | winget install Git.Gitで入れる |
\\wsl$のプロジェクトでGitが出ない | リポジトリの置き場所 | Windowsのドライブへ置き、WSLからは/mnt/で読む |
| WSLで大きなリポジトリが遅い | /mnt/cの下で作業していないか | Linuxのホームへ移す。必要ならwsl --updateとwsl --shutdown |
| WSLのVS CodeでCodexが見つからない | WSLの中でwhich codex | WSLの中でCLIを入れ直す（上の「WSLの中でCLIとVS Codeを使う」） |
| IDE拡張が入っているのに反応しない | C++の開発ツールが入っているか | Visual Studio Build Tools（C++のワークロード）を入れ、VS Codeを完全に再起動する |
| サンドボックスの準備に失敗する・エラー1385が出る | 使っている方式と会社の方針 | エラーごとの対処は公式のWindows sandboxのTroubleshooting。方式の切り替えはMXCの記事 |
| WSLだけログインし直しを求められる | WSLとWindowsでCodexのホームが分かれていないか | 上の「WindowsとWSLで設定とログイン情報を共有する」 |
サンドボックスの不具合をOpenAIへ報告する時に添えるログと、送ってはいけないファイルも、公式のWindows sandboxのTroubleshootingにまとめられています。
まとめ：WindowsでのCodexは、エージェントの動く場所から決める
- Windowsでの始め方は、アプリ、PowerShellのCLI、WSL2の3つ。公式の案内は、基本はWindowsのサンドボックスで、Linuxの道具が要る場合などにWSL2。
- アプリでは、依頼を送る前にAsk for approvalを選び、内蔵ターミナルとエディタを設定する。
- リポジトリは、エージェントがWindowsならWindowsのドライブ、WSLの中ならLinuxのホームに置く。
- WSLのCLIとアプリは、
~/.codexを同期するかCODEX_HOMEを合わせない限り、設定とログイン情報を共有しない。 - 会社のPCでは、アプリを入れる承認、サンドボックスの方式と準備、実行ポリシーを先に社内の担当者と確かめる。
社内でCodexを広げる時は、どの方法を標準にするか、誰が準備と配布を受け持つかを最初に決めておくと、人によって環境が分かれて手間が増えるのを防げます。
