If Codex on Windows suddenly fails every command with helper_unknown_error: setup refresh had errors right after an app update, check sandbox.log for a runtime read/execute validation failed line naming one of Codex's own running files, such as node_repl.exe or a bundled DLL, with Windows error 32 (ERROR_SHARING_VIOLATION). That exact signature means the October 2026 sandbox-repair regression is opening its own active runtime files with MAXIMUM_ALLOWED, which conflicts with the handles Codex itself is holding. Update to Codex Desktop build 26.1007.21434 or later to get the fix; if you cannot update immediately, use the temporary unelevated sandbox fallback rather than disabling isolation.

This is a narrow, version-specific regression, not every sandbox setup failure. For the broader classifier covering CreateProcessAsUserW failed, spawn EPERM, and other sandbox symptoms, use the Codex Windows sandbox error guide and return here only after you match the exact log signature below.

Match the Exact Failure Signature

Use this guide only when your sandbox.log shows all of the following:

• the top-level error is helper_unknown_error: setup refresh had errors, surfaced to the user as exec-server rejected request (-32603);

• the log line reads runtime read/execute validation failed: validate runtime read/execute access on <path>: open ACL target for root-only update: The process cannot access the file because it is being used by another process. (os error 32);

• <path> points inside Codex's own runtimes\cua_node\... directory, naming node_repl.exe, node.exe, codex-computer-use-swift.exe, or a loaded DLL such as VCRUNTIME140_1.dll;

• the failure started immediately after a Windows Desktop app update, with no new failures in logs from the day before; and

• restarting Codex or rebooting Windows does not clear the error, because the same runtime hash is revalidated on every setup refresh.

If your log instead names a path under C:\Program Files\WindowsApps\...\pwsh.exe, use the dedicated CreateProcessAsUserW failed: 5 guide instead. If no runtime-validation line appears at all, your failure is a different branch of the broader classifier above.

Why This Happens

OpenAI Codex issue 51601, opened October 7, 2026, documents the regression in detail. The reporter traced it to codex-rs/windows-sandbox-rs/src/acl.rs: when Codex's setup-provisioning step repairs read/execute permissions across the runtime tree, it opens each target file with access_mode(MAXIMUM_ALLOWED). On a file that Codex's own node_repl.exe or a loaded DLL is already running, requesting the maximum allowed access can implicitly include write access, which Windows refuses while the file is in use, returning ERROR_SHARING_VIOLATION (error 32). That single validation failure aborts the entire setup refresh, so every command fails before it starts, even read-only ones.

More than 30 users confirmed the same signature across Windows 10 and 11, multiple antivirus configurations, and both the Store/MSIX and standalone CLI builds, ruling out a single-machine cause. OpenAI pull request 51822, merged October 7, 2026, fixes it by restricting MAXIMUM_ALLOWED to directories that need to suppress child-ACL propagation; for files, it now requests only READ_CONTROL | WRITE_DAC, and only when an ACL change is actually needed. The fix shipped in Codex Desktop build 26.1007.21434, and multiple reporters on the GitHub thread confirmed normal sandbox setup after updating to that build or later with no workaround applied.

Step 1: Confirm You Have the Exact Signature

Before changing anything, read the last sandbox-setup section of the log:

$sandboxLog = Join-Path $env:USERPROFILE ".codex\.sandbox\sandbox.log"
Select-String -Path $sandboxLog -Pattern "runtime read/execute validation failed|ERROR_SHARING_VIOLATION|os error 32" |
  Select-Object -Last 20 |
  ForEach-Object Line

Expected result for this branch: at least one line naming a path under runtimes\cua_node\ and ending in (os error 32). Also record your installed version:

# In Codex Desktop: Settings > About, or:
Get-AppxPackage -Name "*OpenAI.Codex*" | Select-Object Name, Version

If the version is already 26.1007.21434 or higher and the error still appears, this specific fix does not apply to your case; preserve the log and open a new report referencing issue 51601 rather than assuming the same root cause.

Step 2: Update to the Fixed Build

Open the Codex Desktop app and check for updates, or reinstall from the official Windows download if the in-app updater does not offer the new build yet:

# Fully quit Codex, including the system-tray icon, before reinstalling
Get-Process -Name "Codex*" -ErrorAction SilentlyContinue | Stop-Process -Force

After updating, confirm the version and run one read-only command:

Get-AppxPackage -Name "*OpenAI.Codex*" | Select-Object Name, Version

Then in Codex, ask it to run one trivial read-only command (such as printing the current directory) and confirm it returns normally with no helper_unknown_error.

Step 3: If You Cannot Update Yet

If your organization has not approved the new build, the GitHub thread's most consistently reported interim option is switching the sandbox mode, not disabling isolation entirely:

# Back up your current config first
Copy-Item "$env:USERPROFILE\.codex\config.toml" "$env:USERPROFILE\.codex\config.toml.bak"

Then set sandbox = "unelevated" under [windows] in config.toml and restart Codex. Multiple reporters confirmed this restores basic command execution. This is a real isolation tradeoff, not a fix: unelevated mode is weaker than the default elevated sandbox, and at least one reporter noted it cannot preserve a custom deny-read permission profile. Treat it as a bridge until you can update, and restore the backed-up config once you do.

Do not use the per-file icacls /deny ACE workaround some reporters described unless you fully understand Windows ACL inheritance; it has to be reapplied on every runtime hash change and is easy to misapply. Prefer updating the app.

If the Error Persists After Updating

Common Failure Modes

Verify Your Fix With Aident Loadout

Follow https://aident.ai/SETUP.md to install the public aident CLI, then confirm authentication and discover a current read-only GitHub issue-search Action without touching your sandbox configuration:

aident account auth status
aident capabilities search --query 'Search GitHub issues for an exact Windows Codex error' --types '["action"]' --limit 5

Ask Aident Loadout to inspect the returned Action's input schema, preflight a bounded query for repo:openai/codex is:issue "helper_unknown_error", and execute it only after you approve the preflight. This confirms your Codex Desktop version matches the fixed-build guidance above using a read-only check, with no provider credential pasted into a prompt and no change to your local sandbox state.

Use Aident Loadout to run that same verification pattern for other exact-error Codex or Claude Code regressions as they come up.

Sources

• Windows app 26.1002.51308: sandbox setup fails with sharing violation when validating its own active runtime, OpenAI Codex issue, opened October 7, 2026, inspected October 22, 2026

• Avoid sharing violations when repairing Windows runtime ACLs, OpenAI Codex pull request, merged October 7, 2026, inspected October 22, 2026

• Codex Windows sandbox error guide, Aident, the broader classifier this page branches from

Refresh this guide if OpenAI changes the Windows runtime ACL repair logic again, ships a later regression with the same helper_unknown_error signature, or if the fixed-version number above is superseded by a further patch.