Codex WindowsサンドボックスのセットアップがUACで止まる時elevatedとunelevatedを公式ドキュメントで切り分ける

Codex（ChatGPT desktop appのエージェント機能、またはCodex CLI）をWindowsで動かそうとして、サンドボックスのセットアップだけが通らないという相談は、日本語ではまだほとんど情報が出ていない。結論から言うと、OpenAI公式ドキュメント（developers.openai.com/codex、2026年8月27日に原文確認）は、Windowsネイティブのサンドボックスにはelevatedとunelevatedという2つのモードがあり、elevatedのセットアップは管理者承認の拒否・ローカルユーザー作成の禁止・ファイアウォール変更の禁止・ログオン権限のブロック・その他の企業ポリシーという5つの原因のいずれかで失敗すると明記している。一方で、検索されている「spawn setup refresh」や「setup.exe not found」という具体的なエラー文言そのものは、今回確認した公式ページのどこにも見当たらなかった。以下、原文と一緒に整理する。なお、本記事が扱うのはサンドボックスのセットアップが通らない症状だ。2026年8月下旬のアプリ更新後に「Unable to locate the Codex CLI binary」というエラーでアプリ自体が起動しなくなった、というGitHub上の報告は別の記事にまとめている（Codex Windows Desktopが更新直後に一斉起動不能に）。

3行まとめ

1. Windows版CodexのネイティブサンドボックスはPowerShell上で動き、elevated（専用の低権限サンドボックスユーザー・ファイアウォール規則・ローカルポリシー変更を伴う推奨モード）とunelevated（現在のユーザーから派生した制限トークンとACLで代替する後方互換モード）の2種類がある（2026年8月27日確認）
2. elevatedのセットアップ失敗の原因として公式が挙げるのは、UAC/管理者プロンプトの拒否・ローカルユーザーやグループ作成の禁止・ファイアウォール変更の禁止・サンドボックスユーザーに必要なログオン権限のブロック・その他の企業ポリシーによる妨害、の5パターン。これは主に企業管理端末で起きる
3. 「spawn setup refresh」「setup.exe not found」という文字列は、Windows sandbox・ChatGPT desktop app・WSL・Sandbox・Windows展開の各公式ページに記載を見つけられなかった。公式が扱っているのはエラー1385、「Everyoneに書き込み可能」警告、ネットワーク到達不可、以前は動いていたのに止まった、の4系統

Windowsネイティブサンドボックスの位置づけ

Codexは長らく「WSL2で動かす」か「仮想マシンを使う」かの二択だったが、公式ドキュメントは今のChatGPT desktop appについてこう説明している。

"The app can run natively in PowerShell with a Windows sandbox instead of requiring WSL or a virtual machine. This keeps Codex in Windows-native workflows while enforcing bounded filesystem and network permissions."

つまりネイティブサンドボックスは、WSLを経由せずにPowerShellのまま「ファイルシステム書き込みの範囲」と「ネットワークアクセスの可否」を制限する仕組みだ。モードはconfig.tomlで切り替える。

[windows]
sandbox = "elevated" # or "unelevated"

• elevated（推奨）: 「専用の低権限サンドボックスユーザー、ファイルシステムの権限境界、ファイアウォール規則、サンドボックス内で実行するコマンドに必要なローカルポリシー変更」を使う、と公式は書いている。
• unelevated（フォールバック）: 「現在のユーザーから派生した制限付きWindowsトークンでコマンドを実行し、ACLベースのファイルシステム境界を適用し、専用のオフラインユーザー向けファイアウォール規則の代わりに環境レベルのオフライン制御を使う」もの。公式は「elevatedより弱いが、管理者承認済みのセットアップがローカルまたは企業ポリシーでブロックされている場合には依然として有用」と位置づけている。

両方使える場合はelevatedを使う、というのが公式の推奨で、デフォルトのサンドボックスが動かない場合の一時措置としてunelevatedが用意されている、という順序であって、どちらでも好きな方を選んでいい、という書き方にはなっていない。

企業管理者はrequirements.tomlで使えるモードを縛れる。

[windows]
allowed_sandbox_implementations = ["elevated"]

この設定はelevatedを必須にしてunelevatedへのフォールバックを禁止する。両方許可したい場合は両方の値を並べる（モード未指定時はCodexがelevatedを優先する、と公式は明記）。

また、両モードともデフォルトで「プライベートデスクトップ」によるUI分離を使う。互換性のために従来のWinsta0\Default挙動が必要な場合だけwindows.sandbox_private_desktop = falseにする、と書かれている。

