Windows で Codex が "failed to start codex app-server" になる: 原因と対処 (2026)

Windows での “failed to start codex app-server”: 30秒の診断

Windows で Codex Desktop を起動した。ウィンドウが開くか、トレイアイコンが現れ、そして次が出る。

failed to start codex app-server: The system cannot find the path specified. (os error 3)

ローカライズ版でも同じ内容が各言語で表示されます。ドイツ語ユーザーには Das System kann den angegebenen Pfad nicht finden. (os error 3) と出ます。不変なのは os error 3 というコードで、これは Windows の ERROR_PATH_NOT_FOUND です。

次の3つのチェックを順に実行してください。最初に異常が返ってきたものが対処を指し示します。

# 1. 実際にインストールされている Codex パッケージは?
Get-AppxPackage *Codex* | Select-Object Name, Version, InstallLocation

# 2. プロファイルパスに非 ASCII 文字が含まれるか?
echo $env:USERPROFILE

# 3. PATH 上に Codex が複数バージョン存在するか?
$env:PATH -split ';' | Select-String 'Codex'

最も時間を節約する一つの事実: Codex CLI と Codex Desktop は別プログラムです。 素のターミナルで codex --version が動くのに Desktop アプリが app-server エラーを吐くなら、アカウントもキーも Codex インストールも問題ありません。踏んでいるのは Desktop シェルのバグで、修正されるまで CLI から出荷を続けられます。その逃げ道は本記事の最終セクションです。

以下の各対処は、2026-07-16 時点で openai/codex トラッカーにある実在のオープン issue に紐づいています。捏造したバージョン番号はありません。

app-server とは実際に何か（そしてなぜ os error 3 が起きるか）

Codex Desktop は Electron アプリです。目に見えるウィンドウは薄い UI シェルにすぎません。実際の処理は app-server という別の子プロセスで行われます。モデルとのやり取り、Browser Use の実行、タスクの遂行です。シェルは起動時に app-server を spawn し、ローカルソケット経由で通信します。

os error 3 は、シェルがその子プロセスを spawn しようとした瞬間に、実行するよう指示された実行ファイルへのパスを Windows が見つけられなかったときに発生します。これが何で ない かに注意してください。ネットワークエラーでも、認証エラーでも、レート制限でもありません。失敗はどのリクエストもマシンを出る前に起きます。シェルはパス文字列を持っていて、その文字列がファイルに解決されず、Windows が ERROR_PATH_NOT_FOUND を返し、シェルがそれを failed to start codex app-server として表面化させます。

Codex Desktop (Electron UI shell)
        │
        │  spawn( <path-to-app-server> )   ← path resolved at install/launch
        ▼
   ┌─────────────────────────┐
   │  path is valid  ────────►│  app-server runs, chat + Browser Use work
   │                          │
   │  path is stale/wrong ───►│  os error 3  →  "failed to start codex app-server"
   └─────────────────────────┘

つまり以下の各原因は、一つのテーマのバリエーションです。シェルが解決したパスが間違っている。 古いパッケージ版がまだ PATH にあるから、プロファイルパスの非 ASCII 文字が解決を壊したから、Store サンドボックスがシェルに同梱バイナリの実行を許さないから、あるいはシェルが期待する場所にバイナリがないから。症状は同じ、根は4種類です。

いつ直し、いつ CLI に切り替えるか

Desktop アプリに1時間費やす前に、その価値があるか判断してください。

Desktop アプリを直すべきとき

• Browser Use など、Desktop アプリだけが公開するアプリ内機能が具体的に必要なとき。
• チームが Desktop アプリで標準化していて、足並みをそろえたいとき。
• エラーがアップデート後に出て、PATH 残留のリグレッションを疑うとき（対処1は2分のチェックです）。

代わりに CLI に切り替えるべきとき

