Codex Desktop が Windows または WSL で遅く、同じ小さな作業を Codex CLI や IDE 拡張ではすぐ返せるなら、まず進行中のリポジトリ作業を速い入口へ移し、Desktop App の経路を別に診断します。最初から再インストール、キャッシュ削除、WSL 切り替え、Fast mode 変更を重ねると、何が効いたのか分からなくなります。
| いま見えている状態 | 先に使う入口 | 理由 |
|---|---|---|
| CLI や IDE は速いが Desktop App だけ遅い | CLI または IDE | 現在のコード作業をアプリ経路の調査で止めないため。 |
| worktree、長い thread、Git review、browser task、artifacts、Computer Use が必要 | Desktop App | これらはアプリ側の強みで、普通の編集だけが CLI に移っても残す価値があります。 |
| 同じプロンプトがどの入口でも遅い | モデル、アカウント、サービス状態、リポジトリ規模、プロンプト範囲を確認 | Desktop App だけの問題とはまだ言えません。 |
| 比較条件をそろえても Desktop App が大きく遅い | 報告ルート | version、Windows/WSL mode、project path、timing、Fast mode state、redacted logs が必要です。 |
Fast mode は対応モデルの応答速度を上げる選択肢ですが、Windows/WSL のローカル経路、UI、ファイル監視、ログ書き込み、権限確認の負荷が消えた証拠にはなりません。先に Desktop App version、visible bundled agent version、`codex --version`、Windows build、WSL distro and mode、project path、同じプロンプトの timing を残してください。
最初に五分の比較を行う
有効な比較は退屈なくらいで十分です。同じ repository、同じ小さな prompt、近い model と approval settings を用意し、Desktop App、CLI、IDE extension、必要なら Cloud を順に測ります。最初の測定前に設定を変えないことが重要です。変更前の基準がなければ、次の測定で速くなっても理由が説明できません。
プロンプトは小さく、しかし実作業に近いものにします。たとえば「このファイルを見て、最小で安全な修正案を出して」といった内容です。記録するのは、最初の有用な応答までの時間、最終的に使える回答までの時間、Fast mode の on/off、追加承認の有無、入口ごとの差分です。IDE だけに別の確認が必要なら、その待ち時間もメモに分けます。
環境も同時に残します。Desktop App version、bundled agent version if visible、`codex --version`、IDE extension version、Windows build、WSL distro and mode、project path が Windows filesystem、`/mnt/
CLI と IDE も同じように遅い場合、Desktop App はまだ切り分けられていません。account limits、model/service behavior、巨大すぎる context、長い tests、network trouble、プロンプトが広すぎる可能性を先に見ます。credit、included usage、Fast mode の扱いは OpenAI Codex usage limits を確認し、API key での CLI cost が論点なら Codex CLI token cost estimator で見積もります。
Windows と WSL の境界を分ける
OpenAI の Codex Windows app documentation は、2026年7月8日時点で Windows setup split の事実確認先です。Windows app は native Windows agent でも WSL2 agent mode でも動きますが、これは同じ経路ではありません。filesystem semantics、shell tools、home directory、sandbox behavior、Git visibility が変わる可能性があります。
| 設定の事実 | 遅さに関係する理由 | 安全な確認 |
|---|---|---|
| Native Windows agent | Windows 側の path と sandbox semantics で動く | Windows agent が素直に読める project path を使う。 |
| WSL2 agent mode | agent environment が WSL 側へ移る | Settings で明示的に切り替え、再起動後に測る。 |
| 現行 docs では WSL1 非対応 | 古い前提で誤った期待を持ちやすい | まず WSL2 を確認する。 |
| Windows path、`/mnt`、`\wsl$` | Git visibility や path translation が変わる | 疑わしい path を基準測定にしない。 |
| `CODEX_HOME` の分離 | app と WSL CLI が別の config home を読む場合がある | 意図が分かる時だけ同期または上書きする。 |
結論は「WSL が悪い」でも「native Windows が常に良い」でもありません。Windows app、WSL agent、WSL 内の CLI、IDE extension は、同じ Codex でも実行面が違います。一度に一つだけ変数を変え、native app 対 CLI、WSL agent 対 WSL CLI、きれいな path に置いた copy という順に比べると、判断に使える差分になります。
作業の持ち主で入口を選ぶ
Codex CLI と Desktop App は単純な上下関係ではありません。OpenAI の CLI features documentation は terminal-first workflows、interactive TUI、resume、`codex exec`、review、scripting、shell completions、web search、prompt editing を扱います。OpenAI の app features documentation は worktrees、automations、Git review、integrated terminal、in-app browser、Computer Use、artifacts、IDE sync、project/thread supervision を扱います。
| 入口 | Desktop App が遅い時に先に任せる仕事 | 誤用しないこと |
|---|---|---|
| Codex CLI | terminal-native repo edits、scripts、SSH/container work、速い local comparison | Desktop App が不要という証明 |
| IDE extension | editor-adjacent coding、quick patch review、現在の local development | 長期 supervision の代替 |
| Desktop App Local | thread management、artifacts、Git review、browser、Computer Use、UI workflows | 全ての repo edit の唯一の入口 |
| Desktop App Worktree | 並行した isolated changes と reviewable branches | slow local app path の修理 |
| Cloud/Web | local host state が不要な long-running work | Windows filesystem overhead の診断 |
| Computer Use | GUI や browser を視覚的に操作する task | terminal work の一般的な高速化策 |
| 報告ルート | 同じプロンプトで app-only slowdown が再現する場合 | private logs や推測を貼る場所 |
browser 操作、visual review、long-running supervision が主役なら Desktop App の価値は残ります。逆に「この WSL repository の files を今直す」が仕事なら、CLI または IDE に移したほうが安全なことがあります。GUI-specific tasks については Codex Computer Use guide、host execution と remote supervision の境界は Codex mobile app guide が参考になります。
Fast mode は速度のレバーであり診断結果ではない
OpenAI の Codex Speed documentation では、Fast mode は対応モデルの速度を上げる一方で credit use が増える選択肢です。model response time がボトルネックなら効果があります。しかし local app overhead、WSL path translation、watcher behavior、extension bridge、local logs などが消えたとは言えません。
| 測定結果 | Fast mode から分かること | 分からないこと |
|---|---|---|
| Desktop、CLI、IDE が全て速くなる | model response time が関係している可能性 | Desktop App path が健康かどうか |
| CLI は速くなるが Desktop は遅い | model speed は改善し、app path は残る | credit を増やせば local overhead が直ること |
| Desktop は最初の有用応答前に遅く、CLI は速い | local surface overhead が疑わしい | exact root cause |
| huge context や long tests がある | task complexity が支配的かもしれない | Windows/WSL が原因だという証明 |
Fast mode を最初の診断にしないでください。baseline を取り、次に Fast mode を一つの変数として測ります。速くなったとしても、それは model response が効いたのか、local app path が残っているのかを timing で分けて読む必要があります。
報告前に最小パケットを作る
OpenAI の Codex troubleshooting documentation は、app と CLI が同じ underlying agent と configuration を使いながら、version や experimental behavior が違う場合があると説明しています。だから有効な報告には「遅い」だけでなく、surface detail が必要です。
| 項目 | 入れるもの | 取り除くもの |
|---|---|---|
| Versions | Desktop app version、bundled agent version、`codex --version`、IDE extension version | account identifiers、private workspace names |
| Environment | Windows build、WSL distro and mode、project path type、repo size signal | customer names、不要な private paths |
| Prompt | delay を再現する最小 prompt | secrets、proprietary code、private URLs |
| Timings | Desktop、CLI、IDE、optional Cloud の同一 prompt timing | 比較に無関係な chat history |
| Fast mode | on/off state と結果の変化 | support が求めていない credit screenshots |
| Logs and sessions | app logs、session references、terminal output references | tokens、API keys、passwords、customer data |
強い報告は単純です。同じ repository と prompt で Desktop App on Windows/WSL が 70 秒、CLI が 8 秒、version と path details があり、logs は redacted。弱い報告は一回の slow session からすぐ「Codex が壊れている」と結論し、surface isolation がありません。
試すなら戻せる手順だけにする
最初の benchmark 後は、一度に一つだけ変更し、変更前後の timing を残します。戻せる手順は data と evidence を守り、あとから説明できます。戻せない大掃除は、偶然直っても何が原因だったか分かりません。
| 手順 | 効く可能性がある理由 | 安全な形 |
|---|---|---|
| Desktop App を再起動 | transient UI または agent state を消す | 前後の timing を記録する。 |
| Windows native と WSL agent mode を確認 | agent path が filesystem と tools を変える | 意図的に切り替え、restart する。 |
| repository copy を clean path に置く | path translation や Git visibility の影響を見る | copy または disposable branch で試す。 |
| tiny repo と real repo を比較 | surface overhead と repo complexity を分ける | toy repo だけで結論しない。 |
| CLI と app version を別々に確認 | version drift が差を作る場合がある | 報告前に両方を残す。 |
| 状態削除ではなく rename | rollback を残す | 証拠を最初に消さない。 |
意味を理解していない cleanup command を貼り付けて実行しないでください。state directories、skills、plugins、sessions、credentials に触れる可能性があります。状態仮説を試すなら、削除ではなく rename から始めます。
よくある質問
Windows では Codex CLI のほうが必ず速いですか？
必ずではありません。terminal-native repo work では CLI が速いことがありますが、Desktop App、WSL bridge、path translation、GUI overhead が遅い時に限った判断です。同じ repository と同じ prompt で測ってください。
CLI が速いなら Desktop App は不要ですか？
不要ではありません。active coding は CLI や IDE に移せますが、Desktop App は worktrees、long-running threads、Git review、browser tasks、Computer Use、artifacts、supervision に向きます。
Fast mode で Codex app の遅さは直りますか？
Fast mode は supported model responses を速くできますが、Windows、WSL、filesystem、UI、local agent overhead を直した証拠にはなりません。baseline の後で使います。
WSL で最も大事な記録は何ですか？
app が Windows-native agent か WSL2 agent mode か、project がどこにあるか、app と CLI がどの config home を読むか、`CODEX_HOME` を設定したかです。
Codex の cache を消すべきですか？
最初の手順ではありません。restart、benchmark、versions、reversible path/mode checks を先に行います。state cleanup を試すなら rename または backup を使います。
有効な slow report には何を入れますか？
Desktop app version、bundled agent version if visible、`codex --version`、Windows build、WSL distro and mode、project path、Desktop と CLI または IDE の same-prompt timings、Fast mode state、redacted logs、session references を入れます。tokens、API keys、customer data、未確認の root cause は入れません。