なお、どのフォルダに書き込めてどこへ通信できるかという境界の中身は、elevated/unelevatedの選択とは別に、Permission Profiles（公式ドキュメント上はベータ機能）または従来のsandbox_mode設定で決まる。elevated/unelevatedは、その境界をネイティブWindowsでどう強制するかの違いにあたり、公式はelevatedが最も強く、unelevatedはネットワーク分離が弱いフォールバックだとしている。Permission Profilesの仕組みは別記事で公式原文を確認した（AGENTS.mdだけでは危ない──Codex Permission Profilesの仕組み）。また、サンドボックスの境界を越える操作の承認を、人間の代わりに別のレビュアーエージェントへ回す「Auto-review」という仕組みも公式ドキュメントにある（Codex Auto-reviewの仕組み）。

対応バージョンと前提条件

公式が示すWindowsバージョン別のサポートレベルは次の通り。

追加の前提条件として、公式は次を挙げている。

• wingetが利用可能であること（ない場合はWindowsを更新するかWindows Package Managerを個別インストール）
• 推奨のネイティブサンドボックスは「管理者承認済みのセットアップ」に依存する
• 一部の企業管理端末では、OSバージョン自体は要件を満たしていても、必要なセットアップ手順そのものがブロックされる

この3点目が、個人のPCでは再現しない企業PC特有の失敗の大半を説明している。

elevatedのセットアップが止まる時に公式が挙げる原因

elevatedサンドボックスのセットアップが完了しない場合、公式が挙げる「よくある原因」は次の5つに限定されている。

1. Windows UACまたは管理者プロンプトを拒否した
2. マシンがローカルユーザー・グループの作成を許可していない
3. マシンがファイアウォール規則の変更を許可していない
4. マシンがサンドボックスユーザーに必要なログオン権限をブロックしている
5. （上記以外の）企業ポリシーがセットアップフローの一部をブロックしている

対処として案内されているのは、①UACの管理者プロンプトが出たら承認して再試行、②社給PCでブロックされている場合はIT部門に「ローカルユーザー/グループ作成」「ファイアウォール設定」「サンドボックスユーザーに必要なログオン権限」の管理者承認済みセットアップが許可されているか確認、③それでも失敗する場合はunelevatedに切り替えて作業を継続しながら調査、の3段階。IT部門への確認が前提の設計であり、ユーザー側の設定変更だけで必ず解決するとは書かれていない。

unelevatedに自動的に切り替わった場合、公式は「サンドボックス自体は動く」「ACLベースのファイルシステム境界は適用される」「ただしelevatedにある専用サンドボックスユーザーの境界は無く、ネットワーク分離も弱い」「これは有用なフォールバックだが、企業向けの長期的な推奨構成ではない」としている。長期的な修正はIT部門と一緒にelevatedを通すこと、という立場だ。

エラー1385と「Everyoneに書き込み可能」警告

公式のトラブルシューティングで固有のエラーコードとして名指しされているのは1385だけだった。

サンドボックス化されたコマンドがエラー1385で失敗する場合、Windowsがサンドボックスユーザーに必要なログオンタイプを拒否している。実際にはCodexはサンドボックスユーザーの作成には成功しているが、Windowsポリシーがそのユーザーによるサンドボックス化コマンドの起動をまだ妨げている、という意味であることが多い。

対処は、①IT部門にデバイスポリシーがCodex作成のサンドボックスユーザーへ必要なログオン権限を付与しているか確認、②一部端末・チームだけで起きるならグループポリシーやOUの差分を比較、③すぐ作業を続けたいならunelevatedへ一時的に切り替え、④CODEX_HOME/.sandbox/sandbox.logをWindowsバージョンと症状の説明と一緒に送る、の4段階。エラー1385は「ユーザー作成は成功・起動権限だけが拒否された」状態を指すという定義まではあるが、どの設定項目（GPOのどのポリシー名か等）が原因かまでは公式に書かれていない。

もう一つ、「一部のフォルダがEveryoneに書き込み可能」という警告も文書化されている。これはサンドボックスがそのフォルダを完全には保護できないほど権限が緩いという意味で、対処は該当フォルダの確認→必要ならEveryoneの書き込み権限を外す→Codexの再起動またはセットアップの再実行、という順。権限変更のやり方が分からない場合はIT部門に相談するよう案内されている。

sandbox.logの出し方と、送ってはいけないもの

診断情報を送る際、公式は次を明記している。

• 送るもの: CODEX_HOME/.sandbox/sandbox.log、やろうとしていたことの短い説明、elevatedが失敗したかunelevatedが使われたか、アプリに表示されたエラーメッセージ、1385など固有のWindows/PowerShellエラーの有無、Windows 11かWindows 10か
• 送ってはいけないもの: CODEX_HOME/.sandbox-secrets/の中身

.sandbox-secretsというディレクトリ名がある時点で、そこに認証絡みの情報が入りうることは公式側も前提にしている。切り分けのためにログを共有する時は、このディレクトリを誤って一緒に送らないことが重要になる。

