Windows sandbox fails in Codex & OWL 26.1002.52244

What version of the Codex App are you using (From “About Codex” dialog)?

26.1002.52244

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Codex cannot access local files or run commands on Windows. Every attempt fails with:

helper_unknown_error: setup refresh had errors

App: Codex & OWL 26.1002.52244, released October 7, 2026.
Windows package: OpenAI.Codex_26.1002.7124.0_x64.

The sandbox log reports Windows error 32 (“The process cannot access the file because it is being used by another process”) while preparing ACL permissions for:

node_repl.exe
VCRUNTIME140_1.dll inside the Codex cua_node runtime.

The affected runtime processes are launched by Codex itself:
ChatGPT.exe → codex.exe → node.exe / node_repl.exe.
codex-computer-use-swift.exe also runs from the same runtime.

I restarted the computer, reinstalled Codex, terminated the affected runtime processes, and temporarily paused 360 Total Security protection. None resolved the issue. The runtime processes appeared again, and sandbox initialization continued to fail.

Expected: Codex can read workspace files and run local commands.
Actual: Sandbox setup fails before commands execute, blocking local work.

I noticed the problem after the update. Sandbox logs are available.

What steps can reproduce the bug?

Open Codex & OWL version 26.1002.52244 on Windows.
Open a local workspace, for example:
C:\Users\ehaft\Documents\Codex\2026-10-07\new-chat-2
Ask Codex to list the workspace files using PowerShell:
Get-ChildItem -LiteralPath 'C:\Users\ehaft\Documents\Codex\2026-10-07\new-chat-2'
The command fails before execution with:
helper_unknown_error: setup refresh had errors
Check %USERPROFILE%.codex.sandbox\ sandbox logs.
They show runtime read/execute validation failing with Windows
error 32 while opening node_repl.exe for an ACL update.
Another attempt failed on the runtime's VCRUNTIME140_1.dll.

This reproduces consistently on my computer, including after a
computer restart and reinstalling Codex. Temporarily pausing
360 Total Security protection did not resolve it.

What is the expected behavior?

Codex should initialize the Windows sandbox successfully, read files in the authorized local workspace, and execute PowerShell commands.

Runtime processes launched by Codex itself should not prevent sandbox initialization or cause “setup refresh had errors”.

Additional information

App version: Codex & OWL 26.1002.52244, released October 7, 2026.
Windows package: OpenAI.Codex_26.1002.7124.0_x64.
Antivirus: 360 Total Security.

Troubleshooting already attempted:

Restarted the application and computer.
Reinstalled Codex.
Terminated node_repl.exe and codex-computer-use-swift.exe processes.
Temporarily paused antivirus active protection.
The problem persisted.

Process inspection showed:
ChatGPT.exe → codex.exe → node.exe / node_repl.exe.
codex-computer-use-swift.exe was also launched by ChatGPT.exe.
The runtime processes appeared again after termination.

Relevant log error:
runtime read/execute validation failed:
open ACL target for root-only update:
The process cannot access the file because it is being used
by another process. (os error 32)

Affected files were inside:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\

Failures occurred on node_repl.exe and, on another attempt,
node_modules@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll.

The exact cause is not confirmed. Sandbox logs are available.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Windows app 26.1002.51308: sandbox setup fails with sharing violation when validating its own active runtime #51601
Windows sandbox setup fails with error 32; browser control and commands blocked #51777
Windows sandbox provisioning fails with os error 32 when any runtime file is in use (0.162.0-alpha.2 regression) #51634
Windows: local execution remains blocked after reinstall/reconnect; missing Recents chats and duplicate computer registrations #51736
Windows sandbox setup fails with error 32 on node_repl.exe, blocking shell execution and browser automation #51741

Powered by Codex Action

I encountered the same issue with version 26.1002.52244 on two Windows 11 environments:

A Windows 11 VM on an Intel Mac, with McAfee
A physical AMD desktop running Windows 11, with Microsoft Defender

