MENU

OrcaのスマホでCodexが選べないときの暫定対処法【Windows+WSL】

OrcaのスマホでCodexが選べないときの暫定対処法。WindowsとWSLの環境向け。

🐧 Orcaをスマホから操作していて、
新規セッションの候補にCodexが出てこない問題にハマった。
WSLにはCodexが入っているのに、
スマホ側から選べない。

調べると、
スマホ用のエージェント検出がWindows側だけを見てしまう既知の不具合だった。
今回はWindows側にWSLのCodexを呼ぶ起動用ファイルを追加して、
検出APIにCodexが戻り、
スマホからの利用も確認できた!!

確認日は2026年10月5日。
スマホ実機での利用も確認済み。
Orca本体のWSL検出処理を直すものではないため、
正式対応までの暫定回避策として残しておく。

目次

試した回避策:Windowsから見えるCodexの起動口を追加する

WindowsのPATHに入っているフォルダへ、
codex.cmdとcodex.ps1を追加した。
どちらもWSL内の既存Codexを呼び出すための短いファイル。

スマホ向けの検出処理からはWindows上のcodexコマンドが見えるようになり、
起動用ファイルを実行するとWSLのCodexへつながる。
Orca本体の書き換えや、
Windows版Codexの追加インストールはしていない。

確認対象対応前対応後
スマホ用の検出APIが返す候補claudeclaude・codex
WindowsからWSL内のCodexを呼ぶファイルなしPowerShell用・cmd用ともにバージョン表示が成功
スマホ実機での利用Codexを選べない症状スマホからCodexを利用できることを確認

今回の環境

項目確認した環境
PC側Windows上でOrcaを実行
Orca1.4.219
WSLディストリビューションUbuntu
Codex CLI0.160.0(WSL内にインストール)
作業フォルダWSL内。
Windowsからは \\wsl.localhost\Ubuntu\… の共有パスで参照

以下のコードにあるusernameとCodexのパスは、
読者向けの置き換え例。
Ubuntuという名前も、
自分のディストリビューションに合わせて変更する。

原因:スマホからの検出にWSLの情報が渡っていなかった

公式リポジトリに、
同じ構成の不具合が報告されていた。
デスクトップ側は作業フォルダからWSLのディストリビューションを判断できる一方、
スマホから呼ばれるpreflight.detectAgentsには実行環境の情報が渡らず、
WindowsのPATHを調べてしまう。

