Error messages

Failed to create unified exec process: helper_unknown_error: setup refresh had errors

Failed to create unified exec process: helper_unknown_error: setup refresh had errors

On Windows, Codex (the desktop app, the CLI or the VS Code extension) refuses to run even a trivial command like Get-Date, and prints:

Failed to create unified exec process: helper_unknown_error: setup refresh had errors

Tasks that a delegated agent starts on your PC show the same failure wrapped differently, as exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors. Either way, nothing reaches your shell. It's the sandbox failing first.

It spiked on October 8, 2026. A GitHub search that evening found 294 results for "setup refresh had errors" in openai/codex, 133 of them filed since October 7.

What the sandbox is refreshing

Codex runs commands on Windows inside a sandbox. In its "elevated" mode, the one in these reports, it sets up file permissions once with administrator approval and refreshes them later, adjusting the access lists (Windows' per-file permission entries) on your workspace and on the runtime files Codex ships. We read that code in the windows-sandbox-rs crate. If any single permission update fails during a refresh, it gives up with "setup refresh had errors", and because the sandbox fails closed, the command is refused.

"helper_unknown_error" only says the setup helper failed for a reason it didn't classify. The real reason is in the sandbox log, which one reporter found at %USERPROFILE%\.codex\.sandbox\sandbox.<date>.log.

The October 8 cause: node_repl.exe is in use

Most of the new reports show this line in that log:

open ACL target for root-only update: <file in use, cannot access> (os error 32)

Error 32 is Windows' "being used by another process". One detailed report traced it: the refresh tries to open node_repl.exe in Codex's runtimes\cua_node folder to fix its permissions, but Codex's own computer-use helpers already have it open, start about 35 seconds after launch, and keep it open while the app runs. So the refresh can never win. A Reddit thread the same day found the same file held by Codex's delegated exec server.

OpenAI merged a fix the day before, on October 7: “Avoid sharing violations when repairing Windows runtime ACLs”, which opens those files asking for less access so a running copy doesn't block it. By GitHub's comparison of the release tags it's in the 0.163.0 alpha builds published late on October 8, and not in the 0.162.0 release from earlier that day. (The desktop app bundles its own copy of the CLI, so its version number won't match these.)

The other cause: a .agents folder

A smaller group of reports, from late September on, log a failure on a .agents folder in the project instead ("deny ACE failed on ...\.agents"). An OpenAI contributor replied on October 5 that a fix for that one was "in-flight" too. A user's stopgap there was taking ownership of the folder with icacls /setowner, which only makes sense if that folder is the one named in your log.

What to do until the fix reaches you

• Quit Codex completely, including any Codex or node processes left in Task Manager, and try again. Several reporters say a restart and even a reboot didn't help with the in-use case, since Codex reopens the file on launch, but it's free to try.
• Switch the sandbox mode. In %USERPROFILE%\.codex\config.toml, add [windows] and under it sandbox = "unelevated". The config reference lists that key, and users in the main thread report it got the desktop app and the VS Code extension running again.
• Update when a release newer than 0.162.0 shows up, then remove the setting.

Know what you're giving up with the second step. OpenAI's Windows page describes unelevated as a fallback with "weaker network isolation than elevated" that "doesn't support denied read paths", so keep approval prompts on while you use it. On a work machine, check that your organization's policy allows it (that page says it's only for when policy permits).

Running codex doctor won't tell you more than the log does: for this error code its advice is to "repair or reinstall the Codex CLI". A Windows app repair didn't clear it for one reporter in the main thread, and for the error 32 case that fits: the problem is how Codex treats its own running files, which a reinstall puts straight back.