CodexをWSLで動かすWindows手順と失敗対処・設定確認のポイント

CodexをWSLで動かすと何が変わるか

WSL2でCodexを動かすと、Codex CLIはWindows側のネイティブ環境ではなく、WSL2が提供するLinux環境の中で動きます。端末はWindows Terminalでも構いませんが、Codexの実体、現在地、NodeやPythonなどの開発道具はLinux側で確認するのが基本です。Windowsから起動した見た目だけで判断せず、コマンドを入力したシェルがどの環境に属しているかを先に確かめます。

この方式が向くのは、Linux向けのパッケージやコンパイラを使うプロジェクト、既存リポジトリをWSL2に置いている人、Windows側の実行環境と分けて調べたい人です。逆にWindows固有のツールだけを使う作業なら、ネイティブWindows側のCodexの方が迷いが少ないこともあります。選択の基準は名前ではなく、対象リポジトリと必要な道具がどちらの環境にあるかです。

Windows側とWSL2側の境界

Windows側のPowerShellからwslと入力して開いた先は、同じPC上の別の作業環境です。そこでpwdを実行して/home/...が表示されるならLinux側、C:...が表示されるならWindows側です。Codexへ渡したいパスも、シェルの表示に合わせて書きます。C:\projectと/mnt/c/projectは同じ場所を指せる場合がありますが、Codexから見た文字列と関連ツールの設定は同じではありません。

WSL1ではなくWSL2を使う理由

OpenAIの現行ガイドでは、WSL1はCodex 0.114までの対応で、0.115以降はLinux側の仕組みが変わったため対象外と説明されています。古い記事のコマンドが動かないときは、入力ミスより先にWSLの世代を確認します。wsl --statusやwsl -l -vでVERSION欄を見て、対象ディストリビューションが2になっているかを確かめます。出典: OpenAI WSL guide

2026年8月25日に確認する公式情報

今回の「なぜ今か」は、WSLが新しい入口として突然登場したからではありません。2026年8月24日にOpenAIの公式リリースページでCodex CLI 0.149.1がLatest表示になり、Windowsで最新版を使いたい人が、どの環境に入れた版を確認しているかを見直す時期になったためです。リリースページには版番号と公開日、変更履歴への導線がありますが、WSLでの個別の動作を番号だけから補うことはできません。

現行のWSLガイドは、WSL2ではCodexがLinux環境の中で動くこと、WSL1は対象外であること、Linuxのホームディレクトリにプロジェクトを置くと扱いやすいことを明確にしています。導入手順もWindows側でwsl --installを実行し、WSLシェルから公式のインストール方法を使ってcodexを起動する順番です。これらを一つの環境で確認してから、VS Code連携やリポジトリの移動へ進むと迷いにくくなります。

0.149.1を基準にする理由

公式リリースページの Codex CLI 0.149.1 では、0.149.1がLatestとして表示され、公開日は2026年8月24日です。これは「現在公開されている版の目印」であり、手元のWSLに入っている版が同じだと証明するものではありません。WSL側でcodex --versionを実行し、表示された文字列をリリースページと照合します。版番号が違う場合も、まず入口とインストール方法を記録してから更新を考えます。

公式ガイドから読み取れる範囲

公式の WSLガイド は、WSL2を選ぶ場面、VS CodeをWSLから開く方法、Codex CLIの導入例、/mnt/cが遅く感じられる場合の確認点を一つにまとめています。ここから言えるのは、WSL2をLinux側の作業環境として使うための入口と切り分けです。個別のリポジトリの依存関係や社内の設定まで保証する資料ではないため、最後は手元の短い確認作業で判断します。

導入前にそろえる環境

Codexをいきなりインストールする前に、Windows、WSL2、Linuxディストリビューション、作業フォルダーの四つを分けて確認します。どれか一つが未設定でも、表示されるエラーは「Codexが壊れた」ように見えることがあります。先に環境の境界をそろえると、後から版番号やVS Codeの接続先を調べるときにも、どの画面の情報なのかが分かります。

Step 1: WSLの状態を確認する

管理者として開いたPowerShellまたはWindows Terminalで、WSLの状態を確認します。未導入なら公式ガイドにあるwsl --installを使い、再起動を求められた場合は指示に従います。すでに導入済みなら、ディストリビューション名とVERSIONを確認し、Codexを実行するLinux環境が一つに決まっている状態にします。

wsl --status
wsl -l -v

Step 2: Linux側の作業場所を決める

Codexで扱うプロジェクトを、まずLinuxのホームディレクトリ配下に置くかどうか決めます。公式ガイドは、Windowsのマウント先である/mnt/cより、~/codeのようなLinux側の場所を勧めています。大きなリポジトリやファイル数の多いプロジェクトで差が出やすいため、速度が気になる人ほど最初の置き場所を慎重に選びます。

mkdir -p ~/code
cd ~/code
pwd

Step 3: VS Code連携を使うか決める

