WSL2＋Codex CLIを捨てずにWindows版ChatGPTを追加する構成【Pro X20実践①】

Last updated at 2026-07-14Posted at 2026-07-12

検証日：2026年7月14日
環境：Windows 11／複数のWSL2ディストリビューション／ChatGPT Pro 20x／Codex CLI
ChatGPTやCodexの機能は段階的に展開される場合があります。画面や利用可能な機能が本記事と異なる場合は、最新の公式ドキュメントも確認してください。

2026年7月14日改訂
初版公開後、複数のWSL2ディストリビューションが存在する環境でDesktop Codexを検証しました。本改訂では、プロジェクトの保存先とAgentの実行先を明確に分け、Windows native／WSLの切り替え、任意のWSLディストリビューション指定、worktreeの保存先に関する制約を反映しています。

はじめに

前回の記事では、ChatGPT Pro 20xを前提に、Chat、Work、Codexの構成、モデルの選び方、利用枠、トークン消費について整理しました。(前回の記事)

今回は、その実践編です。

筆者は現在、Windows上に複数のWSL2ディストリビューションを用意し、そのうち独自に構築した開発環境でCodex CLIをFull accessで使用しています。ソースコードはGitHubで管理し、複数のソフトウェア開発プロジェクトと技術ドキュメント制作を並行して進めています。

新しいWindows版ChatGPTでは、Chat、Work、Codexが一つのデスクトップアプリへ統合されました。既存のCodexアプリを更新した場合も、新しいChatGPTデスクトップアプリへ移行し、既存のCodexタスクやプロジェクトは原則として維持されます。(OpenAI Help Center)

ここで生じる疑問は、次のとおりです。

安定稼働している独自WSL2環境上のCodex CLIをやめて、Windows版ChatGPTのCodexへ移行すべきなのか。

本記事の結論は、全面移行しないです。

WSL2とCodex CLIは実装・デバッグの主力として残します。Windows版ChatGPTは、ChatとWork、複数プロジェクトの可視化、レビュー、および動作確認できた実行環境でのCodexタスクを担当する上位レイヤーとして追加します。

結論

移行後の役割分担は次のとおりです。

環境	主な役割
Chat	要件整理、設計相談、選択肢の比較
Work	調査、技術文書、完成成果物の作成
Windows版ChatGPTのCodex	プロジェクト管理、レビュー、長時間タスク、動作確認済み環境での作業
独自WSL2環境上のCodex CLI	実装、デバッグ、ビルド、テスト、Docker操作、GitHub操作
Gitリポジトリ	設計、コード、判断、作業状態の正本
GitHub	Issues、Pull Requests、Actions、リリース管理

要点は次の5つです。

WSL2内の既存リポジトリとツールチェーンは移動しない
Codex CLIの既存設定とFull access運用は維持する
\\wsl$\DistroName\...で選ぶのはプロジェクトの保存先であり、Agentの実行先ディストリビューションではない
Desktop CodexのAgent EnvironmentはWindows nativeまたはWSLのアプリ全体設定で、切り替えには再起動が必要
非既定の独自WSL環境や複数ディストリビューションの並行作業は、各環境内のCodex CLIを主力にする

Windows版ChatGPTは、複数プロジェクトや長時間タスクを一つのワークスペースで管理する「command center」として位置づけられています。一方、Codex CLIは、ローカルリポジトリをターミナル内で調査、編集、実行、自動化する環境として引き続き提供されています。(ChatGPT desktop app)(Codex CLI)

移行前の構成

従来の構成は、次のようになっています。

この構成は単純で、ターミナル中心の作業には適しています。

特に、次のような作業ではCodex CLIが扱いやすい環境です。

ログを見ながら行うデバッグ
Docker Composeを使った複数サービスの操作
テストを繰り返し実行する作業
Linux用のビルドツールやシェルスクリプトの使用
コマンドの実行結果を見ながら指示を修正する作業
IDEのターミナル内で完結する小規模な変更
特定のWSLディストリビューション固有のパッケージ、DB、認証情報、ネットワーク設定を使う作業

Codex CLIは、ローカルリポジトリ内でファイルの調査、変更、コマンド実行、レビューを行えます。モデル、権限、コマンドをタスクに合わせて選択でき、codex execによる反復処理やCIへの組み込みにも対応します。(Codex CLI)