Both produced the same sandbox setup error: “helper_unknown_error: setup refresh had errors”. The logs showed “open ACL target for root-only update” failing with Windows error 32 on node_repl.exe in the cua_node/3dd31cfff853001c runtime.

Rolling back to the October 6 release using the offline MSIX package resolved the issue on both machines. After rollback, the About dialog shows app version 26.930.61225. The MSIX installer displayed package version 26.930.7945.0. Workspace file listing worked again without the previous startup error.

I downloaded the offline MSIX using the link on the Japanese version of this page (English version linked here):
https://www.codex-docs.com/en/docs/enterprise/windows-deployment
For reference, Windows displays the digital signature timestamp as October 6, 2026, 10:46:03 (see screenshot; the UI is in Japanese).

The app automatically downloaded an update after launch, but I have not clicked the install button. Since the download URL may be updated, I cannot guarantee that it will continue to provide the same package.

I’m seeing the same issue on Windows and can reproduce it consistently.

Additional environment details:

ChatGPT / Codex & OWL version: 26.1002.52244
Released: 7 Oct 2026
bundled codex-cli: 0.162.0-alpha.2
Windows sandbox configuration:

[windows]
sandbox = "elevated"
affected runtime:
cua_node\3dd31cfff853001c

The practical effect is that Codex cannot perform normal local work inside the sandbox at all.

Even very simple operations fail before execution. For example, I tested:

cmd /c echo CODEX_SANDBOX_OK

with explicit instructions not to retry outside the sandbox.

It failed before a process was created:

exec_command failed: CreateProcess {
message: "Rejected("Failed to create unified exec process:
helper_unknown_error: setup refresh had errors")"
}

This also affects ordinary file access. In normal Codex work, even reading project/prompt files causes Codex to request permission to run outside the sandbox, because the sandboxed operation cannot start.

My setup_error.json contains:

{
"code": "helper_unknown_error",
"message": "setup refresh had errors"
}

The sandbox log consistently points to the same root cause:

runtime read/execute validation failed:
validate runtime read/execute access on
C:\Users<USER>\AppData\Local\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\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 failure repeats on every sandbox setup refresh.

I have not applied ACL workarounds or downgraded the application. The current workaround is effectively to approve individual commands outside the sandbox, which makes normal Codex usage impractical because even read-only project operations require approval.

This appears to be the same regression described in this issue rather than a project/workspace-specific permissions problem.

I can reproduce the same failure on Windows after updating Codex today (October 7). It affects both an existing local task and a newly created task. Even Get-Location fails before the process starts:

exec-server (-32603): helper_unknown_error: setup refresh had errors

The sandbox log at 2026-10-07T21:27:27Z shows this specific failure (personal path redacted):

runtime read/execute validation failed:
validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\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)

Closing and reopening the Codex application did not resolve it. A subsequent minimal command still failed at approximately 21:55 UTC. Resource Monitor's Associated Handles search for node_repl returned no results at the time of inspection, so we have not identified the lock holder; that empty result does not establish that no file mapping/lock exists.

The log also names codex-command-runner-0.162.0-alpha.2.exe, but I have not independently verified the installed app version or CLI version. Later log entries show intermediate setup steps with errors=[] and successful helper copy/launch resolution, yet the actual command still fails.

No ACL changes, sandbox bypass, runtime deletion, or process termination were used during these checks. Feedback has also been submitted through the app. Is there a supported way to identify the process holding this runtime file, or a confirmed fix for this error-32 case?

Diagnostic report prepared by dot from actual tool results:
Windows local command execution remains broken after the October 7 incident was marked resolved. Repeated checks for this user have failed for approximately 14 hours, including after they reported installing an app update.
Latest verification: October 7, 2026, approximately October 7, 23:02 UTC (October 8, 07:02 Taiwan time),.

