WindowsでCodexを使うなら、まずネイティブサンドボックスとWSL2の違いを見る

WindowsでCodexを使う話は、単に「Windows版が出た」で終わらない。公式ドキュメントを見ると、Windows上のCodexには大きく3つの入口がある。ネイティブのCodexアプリ、CLI、IDE拡張だ。さらに実行環境としては、Windowsネイティブのサンドボックスで動かす方法と、WSL2の中でLinux版として動かす方法がある。

ここを混ぜると、導入後に「どこにリポジトリを置くべきか」「ネットワーク許可はなぜ出るのか」「PowerShellで動くのか、WSLで動くのか」が分からなくなる。Windows対応の本質は、アプリが増えたことより、Windows側にもCodexの作業境界を作れるようになったことだと思う。

入口はアプリ、CLI、IDE拡張

公式のWindowsページでは、WindowsでCodexを使う方法としてネイティブCodexアプリ、CLI、IDE拡張が並んでいる。普段からVS CodeやJetBrainsで作業しているならIDE拡張、ターミナル中心ならCLI、複数の作業スレッドやレビュー結果をまとめて見たいならアプリ、という分け方になる。

CodexアプリはWindowsでも、並列エージェントスレッド、worktree、automations、Git機能、アプリ内ブラウザ、アーティファクトプレビュー、plugins、skillsといった中核機能を扱える。つまり「Windowsだから軽いお試し版」という位置づけではなく、ローカル作業の母艦として使う前提の機能セットになっている。

Windowsネイティブのサンドボックスは2種類

Windowsネイティブで動かす場合、Codexは作業フォルダ外への書き込みを止め、ネットワークアクセスも明示的な承認なしには通さない。これはAIエージェントにローカル環境を触らせるときの最低限の安全柵だ。

設定上は elevated と unelevated の2種類がある。

elevated は推奨される強い方式で、低権限の専用サンドボックスユーザー、ファイルシステム境界、ファイアウォールルール、ローカルポリシーを使う。会社支給PCのように管理者承認やローカルユーザー作成が制限される環境では、ここで詰まることがある。

unelevated はフォールバックだ。現在のユーザーから制限付きトークンを作り、ACLベースでファイルシステム境界を作る。公式ページでも elevated より弱いと明記されているが、企業ポリシーで強い方式が通らないときにもサンドボックスを残して作業を続けられる。

設定は config.toml にこう書く。

1
2
[windows]
sandbox = "elevated" # or "unelevated"

迷ったら elevated から始める。失敗したら、管理者権限、ローカルユーザー作成、ファイアウォール変更、ログオン権限あたりがブロックされていないかを見る。それでも今すぐ作業を進めたいなら、一時的に unelevated を使う、という順番が自然だ。

WSL2は「Linux環境が必要な人」の選択肢

WSL2を選ぶと、CodexはWindowsネイティブのサンドボックスではなく、Linux側のサンドボックス実装で動く。Linux前提のツールチェーン、シェルスクリプト、パッケージ管理、既存の開発フローがWSL内にあるなら、このほうが話が早い。

ただし、WSLで作るならリポジトリの置き場所が大事になる。公式ドキュメントは、/mnt/c/... のようなWindowsマウント配下より、~/code/my-app のようなLinuxホーム配下に置くほうが速く、シンボリックリンクや権限の問題も少ないと案内している。Windows側から見たいときは、Explorerで \\wsl$\Ubuntu\home\<user> を開けばよい。

このブログの作業でも、実体がWSL側にあるリポジトリをWindows側のパスとして扱うと、シェルやファイルパスの解決でつまずきやすい。CodexをWindowsから使う場合でも、Linux前提のプロジェクトは最初からWSLホームに置き、VS Codeも「WSL: Reopen Folder in WSL」で開くほうが事故が少ない。

なお、WSL1はもう前提にしないほうがいい。公式ページでは、Codex 0.115 以降はLinuxサンドボックスが bubblewrap に移り、WSL1はサポートされないと説明されている。

Windows 11が本命、Windows 10は条件付き

対応OSも確認しておく。公式のWindows版マトリクスでは、Windows 11が推奨、最新状態のWindows 10はベストエフォート、古いWindows 10は非推奨という扱いだ。Windows 10で使う場合は、少なくともConPTYなど近代的なコンソール機能が必要で、実質的にはWindows 10 version 1809以降が前提になる。

会社PCでCodexが動かないときは、アプリそのものより、サンドボックスセットアップ、ログオン権限、ファイルシステム権限、ネットワーク制御のどれかで止まっている可能性が高い。エラーを見ずに再インストールを繰り返すより、elevated サンドボックスのセットアップがどこで失敗したかを見るほうが早い。

料金は「Codex単体」ではなくChatGPTプランに乗る

2026年6月3日時点の公式価格ページでは、CodexはChatGPT Free、Go、Plus、Pro、Business、Edu、Enterpriseに含まれる。個人向けではFreeが0ドル、Goが月8ドル、Plusが月20ドル、Proは月100ドルから、という整理になっている。

古い記事のように「Plusは20ドル、Proは200ドル」と固定で書くとすぐ古くなる。今はCodexの機能表も、Web、アプリ、CLI、IDE拡張、SDK、ローカルレビュー、auto-review、worktree、MCP、skills、pluginsなどに分かれており、プランごとに使える範囲が変わる。導入記事を書くなら、金額より「自分の作業面で必要な入口が、そのプランに含まれるか」を見たほうが実用的だ。

まず決めるべきこと

WindowsでCodexを使うなら、最初に決めるのはアプリ名ではなく実行面だ。

Windowsネイティブの開発環境で、PowerShell、Visual Studio、Windows側のツールを中心に使うなら、CodexアプリやCLIをネイティブサンドボックスで動かすのが本筋。まず elevated を試し、企業ポリシーで詰まるなら unelevated に落とす。

一方、プロジェクトがLinux前提ならWSL2に寄せる。リポジトリはWSLホームに置き、VS CodeもWSL接続で開く。Windowsから見えるからといって /mnt/c に置くと、I/Oや権限で余計な時間を使う。

CodexのWindows対応は「WSLなしでも動くようになった」という話ではある。ただ、WSLを捨てる話ではない。Windowsネイティブで安全に動かす道と、WSL2でLinux開発を続ける道が、どちらも公式の選択肢として整理された。自分のプロジェクトがどちら側に寄っているかを先に決めるのが、いちばん失敗しにくい。

参考

この記事は Codex GPT-5 が執筆しました。