したがって、CLIを使わなくなる理由はありません。

移行後の構成

複数WSL2環境の制約を反映すると、移行後の構成は次のようになります。

この構成では、次のように役割が分かれます。

CLI      ：特定の実行環境で一つの作業へ深く入る
Desktop  ：複数の作業を可視化し、レビューする
Chat     ：方針を考える
Work     ：読める成果物へまとめる
GitHub   ：確定した状態を保存する

重要なのは、Desktop Codexを複数のWSLディストリビューションへ自由に接続できる統一フロントエンドとは考えないことです。

独自に作成したWSL2環境をアプリ側で指定できるか

プロジェクトの保存先は選べる

Windows版ChatGPTでは、プロジェクト追加画面で次のパスを入力し、WSLファイルシステム内のフォルダーを選べます。

\\wsl$\

例：

\\wsl$\Ubuntu-Development\home\<user>\projects\product-api

公式ドキュメントにも、\\wsl$\からLinuxディストリビューションとフォルダーを選択する手順が記載されています。(Windows app docs)

ただし、ここで選択しているのは次のものです。

プロジェクトの保存先ディストリビューション

次の設定とは別です。

Codex Agentの実行先ディストリビューション

公開UIで選べるAgentはWindows nativeまたはWSL

2026年7月14日時点の公式ドキュメントでは、Agentの設定として説明されているのは次の二つです。

Windows native
WSL

AgentをWindows nativeからWSLへ変更した場合、変更を反映するにはアプリの再起動が必要です。(Windows app docs)

一方、WSLモードで使用するディストリビューション名を、プロジェクトごとに明示指定する公開手順は確認できません。

複数ディストリビューションでは既定WSLが使われる報告がある