VS Codeを使う場合は、Windows側のVS CodeにWSL拡張を入れ、WSLシェルからcode .でプロジェクトを開きます。公式の VS Code WSLチュートリアル に沿って、ステータスバーがWSL: ディストリビューション名になっているかを見ます。表示がWindows側のパスのままなら、Codexの導入をやり直す前にVS Codeの接続先を直します。

CodexをWSLにインストールする手順

ここでは、Windows側でWSL2を用意し、WSLシェルへ入り、Linux側でCodex CLIを導入してから、版番号と作業場所を確認する流れを説明します。コマンドを入力する場所を混ぜないことが重要です。wsl --installはWindows側、Codexのインストールとcodex --versionはWSL側で実行します。公式ガイドの最新手順は、実際に使う前に OpenAIのCodex CLIドキュメント でも確認してください。

Step 1: Windows側でWSL2を用意する

PowerShellを管理者として開き、次のコマンドを入力します。すでにWSL2とLinuxディストリビューションがある場合は、同じコマンドを重ねて入力せず、wsl -l -vで現在の状態を確認します。インストール後に再起動を求められたら、再起動が終わるまでCodexの導入へ進みません。

wsl --install

Step 2: WSLシェルに入り現在地を確認する

Windows側で次のコマンドを入力し、Linuxシェルを開きます。プロンプトが切り替わったら、ユーザー名と現在地を確認します。/home/ユーザー名の下にいるなら、Linux側で作業を始める準備ができています。/mnt/cにいる場合は、対象プロジェクトをLinux側へ置くか、まず小さな検証だけで速度を比べます。

wsl
echo $WSL_DISTRO_NAME
pwd

Step 3: WSL側でCodexを導入する

WSLシェルの中で、OpenAIが案内しているインストール方法を使います。現行の公式ガイドには、インストール用URLを取得してシェルへ渡す例が掲載されています。URLを別の文字列に置き換えず、公式ページから開いた導入手順と一致しているかを確認してから入力します。

curl -fsSL https://chatgpt.com/codex/install.sh | sh

導入が終わったら、同じWSLシェルでcodexを起動します。初回に接続や利用条件の案内が出た場合は、画面に表示された内容を読み、利用するアカウントで進めます。Windows側で別の入口を開いていたとしても、WSL側のCodexとは別の実行環境なので、両方を同じ版だと決めつけないようにします。

Step 4: 版番号と実体の場所を確認する

Codexを使い始める前に、WSL側で版番号と実行ファイルの場所を確認します。which codexが空になる場合は、導入が完了していないか、シェルのPATHに導入先が含まれていません。表示された場所を控えておくと、Windows側のPowerShellで同じコマンドを実行したときに、別のCodexを見ていることへ気づきやすくなります。

codex --version
which codex

Step 5: VS Codeから同じWSL環境を開く

プロジェクトのLinux側ディレクトリへ移動してからcode .を入力します。VS Codeが開いたら左下の表示を確認し、WSLのディストリビューション名が表示されていること、統合ターミナルの現在地が/home/...であることを見ます。そのターミナルからwhich codexを再実行し、先ほどのWSLシェルと同じ場所が表示されれば、エディタとCodexの環境がそろっています。

cd ~/code/your-project
code .

プロジェクトはどこに置くべきか

WSLでの体感差は、Codexのモデルや版番号だけでなく、プロジェクトをどのファイルシステムに置くかでも変わります。公式ガイドが勧める基本は、リポジトリをLinuxのホームディレクトリ配下に置くことです。Windowsから見えることだけを優先して/mnt/cに置くと、ファイル数の多い調査や依存関係の読み込みで待ち時間が増えることがあります。

Linuxのホームディレクトリを優先する

/code/projectに置いたプロジェクトは、WSL側のツールがLinuxのパスとして自然に扱えます。Node、Python、RustなどのコマンドがLinux側に入っているなら、依存関係のインストール先や実行結果も同じ環境にそろいます。Codexへ依頼するときも「プロジェクトは/code/projectにある」と伝えれば、WindowsとLinuxのパスを取り違えにくくなります。

大きなプロジェクトを移す前に、読み取りだけの小さな確認を行います。pwdで現在地を出し、lsでルートのファイルを見て、VS Codeのステータスバーと同じ場所を指しているかを比べます。移動後に依存関係を入れ直す必要がある場合は、プロジェクトの説明書に書かれたLinux向けの方法を使い、Windows側で作った生成物をそのまま流用しないようにします。

WindowsからLinux側のファイルを見る

Linux側へ置いたプロジェクトは、Windowsのエクスプローラーから\wsl$</code>を入口にして開けます。公式ガイドは、ディストリビューション名とホームディレクトリを続けて指定する形を案内しています。Windowsのエディタで直接フォルダーを開き直すのではなく、VS CodeではWSL拡張を使い、Codexを実行するシェルと同じLinux側へ接続することが大切です。