# Codex Windows Sandbox Setup Fails with os error 32: Fixed Builds > Codex commands failing on Windows with os error 32 and "setup refresh had errors" is a Codex sandbox bug, fixed in CLI 0.163.0 and desktop app 26.1007.21434. - Source: https://www.aifreeapi.com/en/posts/codex-windows-sandbox-error-32 - Language: en - Published: 2026-10-22 - Updated: 2026-10-22 - Publisher: AI Free API (https://www.aifreeapi.com) If every Codex command on Windows fails before it starts with `helper_unknown_error: setup refresh had errors`, and the sandbox log shows `os error 32` on `node_repl.exe`, your project and your Windows permissions are fine. It's a bug in the elevated sandbox's setup helper that arrived with the desktop app's 26.1002 builds on October 7, 2026, and it has been fixed: - **Codex CLI 0.163.0 or later**, released October 15, 2026. An OpenAI staff reply confirms this version carries the fix and that 0.161.0 and 0.162.1 do not ([#54325](https://github.com/openai/codex/issues/54325)). - **Desktop app 26.1007.21434 (build 13901) or later.** Several users confirmed the error stopped on this build with the elevated sandbox left as it was ([#51601](https://github.com/openai/codex/issues/51601#issuecomment-6087975422)). OpenAI hasn't named a fixed desktop build, so this number comes from those reports. Update every Codex component on the machine, not only the one you use, then quit and restart all of them. If the error survives the update, look for an older CLI still running next to the fixed app, or a config entry that still points at an old build. ## What os error 32 means in the Codex sandbox Windows error 32 is `ERROR_SHARING_VIOLATION`: "The process cannot access the file because it is being used by another process" ([Microsoft system error codes](https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-)). In this case, the other process is Codex. Before a sandboxed command runs, the elevated sandbox does a setup refresh with `codex-windows-sandbox-setup.exe`. Part of that refresh checks the permissions on Codex's own runtime folder, `%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\`. The affected helper opened the files there asking for `MAXIMUM_ALLOWED` access, and Windows refuses that request on an EXE or DLL that is currently running. Codex starts `node_repl.exe`, the Node REPL behind its browser and Computer Use tools, before your first command. So the refresh fails every time, and the command you asked for never starts. OpenAI's fix, [PR #51822 "Avoid sharing violations when repairing Windows runtime ACLs"](https://github.com/openai/codex/pull/51822), merged October 7, 2026, keeps `MAXIMUM_ALLOWED` for directories only. On files, the helper now asks just for the rights to read and change permissions, and only when a change is needed. That mechanism explains the pattern people keep seeing: - Restarting Codex or rebooting Windows changes nothing, because Codex starts `node_repl.exe` again right away. - A sandbox command can succeed while the desktop app is fully closed and fail as soon as the app is open again ([#52328](https://github.com/openai/codex/issues/52328)). - Reports begin on October 7, 2026, after the desktop app moved to 26.1002 builds bundling CLI `0.162.0-alpha.2`. Logs from the previous 0.160.x helper show clean refreshes ([#51601](https://github.com/openai/codex/issues/51601), [#51634](https://github.com/openai/codex/issues/51634)). ## Read the sandbox log: the fatal node_repl.exe line vs the harmless one The message in the app doesn't tell you which sandbox problem you have. With this bug it can appear as any of these: - `Failed to create unified exec process: helper_unknown_error: setup refresh had errors` - `exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors` - `windows sandbox failed: helper_unknown_error: setup refresh had errors`, then `trusted Node process exited unexpectedly` or `node_repl kernel exited unexpectedly` when a Node REPL, browser or Computer Use tool starts - a "Windows setup didn't finish" or "Setup stopped" banner whose Retry button shows no UAC prompt The log decides it. Open `%USERPROFILE%\.codex\.sandbox\`. OpenAI's docs call the file `sandbox.log`; many installs write dated files such as `sandbox.2026-10-15.log` in the same folder. Open today's file and search for `os error 32`. This line means you have this bug: ```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) ``` The same error on `...\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll` counts too. That DLL is loaded by `codex-computer-use-swift.exe`. Either line is followed by `setup refresh: ... errors=[...]` and `top-level error: setup refresh had errors`. On non-English Windows the sentence in the middle is in your system language, while the path and `(os error 32)` stay the same. This line does not mean you have it: ```text failed to grant non-inheriting read-attributes ACE on user profile C:\Users\: open ACL target for root-only update ... (os error 32); continuing setup ``` It concerns your user profile folder and ends in `continuing setup`. It also shows up on fixed builds, where the refresh still finishes with `errors=[]`. Skip it and look for the runtime line. Also note the `setup refresh: spawning ...` line just before the failure. Its path tells you which copy of the setup helper ran, which matters if the error survives an update. ![Four sandbox log lines that mention os error 32 or a related failure: the node_repl.exe validation line is this bug, the user profile line is harmless, a spawning path in OpenAI\Codex\bin\ after updating means checking CODEX_CLI_PATH, and HRESULT 0x80070020 is a separate MXC bug](https://www.aifreeapi.com/posts/en/codex-windows-sandbox-error-32/img/sandbox-log-lines.webp) ### Windows sandbox errors that are a different problem | What the log or app shows | What it points to | Where to start | | --- | --- | --- | | `os error 5`, `helper_sandbox_lock_failed`, `SetNamedSecurityInfoW ... failed: 5` | Access denied while setting permissions | A permissions or ownership problem; the ownership fixes posted online are for this, not for error 32 | | Error `1385` | Windows denies the logon type the sandbox users need | OpenAI's docs: ask IT to grant the logon rights; use `unelevated` meanwhile | | Error `740` | An elevation (administrator) boundary during setup | Retry setup and approve the admin prompt, if your device allows it | | `CreateProcessAsUserW failed` | Windows couldn't start the command as the sandbox user | A separate setup problem, not a file lock | | `CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020)` | A sharing violation on the MXC sandbox path | An open issue that 0.163.0 doesn't fix; see the section on updates below | OpenAI's [Windows sandbox troubleshooting](https://learn.chatgpt.com/docs/windows/windows-sandbox) covers legacy setup failures and error 1385 but doesn't mention error 32. Examples of the other errors are in [#45734](https://github.com/openai/codex/issues/45734) and [#49025](https://github.com/openai/codex/issues/49025). If the Codex app doesn't start at all, that's a different set of errors: see [Failed to Start Codex App-Server on Windows: Fixes by Error Text](/en/posts/codex-app-server-failed-to-start). ## Which Codex versions fix os error 32: CLI 0.163.0, app 26.1007.21434 | Codex component | Still affected | Fixed | Where to read the version | | --- | --- | --- | --- | | Desktop app (also where Codex runs inside the ChatGPT desktop app) | 26.1002 builds such as 26.1002.51308 and 26.1002.52244 (packages 26.1002.6548.0, 26.1002.7124.0), bundling CLI 0.162.0-alpha.2 | 26.1007.21434, build 13901 (package 26.1007.2314.0) or later, bundling CLI 0.162.0-alpha.17.2; confirmed by users | About Codex | | Codex CLI from npm or a standalone install | 0.161.0, 0.162.0, 0.162.1 | 0.163.0 or later; npm `latest` since October 15, 2026 | `codex --version` | | Codex daemon or `codex app-server` processes | Whatever build they started from | Fixed once the CLI they come from is 0.163.0+ and they've been restarted | Restart them; OpenAI asks for the daemon version when you report | | VS Code extension | 26.1002.51308 reported affected | No public report names a fixed build | Extension version in VS Code, then the log check below | The version numbers are the trap. The app's bundled 0.162.0-alpha.17.2 has the fix, but the stable 0.162.0 and 0.162.1 releases don't. The fix reached 0.162.0-alpha.17.2 as a cherry-pick, while the [`acl.rs` source at the rust-v0.162.1 tag](https://github.com/openai/codex/blob/rust-v0.162.1/codex-rs/windows-sandbox-rs/src/acl.rs) and at rust-v0.162.0 doesn't contain the change. A CLI reporting 0.162.1 looks newer than the app's alpha and is still broken. The [rust-v0.163.0 release notes](https://github.com/openai/codex/releases/tag/rust-v0.163.0) list "#51822 Avoid sharing violations when repairing Windows runtime ACLs", and OpenAI staff put it plainly on October 16, 2026: "Versions 0.161.0 and 0.162.1 still had the faulty behavior, which explains why downgrading didn't help. Please update to 0.163.0 or later and restart Codex, including any running Codex app/daemon processes." ([#54325](https://github.com/openai/codex/issues/54325)) For the desktop app, the evidence is user reports. One user on 26.1007.21434 ran sandboxed PowerShell with exit code 0 and had Computer Use and the in-app browser working again with no other steps. Another, on ChatGPT for Business with deny-read rules, saw the refresh finish with `errors=[]` ([#51601](https://github.com/openai/codex/issues/51601#issuecomment-6120900979)). OpenAI's app release notes for 26.1007 don't mention the fix. The 26.1002 note "Fixed Windows sandbox refresh failures after app updates" refers to something else, since error 32 reports kept arriving on later 26.1002 packages. Nothing public says how non-production app channels behave. ## Update every Codex component, then restart all of them 1. **Desktop app.** Install the update from the Microsoft Store or the app's own updater and let it restart. Open About Codex and check for 26.1007.21434 or later. One user needed no Windows reboot after this update. 2. **Every CLI on the machine.** Update the npm install and check it: ```powershell npm install -g @openai/codex@latest codex --version ``` You want `codex-cli 0.163.0` or later. Do this even if you work only in the app: a stale CLI used by VS Code, a script, or another agent's plugin that calls `codex app-server` hits the same runtime folder. `where.exe codex` shows every `codex` on your PATH if you suspect more than one install. 3. **Quit everything, then reopen.** Close the desktop app completely, every terminal running `codex`, VS Code windows using the extension, and any tool running `codex app-server`. Before reopening, check Task Manager for leftover `codex.exe` or `node_repl.exe` processes. A process that started from the old build keeps running the old helper until it exits. 4. **Verify**, as described in the next section. ## Confirm the fix: SANDBOX-OK and errors=[] in the log Test with the desktop app open, since that's the state that used to fail. From your project folder in PowerShell: ```powershell codex sandbox cmd /c "cd && echo SANDBOX-OK" $LASTEXITCODE ``` A fixed setup prints your folder and `SANDBOX-OK`, and `$LASTEXITCODE` is `0`. Today's sandbox log gets a line like `setup refresh: processed N write roots ...; errors=[]`. The command checks sandbox startup without a model call ([#51601](https://github.com/openai/codex/issues/51601)). On CLI 0.162.0 and later you can also use the form from OpenAI's docs: ```powershell codex sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo SANDBOX_OK ``` `codex sandbox` flags vary between versions, so if one form is rejected, use the other. This tests the CLI on your PATH. For the desktop app itself, ask Codex in a chat to run `Get-Location`. If you use Computer Use or the browser, try one of those actions as well, because they start `node_repl.exe`. ## Still os error 32 after updating: three things that keep it alive The desktop app, every CLI and every `codex app-server` session run their own setup refresh against the same runtime folder. One old helper anywhere on the machine is enough to bring the error back. ![The shared cua_node runtime with node_repl.exe in use, reached by three callers: the desktop app 26.1007.21434 or later with a fixed helper, an older Codex CLI 0.161.0 to 0.162.1 that hits os error 32 and needs 0.163.0+, and a stale CODEX_CLI_PATH pointing at an old codex.exe that needs repointing](https://www.aifreeapi.com/posts/en/codex-windows-sandbox-error-32/img/shared-runtime-old-helper.webp) ### An older Codex CLI still runs next to the fixed app With a fixed desktop app running, npm CLI 0.162.1 still fails with the same error on the app's runtime folder, because the CLI's own setup refresh touches that shared folder. A separate `CODEX_HOME` doesn't isolate it. With the app fully quit, the same CLI command works ([#51601](https://github.com/openai/codex/issues/51601#issuecomment-6183922808)). Quitting the app is a workaround; updating the CLI to 0.163.0 is the fix. Automated `codex app-server` sessions are a sneakier case. The session starts its own `node_repl.exe`, so it holds the file itself, and quitting the desktop app changes nothing. In one report, every shell command in a review session failed while the model still returned a normal-looking verdict based only on the context it had been given ([#54138](https://github.com/openai/codex/issues/54138)). If an automated Codex result never shows command output, check the sandbox log for that time. ### A stale CODEX_CLI_PATH pins Computer Use to an old build A detailed report from October 16, 2026 (CLI 0.163.0 with app 26.1002.52244) traced the failing refresh to an older helper ([#54635](https://github.com/openai/codex/issues/54635)). The failing `setup refresh: spawning` lines pointed to `%LOCALAPPDATA%\OpenAI\Codex\bin\\codex-windows-sandbox-setup.exe`, a 0.162.0-alpha.2 build. That path came from `CODEX_CLI_PATH`, stored in two places: - `%USERPROFILE%\.codex\config.toml`, under `[mcp_servers.node_repl.env]` - `%USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\\.mcp.json` If your log's spawning path points into `OpenAI\Codex\bin\\`, run the `codex.exe` in that folder with `--version`. If it reports a build without the fix: 1. Back up both files. 2. Point `CODEX_CLI_PATH` in both at your newest `codex.exe`. In that report it was under `%USERPROFILE%\.codex\packages\app-server-daemon\releases\\bin\`. Run it with `--version` to make sure it's 0.163.0 or later. 3. Quit and restart Codex completely, then repeat the test above. This comes from one reporter with logs, and OpenAI hasn't replied to it yet. Folder names may differ on your install, and an app update may write the old value back, so check again after the next update. If your spawning path already points at a current build, leave these files alone. Where `config.toml` lives and what its sandbox settings do is covered in [Codex Sandbox and config.toml: Permissions Without Full Access](/en/posts/codex-config-toml). ### HRESULT 0x80070020 on the MXC sandbox is a separate bug `CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020)` is also a sharing violation (0x20 is 32), but it comes from the newer MXC sandbox, not the elevated helper. It was reported on desktop app 26.1013.40934 with Windows 11 25H2. One user reproduced it only when MXC was preferred (`-c features.prefer_mxc=true`), while the CLI without MXC worked. Another sees it in Codex inside the ChatGPT desktop app while npm CLI 0.163.0 works on the same machine. The issue is open with no staff reply as of October 22, 2026 ([#55230](https://github.com/openai/codex/issues/55230)), and 0.163.0 doesn't fix it. ## Can't update yet? The unelevated fallback and what it costs Setting the legacy unelevated sandbox in `%USERPROFILE%\.codex\config.toml` has brought commands back for some users: ```toml [windows] sandbox = "unelevated" ``` It is a downgrade in protection, not a fix. OpenAI's [Windows sandbox docs](https://learn.chatgpt.com/docs/windows/windows-sandbox) call `unelevated` a legacy fallback for when elevated setup is unavailable "and organizational policy permits it". It runs commands with a restricted token derived from your own user, "provides weaker network isolation than `elevated` and doesn't support denied read paths". Results are mixed: it worked for users in an [OpenAI community thread](https://community.openai.com/t/windows-11-setup-refresh-had-errors-blocks-commands-and-browser-tasks/1404213), one user got `cannot enforce split writable root sets` instead, and another needed `sandbox_mode = "workspace-write"` as well. On managed devices, `allowed_sandbox_implementations` may block it. Switch back to `elevated` once you're on a fixed build. On Windows 11 24H2 (build 26100.9278 or later) or 25H2 (build 26200.9278 or later), check MXC before reaching for `unelevated`. OpenAI's docs call MXC "the recommended sandbox on compatible Windows devices", and it doesn't need the administrator-approved setup that the elevated sandbox uses. Test one command without changing settings (CLI 0.162.0 or later): ```powershell codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK $LASTEXITCODE ``` If it prints `MXC_OK` with exit code `0`, CLI users can turn it on with `[features] prefer_mxc = true` in `config.toml`. The desktop app already prefers MXC automatically for consumer accounts when the device supports it. Keep in mind the open MXC issue above, and that an enterprise policy of `allow_mxc = false` blocks it. ## What doesn't fix Codex os error 32 - **Restarting the app, rebooting Windows or starting a fresh thread.** Codex starts `node_repl.exe` again right away. - **Reinstalling.** In the stale-path report, the old `CODEX_CLI_PATH` survived a reinstall. - **Killing `node_repl.exe`.** Commands work until Codex starts a new kernel, and stopping it can just move the failure to another runtime file such as `node.exe`. - **Adding permissions on `node_repl.exe`.** An explicit read/execute permission changed nothing. The helper's open request is the problem, not a missing permission. - **Downgrading the npm CLI to 0.161.0.** It has the same bug, per OpenAI staff. - **Full access mode.** It hides the error by taking the sandbox away. OpenAI's docs warn that full access lets Codex act outside your project and "might perform unintentional destructive actions that can lead to data loss". - **Rolling the desktop app back to a 26.930 build.** Some users did this before the fix shipped. With fixed builds available, updating is the better route. ## What to send OpenAI if error 32 continues on fixed builds If `codex --version` shows 0.163.0 or later, About Codex shows 26.1007.21434 or later, nothing old is still running, and the runtime line still appears, open an issue on [openai/codex](https://github.com/openai/codex/issues) or add to an existing one. OpenAI staff and docs ask for: - a fresh sandbox log from `%USERPROFILE%\.codex\.sandbox\`, captured right after the failure - the versions reported by the CLI and the daemon, plus the desktop app's About version - the sandbox implementation in use: `mxc`, `elevated` or `unelevated` - your Windows build number and whether it's Windows 10 or 11 Don't send anything from `%USERPROFILE%\.codex\.sandbox-secrets\`.