Windows版Codexで、シェルのコマンドもファイルの読み込みもNode REPLも実行前に失敗し、setup refresh had errorsと出るようになったら、まず%USERPROFILE%\.codex\.sandbox\にある当日のサンドボックスログを開いてください。node_repl.exeかVCRUNTIME140_1.dllについて(os error 32)が記録されていれば、原因はプロジェクトや権限の設定ではなく、Codexのサンドボックスを準備するヘルパーの不具合です。2026年10月7日以降のアップデートで入り込み、PR #51822で修正されました。
直し方は、手元のCodexの各コンポーネントを修正済みのビルドにそろえ、動いているCodexのプロセスをすべて終了してから起動し直すことです。2026年10月22日時点の目安は次のとおりです。
- npm版・単体のCodex CLI：0.163.0以上（2026年10月15日公開）。0.161.0、0.162.0、0.162.1は未修正です。
- Codexデスクトップアプリ（ChatGPTデスクトップアプリ内のCodexを含む）：26.1007.21434（build 13901）以降。OpenAIは修正の入った最初のビルドを公表しておらず、この番号は「更新したら直った」という複数の利用者の報告によるものです。
config.tomlの[windows] sandbox = "elevated"は変えなくて構いません。フルアクセスの常用、Defenderなどの保護の無効化、ACLや所有者の変更は、サンドボックスの守りを弱めるだけでこの不具合の修正にはならないので勧めません。
「セットアップが完了しない」・setup refresh had errorsの症状
この不具合では、Codexが何かを実行しようとするたびに、サンドボックスの準備（setup refresh）の段階で止まります。GitHubの#51601や#52328に寄せられた報告では、次の表示がそろって出ています。
- シェルのコマンドが始まる前に
helper_unknown_error: setup refresh had errorsで失敗する。CLIやアプリではFailed to create unified exec process: …やexec-server rejected request (-32603): …の後ろに続く形でも出ます。 - Node REPL、Computer Use、ブラウザー操作は
windows sandbox failed: helper_unknown_error: setup refresh had errorsのあと、trusted Node process exited unexpectedlyやnode_repl kernel exited unexpectedlyで終わる。 - アプリに「Windows setup didn't finish」「Setup stopped」（Windowsのセットアップが完了しなかった、という案内）が出て、再試行してもUAC（管理者の確認）の画面が出ない。
- アプリの再起動やWindowsの再起動では戻らない。
起きているのはWindows 10/11のCodexデスクトップアプリ、VS Code拡張、npm版のCodex CLIで、報告の多くは[windows] sandbox = "elevated"の環境です。アプリそのものが起動しない、ChatGPTが開かないといった症状は別の問題なので、WindowsでCodex app-serverが起動しない：エラー文別の直し方を見てください。
エラー32（共有違反）とは：Codexが自分で使っているファイルを開けない
Windowsのシステムエラー32はERROR_SHARING_VIOLATION（0x20）で、日本語のWindowsでは「プロセスはファイルにアクセスできません。別のプロセスが使用中です。」と表示されます。いわゆる共有違反で、ほかのプロセスが使用中のファイルを、両立しない方法で開こうとしたときに返ります。HRESULTの形では0x80070020です（Microsoftのシステムエラーコード一覧）。
Codexの場合、使用中のファイルを握っているのはCodex自身です。elevatedサンドボックスの準備用ヘルパーcodex-windows-sandbox-setup.exeは、コマンドの前にCodexの実行環境（%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>）のアクセス権を点検し、必要なら直します。不具合のあるヘルパーはこのとき、実行中のEXEやDLLまでMAXIMUM_ALLOWEDという広いアクセス要求で開こうとしていました。一方でCodexは最初のコマンドより前にnode_repl.exeを起動し、Computer Use用のcodex-computer-use-swift.exeはVCRUNTIME140_1.dllを読み込みます。そのため古いヘルパーは毎回共有違反に当たり、準備が終わりません。
PR #51822（2026年10月7日UTCにマージ）は、MAXIMUM_ALLOWEDで開く対象をフォルダーに限り、ファイルはACLの更新が本当に必要なときだけREAD_CONTROL | WRITE_DACで開くように変えています。
始まった時期もはっきりしています。報告は2026年10月7日、Windowsアプリが26.1002.51308（build 13417）や、パッケージ26.1002.6548.0、26.1002.7124.0、26.1002.52244に更新されたあとから出ており、これらに同梱のヘルパーは0.162.0-alpha.2でした。それ以前のヘルパー（0.160.x）のログでは準備が正常に終わっています（#51634は「0.162.0-alpha.2の退行」と記録）。プロジェクトのフォルダーやWindowsのユーザー権限をいじっても直らないのはこのためです。
サンドボックスログの1行で、この不具合かを見分ける
判断に使うのは%USERPROFILE%\.codex\.sandbox\のsandbox.<日付>.logです（公式ドキュメントではCODEX_HOME/.sandbox/sandbox.logと書かれていますが、実際には日付入りのファイルが並びます）。PowerShellなら次のように当日のログからエラー32の行を拾えます。
Select-String -Path "$env:USERPROFILE\.codex\.sandbox\sandbox.*.log" -Pattern "os error 32" | Select-Object -Last 10この不具合なら、次の形の行のあとにsetup refresh … errors=[…]とtop-level error: setup refresh had errorsが続きます。日本語や他の言語のWindowsでは、真ん中の英文がその言語の文に変わります。
runtime read/execute validation failed: validate runtime read/execute access on C:\Users\<ユーザー名>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe: open ACL target for root-only update: The process cannot access the file because it is being used by another process. (os error 32)同じos error 32でも、無害な行や別の原因の行があります。ログの行ごとの意味は次のとおりです。
| ログに出る行 | 意味 | 次にすること |
|---|---|---|
runtime read/execute validation failed … node_repl.exeまたはVCRUNTIME140_1.dll … (os error 32) | この不具合（古いヘルパーの共有違反） | 修正済みバージョンにそろえる |
failed to grant non-inheriting read-attributes ACE on user profile C:\Users\<ユーザー名> … (os error 32); continuing setup | ユーザープロファイルへの読み取り属性の権限付与を飛ばしただけ。準備は続く | 何もしない。最後がerrors=[]なら成功 |
setup refresh: processed N write roots …; errors=[] | サンドボックスの準備は成功 | 失敗の原因はサンドボックスの準備以外 |
CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020) | MXCサンドボックス側の別の問題（未解決） | 後述のMXCの節を参照 |
helper_sandbox_lock_failed、SetNamedSecurityInfoW … failed: 5 | エラー5（アクセス拒否）。ACLや所有者の問題 | 別の不具合（#45734、#49025） |
エラー1385、エラー740、CreateProcessAsUserW failed | ログオンの種類の拒否、昇格の要求、プロセス作成の失敗 | OpenAIのWindowsサンドボックス文書のトラブルシューティング |
2行目のcontinuing setupは修正済みのヘルパーでも出ます。この行だけを見て「まだ直っていない」と判断しないでください。ログに何度も出るのが1行目の形で、最後にsetup refresh had errorsで終わっているかどうかが分かれ目です。
修正済みバージョン：CLIは0.163.0以上、アプリは26.1007.21434以降
修正はコンポーネントごとに入った時期が違います。手元で動いているものを1つずつ照らし合わせてください。
| コンポーネント | 未修正（エラー32が出る） | 修正済み | 根拠 |
|---|---|---|---|
npm版・単体のCodex CLI（@openai/codex） | 0.161.0、0.162.0、0.162.1 | 0.163.0以上（2026年10月15日公開、npmのlatest） | 0.163.0のリリースノートに#51822。OpenAIスタッフの回答 |
| Codexデスクトップアプリ（ChatGPTデスクトップアプリ内のCodexを含む） | 26.1002.x（同梱ヘルパー0.162.0-alpha.2） | 26.1007.21434（build 13901）以降。ストアのパッケージ表記では26.1007.2314.0の報告もあり | 利用者の報告（複数）。同梱のCLI 0.162.0-alpha.17.2に修正のコードが入っている |
| プレリリース版のCLI | 0.162.0-alpha.18.1など | 0.162.0-alpha.17.2（修正を個別に取り込み） | 各タグのcodex-rs/windows-sandbox-rs/src/acl.rsの内容 |
CLIについては、OpenAIのスタッフが2026年10月16日に#54325と#54405で、#51822で直りCodex CLI 0.163.0に含まれたこと、0.161.0と0.162.1にはまだ不具合があるので戻しても直らないこと、0.163.0以上に更新して動いているCodexアプリやdaemon（裏で動くCodexの常駐プロセス）も含めて再起動することを案内しています。
0.162系は番号の大小と修正の有無が一致しません。安定版の0.162.0と0.162.1、プレリリースの0.162.0-alpha.18.1には修正がなく、0.162.0-alpha.17.2には個別に取り込まれています。迷ったら安定版の0.163.0以上を使ってください。
デスクトップアプリは、26.1007.21434に更新してアプリを再起動しただけで、elevatedのまま直ったという報告が2026年10月9日から12日にかけて複数あります（#51601）。読み取り禁止のルールを設定したBusinessの環境でも、ログがerrors=[]になっています。ただしOpenAIのアプリの変更履歴には、26.1007でこの修正を入れたという記載がありません。26.1002の項目にある「アプリ更新後のサンドボックス更新失敗を修正」は、その後の26.1002系のパッケージでもエラー32の報告が続いたことから、別の問題と見るのが妥当です。修正が最初に入ったデスクトップのビルドと、production以外の配信チャネルの状況は公表されていません。
VS Code拡張についても修正版の番号は公表されていません。拡張を最新に更新したうえで、ログにエラー32の行が出なくなったか、次の手順の確認コマンドが通るかで判断してください。
修正版にそろえる手順と、codex sandboxでの確認
- バージョンを確かめる：CLIは
codex --version、デスクトップアプリはメニューの「About Codex」で表示されます。アプリとCLIの両方を使っているなら、両方を確認します。 - 更新する：npm版のCLIは
npm install -g @openai/codex@latestで0.163.0以上にします。デスクトップアプリは更新を入れて再起動します（Microsoft Storeから入れた場合はストアで更新）。 - Codexのプロセスをすべて終了する：アプリはウィンドウを閉じるだけでなく、タスクトレイからも終了します。ターミナルのCodexセッション、VS Code、
codex app-serverを呼び出すほかのツールも閉じます。タスクマネージャーにcodex.exeやnode_repl.exeが残っていないことを確かめてから起動し直してください。 - モデルを呼ばずにサンドボックスだけを試す：プロジェクトのフォルダーで次を実行します。
codex sandbox cmd /c "cd && echo SANDBOX-OK"
$LASTEXITCODESANDBOX-OKが表示されて終了コードが0なら成功です。ログにもsetup refresh: processed N write roots …; errors=[]が記録されます。codex sandboxのオプションはバージョンで変わるため、0.162.0以降では公式文書の書き方のcodex sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo SANDBOX_OKでも確かめられます。デスクトップアプリだけを使っている場合は、新しいチャットで簡単なコマンドを実行させ、同じログにerrors=[]が出るかを見ます。
更新してもエラー32が消えないとき：古いCLIとCODEX_CLI_PATH
修正版に更新したのに同じ行が出続けるときは、古いヘルパーを呼ぶものがまだどこかに残っています。報告されているのは次の3つです。
デスクトップアプリが直っても、npm版CLI 0.162.1が失敗させる
デスクトップアプリを修正版にしたあとでも、アプリを起動したままnpm版のCLI 0.162.1を使うと、同じos error 32で失敗します（#52328、#54165）。CLIは自分の古いヘルパーで、アプリと共有している実行環境（%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>）を点検しにいくためです。CODEX_HOMEを分けても切り離せず、アプリを完全に終了すると同じコマンドが通る、という報告が複数あります。CLIを0.163.0以上にすれば、アプリを起動したままでも動きます。VS Code拡張やCLIを併用している人は、デスクトップアプリだけ更新して終わりにしないでください。
codex app-serverを使うツールでは、セッション自身がnode_repl.exeを握る
ほかのツールから非対話のcodex app-serverセッションを使う場合（#54138ではClaude Codeのcodex-companionやOpenResearchの例）、Codexはセッションの開始時に自分でnode_repl.exeを起動します。このため、デスクトップアプリを閉じてもそのセッションのコマンドはすべて失敗します。厄介なのは、モデルの返答だけを見ると普通に見えることです。実際にはファイルを1つも読めず、渡された文脈だけで答えを返しています。そのツールが呼び出すcodexを0.163.0以上にしてください。
CODEX_CLI_PATHが古いcodex.exeを指したまま
Computer Useやブラウザー操作を古いアプリで使ったことのある環境では、環境変数CODEX_CLI_PATHが古いビルドのcodex.exe（%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe、報告では0.162.0-alpha.2）を指したまま残り、CLIを0.163.0にしても古いヘルパーが呼ばれることがあります（#54635）。値が書かれているのは次の2か所です。
%USERPROFILE%\.codex\config.tomlの[mcp_servers.node_repl.env]%USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\<バージョン>\.mcp.json
当てはまるかどうかは、当日のログで失敗しているsetup refresh: spawningの行を見れば分かります。起動されているのがOpenAI\Codex\bin\<hash>\codex-windows-sandbox-setup.exeなら、この状態です。報告者は2つのファイルをバックアップしたうえで、CODEX_CLI_PATHを最新のcodex.exe（その環境では%USERPROFILE%\.codex\packages\app-server-daemon\releases\<バージョン>\bin\の下）に書き換え、--versionでバージョンを確かめてからCodexを完全に再起動し、すぐに直ったとしています。
[mcp_servers.node_repl.env]
CODEX_CLI_PATH = 'C:\Users\<ユーザー名>\.codex\packages\app-server-daemon\releases\<バージョン>\bin\codex.exe'これは1人の詳しい報告で、2026年10月22日時点でOpenAIの回答はありません。フォルダーの構成はインストール方法によって違う可能性があり、アプリの更新で古い値に戻されることもあるため、更新のたびにログを見直してください。再インストールでは.codex内のこの値は書き換わりません。同じCODEX_CLI_PATHが消えたフォルダーを指してos error 3になる症状については、WindowsでCodex app-serverが起動しない：エラー文別の直し方を参照してください。
エラー32に効かない対処と、勧めない対処
GitHubのissueでは、次の方法では直らなかったと報告されています（#51601、#54325、#54635）。
- アプリの再起動、Windowsの再起動、新しいスレッド：起動し直しても、同じ古いヘルパーが同じファイルを開きにいきます。
- 再インストール：古い
CODEX_CLI_PATHが残っていれば結果は同じです。 node_repl.exeの強制終了：次のカーネルが起動するまでしか持たず、実行中のセッションのnode_replも止まったままになります。node_repl.exeに読み取り・実行の権限（ACE）を追加する：変化はありません。権限が足りないのではなく、使用中で開けないことが原因だからです。- npm版CLIを0.161.0に戻す：0.161.0も未修正です。
掲示板には、デスクトップアプリを26.930.7945.0に戻すという回答もあります。OpenAIはこの方法を案内しておらず、修正版が出ている今は戻す理由がありません。
フルアクセスでの常用、Defenderなどの保護の無効化、icaclsやtakeownによる所有者・ACLの変更も勧めません。ACLや所有者を直す手順は、エラー5（アクセス拒否）のための対処で、エラー32とは原因が違います。
すぐ更新できないとき：unelevatedへの一時切り替えとその代償
会社の端末などで更新をすぐ入れられない場合、%USERPROFILE%\.codex\config.tomlでサンドボックスをunelevatedに切り替えると、コマンドが戻ったという報告があります（OpenAIコミュニティの報告）。
[windows]
sandbox = "unelevated"ただしOpenAIの文書では、unelevatedは「elevatedの準備ができず、組織のポリシーが許す場合」のレガシーのフォールバックという位置づけです。現在のユーザーから作った制限付きトークンでコマンドを動かすため、elevatedよりネットワークの分離が弱く、読み取り禁止のパスにも対応していません。管理された端末ではallowed_sandbox_implementationsで禁止されていることがあります。
効果にも個人差があります。cannot enforce split writable root setsで失敗したという報告や、sandbox_mode = "workspace-write"も併せて指定する必要があったという報告があります（#51601のコメント）。修正版に更新したらelevatedに戻してください。config.tomlの場所やサンドボックスモードの意味は、Codex サンドボックスと config.toml：承認・書き込み・ネットワークを参照してください。
MXCサンドボックスに切り替えるなら：公式の推奨と別の0x80070020
OpenAIの文書では、対応するWindowsで推奨されるのはMXCで、elevatedは「MXCが使えないときのレガシーのフォールバック」に変わっています。MXCは管理者の承認による準備も、追加のWindowsアカウントやファイアウォールのルールも必要としません。デスクトップアプリは、端末が対応していれば個人向けのアカウントで自動的にMXCを優先します。
MXCにはWindows 11 24H2のbuild 26100.9278、または25H2のbuild 26200.9278以降と、Microsoftが順次配信している機能が必要です。CLI 0.162.0以降なら、保存済みの設定を変えずに1回だけ試せます。
codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODEMXC_OKと終了コード0が返れば使えます。CLIで常に優先させるには、config.tomlに次を書きます。
[features]
prefer_mxc = trueただし、MXC側にも別の未解決の問題があります。アプリ26.1013.40934とWindows 11 25H2の環境でCreateProcessSecurityEnvironment failed (HRESULT = 0x80070020)が出て、MXCを優先したときだけ再現したという報告です（#55230、2026年10月22日時点でスタッフの回答なし）。0x80070020も共有違反ですが、0.163.0の修正では直りません。このエラーが出たら、MXCの優先をやめて、修正済みバージョンのelevatedで動くかを試してください（同じ報告では、MXCを使わないCLIは動いています）。
修正版でも直らないとき：OpenAIに送る情報
CLIが0.163.0以上、アプリが26.1007.21434以降で、プロセスをすべて終了し直してもエラー32が出る場合は、GitHubのissueで次の情報を添えて報告してください（OpenAIスタッフの案内と公式文書の項目）。
- 再現した直後の新しいサンドボックスログ（
%USERPROFILE%\.codex\.sandbox\の当日のファイル） - CLIのバージョン（
codex --version）と、デスクトップアプリ・daemonのバージョン - 使っているサンドボックスの種類（
mxc、elevated、unelevated） - Windows 10か11か、とビルド番号
- アプリに表示されたエラー文と、何をしようとしていたか
%USERPROFILE%\.codex\.sandbox-secrets\の中身は送らないでください。ログに出ているユーザー名などを伏せる場合も、(os error 32)の行とsetup refresh: spawningの行のパスの形は残しておくと、どのヘルパーが動いたかを判断してもらえます。
