CodexをWSLで動かすとComputer UseとChrome連携が使えない理由¶

先に結論

Windows版Codexの画面を使っていても、エージェント本体をWSLで実行していると、Computer UseやBrowser Useがwsl-disabledになる場合がある。ChromeプラグインもWindows側のデスクトップアプリとネイティブホストを必要とするため、WSL上のCodex CLIだけでは利用できない。

WSL上のCodex CLIに、デスクトップ専用のComputer UseやChromeプラグインはない
Windowsデスクトップアプリでも、エージェント実行先がWSLならGUI機能が無効になることがある
Chrome拡張機能だけを再インストールしても、実行環境がWSLのままなら解決しない
Computer UseやChrome連携を使うときは、CodexのエージェントをWindowsネイティブへ戻す

この記事は2026年7月28日時点の公式資料と、OpenAIの公開リポジトリにあるWindows＋WSLの不具合報告を基にしている。配布状況、地域、プラン、組織ポリシー、アプリのバージョンでも利用可否は変わる。

WSL実行とWindowsネイティブ実行におけるGUI連携の違い

Windows上の画面とエージェントの実行先は別である¶

Windows版Codexには、エージェントをWindowsネイティブで動かす設定と、WSL2で動かす設定がある。公式のWSLガイドによると、WSLを選ぶとCodexはWindowsネイティブサンドボックスではなくLinux環境内で実行される。設定変更はアプリの再起動後に反映される。¹

つまり、CodexのウィンドウがWindows上に見えていても、コマンドやツールを実行するエージェントはWSL内のLinuxプロセスである可能性がある。

構成	エージェントの実行先	GUI連携
WSL上のCodex CLI	Linux／WSL	デスクトップ専用機能を利用できない
Windows版Codex＋WSL設定	Linux／WSL	Computer Use／Browser Useが無効になる場合がある
Windows版Codex＋Windowsネイティブ設定	Windows	対応条件を満たせば利用できる

問題の中心は、アプリのウィンドウがどこにあるかではなく、CodexのエージェントがどのOSで動いているかにある。

`wsl-disabled`はChromeの再インストールで直すエラーではない¶

OpenAIの公開Issue #25301では、Windows版Codexでapp-serverをWSL実行にしたとき、Computer Use／Browser Useの可用性判定が次の状態になったと報告されている。²

available=false
reason=wsl-disabled

同じログでは、Windows用Computer Useヘルパーのパスを利用できず、ネイティブパイプの起動にも失敗していた。この事例では、Windows上のデスクトップホスト、WSL内のapp-server、WindowsネイティブのGUIヘルパーが別の実行境界に分かれている。

Windows版CodexからWSL内のCodex app-serverまでは起動できても、その先にあるWindows用GUIヘルパーへ接続できない構成である。

Issueは利用者による不具合報告であり、将来も永久に使えないと宣言する公式仕様ではない。ただし、ログにwsl-disabledが出ている場合は、Chrome拡張機能やサイト権限より先に、エージェントの実行先を確認すべきである。

WSL上のCodex CLIではComputer Useを利用できない¶

Computer Useは、ChatGPTデスクトップアプリ上のChatGPT WorkまたはCodexから、macOSやWindowsの画面とアプリを操作する機能である。公式ガイドは、対応地域のmacOS／Windows版デスクトップアプリでComputer Useプラグインを導入して使うよう案内している。³

WSL上のCodex CLIはLinuxのターミナル環境であり、Windowsの前景画面を操作するデスクトップ機能を持たない。CLIからPowerShellやwsl.exeを呼べることと、Computer Useでマウスやキーボードを操作できることは別である。

内蔵Browserについても同様で、公式ガイドはCodex CLIとIDE拡張では利用できず、ChatGPTデスクトップアプリが必要だと説明している。⁴

Chrome拡張機能だけを入れてもCodexからは使えない¶