なお「以前は動いていたのに突然サンドボックスが止まった」というケースについて、公式は原因候補として「リポジトリやワークスペースの移動」「マシンの権限変更」「Windowsポリシーの変更」「その他システム構成の変更」を挙げ、対処は①再起動→②elevatedの再セットアップ→③直らなければunelevatedへ一時退避→④ログ収集、という同じ4段階に帰着させている。ネットワークに到達できない場合も、まず「そのタスクはネットワーク無効で実行される設計だったか」を確認するよう案内しており、サンドボックスの不具合と設計上の制限を混同しないことを求めている。

WSL2という代替と、WSL1が0.115で切られた話

ネイティブサンドボックスがどうしても通らない場合、公式はWSL2への切り替えを代替手段として案内している。「Linuxネイティブのツールが必要」「ワークフローが既にWSL2上にある」「どちらのネイティブWindowsサンドボックスモードも要件に合わない」場合にWSL2を選ぶ、という書き方だ。

ここで公式が示している構成は2つあり、混同しないよう分けて書く。1つ目は、Windowsネイティブのエージェントをそのまま使い続ける場合の推奨で、プロジェクトはWindowsファイルシステムに置いたまま/mnt/<drive>/...経由でWSL側からアクセスする方が、\\wsl$\経由でWSLファイルシステム上のプロジェクトを直接開くより安定する、というものだ。2つ目は、**エージェント自体をWSL2上で動かす**設定で、ChatGPT desktop appのSettingsでエージェントをWindowsネイティブからWSLへ切り替え、**アプリを再起動する**必要がある(再起動するまで変更は反映されない、と明記)。この2つ目のケースについては、WSL側の公式ドキュメントが逆方向の注意を示している。/mnt/c/...のようなWindowsマウントパス上での作業はWindowsネイティブパスより遅くなりうるため、リポジトリはLinuxのホームディレクトリ（~/code/my-appのような場所）に置く方がI/Oが速く、シンボリックリンクや権限まわりの問題も少ない、という案内だ。つまり「Windowsネイティブのエージェントを使い続けるなら/mnt経由でアクセス」「エージェントをWSL2に切り替えるなら/mntは避けてLinuxホームに置く」という、シナリオによって逆の推奨になっている。

バージョン面での注意点として、WSL1はCodex 0.114まではサポートされていたが、0.115でLinuxサンドボックスの実装がbubblewrapに切り替わったため、WSL1は非サポートになったと明記されている。古い手順書やフォーラムの回答をそのまま試すと、この version 境界のせいで再現しない可能性がある。

「spawn setup refresh」「setup.exe not found」は公式ドキュメントに記載を見つけられなかった

ここまでの内容は、developers.openai.com/codex/windows/windows-sandbox、/codex/windows/windows-app、/codex/windows/wsl、/codex/sandboxing、/codex/enterprise/windows-deployment、/codex/cliの6ページ（いずれも2026年8月27日に.md形式で原文取得）を対象に確認した。この範囲で、検索されている「spawn setup refresh」「setup.exe not found」という具体的な文字列、あるいはそれに相当するエラー名や再現条件は見つけられなかった。

公式が扱っている固有の失敗パターンは、①UAC/管理者プロンプトの拒否、②ローカルユーザー・グループ作成の禁止、③ファイアウォール変更の禁止、④サンドボックスユーザーのログオン権限ブロック、⑤エラー1385、⑥Everyone書き込み可能警告、⑦ネットワーク到達不可、⑧移行後の突然の停止、⑨IDE拡張がC++ビルドツール不足で無反応、の9系統に限られる。「setup.exe」という実行ファイル名自体、今回確認したページのどこにも登場しない（インストーラーはWindows版CLIがinstall.ps1、ChatGPT desktop appがMSIXパッケージで、いずれも.exeという名前の成果物ではない）。

したがって、もし「spawn setup refresh」や「setup.exe not found」に遭遇した場合、それが上記9系統のどれかの派生表現なのか、それとも公式ドキュメントにまだ反映されていない未文書化の不具合なのかは、今回のドキュメント調査だけでは判断できない。公式が案内している唯一の確実な切り分け手順は、CODEX_HOME/.sandbox/sandbox.logを確認し、.sandbox-secretsを含めずにWindowsバージョンとエラーメッセージの実物を添えて報告する、というものになる。推測でこれ以上の原因を断定することは避ける。

サンドボックス以外も含めたCodexの入口・プラン・既知の不具合の全体像は、当サイトの別記事にまとめている（Codexの使い方【2026年9月版】）。

Windows・WSL・サンドボックス関連の公式ドキュメント6本

• Windows sandbox — OpenAI Codex公式ドキュメント
• ChatGPT desktop app for Windows — OpenAI Codex公式ドキュメント
• WSL — OpenAI Codex公式ドキュメント
• Sandbox — OpenAI Codex公式ドキュメント
• Deploy the Windows app — OpenAI Codex公式ドキュメント
• Codex CLI — OpenAI Codex公式ドキュメント