Since 2026-10-07, anyone running the Codex app on Windows with the elevated sandbox has watched every command fail before it starts. A harmless Get-Location comes back with Failed to create unified exec process: helper_unknown_error: setup refresh had errors, and the Node REPL goes down with trusted Node process exited unexpectedly. Issue #51601 passed 119 comments in three days.
The good news: the fix has shipped. The message, though, is generic and shows up for more than one reason. This guide shows how to find the real cause in the log and which way out fits each one.
What does "setup refresh had errors" mean in Codex?
It means the Windows sandbox helper (codex-windows-sandbox-setup.exe) failed while preparing permissions before running your command, so Codex refused to execute it. The error does not say which step failed; the sandbox log does.
Before each command, Codex runs this helper to check the permissions (ACLs) on the folders the agent will use. If any required step fails, the command never starts. That is why the symptom is always the same, with a 0 ms duration, whether you asked for a git status or a build.
Where do you find the real cause?
In %USERPROFILE%\.codex\.sandbox\sandbox.<date>.log. The last failure is also summarized in %USERPROFILE%\.codex\.sandbox\setup_error.json. In PowerShell, this shows the latest relevant lines:
Select-String -Path "$env:USERPROFILE\.codex\.sandbox\sandbox.*.log" -Pattern "os error|failed" | Select-Object -Last 20If you use the CLI, codex doctor --summary also flags when sandbox provisioning recorded a failure.
One line tends to mislead: failed to grant non-inheriting read-attributes ACE on user profile ... (os error 32); continuing setup. It ends in continuing setup, so it is not fatal. Look at the line that comes after it.
Which log line maps to which cause?
| Log line | Cause | Way out |
|---|---|---|
runtime read/execute validation failed ... cua_node\...\node_repl.exe ... (os error 32) | Regression in the helper shipped with app 26.1002.x (bundled CLI 0.162.0-alpha.2) | Update the app to 26.1007.21434 or newer |
setup refresh failed to launch helper Access denied (os error 5) | The helper cannot be launched from the package's WindowsApps folder | CODEX_CLI_PATH variable pointing to another copy of codex.exe |
| Fails only in one project folder, other folders work | Workspace state stuck to that path | Open the same repository through a junction (mklink /J) |
The October case is the first row, and it is what the rest of this guide fixes.
Why has os error 32 shown up since 10/07?
Because the new helper started validating permissions on every file in the cua_node runtime by opening each file with MAXIMUM_ALLOWED access, and Windows refuses that request on a file in use. os error 32 is ERROR_SHARING_VIOLATION.
The detail that locks everything: the process using those files is Codex itself. The app keeps node_repl.exe and codex-computer-use-swift.exe running from that folder. Users on the issue reported that killing those processes only moves the failure to the next open file (a DLL), and that the app respawns the process in under a second. Restarting the app or Windows does not help.
OpenAI fixed this in PR #51822, merged on 2026-10-07: MAXIMUM_ALLOWED is now limited to directories, and files are opened only with READ_CONTROL | WRITE_DAC when an ACL change is actually needed.
How do you fix os error 32 in the Codex app?
Update the app to version 26.1007.21434 (build 13901) or newer. Several users confirmed on the issue, on October 9 and 10, 2026, that commands, Node REPL and browser control work again with the elevated sandbox untouched, with no extra steps.
- Check the version under About Codex. If it says 26.1002.x, you are on the affected build.
- Update through the Microsoft Store (Library, then Get updates) or from the terminal:
winget upgrade --id 9PLM9XGG6VKS -s msstore - Quit the app completely and open it again.
- Ask for a simple command and check that the
runtime read/execute validation failedline is gone from the log.
What if you cannot update right now?
Temporarily switch the sandbox to unelevated mode in %USERPROFILE%\.codex\config.toml:
[windows]
sandbox = "unelevated"According to the repository's config schema, the accepted values for this key are elevated, unelevated and mxc. Close every app instance (including the hidden ones in Task Manager) and reopen it. On the issue, people who made this switch reported commands and file edits working again, with partial recovery in some cases.
This is a stopgap, not a fix. unelevated mode uses a restricted token and, per the code's own documentation, supports a smaller set of filesystem policies than elevated. Switch back to elevated as soon as you update.
Is the Codex CLI installed from npm affected too?
It can be. One user reported the same os error 32 with a global @openai/codex@0.161.0, with the desktop app installed on the same machine. We checked the code on 2026-10-10: the PR #51822 fix is in main, in 0.162.0-alpha.17.2 onward and in the 0.163.0-alpha series, but it is not in the stable 0.162.0 or 0.162.1 releases, and 0.162.1 is the current latest on npm.
Until a stable release ships with the fix, the CLI options are the same sandbox = "unelevated" above or an alpha build that already has the fix:
npm install -g @openai/codex@0.163.0-alpha.5
codex --versionAn alpha build can bring other changes. If your workflow depends on stability, prefer the config.toml stopgap and watch the repository's releases.
How do you fix the other causes of the same error?
os error 5 when launching the helper. In an August 2026 report on the OpenAI forum, the helper failed to launch from the package's WindowsApps folder. What worked was pointing Codex to another copy of the executable before opening the app:
setx CODEX_CLI_PATH "%USERPROFILE%\.codex\plugins\.plugin-appserver\codex.exe"Check first that this file exists on your machine, and remove the variable once a new package version launches its helper normally again.
Failure tied to one folder. If other folders work and only one repository breaks, another forum report solved it by opening the same repository through a Windows junction, as if it were a new path:
mklink /J D:\CodexWorkspaceAlias D:\Projects\my-repositoryQuick questions
Does running commands without the sandbox fix it? It runs, but it strips protection from every agent command and can be refused if your approval policy is granular. Try unelevated first.
Do I need to change permissions with icacls? No. One user granted read and execute on 2,702 runtime files and the failure stayed identical: the problem is opening a file in use, not the permission it has.
If you want a coding agent that runs straight in the terminal, with no desktop app holding files from its own runtime, Verboo Code works as a CLI and offers unlimited tokens.