• Codex を主にターミナルやエディタでのコーディングに使うとき。そのワークフローにおいて CLI は app-server がやることをすべてこなし、Electron シェルにはまったく依存しません。
• Windows ユーザー名に非 ASCII 文字が含まれていて、新しいユーザーアカウントを作るより CLI を使うほうが手間が少ないとき。
• Store パッケージの権限を変更できないロックダウンされたマシン上にいるとき。

打ち切りルール

対処1から対処4まで実行しても app-server が立ち上がらないなら、アプリのデバッグをやめてください。CLI をインストールし（npm i -g @openai/codex）、codex --version がバージョンを表示することを確認して、そこから作業してください。Desktop アプリは Codex を使うための前提条件ではありません。4つの対処を超えてオープンな Electron バグを追いかけるのは、午後を浪費する使い方です。

os error 3 クラスター: 2026-07-16 時点のオープン issue

実際に報告されている内容のマップを示します。自分の正確なエラー文言を根本原因と対処に対応づけられます。以下の issue はすべて OPEN です。

自分のエラー文言がこれらのどれとも正確に一致しないなら、最も近いものを読み、その対処を起点として扱ってください。os error 3 の文字列そのものは #20206 と #20048、“Unable to locate the Codex CLI binary” の文言は #28392 と #28031、起動後のクラッシュ（code=1）とプラグイン WARN は #26440 です。

対処1: 古いパッケージ版を指す PATH の残留

これが最も一般的な原因で、確認も最速です。Codex のアップデートはバージョン刻印されたフォルダ名を持つ新しい Windows Store パッケージとして配布されます。例えば OpenAI.Codex_26.422.8496.0_x64__2p2nqsd0c76g0 です。古いパッケージ版がまだ PATH で参照されていると、シェルは目的のファイルをもう含まないフォルダに対して app-server のパスを解決してしまいます。

#20206 では報告者がまさにこれを指摘しています。再起動後、PATH は現行のパッケージ版だけを指していましたが、再起動前には古いパッケージ版も PATH にあったのです。それを片付けるのが最初のステップです。

# インストール済みの Codex パッケージをすべて一覧
Get-AppxPackage *Codex* | Select-Object Name, Version, PackageFullName

# PATH 上の残留 WindowsApps エントリを探す
$env:PATH -split ';' | Select-String 'OpenAI.Codex'

異なるバージョン文字列が2つ以上見えたら、古いものを削除します。

# Store パッケージを完全に削除してから、クリーンなコピーを1つだけ再インストール
Get-AppxPackage OpenAI.Codex | Remove-AppxPackage

単一のソース（Store、あるいはより望ましくは対処4で扱う npm/公式インストーラー）から再インストールします。再インストール後は 新しい ターミナルを開き（PATH の変更は既に開いているシェルには決して反映されません）、Codex Desktop を再起動します。

ここでは再起動だけでは対処になりません。メモリ上の古い PATH は消えますが、パスが間違っている根本理由が構造的（対処2、3、4）なら、エラーはすぐに再発します。#20206 がその証拠です。完全な Desktop 再起動でも解決しませんでした。

対処2: Windows プロファイルパスの非 ASCII 文字

Codex はプロファイルディレクトリ配下で状態を読み書きします: C:\Users\<you>\.codex\...。<you> に非 ASCII 文字（å ö ø のような北欧文字、ドイツ語ウムラウト、アクセント付きラテン文字、CJK）が含まれると、パス解決が os error 3 として表面化する形で失敗することがあります。これは ASCII パスを前提とする Windows ツールの長年の失敗モードで、Codex の app-server spawn もその例外ではありません。

まず確認します。

echo $env:USERPROFILE
# C:\Users\Håkon\...   ← the å is the problem

プロファイルパスがクリーンな ASCII なら、これは原因ではありません。対処3へ飛んでください。非 ASCII 文字を含むなら、最もきれいな切り分けは ASCII のみの名前で新しいローカルユーザーを作ることです。

Settings → Accounts → Other users → Add account
→ create a local account with an ASCII-only username (e.g. "dev")
→ sign in as that user
→ install and run Codex there

