# Codex Windowsサンドボックスのエラー32：CLI 0.163.0で修正済み > Windows版Codexのsetup refresh had errors（os error 32）はCodex側の不具合です。CLI 0.163.0以上・アプリ26.1007.21434以降にそろえれば、elevatedのまま直ります。 - Source: https://www.aifreeapi.com/ja/posts/codex-windows-sandbox-error-32 - Language: ja - Published: 2026-10-22 - Updated: 2026-10-22 - Publisher: AI Free API (https://www.aifreeapi.com) 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](https://github.com/openai/codex/pull/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](https://github.com/openai/codex/issues/51601)や[#52328](https://github.com/openai/codex/issues/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が起動しない：エラー文別の直し方](/ja/posts/codex-app-server-failed-to-start)を見てください。 ## エラー32（共有違反）とは：Codexが自分で使っているファイルを開けない Windowsのシステムエラー32は`ERROR_SHARING_VIOLATION`（0x20）で、日本語のWindowsでは「プロセスはファイルにアクセスできません。別のプロセスが使用中です。」と表示されます。いわゆる共有違反で、ほかのプロセスが使用中のファイルを、両立しない方法で開こうとしたときに返ります。HRESULTの形では`0x80070020`です（[Microsoftのシステムエラーコード一覧](https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-)）。 Codexの場合、使用中のファイルを握っているのはCodex自身です。elevatedサンドボックスの準備用ヘルパー`codex-windows-sandbox-setup.exe`は、コマンドの前にCodexの実行環境（`%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\`）のアクセス権を点検し、必要なら直します。不具合のあるヘルパーはこのとき、実行中のEXEやDLLまで`MAXIMUM_ALLOWED`という広いアクセス要求で開こうとしていました。一方でCodexは最初のコマンドより前に`node_repl.exe`を起動し、Computer Use用の`codex-computer-use-swift.exe`は`VCRUNTIME140_1.dll`を読み込みます。そのため古いヘルパーは毎回共有違反に当たり、準備が終わりません。 [PR #51822](https://github.com/openai/codex/pull/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](https://github.com/openai/codex/issues/51634)は「0.162.0-alpha.2の退行」と記録）。プロジェクトのフォルダーやWindowsのユーザー権限をいじっても直らないのはこのためです。 ## サンドボックスログの1行で、この不具合かを見分ける 判断に使うのは`%USERPROFILE%\.codex\.sandbox\`の`sandbox.<日付>.log`です（公式ドキュメントでは`CODEX_HOME/.sandbox/sandbox.log`と書かれていますが、実際には日付入りのファイルが並びます）。PowerShellなら次のように当日のログからエラー32の行を拾えます。 ```powershell 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では、真ん中の英文がその言語の文に変わります。 ```text runtime read/execute validation failed: validate runtime read/execute access on C:\Users\<ユーザー名>\AppData\Local\OpenAI\Codex\runtimes\cua_node\\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](https://github.com/openai/codex/issues/45734)、[#49025](https://github.com/openai/codex/issues/49025)） | | エラー1385、エラー740、`CreateProcessAsUserW failed` | ログオンの種類の拒否、昇格の要求、プロセス作成の失敗 | [OpenAIのWindowsサンドボックス文書](https://learn.chatgpt.com/docs/windows/windows-sandbox)のトラブルシューティング | 2行目の`continuing setup`は修正済みのヘルパーでも出ます。この行だけを見て「まだ直っていない」と判断しないでください。ログに何度も出るのが1行目の形で、最後に`setup refresh had errors`で終わっているかどうかが分かれ目です。 ![エラー32を含む3種類のログ行の見分け方。node_repl.exeの行は「この不具合」で修正版にそろえる、continuing setupの行は「無害」で最後のerrorsが空なら成功、CreateProcessSecurityEnvironmentの0x80070020は「別の問題」でMXCの優先をやめて試す](https://www.aifreeapi.com/posts/ja/codex-windows-sandbox-error-32/img/log-error-32-lines.webp) ## 修正済みバージョン：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のリリースノート](https://github.com/openai/codex/releases/tag/rust-v0.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](https://github.com/openai/codex/issues/54325)と[#54405](https://github.com/openai/codex/issues/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](https://github.com/openai/codex/issues/51601)）。読み取り禁止のルールを設定したBusinessの環境でも、ログが`errors=[]`になっています。ただしOpenAIのアプリの変更履歴には、26.1007でこの修正を入れたという記載がありません。26.1002の項目にある「アプリ更新後のサンドボックス更新失敗を修正」は、その後の26.1002系のパッケージでもエラー32の報告が続いたことから、別の問題と見るのが妥当です。修正が最初に入ったデスクトップのビルドと、production以外の配信チャネルの状況は公表されていません。 VS Code拡張についても修正版の番号は公表されていません。拡張を最新に更新したうえで、ログにエラー32の行が出なくなったか、次の手順の確認コマンドが通るかで判断してください。 ## 修正版にそろえる手順と、codex sandboxでの確認 1. **バージョンを確かめる**：CLIは`codex --version`、デスクトップアプリはメニューの「About Codex」で表示されます。アプリとCLIの両方を使っているなら、両方を確認します。 2. **更新する**：npm版のCLIは`npm install -g @openai/codex@latest`で0.163.0以上にします。デスクトップアプリは更新を入れて再起動します（Microsoft Storeから入れた場合はストアで更新）。 3. **Codexのプロセスをすべて終了する**：アプリはウィンドウを閉じるだけでなく、タスクトレイからも終了します。ターミナルのCodexセッション、VS Code、`codex app-server`を呼び出すほかのツールも閉じます。タスクマネージャーに`codex.exe`や`node_repl.exe`が残っていないことを確かめてから起動し直してください。 4. **モデルを呼ばずにサンドボックスだけを試す**：プロジェクトのフォルダーで次を実行します。 ```powershell codex sandbox cmd /c "cd && echo SANDBOX-OK" $LASTEXITCODE ``` `SANDBOX-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・VS Code拡張、codex app-serverを呼ぶツール、CODEX_CLI_PATHの4つが同じ実行環境のnode_repl.exeを点検しにいく図。修正済みのアプリだけが準備に成功し、古いCLIを使う3つはos error 32になる](https://www.aifreeapi.com/posts/ja/codex-windows-sandbox-error-32/img/mixed-versions-shared-runtime.webp) ### デスクトップアプリが直っても、npm版CLI 0.162.1が失敗させる デスクトップアプリを修正版にしたあとでも、アプリを起動したままnpm版のCLI 0.162.1を使うと、同じ`os error 32`で失敗します（[#52328](https://github.com/openai/codex/issues/52328)、[#54165](https://github.com/openai/codex/issues/54165)）。CLIは自分の古いヘルパーで、アプリと共有している実行環境（`%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\`）を点検しにいくためです。`CODEX_HOME`を分けても切り離せず、アプリを完全に終了すると同じコマンドが通る、という報告が複数あります。CLIを0.163.0以上にすれば、アプリを起動したままでも動きます。VS Code拡張やCLIを併用している人は、デスクトップアプリだけ更新して終わりにしないでください。 ### codex app-serverを使うツールでは、セッション自身がnode_repl.exeを握る ほかのツールから非対話の`codex app-server`セッションを使う場合（[#54138](https://github.com/openai/codex/issues/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\\codex.exe`、報告では0.162.0-alpha.2）を指したまま残り、CLIを0.163.0にしても古いヘルパーが呼ばれることがあります（[#54635](https://github.com/openai/codex/issues/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\\codex-windows-sandbox-setup.exe`なら、この状態です。報告者は2つのファイルをバックアップしたうえで、`CODEX_CLI_PATH`を最新の`codex.exe`（その環境では`%USERPROFILE%\.codex\packages\app-server-daemon\releases\<バージョン>\bin\`の下）に書き換え、`--version`でバージョンを確かめてからCodexを完全に再起動し、すぐに直ったとしています。 ```toml [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が起動しない：エラー文別の直し方](/ja/posts/codex-app-server-failed-to-start)を参照してください。 ## エラー32に効かない対処と、勧めない対処 GitHubのissueでは、次の方法では直らなかったと報告されています（[#51601](https://github.com/openai/codex/issues/51601)、[#54325](https://github.com/openai/codex/issues/54325)、[#54635](https://github.com/openai/codex/issues/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コミュニティの報告](https://community.openai.com/t/windows-11-setup-refresh-had-errors-blocks-commands-and-browser-tasks/1404213)）。 ```toml [windows] sandbox = "unelevated" ``` ただし[OpenAIの文書](https://learn.chatgpt.com/docs/windows/windows-sandbox)では、unelevatedは「elevatedの準備ができず、組織のポリシーが許す場合」のレガシーのフォールバックという位置づけです。現在のユーザーから作った制限付きトークンでコマンドを動かすため、elevatedよりネットワークの分離が弱く、読み取り禁止のパスにも対応していません。管理された端末では`allowed_sandbox_implementations`で禁止されていることがあります。 効果にも個人差があります。`cannot enforce split writable root sets`で失敗したという報告や、`sandbox_mode = "workspace-write"`も併せて指定する必要があったという報告があります（[#51601のコメント](https://github.com/openai/codex/issues/51601#issuecomment-6183922808)）。修正版に更新したら`elevated`に戻してください。`config.toml`の場所やサンドボックスモードの意味は、[Codex サンドボックスと config.toml：承認・書き込み・ネットワーク](/ja/posts/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回だけ試せます。 ```powershell codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK $LASTEXITCODE ``` `MXC_OK`と終了コード`0`が返れば使えます。CLIで常に優先させるには、`config.toml`に次を書きます。 ```toml [features] prefer_mxc = true ``` ただし、MXC側にも別の未解決の問題があります。アプリ26.1013.40934とWindows 11 25H2の環境で`CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020)`が出て、MXCを優先したときだけ再現したという報告です（[#55230](https://github.com/openai/codex/issues/55230)、2026年10月22日時点でスタッフの回答なし）。`0x80070020`も共有違反ですが、0.163.0の修正では直りません。このエラーが出たら、MXCの優先をやめて、修正済みバージョンのelevatedで動くかを試してください（同じ報告では、MXCを使わないCLIは動いています）。 ## 修正版でも直らないとき：OpenAIに送る情報 CLIが0.163.0以上、アプリが26.1007.21434以降で、プロセスをすべて終了し直してもエラー32が出る場合は、GitHubのissueで次の情報を添えて報告してください（[OpenAIスタッフの案内](https://github.com/openai/codex/issues/54325)と[公式文書](https://learn.chatgpt.com/docs/windows/windows-sandbox)の項目）。 - 再現した直後の新しいサンドボックスログ（`%USERPROFILE%\.codex\.sandbox\`の当日のファイル） - CLIのバージョン（`codex --version`）と、デスクトップアプリ・daemonのバージョン - 使っているサンドボックスの種類（`mxc`、`elevated`、`unelevated`） - Windows 10か11か、とビルド番号 - アプリに表示されたエラー文と、何をしようとしていたか `%USERPROFILE%\.codex\.sandbox-secrets\`の中身は送らないでください。ログに出ているユーザー名などを伏せる場合も、`(os error 32)`の行と`setup refresh: spawning`の行のパスの形は残しておくと、どのヘルパーが動いたかを判断してもらえます。