CodexのChrome連携は、Chrome Web Storeの拡張機能だけで完結しない。公式手順では、まずChatGPTデスクトップアプリのPlugins DirectoryからChromeプラグインを導入し、そのセットアップからChrome拡張機能をインストールする。⁵

必要な経路は、Windows版Codex、Chromeプラグイン、 Windowsのネイティブメッセージングホスト、Chrome拡張機能、 Chromeのタブとプロファイルの順である。

WSL上のCodex CLIだけを起動しても、このWindowsネイティブの接続経路は作られない。また、Windows版Codexを開いていても、エージェントをWSL実行にしてBrowser Use自体がwsl-disabledになっていれば、Chrome側だけを再インストールしても根本原因は残る。

Chrome拡張機能が「未接続」になる原因はほかにもある。Windowsネイティブへ戻しても使えない場合は、公式ガイドの順序で次を確認する。

Windows版Codexを最新版へ更新する
Plugins DirectoryでChromeプラグインが有効か確認する
Chromeを再起動し、拡張機能のサイドパネルが開くか確認する
利用中のChromeプロファイルに拡張機能が入っているか確認する
新しいCodexチャットで@Chromeを試す
ネイティブホストが見つからない場合は、Chromeプラグインを削除して追加し直す

Windowsネイティブへ戻してから機能を確認する¶

wsl-disabledが原因なら、Windows版Codexの設定でエージェントをWindowsネイティブへ戻し、アプリを再起動する。

Windows版CodexでSettingsを開く
エージェントの実行環境をWSLからWindows nativeへ変更する
Codexを完全に終了して再起動する
Plugins DirectoryでComputer UseとChromeを確認する
SettingsのComputer UseでGoogle Chromeの接続状態を確認する
新しいチャットで小さな読み取りテストを行う

最初の確認では、購入、送信、削除、公開、権限変更などを避ける。表示やタイトルの読み取りだけに限定する。

@Computer で電卓を開き、画面が見えるか確認して。操作はまだしないで
@Chrome で現在のテスト用タブを開き、ページタイトルだけ教えて

WindowsのComputer Useはアクティブなデスクトップを操作する。テスト中は対象アプリを前景に表示し、Codexがマウスとキーボードを操作することを前提にする。³

Linuxコマンドが必要ならWindows側からWSLを呼べる¶

Computer UseやChrome連携のためにWindowsネイティブへ戻しても、Linuxツールをすべて諦める必要はない。公式のWindowsガイドは、Windowsネイティブのエージェントから必要に応じてwsl CLIを使えると説明している。¹

wsl.exe -d <DISTRO> -- bash -lc "cd ~/code/project && npm test"

エージェント本体はWindows側に置き、Linux固有のテストやビルドだけをWSLへ委譲すれば、WindowsのGUI連携とLinuxツールを併用できる。

WSLからWindowsへ切り替えたあとサイドバー履歴が表示されなくなった場合は、SQLiteをOS間でコピーしない。安全な復元方法はCodexをWSLからWindowsへ移行し、消えたサイドバー履歴を復元するで解説している。

まず実行環境を確認すれば切り分けが速い¶

Computer UseやChrome連携が使えないとき、最初から拡張機能、Chromeプロファイル、サイト権限をすべて調べる必要はない。

症状	最初に確認すること
ログに`wsl-disabled`がある	エージェントをWindowsネイティブへ戻す
WSLのCodex CLIだけを使っている	Windows版Codexを使う
WindowsネイティブでもChromeが未接続	Chromeプラグインとネイティブホストを確認する
Computer Useは表示されるが操作できない	対応地域、権限、対象アプリの前景表示を確認する
切り替え後に履歴が消えた	`CODEX_HOME`とセッション索引を確認する

要点は一つである。Windowsの画面やChromeを操作する機能は、Windows側のデスクトップ実行基盤を必要とする。 WSLで使えない状態に遭遇したら、Chrome拡張機能を何度も入れ直す前に、CodexのエージェントがWindowsネイティブで動いているかを確認する。