The Windows computer is listed as connected, attached and authorized for tasks.
I can send a request to an existing local task.
That task attempts the harmless PowerShell command Get-Location.
Execution fails before the command runs, with: “exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors”.
The user reported restarting the desktop app and later installing an update. Subsequent checks still failed. Their exact installed version has not been independently verified.
A separate failure also persists when I try to read an existing Codex task: “unsupported placement format version 2”. I cannot establish whether these two failures share a cause.
Impact: I cannot inspect, edit or test the user’s local project through the affected execution route. Chat and task messaging still work, so successful connection or task creation does not demonstrate that execution has recovered.
Could the team confirm whether the continuing Windows helper/setup failure is being tracked separately from the resolved thread-creation incident, and whether there is a supported fix or additional diagnostic information needed?

I can reproduce this on Windows after rebooting, reinstalling Codex, and terminating the related runtime processes.

My sandbox log’s first fatal error on October 7 was Windows error 32 while updating the ACL for VCRUNTIME140_1.dll in the Codex cua_node runtime. On October 8, the same error occurred for node_repl.exe, followed by setup refresh had errors. Even Get-Location fails before PowerShell starts.

The runtime file exists. Its owner is my user account, and its readable ACL includes ReadAndExecute for CodexSandboxUsers. Currently running node_repl.exe processes started after the first October 8 failure, so I cannot identify them as the cause of that initial failure.

Workaround confirmed: Changing sandbox from "elevated" to "unelevated" under [windows] in config.toml allowed commands to run successfully in the desktop app as well.

The issue occurs during the setup process for the elevated sandbox, and switching to "unelevated" bypasses that setup path.

This reduces sandbox isolation, so I plan to switch back to "elevated" once the upstream fix is available.

@johnl-oai

Adding another affected Windows installation, with a diagnostic summary.

Environment and impact

Codex desktop app: 26.1002.52244.
Windows 11 Home, 25H2, OS build 26200.9457.
The desktop updater reports that the installed app is up to date.
Existing and newly created local tasks are affected.
Conversation and task creation can work, but local command execution fails before the requested process starts, including ordinary read-only file operations. This blocks local development functionality.

Reproduction

Open the Windows desktop app.
Open an existing local task or create a fresh local task.
Request an authorized, minimal read-only local operation.
Setup fails before the requested command starts.

Observed outer error:

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

The setup-error record contains:

{
  "code": "helper_unknown_error",
  "message": "setup refresh had errors"
}

Diagnostic observations

A review of five recorded setup attempts found the same fatal failure involving the bundled node_repl.exe. Diagnostic signature:

runtime read/execute validation failed
... 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)

Setup then exits with status 1. This identifies the immediate setup failure, but does not identify which process holds incompatible access or establish the complete underlying cause.

A separate profile-folder warning explicitly says setup is continuing; it should not be confused with this fatal runtime-file validation failure. Intermediate completed ACL steps also did not establish that command execution recovered.

Troubleshooting actually performed on this installation

Closed and reopened the app.
Fully rebooted Windows.
Tried a freshly created local task as well as existing tasks.
Checked for an app update; none newer was offered.
Inspected the setup-error record and sandbox log.
Searched Resource Monitor's Associated Handles for node_repl.exe; no matching handles were shown. That is inconclusive, not proof that no file mapping or lock exists.
Task Manager showed eight running node_repl.exe processes. The inspected executable's properties showed it under the Codex application directory. Their presence alone does not prove they are stale or identify the blocking process.

The command-launch failure remained unresolved. I have not applied ACL/ownership changes, disabled security software, terminated runtime processes, downgraded/reinstalled the app, or switched to the unelevated sandbox as part of these checks.

WSL fallback UI observation

The documented WSL agent-environment option could not be reached in this build. Settings search finds Agent environment under General, but selecting the result leaves the General page visible without a Windows/WSL selector. The separate Integrated terminal shell setting is visible; it has not been treated as an agent-environment switch. WSL installation status has not been established, so this observation is not a diagnosis of why the control is missing.

Verified environment