WSL上のエージェントがスマホの候補に出ない不具合報告(Issue #19885)で、
この違いが説明されている。
報告時の環境はOrca 1.4.199だが、
手元の1.4.219にも同じ引数なしの処理が残っていた。

今回の環境ではWindows側にCodexがなく、
WSL内にだけ存在していた。
スマホ用のAPIを実際に呼ぶと、
返ってきた候補はclaudeのみ。
Codexがインストールされている場所と、
検出処理が探している場所がずれていたわけ。

根本対応のWSLのディストリビューションを検出APIへ渡す修正PR(#20101)もある。
ただし2026年10月5日の確認時点ではOpenだったため、
今回は手元の環境で回避策を試した。

設定手順

1. WSL内のCodexの場所を確認する

WindowsのPowerShellで、
ディストリビューション名とCodexの実行ファイルを確認する。
2行目のUbuntuは1行目の結果に合わせる。

wsl.exe --list --quiet
wsl.exe --distribution Ubuntu --exec bash -lc 'command -v codex'

ここで表示されたCodexの絶対パスを、
後の2つのファイルに指定する。
この記事では/home/username/.local/bin/codexという例を使う。
WSLの既定ユーザーでCodexを使えていることも前提。

2. Windows側の既存コマンドとPATHを確認する

Get-Command codex -All -ErrorAction SilentlyContinue
$env:Path -split ';'

すでにWindows版のcodexや同名の起動用ファイルがある場合は、
上書きせずに内容を確認する。
今回追加したのは、
Windows側にCodexがない環境。

保存先には、
ユーザー用PATHに含まれていたC:\Users\username\.local\binを使った。
このフォルダがどのPCでも最初からPATHに入っているわけではないので、
自分の環境でも確認しておく。

PATHに含まれていなければ、
既存のユーザー用コマンドフォルダを選ぶか、
保存先をユーザー環境変数のPathへ追加する。
PATHを変更した場合はOrcaにも新しい設定を読み込ませる必要があるため、
作業中のセッションを確認してから再起動する。
今回はPATHを変更せずに進められた。

3. codex.cmdを作る

先ほど確認したフォルダにcodex.cmdを作成する。
Ubuntuと/home/username/.local/bin/codexは、
自分の環境で確認した値に置き換える。

@echo off
rem Temporary workaround for Orca mobile WSL agent detection.
"%SystemRoot%\System32\wsl.exe" --distribution Ubuntu --cd "%CD%" --exec /home/username/.local/bin/codex %*
exit /b %errorlevel%

このファイルはWindows側でCodexを検出させるための起動口にもなる。
–cdで作業ディレクトリを渡し、
–execで指定したWSL内の実行ファイルを起動する。

4. codex.ps1も作る

同じフォルダにcodex.ps1も追加する。
PowerShellからWSLの共有パス上で実行する場合には、
こちらで作業ディレクトリを渡す。

# Temporary workaround for Orca mobile WSL agent detection.
& "$env:SystemRoot\System32\wsl.exe" --distribution Ubuntu --cd $PWD.ProviderPath --exec /home/username/.local/bin/codex @args
exit $LASTEXITCODE

PowerShellでは@argsで受け取った引数を渡し、
終了コードも引き継ぐ。
今回はPowerShell用とcmd用の両方を用意した。

この2つのファイルはUbuntu内の特定のCodexを呼ぶ設定。
複数のディストリビューションやWSLユーザーを使い分けている場合は、
起動先が意図した環境になっているか確認する。

ハマりポイント:$PWD.PathだとWSLに渡せないパスになった

最初はPowerShell用の起動ファイルで$PWD.Pathを使っていた。
ところがWSLの共有パスへ移動して実行すると、
Wsl/E_INVALIDARGで失敗。

今回のPowerShellでは、
$PWD.Pathに次のようなプロバイダー名が付いていた。
これは説明用にユーザー名とフォルダ名を置き換えた例。

Microsoft.PowerShell.Core\FileSystem::\\wsl.localhost\Ubuntu\home\username\your-project

wsl.exeへ渡したいのは実際のファイルシステム上のパス。
そこで$PWD.ProviderPathに変更すると、
WSLの作業フォルダからもバージョン表示が通るようになった。

なおcmd.exeはUNCパスをカレントディレクトリとして扱えないため、
WSLの共有パスから直接試すときはPowerShell用のcodex.ps1を使う。
cmd用はWindows側の通常のフォルダから確認した。

対応後に確認したこと

WindowsのPowerShellでWSL側の作業フォルダへ移動し、
追加したコマンドを確認した。
下のusernameとyour-projectは実際のパスへ置き換える。

Set-Location '\\wsl.localhost\Ubuntu\home\username\your-project'
Get-Command codex
codex --version

cmd用もWindows側のフォルダから確認。
どちらも手元ではcodex-cli 0.160.0と表示され、
終了コードは0だった。

Set-Location $env:USERPROFILE
codex.cmd --version

さらに稼働中のOrcaで、
スマホが使うものと同じpreflight.detectAgentsを呼び直した。
結果のagents部分を抜き出すと、
次の変化を確認できた。

タイミングagents
追加前[“claude”]
追加後[“claude”, “codex”]

PC側の確認に加えて、
スマホ実機でもCodexを利用できることを確認した。
今回のWindows+WSL環境では、
この回避策でスマホから使える状態に戻った。

正式な修正が入ったら起動用ファイルを見直す

今回の回避策は、
Windows側からCodexを見つけられる状態を作るもの。
Orca本来のWSL検出処理を直したわけではない。

正式な修正を含むバージョンでスマホからの検出を確認できたら、
今回追加したcodex.cmdとcodex.ps1を退避して、
ファイルなしでも候補に出るか確認するとよさそう。
既存のファイルと取り違えないよう、
今回作成した2つだけを対象にする。

WSLには入っているのに、
Windowsアプリから見つからない。
そんなときは「どちらの環境を探しているのか」を確認すると、
原因にたどり着きやすかった。

参考

以上!!
同じところでハマった人のお役に立てれば嬉しいです🐧

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次