OpenAI公式GitHubリポジトリには、非既定のWSLディストリビューション上にあるプロジェクトを\\wsl$\DistroName\...で開いても、Codex AppがWindowsの既定WSLディストリビューションを使用し、プロジェクトへアクセスできないという未解決の報告があります。(Issue #13966)

このIssueは公式仕様ではなく、現行実装に関する公開された不具合報告です。しかし、筆者の複数WSL環境での実測とも方向性が一致しています。

したがって、次の方針を採用します。

条件	推奨
Windows nativeプロジェクト	Desktop CodexのWindows native Agent
既定WSL上のプロジェクト	実行環境を確認してDesktop Codexを試す
非既定の独自WSLディストリビューション	その環境内のCodex CLI
複数WSLディストリビューションを並行利用	各環境内のCodex CLI
実行ディストリビューションが不明	変更を行わず、環境を確認してから判断

アプリが新しいWSLディストリビューションを作っているのか

2026年7月14日時点では、ChatGPTデスクトップアプリが独自のWSLディストリビューションを新規作成・インポートするという公式説明は確認できません。

一方、Windows nativeモードを選択していても、アプリ起動時に既存のUbuntuディストリビューションとWSL関連プロセスが起動するという未解決の報告があります。(Issue #30048)

したがって、アプリ起動後にWSLが動いていることだけを根拠に、「アプリが新しいディストリビューションを作成した」「選択した独自環境でAgentが動いている」と判断することはできません。既存WSLの起動と、新規ディストリビューションの作成を分けて確認します。

新しいWSL環境が起動したように見える場合は、推測せず、アプリ起動前後で次を比較します。

wsl --list --verbose
wsl --list --running

一覧に新しいディストリビューション名が追加されていなければ、新規ディストリビューションが作られたのではなく、既存のディストリビューションが起動された可能性が高いと判断できます。

Windows nativeとWSLはアプリ全体の設定

Agent Environmentはプロジェクト単位ではなく、現行アプリの全体設定として扱われます。

Windows native
        ↑
   設定変更＋再起動
        ↓
WSL

OpenAI公式GitHubリポジトリには、現在は単一のグローバル実行環境であり、Windows native／WSLの切り替えに設定変更と再起動が必要であるとして、プロジェクト別設定と複数環境の同時実行を求める機能要望がOpenの状態で登録されています。(Issue #23071)

現行アプリでは、次のような同時運用はできないと考えるのが安全です。

Project A → Windows native Agent
Project B → WSL Agent
Project C → 別のWSLディストリビューション

一方、次の構成は可能です。

ChatGPT Desktop
└─ Windows native Agent または一つのWSL Agent

WSLディストリビューション A
└─ Codex CLI

WSLディストリビューション B
└─ Codex CLI

つまり、同一アプリ内で複数Agent環境を同時利用できなくても、Desktopと複数のCodex CLIは並行利用できます。

なお、統合ターミナルはAgentとは独立して設定できます。AgentをWSLにしてPowerShellターミナルを使う、またはAgentとターミナルの両方をWSLにする、といった構成が可能です。統合ターミナルの変更は新しいターミナルセッションに適用されます。(Windows app docs)

なぜCodex CLIを置き換えないのか

1. すでに安定した実行環境がある

現在の独自WSL2環境には、次のような開発環境が構築されています。

Git
GitHub CLI
Docker
言語ランタイム
パッケージマネージャー
ビルドツール
テストツール
データベース
各プロジェクト固有の環境変数
ディストリビューション固有の設定やサービス

Codex CLIは、この環境をそのまま利用します。

Windows版ChatGPTへ移行するためにリポジトリをWindows側へ移したり、Windowsネイティブ版のツールを再構築したりすると、現在安定している環境へ新しい差異を持ち込むことになります。

2. CLIとDesktopでは得意な作業が異なる

Codex CLIは、ターミナルからローカルリポジトリを操作する環境です。

Windows版ChatGPTのCodexは、複数プロジェクト、長時間タスク、レビュー、worktreeなどを一つの画面で扱う環境です。(ChatGPT desktop app)

アプリ版を追加する目的は、CLIと同じ操作を別のUIで行うことではありません。

CLIだけでは管理しにくかった次の部分を補うことが目的です。

複数プロジェクトのタスク一覧
長時間タスクの進捗確認
Gitリポジトリのdiffレビュー
行単位のフィードバック
stage、revert、commit、push
Chat、Work、Codexの切り替え
動作確認済み環境での並列タスク

3. Full access環境を作り直す必要がない

現在のCodex CLIでは、独自WSL2環境をFull accessで運用しています。

この環境を維持するなら、まずCLIをそのまま残した方が移行リスクを抑えられます。Windows版ChatGPT側でもFull accessは選択できますが、プロジェクト外のファイルや広い範囲へアクセスでき、意図しない破壊的操作やデータ損失につながる可能性があります。公式ドキュメントもFull accessのリスクを明記しています。(Windows app docs)

本稿では、Full accessそのものの権限設計は扱いません。

方針は次のとおりです。

既存のCodex CLI Full accessは維持する
Desktop Codexは環境確認後、小さなタスクから導入する
GitHubへの書き込みや破壊的操作には別の承認境界を設ける
詳細な権限設計は後続記事で扱う

Windows版ChatGPTでWSL2を使う設定

1. 新しいChatGPTデスクトップアプリへ更新する

既存のCodexアプリを使っている場合は、通常どおり更新します。更新後はChat、Work、Codexを統合した新しいChatGPTデスクトップアプリになります。

既存のCodexユーザーでは、更新後もCodexを初期画面として使う設定が可能です。(OpenAI Help Center)

2. Codex AgentをWSLへ変更する

Windows版ChatGPTの設定画面で、Codex AgentをWindows nativeからWSLへ変更できます。

変更後はアプリを再起動します。再起動するまで設定は反映されません。(Windows app docs)

ただし、この設定は「任意のWSLディストリビューションを選択する設定」ではありません。複数ディストリビューション環境では、後述の確認を行います。

3. 統合ターミナルを設定する

Codex Agentと統合ターミナルは別々に設定できます。

例：

Codex Agent        : WSL
Integrated Terminal: WSL

または、次のような構成も可能です。

Codex Agent        : WSL
Integrated Terminal: PowerShell

ターミナルをWSLに設定しても、Agentの実行ディストリビューションを指定したことにはなりません。(Windows app docs)

4. WSL2上のプロジェクトを追加する

プロジェクト追加画面で次を入力します。

\\wsl$\

そこからディストリビューションとリポジトリの保存先を選択します。

例：

\\wsl$\Ubuntu-Development\home\<user>\projects\product-api

繰り返しになりますが、これはファイルの保存先を選ぶ操作です。Agentが同じディストリビューションで動くことを保証する設定ではありません。

5. Windows側にもGitを導入する

Codex AgentをWSLへ設定しても、Windows版ChatGPTのレビュー画面など、一部のアプリ機能ではWindows側のGitが必要です。

GitとGitHub CLIを未導入の場合は、PowerShellからインストールします。

winget install --id Git.Git
winget install --id GitHub.cli

公式ドキュメントでは、Gitはレビュー画面や変更の確認・取り消しに、GitHub CLIはGitHub固有の機能に使用されると説明されています。(Windows app docs)

WSL側とWindows側のGitHub CLIは別の実行環境なので、必要な側でそれぞれ認証します。

gh auth login

最初に実行環境を確認する

複数WSLディストリビューション環境では、最初からファイルを変更させず、Agentが実際にどこで動いているか確認します。

Windows側では、アプリ起動前後に次を実行します。

wsl --list --verbose
wsl --list --running

Desktop Codexには、最初のタスクとして次を依頼します。

このプロジェクトを変更せずに、実行環境を確認してください。

次のコマンド相当の情報を取得してください。

- WSL_DISTRO_NAME
- HOME
- CODEX_HOME
- PWD
- /etc/os-release
- id
- Gitリポジトリのルート
- 現在のブランチ
- 未コミット変更

ファイル変更、依存関係の追加、テスト実行、外部への書き込みは行わないでください。
確認結果だけを簡潔に報告してください。

シェルで確認する場合は次を使えます。

printf 'WSL_DISTRO_NAME=%s\n' "${WSL_DISTRO_NAME:-<unset>}"
printf 'HOME=%s\n' "$HOME"
printf 'CODEX_HOME=%s\n' "${CODEX_HOME:-<unset>}"
printf 'PWD=%s\n' "$PWD"

cat /etc/os-release
id
git rev-parse --show-toplevel
git branch --show-current
git status --short

確認項目は次のとおりです。

確認項目	期待する状態
`WSL_DISTRO_NAME`	使用したいディストリビューション名と一致
`PWD`	対象リポジトリ内
`/etc/os-release`	期待するLinux環境
Gitルート	対象リポジトリと一致
ブランチ	CLIで見ているものと一致
未コミット変更	既存の状態と一致
`CODEX_HOME`	意図した保存先

期待するディストリビューションと一致しない場合は、そのタスクでファイルを変更せず、対象ディストリビューション内のCodex CLIへ戻します。

最初は`CODEX_HOME`を共有しない

Windows版ChatGPTとWSL2上のCodex CLIは、初期状態では異なるCodexホームを使います。

Windows版ChatGPT:
%USERPROFILE%\.codex

WSL2 Codex CLI:
~/.codex

公式ドキュメントでは、必要に応じてWSL側からWindowsのCodexホームを参照する方法が案内されています。(Windows app docs)

export CODEX_HOME=/mnt/c/Users/<windows-user>/.codex

ただし、今回の移行では最初から共有しません。

理由は次のとおりです。

現在のCLI設定が安定している
WindowsとWSLでは実行ファイルのパスが異なる
MCPサーバーや外部ツールの設定が環境依存になりやすい
問題発生時にCLIとDesktopのどちらが原因か分かりにくくなる
CODEX_HOMEの共有は実行ディストリビューションの選択にはならない

さらに、OpenAI公式GitHubリポジトリには、Windows版DesktopのWSLモードがWindows側のCODEX_HOMEをWSLへ持ち込み、Codex-managed worktreeをLinuxファイルシステムではなく/mnt/c/...配下へ作成するという未解決の報告があります。(Issue #13762)

/mnt/c配下のworktreeは、LinuxネイティブファイルシステムよりGit操作が遅くなる可能性があります。したがって、Desktopのworktreeを本格利用する前に、作成先を確認します。

初期段階では、共有する情報をGitリポジトリ内に限定します。

repository/
├─ AGENTS.md
├─ .codex/
└─ docs/
   ├─ requirements/
   ├─ adr/
   ├─ plans/
   └─ handoffs/

Desktop Codexで新しくできること

1. 複数プロジェクトを一つの画面で監督する

Windows版ChatGPTは、複数プロジェクトや長時間タスクを一覧で管理し、タスク間を切り替える用途に向いています。(ChatGPT desktop app)

CLIだけで複数プロジェクトを扱う場合、ターミナル、tmux、作業ディレクトリ、履歴を自分で管理する必要があります。

Desktopを追加すると、次を一覧化できます。

product-api
├─ 認証不具合の調査
├─ API追加
└─ 回帰テスト

web-frontend
├─ 表示崩れの修正
└─ E2Eテスト

developer-docs
├─ APIリファレンス更新
└─ リンク切れ修正

2. GUIでdiffをレビューする

Windows版ChatGPTのレビュー画面では、Gitリポジトリの変更を確認し、行単位のフィードバックを付けられます。stage、revert、commit、pushも扱えます。

/reviewを実行すると、選択した差分を専用レビュー担当が読み、作業ツリーを変更せずに優先順位付きの指摘を返します。(Code review)

CLIで実装し、Desktopでレビューする使い方も可能です。ただし、WSLプロジェクトをアプリから正しく参照でき、Gitが検出されることが前提です。

3. worktreeで並列作業する。ただし環境確認後

Desktop Codexのworktreeは、同じGitプロジェクト内で複数の独立タスクを並行実行する機能です。Handoffにより、LocalとWorktreeの間でタスクを移動できます。(Worktrees)

Codex-managed worktreeは、既定では$CODEX_HOME/worktrees配下に作成されます。現在の公式ドキュメントでは、次の設定から別の保存先を指定できます。(Worktrees)

Settings
└─ Worktrees
   └─ Worktree root

ただし、Worktree rootを指定できることと、Agentの実行先WSLディストリビューションを指定できることは別です。複数WSL環境では、設定後も実際のworktree保存先と実行環境を確認します。

Local checkout
└─ 自分＋Codex CLIで障害調査

Worktree A
└─ 新しいAPIの実装

Worktree B
└─ 回帰テストの追加

Worktree C
└─ 技術文書の更新

ただし、複数WSL環境では次を確認してから使います。

Agentが期待するディストリビューションで動いているか
worktreeがLinuxファイルシステム内へ作られているか
/mnt/c/...配下へ作られていないか
Local checkoutとHandoff先の環境が一致しているか
Git性能に問題がないか

検証が完了するまでは、独自WSL環境内で通常のgit worktreeとCodex CLIを使う方が確実です。

git worktree add ../product-api-issue-101 -b issue-101
cd ../product-api-issue-101
codex

推奨する日常の使い分け

作業	推奨環境
数分で終わる修正	独自WSL2内のCodex CLI
ログ・DB・Dockerを使う障害調査	独自WSL2内のCodex CLI
非既定WSL固有のツールチェーン	独自WSL2内のCodex CLI
複数WSLディストリビューションの並行作業	各ディストリビューションのCodex CLI
Windowsネイティブアプリの作業	Desktop CodexのWindows native Agent
既定WSL上の小規模タスク	実行環境を確認後、Desktop Codex
Git差分の可視化と行単位レビュー	Desktop review paneまたはIDE／GitHub
複数タスクの一覧管理	Desktop
技術文書の調査・編集	Work

数分で終わる修正

独自WSL2
  ↓
Codex CLI
  ↓
テスト
  ↓
git diff
  ↓
Pull Request

Desktopを使う必要はありません。

通常の機能実装

Chat
  ↓ 要件と設計方針を整理

docs/plans/feature.md
  ↓ 方針をGitへ保存

独自WSL2のCodex CLI
  ↓ 実装・テスト

Desktop review pane / IDE / GitHub
  ↓ 差分レビュー

GitHub Pull Request

DesktopのWSL実行環境が期待どおりと確認できたプロジェクトだけ、worktreeやHandoffを追加します。

複数の独立したIssue

WSL A / Local       ：Issue #101をCodex CLIで調査
WSL A / Worktree 1  ：Issue #102をCodex CLIで実装
WSL B / Local       ：Issue #103を別のCodex CLIで処理
Desktop             ：タスク一覧とレビュー

原因不明の障害

Codex CLI
  ↓ ログ・プロセス・DBを対話的に調査

必要なら手動worktree
  ↓ 修正案を分離して試作

Codex CLI
  ↓ 実環境で再検証

Desktop / IDE / GitHub
  ↓ 差分レビュー

障害調査のように、前のコマンド結果によって次の行動が変わる作業は、無理に並列化せず、CLIで逐次的に進めた方が扱いやすい場合があります。

トークン消費は減るのか

アプリを追加するだけでは減らない

Windows版ChatGPTへ移したからといって、同じ作業のトークン消費が自動的に減るわけではありません。

Codex CLI、IDE Extension、Desktop、Cloudは、ChatGPTプラン内のCodex利用量を使う複数のサーフェスです。Pro 20xはPlusより大きい利用枠を提供しますが、CLIとDesktopへ別々の20x枠が付与されるわけではありません。WorkとCodexも利用量を共有します。(Pricing)

worktreeはトークン節約機能ではない

worktreeを複数動かすと、経過時間は短縮できる可能性があります。

しかし、各タスクはそれぞれ次の処理を行います。

リポジトリの読み取り
指示の理解
推論
コマンド実行
テスト
結果報告

そのため、並列化は時間を短縮する機能であり、合計利用量を減らす機能ではありません。

Full accessそのものに別のトークン単価はない

公開されている料金体系では、権限モードはトークン単価の項目ではありません。

ただし、Full accessでは承認待ちで停止せず、コマンド、テスト、ネットワークアクセスを連続実行できるため、結果的に一つのタスクが長くなり、利用量が増える可能性があります。

移行後の節約ルール

1リポジトリ1プロジェクトを基本にする
実装対象のディレクトリを限定する
長いChat履歴ではなく計画ファイルを渡す
一つのタスクに複数の目的を混在させない
出力は変更点、テスト結果、残課題に限定する
worktreeは独立性が高い作業だけに使う
不要なPluginやMCPを有効にしない
CLIとDesktopで同じ調査を重複させない
実行環境が不明なDesktopタスクを走らせない

段階的な導入手順

段階0：WSL環境を棚卸しする

まず、Windows側でディストリビューションを確認します。

wsl --list --verbose

記録する項目は次のとおりです。

既定ディストリビューション
各プロジェクトが存在するディストリビューション
各ディストリビューションのユーザー
Codex CLIのCODEX_HOME
Docker、DB、GitHub CLIの配置

段階1：Desktopでは管理・レビューだけを試す

最初はCLIの実装フローを変更しません。

Codex CLIで実装
  ↓
Desktop、IDE、またはGitHubで差分確認
  ↓
必要に応じて/review

DesktopでリポジトリとGitが正しく認識されない場合は、無理に使わずIDEまたはGitHubのレビューへ戻します。

段階2：Desktopの実行環境を確認する

AgentをWSLへ切り替え、アプリを再起動します。最初のタスクは読み取り専用の環境確認にします。

WSL_DISTRO_NAME
/etc/os-release
HOME
CODEX_HOME
PWD
Gitルート

期待する環境と一致しなければ、ファイル変更を行いません。

段階3：小さなタスクを試す

実行環境が一致した場合だけ、独立した低リスクのタスクを一つ試します。

例：

テスト追加
lint修正
README更新
型定義追加
小規模なバグ修正

段階4：worktreeの保存先を確認する

Codex-managed worktreeは、既定では$CODEX_HOME/worktrees配下に作成されます。必要に応じて、次の設定でWorktree rootを指定します。(Worktrees)

Settings
└─ Worktrees
   └─ Worktree root

設定後に低リスクのworktreeを一つ作成し、実際の保存先を確認します。

git worktree list

期待するLinuxファイルシステム内に作成されていない場合や、/mnt/c/...配下で性能・パス整合性に問題がある場合は、独自WSL環境内の手動worktreeへ戻します。Worktree rootの指定だけで、Agentの実行ディストリビューションやCODEX_HOMEの問題が解消したとは判断しません。

段階5：Workを文書プロジェクトへ追加する

技術文書や技術書では、次の分担を試します。

Work
  ↓ 調査、構成、初稿、編集

Git管理ファイル
  ↓ 仕様・判断・原稿を保存

独自WSL2のCodex CLI
  ↓ Markdown反映、コード例検証、ビルド

GitHub
  ↓ 原稿、レビュー、公開

移行時に避けたこと

リポジトリをWindows側へ移さない

Linux環境を前提にしたプロジェクトでは、リポジトリをWindowsへ移動しません。

DesktopのWSL Agentが期待するディストリビューションを使えない場合も、リポジトリを移すのではなく、既存のCodex CLIを継続します。

任意のWSLディストリビューションを選べると仮定しない

\\wsl$\DistroName\...でフォルダーを開けても、同じディストリビューションでAgentが動くとは限りません。

必ず実行環境を確認します。

`CODEX_HOME`をすぐに統合しない

現在安定しているCLI設定を保護するため、DesktopとCLIの個人設定は当面分離します。

共通化する情報は、まずGit管理された次のファイルに限定します。

AGENTS.md
.codex/
docs/

すべての作業をDesktop worktreeへ移さない

対話的な障害調査、非既定WSL固有の環境、ローカルDBやDockerに強く依存する作業はCLIに残します。

アプリ導入をトークン節約策と考えない

Desktopは管理、並列化、レビューを改善します。

利用量を減らすには、画面を変えるのではなく、対象範囲、タスク分割、モデル、プロンプト、出力を見直す必要があります。

会話履歴を正本にしない

設計や判断は、ChatやCodexの履歴だけに残しません。

長期的に必要な情報は、次のようなGit管理ファイルへ保存します。

docs/requirements/
docs/adr/
docs/plans/
docs/issues/
docs/handoffs/

移行によって変わること

項目	移行前	移行後
実装	Codex CLI	Codex CLI中心
デバッグ	Codex CLI	Codex CLI中心
独自WSL環境	CLIから直接利用	引き続きCLIから直接利用
プロジェクト管理	ターミナルや手作業	Desktopで一覧化
Windows／WSL切り替え	各シェルを直接起動	Desktop Agentは全体設定・再起動が必要
複数WSLの同時利用	各ターミナル	各ディストリビューションのCLIを併用
並列作業	手動worktree／複数端末	手動worktreeを基本に、検証済みならDesktop worktree
差分レビュー	CLI、IDE、GitHub	Desktop review paneを追加可能
長時間タスク	CLIセッション	Desktopで監督可能
技術文書	Chat＋CLI	Work＋Git管理＋CLIへ拡張
GitHub	正本	引き続き正本
Full access	CLIで利用	CLIを維持し、Desktopは段階導入

まとめ

今回の移行では、Codex CLIをWindows版ChatGPTへ置き換えません。

移行後の構成は次のとおりです。

Chat
└─ 要件・設計・判断

Work
└─ 調査・技術文書・成果物

Windows版ChatGPT Codex
├─ 複数プロジェクトの可視化
├─ 動作確認済み環境でのタスク
├─ 長時間タスク
└─ diffレビュー

独自WSL2環境のCodex CLI
├─ Full access
├─ 実装
├─ デバッグ
├─ ビルド・テスト
├─ Docker・Linuxツール
└─ 複数ディストリビューションの並行利用

GitHub
├─ Issues
├─ Pull Requests
├─ Actions
└─ 確定状態の正本

最も重要な点は、次の役割分担です。

Codex CLIは、特定の実行環境で深く作業する場所。
Windows版ChatGPTは、複数の作業を可視化し、レビューする場所。
GitHubは、確定した計画と成果を残す場所。

Windows版ChatGPTのWSLモードは有用ですが、複数の独自WSLディストリビューションをプロジェクトごとに選択し、Windows nativeと同時に動作させる統一実行基盤ではありません。

\\wsl$\DistroName\...で選べるのはプロジェクトの保存先です。Agent Environmentはアプリ全体でWindows nativeまたはWSLの一方を選び、切り替えには再起動が必要です。非既定の独自WSL環境を確実に使う作業では、対象ディストリビューション内のCodex CLIを残す構成が現実的です。

次回は、Web版Chatで作った設計をWorkで仕様書とIssue草案へ変換し、独自WSL2環境のCodex CLIで実装と照合した後、GitHub Issueへ登録する連携方法を整理します。

変更履歴

2026年7月12日：初版公開
2026年7月14日：
- 複数WSL2ディストリビューション環境の実測を反映
- \\wsl$によるプロジェクト選択とAgentの実行先を区別
- Agent Environmentがアプリ全体の設定であることを明記
- Windows native／WSLの切り替えにアプリ再起動が必要なことを追記
- 同一アプリ内でWindows native AgentとWSL Agentを同時実行できない現状を追記
- 非既定の独自WSL2環境ではCodex CLIを継続利用する方針へ修正
- CODEX_HOME共有とworktree保存先の注意を追記
- Desktop-managed worktreeを環境確認後に導入する方針へ変更
- 公式のWorktree root設定と、設定後も保存先を実測する手順を追記

参考資料

GitHub Issueは公式仕様ではなく、不具合報告または機能要望です。本記事では、公式ドキュメントに記載のない現行挙動を補足する材料として参照しています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up