Codex Desktop: 26.1002.52244, build 13536, channel prod; updater reported up to date.
Windows (exact OS edition/build not collected).
Bundled CLI version and Windows sandbox mode were not independently verified.

Minimal failure

In an existing local workspace, even a minimal read-only shell command fails before process creation:

exec_command failed: CreateProcess {
  message: "Rejected(\"Failed to create unified exec process:
  helper_unknown_error: setup refresh had errors\")"
}

The workspace files could not be read; the command body did not run.

Log evidence

2026-10-08 13:16:28: earlier sandbox setup completed with errors=[].
15:46:19, and again 15:57:03: sandbox runtime read/execute validation failed while opening the ACL target for a root-only update on:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_repl.exe
Windows returned os error 32: another process is using this file. The sandbox setup then exited with status 1.
After a normal Windows reboot, at 19:01:16, a single minimal read-only attempt produced the same runtime ACL validation error on the same file, again exiting with status 1.
A separate read-attributes ACE warning on the user-profile root also recorded error 32 but said continuing setup; the fatal error was the runtime validation.
The earlier successful logs used sandbox-setup helper directory ...\Codex\bin\5ea220ae823df3d7; the failed entries used ...\Codex\bin\9691020b546a15b2. This is correlation, not confirmed causation.

Checks and limits

The file node_repl.exe exists.
Windows Resource Monitor → Associated Handles searches for both node_repl.exe and cua_node returned no results at inspection time; the lock owner is unknown.
Normal Windows reboot did not resolve the error. No ACL edits, sandbox disabling, runtime/cache deletions, process killing, executable replacement, or privileged workaround were attempted.
The user's local project and production data were not modified during this incident.

Request

PR #51822 ("Avoid sharing violations when repairing Windows runtime ACLs") is merged. Could maintainers confirm which supported Windows Desktop production build contains the fix, and the supported recovery path for users on build 13536 that preserves sandbox protections, local chats and project files?

Full raw logs contain local paths and command fragments, so they have not been posted publicly; sanitized excerpts are retained and can be provided by an appropriate private support channel if required.

Environment
Codex Desktop: 26.1002.52244
Windows: Windows 10 x64
Workspace: A:\MyProject

Issue
All local command execution fails before the requested command starts with:
helper_unknown_error: setup refresh had errors
The sandbox log consistently reports:
runtime read/execute validation failed
validate runtime read/execute access on ...\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)
Troubleshooting already attempted

Restarted Codex
Restarted Windows
Launched Codex as Administrator
Closed unrelated CMD/PowerShell windows
Renamed the affected cua_node runtime folder so Codex recreated it
Checked Task Manager for stale Node/Codex processes
Checked Resource Monitor for persistent handles
Verified .git ownership is my normal Windows user, not CodexSandboxOffline

.git owner:
DESKTOP-82GVC5E\VeriduraDESKTOP

ProcMon evidence
ProcMon captures:
codex-windows-sandbox-setup.exe -> CreateFile -> ...\node_repl.exe -> SHARING VIOLATION
while the Codex runtime is using the same node_repl.exe.
Additional observation
My project is on A:\MyProject while the Codex runtime is under %LOCALAPPDATA%\OpenAI\Codex..., but the sandbox log successfully applies workspace ACLs before failing on the C: runtime file, so this appears to be a runtime/sandbox sharing conflict rather than a workspace ownership issue.

ATTACHED: ProcMon capture showing codex-windows-sandbox-setup.exe hitting a SHARING VIOLATION on node_repl.exe while the runtime process is active.

I’m seeing the same failure on another Windows machine, in both Codex Desktop and ChatGPT Work using local execution.

Codex Desktop version: 26.1002.52244 (confirmed by the app update check on October 8; reported up to date).
Windows version/build: not independently confirmed. The captured Resource Monitor module versions include 10.0.22621.x, but I am not treating those as a confirmed OS build.
First observed in this workflow: October 7, 2026; whether it began immediately after an update is not confirmed.
Workspace scope: reproduced consistently in one local workspace; other workspaces have not been systematically tested. Both clients fail on minimal local commands.