ASCII ユーザーで Codex Desktop がきれいに起動するなら、原因が確定です。そこから持続的な選択肢は2つ。Codex 専用の ASCII プロファイルを維持するか、Desktop アプリをやめて CLI を使うかです。CLI はユーザー名に関係なく任意の作業ディレクトリに向けられます。既存の Windows ユーザーのプロファイルフォルダ名を変更するのはリスクが高く割に合いません。代わりに新しいアカウントを作ってください。

対処3: Microsoft Store サンドボックスが同梱 codex.exe をブロック

Store パッケージのアプリは C:\Program Files\WindowsApps\ 配下にインストールされます。ここはほとんどのプロセスにとって読み取り専用でアクセス制限のかかったディレクトリです。#28031 では、同梱 codex.exe はパッケージ内に存在するものの、OS がアクセスを拒否するため実行できず、app-server が起動しません。報告者はアプリのリセット、アンインストール/再インストール、CODEX_CLI_PATH のクリアを試しましたが、失敗は続きました。

手元の状態を確認します。

# パッケージはどこに落ちたか、そこにバイナリはあるか?
$pkg = (Get-AppxPackage *Codex*).InstallLocation
Get-ChildItem $pkg -Recurse -ErrorAction SilentlyContinue |
  Where-Object { $_.Name -match 'codex' } |
  Select-Object FullName, Length

バイナリが WindowsApps 配下に存在するのにアプリがまだ access-denied 系のエラーで失敗するなら、サンドボックスと戦わないでください。確実な道は、Store 同梱バイナリへの依存を完全にやめることです。

# 1. Store パッケージを削除
Get-AppxPackage OpenAI.Codex | Remove-AppxPackage

# 2. サンドボックスの外、通常のユーザー書き込み可能な場所に CLI をインストール
npm i -g @openai/codex

# 3. 動作確認
codex --version

これで codex バイナリは、Store サンドボックス内ではなく npm のグローバル prefix 配下（通常の実行可能な場所）に置かれます。それでも Desktop アプリが欲しいなら、CODEX_CLI_PATH でこのバイナリを指してください（対処4を参照）。不要なら CLI をそのまま使ってください。

対処4: “Unable to locate the Codex CLI binary”（バイナリの欠落または誤配置）

Electron シェルは Codex CLI を自身のリソース内の bin/codex、または CODEX_CLI_PATH 環境変数が指すパスで見つけることを期待します。どちらも満たされないと、#28392 と #28031 の明示的なメッセージが出ます。

Codex failed to start.

Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or
ensure the Electron resources include bin/codex.

関連レポート（#25671、#25886）は同種の失敗を別の文言で示します: “Codex app-server is not available”、“Unable to find Electron app at …”、あるいは code=4294967295 でクローズする websocket です。いずれもシェルが動作する app-server バイナリに到達できないケースです。

対処はシェルに見つけられるバイナリを与えることです。通常の実行可能な場所に落ちるソースから CLI をインストールします。

# オプション A: npm（推奨；PATH に Node 16+ が必要）
npm i -g @openai/codex
where.exe codex          # 解決されたパスをメモ、例 C:\Users\you\AppData\Roaming\npm\codex

# オプション B: winget
winget upgrade OpenAI.Codex
# または、まだ未インストールなら:
winget install OpenAI.Codex

次に CODEX_CLI_PATH を解決済みパスに設定して、Codex Desktop をそのバイナリに向けます。

# where.exe が上で表示したパスを使う
[Environment]::SetEnvironmentVariable(
  "CODEX_CLI_PATH",
  "$env:APPDATA\npm\codex.cmd",
  "User"
)

新しい User スコープの変数を拾わせるため、すべてのターミナルを閉じてアプリを再起動します。CODEX_CLI_PATH を設定しても app-server が立ち上がらないなら（複数の報告者が経験しています）、あなたのマシンではアプリにより深い解決バグがあり、フォールバックセクションの CLI 直接ルートが答えです。

対処5: キャッシュされたプラグインマニフェストが app-server をクラッシュさせる

