Repository navigation
Sandbox initialization fails with error 32, blocking local commands, file reads and automation after update 26.1002.51308, build 13417 #51607
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.1002.51308, build 13417
What subscription do you have?
PRO
What platform is your computer?
Windows 10 Pro, version 10.0.19045, 64-bit.
What issue are you seeing?
Codex can no longer run normal local commands or read files in my project through its sandbox. Even a simple command fails before it starts. Node and browser automation also failed during testing.
This is blocking my daily work because I rely on Codex to read project files, make changes and verify the results.
The main error is:
Failed to create unified exec process:
helper_unknown_error: setup refresh had errors
Some attempts instead report:
orchestrator_helper_exit_nonzero:
setup helper exited with status Some(1)
Node automation reports:
node_repl kernel exited unexpectedly
windows sandbox failed:
helper_unknown_error: setup refresh had errors
The sandbox log gives a more specific error:
runtime read/execute validation failed:
validate runtime read/execute access on
<LOCALAPPDATA>\OpenAI\Codex\runtimes\cua_node\<runtime-id>\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)
During the investigation, the same error also appeared for this runtime file:
bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll
What steps can reproduce the bug?
On my affected installation:
Open an existing local project in Codex desktop.
Ask the agent to run a harmless command, such as:
Write-Output 'LOCAL_TEST'
Alternatively, ask it to read an existing project document.
Normal execution fails during sandbox setup, before the requested command runs.
Restart Codex and try again. The failure persists.
Restart the computer and try again. Normal file reading still fails.
This describes what happens on my machine. I do not have a clean-install reproduction or know what originally triggered it.
What is the expected behavior?
Codex should be able to run ordinary commands and read files inside the authorized project through its normal sandbox.
I should not need an outside-sandbox approval just to read an existing project document.
This happened exclusively after update.
Additional information
There is a working workaround: when a command uses sandbox_permissions: "require_escalated" and is approved, it runs successfully outside the failing sandbox. The same project document was read successfully this way after the computer reboot.
That is a workaround, not a sandbox repair.
Troubleshooting so far:
Restarted the desktop app and the computer.
Reset the chat’s Node and browser automation kernels.
With explicit approval, stopped four identified Node runtime processes. Sandbox validation then progressed further but failed on the DLL mentioned above.
With separate approval, stopped the computer-use helper associated with that DLL. The desktop app immediately relaunched it.
New Node helpers also appeared, and the failure returned.
Ran codex doctor --json. It reported elevated Windows sandbox provisioning failure. Configuration loading, configured authentication and the desktop app-server handshake passed.
Checked for a desktop update. The updater reported that the app was up to date.
No sandbox disabling, antivirus exclusions, permission or ownership changes, runtime deletion, or reinstallation was performed.
The evidence suggests a conflict during runtime permission validation, but Codex cannot established the exact underlying cause. The process checks do not prove which individual handle causes the sharing violation.
Looking for a supported repair or workaround that preserves sandbox protection. I can provide redacted diagnostic output and relevant sandbox log excerpts.
Activity
github-actions commentedon Oct 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thankyou-Cheems commentedon Oct 7, 2026
I can reproduce this on Windows with the same desktop version, 26.1002.51308 (build 13417), and bundled Codex core 0.162.0-alpha.2. The updater reports up_to_date.
In my case, ordinary local Codex can successfully run Get-Location, but both existing and newly created dot-delegated tasks on the same connected, authorized computer fail before the command process starts:
helper_unknown_error: setup refresh had errors
Local read-only diagnostics found the more specific setup failure when opening:
\OpenAI\Codex\runtimes\cua_node<runtime-id>\bin\node_repl.exe
The operation returns os error 32 (file in use), followed by setup refresh had errors. File-usage queries identified processes descended from the current desktop application holding the same executable.
Rebooting the computer, reopening the desktop app, and signing out and back in did not resolve it. A fresh check after reopening found seven occupying processes created by the new desktop process. On October 7, 2026, UTC+8:
This supports the recurring runtime-file sharing conflict reported here. It does not establish which individual handle causes the failed open or prove the exact code change responsible. No processes were terminated or permissions changed during my diagnostics.
There is also a separate desktop history symptom: several dot-created conversations remain readable and unarchived through the cloud interface but are absent from the desktop Recent list. An earlier bounded desktop-log review counted 30,909 denied thread/read requests with source=thread_hydration and error -32003 between 13:42 and 18:04 (UTC+8), while thread/list still returned normally. This resembles #51572, but I have not established a common cause with the runtime lock. The latest post-restart text logs were empty, so that count is not evidence of the current hydration state.
I have not disabled the sandbox, added antivirus exclusions, changed ACLs/ownership, deleted runtimes or caches, or reinstalled. Please provide a supported recovery or fixed desktop/runtime version that preserves existing tasks and uncommitted project files.
Private paths, computer/environment IDs, conversation IDs, account information and raw logs are omitted.
Thankyou-Cheems commentedon Oct 7, 2026
Post-update follow-up from my Windows installation on October 7, 2026 (all times UTC):
Please track the remaining conversation visibility/loading problem separately from command execution, with #51572 as a related report. I have not rechecked post-update logs, so I cannot confirm whether the earlier thread_hydration / -32003 pattern persists.
lfai-aidev commentedon Oct 7, 2026
We are seeing the same failure on another Windows installation. It blocks both ordinary local commands and browser automation.
Environment, checked October 7, 2026:
A fresh sandboxed Get-Location still fails before PowerShell starts:
Resetting the browser automation runtime and requesting its initial state also fails before any page interaction:
The local sandbox log repeatedly records the following failure, including at 2026-10-07T15:16:43Z (path redacted):
Restarting Windows and Codex did not resolve it. Resetting the browser runtime did not resolve it either. A narrowly scoped, approved shell read with sandbox_permissions=require_escalated succeeded, so there is a workaround for individual shell commands, but browser automation remains unavailable. This is not a sandbox repair.
We have not identified the specific process or handle responsible for the sharing conflict. No sandbox disabling, ACL/ownership changes, antivirus exclusions, runtime deletion or reinstallation was performed during these diagnostics.
Please advise on a supported repair or fixed app/runtime version that preserves sandbox protection, existing conversations and local work. This report contains only redacted error excerpts and version details; no raw logs, credentials, project content or conversation transcripts are attached.
lfai-aidev commentedon Oct 8, 2026
Follow-up to our earlier report, with additional findings from October 7-8:
The process ancestry strengthens the evidence for a conflict involving runtime processes launched by Codex itself. It does not establish the exact underlying code defect. No processes were terminated or ACLs changed during the file-usage investigation.
Process IDs, local paths, runtime identifiers, account details, project information and chat identifiers are omitted. No raw logs or transcripts are attached.