Even Write-Output 'runtime-check' fails before PowerShell starts with:

helper_unknown_error: setup refresh had errors

Sanitized sandbox-log excerpt from October 8:

runtime read/execute validation failed: validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\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)
setup refresh completed with errors
setup error: setup refresh had errors

There is also a nonfatal error 32 while opening the user-profile directory for a root-only ACL update. The fatal setup error names the runtime executable above.

Troubleshooting actually tried, without resolving the failure:

Restarted the app.
Rebooted Windows.
Fully quit Codex and ended remaining Codex node_repl.exe runtime processes, then reopened it.
Reinstalled the app.
Tested explicit shell/workspace selection and a minimal output-only command.
Ran equivalent local checks through ChatGPT Work; the same failure occurred there.

Resource Monitor showed four node_repl.exe processes with the exact runtime path above. That confirms the executable was loaded, but does not establish which process caused the sharing violation. No ACL changes, runtime deletion, or security-software changes were made as part of these checks.

Is there a supported workaround that preserves sandbox protection, or a build containing a fix? No complete logs or private project contents are attached.

I am experiencing the same issue on Windows since October 8, 2026. Codex was working normally the previous day, but after starting my computer today, it stopped executing commands.

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

Environment:

Windows 11 x64
Codex Windows package: 26.1002.7124.0
Runtime: 26.1007.11041
ChatGPT Plus subscriber

Troubleshooting already completed:

Confirmed PowerShell works normally outside Codex.
Verified that my project directory exists and is accessible.
Confirmed Node.js, npm, and Git work outside Codex.
Reinstalled the Codex runtime successfully.
Completely terminated and restarted Codex processes.
Restarted CodexSandboxService.OpenAI.Codex as administrator.
Ran the built-in Codex dependency diagnostics, which reported no problems.

None of these steps resolved the issue. Codex still cannot execute even a simple Get-Location command.

This completely blocks my development workflow. Please investigate this Windows regression and provide a fix or workaround.

I have also submitted a bug report through the Codex application.

I'm experiencing the same issue and need to restore computer use for my CAD documentation work. Can you confirm which supported Windows desktop build includes fix #51822, and whether there is a supported temporary recovery that preserves the existing sandbox protections?

Verified on this installation:

Desktop updater: 26.1002.52244, build 13536, production channel; checked again October 8 and still reports up to date.
Windows package: 26.1002.7124.0. Bundled CLI: 0.162.0-alpha.2. Windows 11 Core, build 26300. Sandbox setting: elevated.
Normal commands and computer-use startup fail before execution with helper_unknown_error: setup refresh had errors.
The sandbox log reports Windows error 32 during the root-only ACL update of node_repl.exe; after stopping those processes, it reports the same error on the computer-use runtime's VCRUNTIME140_1.dll.
Process-module inspection identified codex-computer-use-swift.exe loading that DLL. Stopping it caused the desktop app to restart it.
Fully quitting and reopening the app, and Windows Settings Repair, did not restore normal execution.

We also ran a controlled startup test from a separate terminal after fully quitting the app. The bundled codex.exe sandbox command successfully printed a test marker, returned exit code 0, and reported no stderr at 09:07 PDT on October 8. After reopening the app, ordinary commands and computer-use startup failed again with the same error 32. The standalone and in-app tests may have different effective permission profiles; this is not a claim that they were identical configurations.

No manual runtime ACL changes, sandbox-mode changes, security-software changes, or binary replacements were made. The successful standalone test did not restore the in-app workflow.

Please identify the desktop release containing #51822, or the supported next step for this installed build. A merged source fix alone has not made an update available to this installation. This comment was prepared with Codex assistance and posted at my request; private paths, raw logs, screenshots, and project files are omitted.

I'm also experiencing this failure on Windows in the Codex desktop app on October 8, 2026.