別の失敗形態: アプリは 起動する が、数秒後に app-server が終了する。#26440 では、キャッシュされたプラグインマニフェストの読み込み中に app-server が code=1 でクラッシュします。ログには、あるプラグインの interface.defaultPrompt[0] が Codex の128文字上限を超えたという WARN が出て（問題のキャッシュ済みマニフェストは約313文字の文字列を持っていた）、app-server が予期せず終了します。これは Codex Desktop と VS Code 上の Codex の両方で起き、チャットがアイドルでも発火し得ます。報告者が踏んだプラグインは config.toml で有効化すらされていませんでした。

エラーが起動時のクリーンな os error 3 ではなく code=1 の起動後クラッシュなら、プラグインキャッシュをクリアします。

# バックアップしてから、プロファイル配下のキャッシュされたプラグインツリーを削除
Move-Item "$env:USERPROFILE\.codex\.tmp\plugins" `
          "$env:USERPROFILE\.codex\.tmp\plugins.bak" -ErrorAction SilentlyContinue

Codex を再起動します。プラグインキャッシュがゼロから再生成されます。特定のプラグインのマニフェストが128文字上限を超えさせる要因なら、そのプラグインを config から外しておけばキャッシュへの再取り込みを防げます。これは上記のパスエラーとは別個の根本原因です。code=1 のプラグインクラッシュに対して対処1から対処4を実行しないでください。それらは触れません。

Windows Codex Desktop でよくある失敗パターン

クラスターをまとめると、繰り返し起きるものとその形の違いは次のとおりです。見えている正確な文字列に合わせてください。

パターンから2つの教訓。第一に、「app-server が起動しない」は単一のバグではありません。少なくとも4つ（パス、サンドボックス、バイナリ欠落、プラグインクラッシュ）あり、それぞれ独自の issue を持ちます。第二に、Store パッケージがクラスター全体で過剰に多く現れます。Microsoft Store からインストールして詰まっているなら、npm または公式インストーラーの CLI に移ることで、これらのカテゴリー全体を一度に取り除けます。

何かを変える前にログを読む

エラーダイアログは1行しか教えてくれません。ログは Codex が実際に spawn しようとしたパスを教えてくれます。それが上記のどの原因なのかを示す肝です。ここで2分使えば、間違った根本原因の対処を走らせずに済みます。

Codex はプロファイル配下に状態とログを書きます。そこから始めます。

# Codex の状態ディレクトリを確認
Get-ChildItem "$env:USERPROFILE\.codex" -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 20

最も新しく書かれたファイルを先に見ます。たった今引き起こした失敗が一番上にあります。os error 3 メッセージのログが具体的なパスを名指ししているなら、実際にインストールされているものと比較します。

# アプリが app-server の在り処だと思っているパス vs. ディスク上の実体は?
Get-AppxPackage *Codex* | Select-Object Name, Version, InstallLocation
Test-Path "C:\Program Files\WindowsApps\OpenAI.Codex_*\app\resources\codex.exe"

Test-Path が False を返すなら、シェルが探しているバイナリは実際にそこにありません（対処4）。True を返すのにアプリがまだ access-denied 系で失敗するなら、ファイルは存在しサンドボックスが実行をブロックしています（対処3）。パッケージが2バージョン現れるなら PATH 残留のケースです（対処1）。この1つのチェックが5原因のうち3つを切り分けます。

起動後クラッシュのケースでは、有用なシグナルはダイアログではなく CLI のログ行です。#26440 では、code=1 終了の直前に、ログが正確なプラグインマニフェストのパスと理由（prompt must be at most 128 characters）を出力していました。状態ディレクトリを WARN で grep します。

# app-server をクラッシュさせているプラグインマニフェストを見つける
Select-String -Path "$env:USERPROFILE\.codex\*.log" -Pattern "defaultPrompt|exited unexpectedly|os error 3" -ErrorAction SilentlyContinue

経験則: 起動時の os error 3 はパスの問題、ウィンドウ描画の数秒後の code=1 終了はプラグイン/マニフェストの問題、websocket-closed メッセージは app-server が UI に引き継ぐ前に死んでいる状態です。ログ行をクラスター表に合わせ、その根本原因の対処だけを実行してください。

これが判断フローを1枚にしたものです。ログやダイアログが実際に示すもので上から始めてください。

 app-server error
        │
        ├─ "os error 3" at startup ──────────┐
        │                                     │
        │   two package versions on PATH? ──► Fix 1 (remove stale version)
        │   non-ASCII in $env:USERPROFILE? ─► Fix 2 (ASCII profile)
        │
        ├─ "Unable to locate the CLI binary"
        │        │
        │        ├─ binary present but blocked ► Fix 3 (Store sandbox)
        │        └─ binary absent ────────────► Fix 4 (install + CODEX_CLI_PATH)
        │
        ├─ "code=1" + defaultPrompt WARN ────► Fix 5 (clear plugin cache)
        │
        └─ none apply, `codex --version` works ► Fallback (use the CLI)

すべての経路を締めくくる唯一の分岐: ターミナルで codex --version が動くなら、Desktop アプリの状態に関係なく動作する Codex を持っています。だからフォールバックは慰めの賞ではありません。しばしば5つの対処のどれよりも速いのです。

VS Code の Codex でも同じエラーが出る

VS Code の Codex 拡張は Desktop アプリと同じ app-server を起動するので、同一の失敗がそこでも現れます。#26440 のプラグインクラッシュは両方で再現します。拡張が app-server エラーを吐くのにターミナルの codex が健全なら、対処は同じです。拡張は Desktop クラスのバグを踏んでいるので、統合ターミナルで codex を直接実行すればそれを回避できます。違う結果を期待して拡張を再インストールしないでください。app-server のコードは共有されています。

Desktop アプリが起動しないとき: CLI から作業を続ける

対処を一巡しても Desktop アプリがまだ拒否するなら、やめてください。それは要りません。Codex CLI は Electron シェルにもその app-server にも依存しないスタンドアロンのプログラムで、ネイティブ Windows で動きます。

無料/個人: CLI を直接実行

一度インストールすれば、任意のターミナルで実行できます。

# PATH に Node 16+ が必要
npm i -g @openai/codex
codex --version
codex

codex --version がバージョンを表示し、codex が対話セッションを開くなら、コーディング作業に必要な Codex の全機能が手に入っています。app-server も Electron も、上記の Windows Desktop の失敗モードもありません。これは #20048 の状況、つまり npm CLI は動くのに Desktop アプリが os error 3 を吐くケースへの答えです。CLI を使い、Desktop のバグを起票/追跡して、先へ進んでください。

有料/チーム: クリーンなインストールを1つ固定し Store を避ける

チームは Store パッケージで繰り返し噛まれます。どのマシンもサンドボックスと古いバージョンの問題に個別に当たるからです。npm CLI を固定バージョンで標準化し、すべての開発者と CI ランナーを同一にしてください。

# すべての開発マシンと CI ランナーで
npm i -g @openai/codex
codex --version   # どこでも同じバージョンであることを確認

固定は、Store のマシン単位パッケージングが生む「自分のマシンでは動く」ばらつきを取り除きます。それでも Desktop UI を欲しい人は、同梱バイナリに頼るのではなく CODEX_CLI_PATH でこの CLI を指せます（対処4）。

どのプランでも: CLI を OpenAI 互換プロバイダー経由でルーティング

Codex を開く理由がコーディング作業を終わらせることで、リクエストが OpenAI に直接行くかどうかを気にしないなら、ゲートウェイ経由で Codex CLI を OpenAI 互換エンドポイントに向けられます。これは「Codex を実行できるか」を「Desktop アプリが健全か」から完全に切り離します。CLI はゲートウェイと話し、ゲートウェイは設定したモデルと話します。

Ofox は Codex CLI が受け付ける単一の https://api.ofox.ai/v1 ベース URL を提供します。Windows で Desktop アプリが落ちているとき、CLI を一度設定すれば選んだモデルに対して出荷を続けられます。

# ~/.codex/config.toml  (on Windows: C:\Users\<you>\.codex\config.toml)
model_provider = "ofox-codex"

[model_providers.ofox-codex]
name = "Ofox"
base_url = "https://api.ofox.ai/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"

Codex には wire_api = "responses" が必要です。 現行の Codex は古い wire_api = "chat" の値を削除しました。渡すとリクエストが出る前に config 読み込み時点で失敗します。/v1/chat/completions しか実装しないゲートウェイは動かないので、ゲートウェイが Responses API 対応を明記していることを確認し、頼る前に本物のキーでテストしてください。

周辺の CLI 問題を直接カバーする姉妹記事が2本あります。CLI 自体が PATH で解決されないなら、まず codex: command not found の対処 から始めてください。CLI は動くのに Desktop アプリがカスタムモデルを隠すなら、Codex Desktop がカスタムモデルを表示しない を参照してください。

app-server バグの状況を追う方法

このクラスターは動いています。新しい Codex バージョンはおよそ週次で配布され、修正は一括ではなく issue 単位で入ります。アップデートで自分のケースが直ると決めつける前に、エラー文言に一致する具体的な issue を確認してください。

クラスター全体ではなく、自分のエラー文字列に一致する正確な issue をウォッチしてください。os error 3 には #20206 と #20048、バイナリ欠落の文言には #28392 と #28031、プラグインクラッシュには #26440 を使います。アップデート前に 公式 Codex changelog を読んでください。当てずっぽうでアップデートしてランダムなリリースが助けてくれることを願うのではなく、ノート内の issue 番号や “app-server” の語を探してください。そして CLI をベースラインとして維持してください。Desktop の app-server に依存しないので、ターミナルで codex --version が動くなら、壊れた Desktop アプリは不便であってブロッカーではありません。

これを codex-diag.ps1 として保存し、app-server エラーが再発するたびに実行してください。上記の対処が判断材料にするすべてのシグナルを一括で収集します。

# codex-diag.ps1 : collect the signals the app-server fixes depend on
Write-Host "== Installed packages =="
Get-AppxPackage *Codex* | Select-Object Name, Version, InstallLocation

Write-Host "== Profile path (non-ASCII breaks path resolution) =="
$env:USERPROFILE

Write-Host "== Stale versions on PATH =="
$env:PATH -split ';' | Select-String 'OpenAI.Codex'

Write-Host "== CLI on PATH? (your fallback) =="
where.exe codex 2>$null; codex --version 2>$null

Write-Host "== Recent errors in the state dir =="
Select-String -Path "$env:USERPROFILE\.codex\*.log" `
  -Pattern "os error 3|exited unexpectedly|defaultPrompt|websocket closed" `
  -ErrorAction SilentlyContinue | Select-Object -Last 10

出力は推測なしにどの対処が当てはまるかを教えてくれます。パッケージ2バージョンなら対処1、非 ASCII プロファイルなら対処2、存在するがブロックされたバイナリなら対処3、欠落バイナリなら対処4、defaultPrompt WARN なら対処5です。一番下に動作する codex --version があれば、デバッグをやめて今すぐ CLI に切り替えられます。

FAQ

frontmatter の faq ブロックに正典の回答があります。os error 3 の意味、“Unable to locate the Codex CLI binary” の文言、再起動で直るか、非 ASCII ユーザー名の罠、Desktop アプリなしで作業を続けられるか、バグはもう直ったか、PATH から古いパッケージ版を消す方法をカバーしています。

参考情報源

• openai/codex#20206
• openai/codex#20048
• openai/codex#25671
• openai/codex#25886
• openai/codex#26440
• openai/codex#28031
• openai/codex#28392
• Codex CLI changelog
• ofox docs: Codex integration
• codex: command not found, 7 fixes
• Codex Desktop Not Showing Custom Models

---