Every attempted local command fails before execution with:
Failed to create unified exec process: helper_unknown_error: setup refresh had errors

The fallback Node runtime also exits unexpectedly. Browser automation fails with:
windows sandbox failed: helper_unknown_error: setup refresh had errors

This blocks workspace file access, command execution, and browser automation, preventing us from continuing an existing website implementation and deployment.

The failure was reproduced with both the default command runner and an explicitly selected Windows PowerShell executable. No workspace changes were made.

The installed app version and underlying sandbox-log cause have not yet been verified. We have not tested restarting or reinstalling the app.

Adding an independent Windows reproduction from October 8, 2026, with sanitized observations.

A minimal Get-Location request fails before the command process is created:
exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors

This reproduced with both Windows PowerShell 5.1 and the bundled pwsh.exe. The latest attempt was at 2026-10-08 15:57:26 UTC (23:57:26 UTC+8).

Relevant sandbox-log excerpt (personal path removed; Windows error text translated from Chinese):
runtime read/execute validation failed: validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\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)
setup error: setup refresh had errors
setup refresh: exited with status ExitStatus(ExitStatus(1))

The fatal errors array contains this runtime-file validation failure. There is also an error-32 warning while opening the user-profile root for a read-attributes ACE, but that line explicitly says "continuing setup".

The same log records setup completing with errors=[] at 15:13 UTC, followed by failures on the same node_repl.exe at 15:19, 15:43, and 15:57 UTC. The earlier successful setup entry did not mean subsequent command execution was working.

Process observations:

Process Explorer's "Find Handle or DLL" search for node_repl.exe returned four node_repl.exe processes, PIDs 19912, 22832, 30688, and 35096, all referencing the runtime path above.
All four search results had Type "DLL". This establishes that the executable was mapped in those processes; it does not identify a specific incompatible handle or prove which process caused the sharing violation.
Earlier process inspection showed codex.exe as the parent of the observed runtime processes, using the Codex bin directory 9691020b546a15b2.
After fully exiting ChatGPT, the two processes being observed at that point disappeared. Reopening the app, reconnecting, and retrying still failed.

Reinstalling the client and recreating the workspace did not resolve the failure. The built-in dependency diagnostics reported healthy dependencies.

For version correlation, the sandbox log's package path contains OpenAI.Codex_26.1002.7124.0_x64__2p2nqsd0c76g0. This is the package identifier recorded in the log, not an independently verified About-dialog version. The exact Windows edition/build has not been verified.

Could maintainers confirm the supported recovery path or desktop build containing a fix for this failure, while preserving sandbox protections? Personal paths, project details, screenshots, and complete raw logs are omitted.

Update: Working workaround confirmed on Windows 11.
OpenAI Support suggested switching the Windows sandbox mode from elevated to unelevated.
My configuration previously contained:
[windows]
sandbox = "elevated"

I changed it to:
[windows]
sandbox = "unelevated"

After completely restarting Codex Desktop, command execution started working again.
Verification: Get-Location successfully returned my project directory. Previously, the same command failed with helper_unknown_error: setup refresh had errors.
This workaround restored PowerShell command execution without reinstalling Codex.
Important: This is a workaround, not a confirmed fix for the underlying issue. The unelevated sandbox mode may provide different security isolation than elevated.
Hopefully this helps others experiencing the same problem. Thanks to OpenAI Support for suggesting the workaround!

confirming that the proposed fix works

…

On Thu, Oct 8, 2026 at 1:15 PM Lovish-byte ***@***.***> wrote: *Lovish-byte* left a comment (openai/codex#51778) <#51778 (comment)> Update: Working workaround confirmed on Windows 11. OpenAI Support suggested switching the Windows sandbox mode from elevated to unelevated. My configuration previously contained: [windows] sandbox = "elevated" I changed it to: [windows] sandbox = "unelevated" After completely restarting Codex Desktop, command execution started working again. Verification: Get-Location successfully returned my project directory. Previously, the same command failed with helper_unknown_error: setup refresh had errors. This workaround restored PowerShell command execution without reinstalling Codex. Important: This is a workaround, not a confirmed fix for the underlying issue. The unelevated sandbox mode may provide different security isolation than elevated. Hopefully this helps others experiencing the same problem. Thanks to OpenAI Support for suggesting the workaround! — Reply to this email directly, view it on GitHub <#51778?email_source=notifications&email_token=AB56MCUTGLAT2UGYNY4JP7L5S7DRPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMBWGUYTQOJQGQ3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6065189046>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB56MCQDBCR2IYIGBFOB2KD5S7DRPAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKNZUHEZDMOBYGIZ2C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AB56MCRNP2CURMTMGJEUMQL5S7DRPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMBWGUYTQOJQGQ3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AB56MCUJW44J67DWPHI5UTT5S7DRPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMBWGUYTQOJQGQ3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: <openai/codex/issues/51778/6065189046 ***@***.***>

Independent reproduction on Windows with Codex package OpenAI.Codex_26.1002.7124.0_x64 and elevated sandbox.

After a full Windows reboot, local PowerShell execution still failed before the command started.

The sandbox log identifies runtime read/execute validation failed on VCRUNTIME140_1.dll, with Windows os error 32, followed by helper_unknown_error: setup refresh had errors and exec-server error -32603.

Process Explorer confirmed that codex-computer-use-swift.exe had the affected DLL loaded, although an exclusive blocking handle was not established.

No manual DLL replacement, ACL modifications, or sandbox configuration changes were made. Detailed diagnostics were submitted privately to OpenAI Support.

Confirming the same failure on my Windows Codex desktop installation, version 26.1002.52244.

The problem persists after a full Windows restart and reopening the desktop app. Local Workers cannot run PowerShell or read the files required for their assignments.

My latest sandbox log, sandbox.2026-10-09.log, records repeated failures at 02:26:08 and 02:26:38 UTC:

runtime read/execute validation failed
...cua_node\3dd31cfff853001c\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)
setup error: setup refresh had errors

Changing the task configuration from read-only to workspace-write did not resolve the failure.

PR #51822 appears directly relevant. Can the maintainers identify the first Windows desktop release containing that fix and confirm the supported recovery procedure?

No manual ACL changes, security-control changes, or runtime-file deletions have been performed.

Additional reproduction on Windows — October 9, 2026

Desktop app version: 26.1002.52244, build 13536, production channel. The updater reports no available update.

Both browser automation initialization (await cua.getState()) and a simple PowerShell command (Get-Location) fail before execution:

helper_unknown_error: setup refresh had errors

The sandbox log identifies this failure:

runtime read/execute validation failed on:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\
3dd31cfff853001c\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)

Restart/retest attempts have not restored functionality.

Process Explorer showed two processes loading this executable. It also showed numerous process handles from NGenuity2Helper.exe to these processes. This does not establish that NGENUITY causes the file lock; the cause remains unconfirmed.

No ownership reset or sandbox protection reduction has been applied.

Please investigate and advise on a supported fix.

Additional Windows reproduction on October 9, 2026:

Displayed desktop app version: 26.1002.52244. The sandbox log records package OpenAI.Codex_26.1002.7124.0_x64; these are separate version fields.
Get-Location succeeds in a normal local Codex session, while dot-delegated Get-ChildItem fails during initialization with "helper_unknown_error: setup refresh had errors". The effective permission profiles have not been established as identical.
A delegated retry at 13:36:48 UTC failed. sandbox.2026-10-09.log records a fatal error at 13:37:05.292 UTC: "runtime read/execute validation failed" → "open ACL target for root-only update" → Windows os error 32, followed by setup exiting with status 1.

The affected file (user-specific prefix removed):
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_modules@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll

Using Windows tasklist and PowerShell Get-Process module FullName inspection, I verified that codex-computer-use-swift (PID 23056) had this exact DLL loaded, then terminated that process once before the failed retry. At 14:13 UTC, a process with the same name was present under PID 29400; at 14:15 UTC, module inspection again verified this exact DLL. Its start time was not captured, so this does not establish that PID 29400 was present at the failed retry or identify the sole blocking process.

Rebooting Windows, restarting the app, and Windows Repair had not resolved the problem. No manual ACL changes, runtime deletion, or permission weakening were applied.

Could maintainers confirm which supported Windows desktop release contains PR #51822, its rollout ETA, and a supported recovery path that preserves sandbox protections?

Update: local command execution and file reads started working again on my Windows installation after updating the desktop app through Microsoft Store and reopening it.

What helped here:

Install the available app update through Microsoft Store.
Reopen the desktop app and check the About screen. Mine now shows 26.1007.21434 (previously 26.1002.52244).
Retest in the affected local tasks.

Verified on October 9, 2026, at 22:43–22:52 UTC:

A simple output-only command completed with exit code 0.
PowerShell read and SHA256 checks on existing workspace files succeeded.
Two existing synthetic Python unit-test suites ran successfully: 13 + 9 tests, zero failures, both exit code 0.
The original affected task accepted a message, returned a response, and read an existing planning document successfully.

No manual ACL changes, runtime-file replacement, or sandbox-mode change were used for this recovery.

This is a recovery report from one installation, not confirmation that every affected feature is fixed. Browser automation and the earlier CIM/WMI access problem have not been revalidated, and I have not verified whether this desktop build contains PR #51822. A separate Library file-transfer issue still blocks part of my workflow.

Update on my earlier report: after the latest app update, the previous setup-refresh error no longer reproduces in our tested configuration.

We verified local reads and a complete create/write/read-back/delete cycle in a session configured with the intended local workspace. We also successfully tested authorized messages between existing sessions, including acknowledgement replies.

This confirms recovery for the setup we tested, rather than a blanket removal of workspace or session permission limits. Thanks for the update!

Navigation Menu

Repository navigation

Windows sandbox fails in Codex & OWL 26.1002.52244 #51778

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment and impact

Reproduction

Diagnostic observations

Troubleshooting actually performed on this installation

WSL fallback UI observation

Related fix and questions

4 remaining items

Verified environment

Minimal failure

Log evidence

Checks and limits

Request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows sandbox fails in Codex & OWL 26.1002.52244 #51778

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Oct 7, 2026

fliedonion commented on Oct 7, 2026

tayapro commented on Oct 7, 2026

stefanobo commented on Oct 7, 2026

AwesomeMusicStudio commented on Oct 7, 2026

Rachellaiirf commented on Oct 8, 2026

DaidalosKnossos commented on Oct 8, 2026

spoderman916-hub commented on Oct 8, 2026

Environment and impact

Reproduction

Diagnostic observations

Troubleshooting actually performed on this installation

WSL fallback UI observation

Related fix and questions

Lishunz commented on Oct 8, 2026

ve6btc commented on Oct 8, 2026

romzlatin-glitch commented on Oct 8, 2026

4 remaining items

a1219784725-creator commented on Oct 8, 2026

Verified environment

Minimal failure

Log evidence

Checks and limits

Request

DSTELZNER1337 commented on Oct 8, 2026

sashakucharczyk commented on Oct 8, 2026

Lovish-byte commented on Oct 8, 2026

brgla commented on Oct 8, 2026

CQUARED-DS commented on Oct 8, 2026

starleafs commented on Oct 8, 2026

Lovish-byte commented on Oct 8, 2026

sashakucharczyk commented on Oct 8, 2026

kelvinolg-cyber commented on Oct 8, 2026

Lookwright commented on Oct 9, 2026

Velicor commented on Oct 9, 2026

lkk1990 commented on Oct 9, 2026

romzlatin-glitch commented on Oct 10, 2026

Syntrion-AI commented on Oct 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions