Repository navigation
Windows app 26.1002.51308: sandbox setup fails with sharing violation when validating its own active runtime #51601
Description
Title: Windows app 26.1002.51308: sandbox setup fails with sharing violation when validating its own active runtime
Summary
After updating the Windows Codex app to 26.1002.51308 (build 13417), all command execution fails before the requested command starts:
helper_unknown_error: setup refresh had errors
Node REPL also fails:
trusted Node process exited unexpectedly
Sandbox logs show that runtime ACL validation attempts to open files currently used by Codex itself and fails with Windows error 32 (ERROR_SHARING_VIOLATION).
Environment
- OS: Windows
- Codex app: 26.1002.51308, build 13417
- Windows sandbox: elevated
- Previous helper directory:
Codex\bin\5ea220ae823df3d7 - Previous command-runner version: 0.160.1
- Current helper directory:
Codex\bin\979a96ce184041d1 - Current runtime:
cua_node\2c9e75c4e9c71beb
Expected behavior
Sandbox setup should complete while Codex's own runtime processes are running. Commands and Node REPL should start normally.
Actual behavior
Every command fails during sandbox setup refresh. The relevant log entry is:
runtime read/execute validation failed: validate runtime read/execute access on
C:\Users\<USER>\AppData\Local\OpenAI\Codex\runtimes\cua_node\2c9e75c4e9c71beb\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)
After stopping the two node_repl.exe processes during an earlier diagnostic test, validation passed that file but failed with the same error on:
...\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll
Stopping those processes did not resolve the issue.
Regression evidence
From %USERPROFILE%\.codex\.sandbox\sandbox.2026-10-07.log:
- Previous helper: 50 successful setup refreshes, no failures.
- Current helper: 13 failed setup refreshes, no successes.
- Latest recorded failure: October 7, 2026, 15:05 JST.
- Logs from October 6 and earlier contain no
runtime read/execute validationentries.
Both restarting the app and rebooting Windows failed to resolve the problem. No newer app update was available when checked.
Diagnostic findings
- There is only one runtime under
runtimes:cua_node\2c9e75c4e9c71beb. - There are no old runtime directories or
.staging-*directories. - Therefore, the stale-runtime workaround described in Windows sandbox helper fails with helper_unknown_error: setup refresh had errors on every exec_command and file read #44696 does not apply here.
- Processes using the affected runtime include Codex's own
node_repl.exe,node.exe, andcodex-computer-use-swift.exe. - Read and execute permissions for the sandbox group are already present.
- The earlier, separate error 5 /
helper_sandbox_lock_failedissue has been resolved. - A separate error 32 involving
C:\Users\<USER>is followed bycontinuing setup; it is not the fatal failure described above.
The latest investigation was read-only. No files, configuration, or permissions were changed.
Suspected cause — not confirmed
Based on the public openai/codex main branch inspected on October 7, 2026:
In codex-rs/windows-sandbox-rs/src/acl.rs, ensure_allow_mask_aces_with_inheritance_impl opens a target with OpenOptions and access_mode(MAXIMUM_ALLOWED) when inheritance == 0, using the context:
open ACL target for root-only update
In setup_provisioning/setup_runtime_bin.rs, ensure_runtime_tree_readable calls grant_read_execute_aces(..., 0) for files throughout the runtime tree.
My hypothesis is that requesting MAXIMUM_ALLOWED may include write access when opening running executables or loaded DLLs, causing a sharing violation. That validation error then causes the entire setup refresh to fail, blocking all command execution.
This is an inference from the logs and public source, not a confirmed root cause. I have not verified that the public main branch exactly matches the installed app build.
Possible fix directions
Please consider whether ACL inspection can open targets with READ_CONTROL only, requesting WRITE_DAC separately only when an ACL change is actually needed.
It may also be worth reviewing how validation handles files already in use by Codex. Any handling of sharing violations should preserve the required sandbox access checks rather than simply bypassing them.
Related issue
#44696 reports runtime validation failures, but its stale-runtime workaround does not match this environment.
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
MazDragon commentedon Oct 7, 2026
Seeing the same failure with the same helper and runtime on another Windows installation.
A normal delegated PowerShell Get-Location fails before process creation with: exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors.
The sandbox log at 2026-10-07 06:35:28 UTC reports runtime read/execute validation failing on the runtime's bin\node_repl.exe, with "open ACL target for root-only update" and "The process cannot access the file because it is being used by another process. (os error 32)". Earlier attempts reported the same error on bin\node_modules@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll.
Recovery attempts:
No manual ACL, cache, or security-setting changes were made for the recovery attempts listed above. The root cause remains unconfirmed.
Update: After backing up the configuration, setting windows.sandbox to "unelevated", and restarting the app, the same existing delegated thread ran Get-Location normally (exit 0, expected working directory). A read-only check confirmed the configured setting and matching backup. This restored basic command execution through the configured fallback; the elevated-sandbox failure remains unresolved. The effective runtime implementation was not exposed by the check.
KazxMartin commentedon Oct 7, 2026
Additional reproduction and controlled access-mask comparison on Windows 11 Pro x64 (10.0.26200), reported with the affected user's explicit authorization
Environment and impact
Update correlation
Windows deployment logs show the package updating from 26.930.7945.0 to 26.1002.6548.0 on 2026-10-07 at approximately 08:22–08:28 Europe/Moscow
Previous sandbox logs show successful setup with command runner 0.160.1; subsequent logs show the current helper failing
This is evidence of a regression correlation, not a debugger-level match of the installed helper to source
Failure
The fatal setup error is associated with the active runtime file:
After an explicitly authorized termination of the existing Node REPL processes, validation instead failed on the same runtime's Computer Use VCRUNTIME140_1.dll
Stopping helpers did not provide durable recovery; restarting the app did not restore operation
The runtime directory currently contains one runtime version, with no stale staging directory observed
Non-mutating Win32 comparison
Against the same active node_repl.exe, two rounds of CreateFileW probes produced:
All other arguments were identical: share read/write/delete (7), OPEN_EXISTING (3), FILE_FLAG_BACKUP_SEMANTICS (0x02000000), null security/template arguments
Handles were immediately closed; no file contents or ACLs were changed
The file's security descriptor was checked before/after and was unchanged
Ten matching Node REPL processes were still present during the latest comparison
These probes ran in a separately approved diagnostic shell outside the failing sandbox
They establish the access-mask-dependent open failure, not successful end-to-end execution of a repaired elevated sandbox
Scope of suspected fix
The public change #49690 intentionally uses MAXIMUM_ALLOWED for non-inheriting ACL updates to preserve child permissions
We are not proposing blindly removing that behavior or bypassing validation
Please investigate whether inspection of active EXE/DLL targets can use READ_CONTROL first and request ACL changes only when required, while retaining the intended directory inheritance guarantees
A separate one-off unelevated diagnostic launched Node successfully, while the elevated equivalent failed
The persistent configuration has not been changed, no runtime/helper binaries have been replaced, and no manual ACL changes have been made
A separate official 0.160.1 comparison is planned but has NOT yet been performed on this installation
Requested outcome
Please prioritize a supported recovery that restores ordinary commands and Browser Use / Computer Use while retaining elevated isolation
Preferred: a fixed desktop/helper build with regression coverage for active bundled EXE/DLL files and preserved child ACLs
Alternative: guidance on whether an official stable CLI can be used independently with the existing browser/computer-use integration, without replacing signed desktop components
Please identify the fixed version when available, or confirm the supported interim procedure and its limitations
No credentials, browser contents, private project URLs, personal paths, raw logs, or chat transcripts are included in this comment
AmbasaS2 commentedon Oct 7, 2026
Additional affected installation: all business and development work blocked for approximately two hours
I am reporting another affected Windows desktop installation. The user explicitly authorized this report and states that their entire business and development workflow has been effectively paralyzed for approximately two hours. This includes day-to-day business operations, signed-in Chrome workflows, advertising and sales management, software implementation, and verification. Please treat this as an ongoing operational blocker.
Existing chat messages can still be sent, but Browser/Computer Use cannot initialize and normal sandboxed local commands fail before execution. Separately approved outside-sandbox diagnostic commands work; they do not restore the user's normal browser and development workflow.
Reproduction and error
On this affected installation, calling the documented Browser Use entry point
await cua.getState();fails before browser inventory or any Chrome page can be returned:The fatal sandbox log identifies:
After specifically approved helper termination, validation progressed to the same sharing violation on
@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll. The desktop app immediately relaunched its computer-use helper after that helper was separately approved for termination. A subsequent full desktop app restart again reproduced the node_repl.exe validation failure.New controlled access-mode evidence
Without changing file contents or ACLs, we opened and immediately closed handles for the active node_repl.exe and VCRUNTIME140_1.dll. Both tests used FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, OPEN_EXISTING, and FILE_FLAG_BACKUP_SEMANTICS:
This supports the access-mode hypothesis in this issue. It does not establish that public main is identical to the installed binary.
Environment and recovery already attempted
0.162.0-alpha.2.26.1002.51308, build13417, prod,up_to_date.OpenAI.Codex_26.1002.6548.0. The difference between these version labels has not been reconciled.Relationship to today's Work rollback
The separate new Work window's Send button also remains unresponsive. The status incident acknowledges inability to create new Work threads and rollback of version 26.1002.51308:
https://status.openai.com/incidents/01M4ADHMMBK7K92NJFJ0DXRYJM
That announcement does not explicitly cover this Browser/Computer Use runtime sharing violation. Please confirm whether the rollback will also restore Chrome access and normal sandboxed execution, or whether a separate fix is required. Please provide a supported recovery path and restoration guidance that preserves the user's existing data and sandbox protections.
Personal paths are anonymized. No credentials, account details, customer/business data, screenshots, full session transcripts, or raw logs are included.
Master-Zhi commentedon Oct 7, 2026
Additional reproduction on another Windows installation, with a before/running/after control experiment supporting the access-mask regression.
Verified environment and failure
A full Windows reboot was independently verified from LastBootUpTime. After reboot, Codex started new node_repl.exe processes, and the subsequent sandbox refresh failed on that executable again. This was not merely an old process surviving an app restart.
Controlled Win32 experiment
All probes used CreateFileW with FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE (7), OPEN_EXISTING (3), and FILE_FLAG_BACKUP_SEMANTICS (0x02000000). Handles were immediately closed; no content or ACL writes were performed by the probes.
For an independent control, we copied Windows PING.EXE into a disposable project-local diagnostic directory, launched that copy with "-n 4 127.0.0.1", and let it exit normally. The copy was then removed.
This isolates running-image state and desired access as sufficient to reproduce the sharing violation on this host, without stopping Codex helpers or changing their permissions.
Version-pinned source correlation
The inspected rust-v0.162.0-alpha.2 source follows this path:
Sources:
These are local reproduction plus version-pinned source evidence, not a debugger/hash match of the installed setup helper or an end-to-end test of a patched build.
Workaround verification and requested fix
A single invocation using the same bundled CLI with:
codex.exe sandbox -c 'windows.sandbox="unelevated"' -- powershell.exe -NoProfile -Command Get-Locationsuccessfully launched PowerShell; the diagnostic invocation also read a project-local JSON file. Persistent configuration was not changed. This does not establish recovery of every desktop tool or PPT parsing.
Please provide a fixed elevated-sandbox build with regression coverage for active EXE/DLL targets while preserving the child-ACL propagation guarantees intended by #49690. Inspection should avoid requesting unnecessary file-content access; a blanket ACL reset or skipped validation is not proposed.
No credentials, private project paths, account/device identifiers, raw logs, or chat transcripts are included.
KazxMartin commentedon Oct 7, 2026
Follow-up to my reproduction above: we are keeping
windows.sandbox = "elevated"and are not replacing bundled executables or modifying ACLsCould you provide an official signed installer/package for the previous working Windows desktop version, or a supported in-app rollback procedure?
On this installation the Windows package updated from
26.930.7945.0to26.1002.6548.0; the current app reports26.1002.51308, build13417The previous sandbox logs showed successful operation with command runner
0.160.1We need to resume Browser Use / Computer Use in the existing desktop chat and authenticated browser tabs, not merely run an older standalone CLI separately
Please clarify:
We understand that the status incident does not currently confirm a fix for this sandbox failure
An official previous installer or supported rollback would allow work to resume without weakening isolation or manually swapping signed components
doc66666 commentedon Oct 7, 2026
Consolidating my report #51613 here after reviewing the duplicate suggestion. This adds a measured end-to-end recovery to the access-mask evidence already collected in this issue.
Verified installation and failure
windows.sandbox = "elevated".cua_node/2c9e75c4e9c71beb.whoamistill failed before execution withhelper_unknown_error: setup refresh had errors.node_repl.exe, withopen ACL target for root-only updateand Windows error 32. Loaded runtime DLLs produced the same failure.Controlled access-mask comparison
Against the same active
node_repl.exeandVCRUNTIME140_1.dll, with share read/write/delete, OPEN_EXISTING, and FILE_FLAG_BACKUP_SEMANTICS:Temporarily denying only FILE_WRITE_DATA + FILE_APPEND_DATA (mask 0x6) to the current user on node_repl.exe made the MAXIMUM_ALLOWED open succeed. The original ACL was restored after this initial controlled comparison.
The matching published source contains the relevant branch at rust-v0.162.0-alpha.2 acl.rs. The installed helper has not been debugger- or hash-matched to that source.
Measured elevated-sandbox recovery
After backing up original security descriptors, I applied that same narrow, non-inheriting current-user deny ACE to six runtime files with sharing conflicts: node_repl.exe, node.exe, codex-computer-use-swift.exe, VCRUNTIME140_1.dll, VCRUNTIME140.dll, and MSVCP140.dll. Read, execute, and ACL-management access were retained; file contents were not modified.
The configuration remained elevated. Subsequent actual tests showed:
<MACHINE>\CodexSandboxOffline.codex doctorreported sandbox.helpers.status=ok, backend=elevated, provisioning=complete. Setup logs recorded errors=[].This is a reversible local workaround, not a general recommendation or an upstream fix. It can interfere with in-place runtime updates, and replacing the runtime may require reapplication. ACL backups and a rollback script were retained.
Reliability needs priority
I appreciate the new features and fast iteration, but shipping new capabilities while recurring Windows sandbox failures block basic development work is unacceptable. Reliability is a core feature too. Users should not have to diagnose Win32 handle access or manually alter runtime permissions just to keep working after an update.
Please prioritize a supported elevated-sandbox fix and regression coverage for active EXEs and loaded DLLs. Any fix should preserve deny ACEs and the non-inheriting directory-update guarantees intended by #49690, rather than bypass validation or apply a blanket ACL reset.
I will close #51613 as a duplicate after linking this evidence. Closing that report does not mean the upstream bug is resolved.
Personal paths, account/device identifiers, SIDs, credentials, private project data, and full transcripts are omitted.
erson commentedon Oct 7, 2026
Consolidating #51623 here. The access-mask diagnosis in this thread matches what I found. This comment adds a tested source fix with a regression test.
Proposed fix: erson@2bd3cd5 (2 files,
codex-rs/windows-sandbox-rs/src/acl.rsandacl_tests.rs). The repository does not accept external PRs, so I am linking the commit instead.ensure_allow_mask_aces_with_inheritance_implreads the DACL throughfetch_dacl_handle(READ_CONTROL) for both root-only and inheriting grants.MAXIMUM_ALLOWEDhandle only when at least one ACE must be written. The no-propagation behavior from Preserve PowerShell relative paths in the elevated Windows sandbox #49690 for root-only updates is unchanged. An up-to-date ACL, which is the case for these runtime files, is never opened for write.noninheriting_grant_skips_open_for_write_when_ace_is_present: it holds a read-only-sharing handle on the target, like a loaded image. Onmainit fails with the exact production error (open ACL target for root-only update … (os error 32)). With the fix it passes.noninheriting_read_attributes_preserve_unprotected_child_daclstill passes, and the set of other failing tests incargo test -p codex-windows-sandboxis unchanged on my machine.End-to-end, Windows 11 26200, app 26.1002 open with the computer-use helper holding the runtime files. The baseline is the bundled
0.162.0-alpha.2. The fix is a local build ofmainwith the commit.codex sandbox -P :workspace:cmdread/write,powershell.exeandpwsh.exewrite/readsetup refresh had errorserrors=[]codex exec -s workspace-write -c windows.sandbox="elevated" -c features.prefer_mxc=false, same model on both buildsFailed to create unified exec process: helper_unknown_error: setup refresh had errors, no file writtenerrors=[], probe file written and read backThe fix also removes the non-fatal
failed to grant non-inheriting read-attributes ACE on user profile … (os error 32)warning.Limits:
codex-code-mode-host.exewith the localcodex.exe, because the V8 prebuilt could not be downloaded.prefer_mxc), which does not use this code path. I could not test the fix inside the app itself.Tong-tastsy commentedon Oct 7, 2026
Additional affected installation: Windows 11 build 22631; bundled 0.162.0-alpha.2 fails, separate npm 0.154.0 executes a read-only probe
Submitted at the affected user's explicit request. This adds an independent reproduction and an older-CLI comparison to this existing report rather than opening another duplicate. Personal paths and identifiers are redacted. The observations below are from this user's logs, screenshots, and reported test results, not from the other reporters' machines.
Environment
10.0.22631, x64,zh-CN.codex-cli 0.162.0-alpha.2.%LOCALAPPDATA%\OpenAI\Codex\bin\979a96ce184041d1.%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\2c9e75c4e9c71beb.elevatedafter an unsuccessfulunelevatedtest.Desktop reproduction and actual result
cmd.exe /d /c echo CODEX_SANDBOX_OK.The same failure occurs in a newly created empty project and new thread, not just the original project/thread. The captured sandbox log explicitly includes the new probe directory and the same DLL error.
Relevant log excerpt
Paths are anonymized; the Chinese Windows error text is retained. It means that another process is using the file.
setup_error.jsoncontained:{"code":"helper_unknown_error","message":"setup refresh had errors"}Manual
sandbox setup --elevated --current-userreported success. Separate provisioning logs showWFP setup succeededandsetup provisioning binary completed; subsequent per-task refreshes still failed.doctorreportedsandbox.helpers.status=failwith the generic structured provisioning failure.Process observations and unsuccessful recovery attempts
codex-computer-use-swift.exeas loading the exact DLL above.unelevatedwas not a usable fallback: it explicitly refused to run because it could not enforce the active deny-read restrictions. The configuration was returned toelevated; those restrictions were not intentionally bypassed.CLI comparison
The desktop application was normally closed for the standalone CLI tests. Both used the same Windows user and the same dedicated probe directory. The directory was initialized as a Git repository during troubleshooting.
Bundled
0.162.0-alpha.2: failed. The CLI reached model/tool execution using the configuredgpt-6-lunamodel,approval: never, andsandbox: read-only. Actual command-tool calls failed before the process started:The post-run process-inspection command was accidentally concatenated with another PowerShell command and did not execute. Consequently, this test does NOT establish whether the Swift helper was absent throughout the CLI run, or whether that run failed on the same underlying file. A new low-level log for that CLI attempt was not captured.
Separate npm
@openai/codex@0.154.0: succeeded on the minimal probe. The user ran the following after changing to the probe directory:The user reported actual execution output, not just the model repeating the requested text:
Comparison limitations: This was not a fully controlled version-only A/B test. The old client initially rejected the configured
gpt-6-lunamodel, so the successful test explicitly selectedgpt-5.6-luna. Installation location, client configuration interpretation, and runtime/process state may also differ. The successful minimal read-only probe does not verify all sandbox restrictions, project writes, or desktop functionality. It supports investigating a client/runtime regression but does not identify the introducing commit or prove that all Windows permissions are healthy.Historical October 5 logs also show repeated successful setup refreshes with
errors=[]while usingcodex-command-runner-0.155.0-alpha.9.2.exe. These are historical observations, not an identical-environment control.Requested resolution
Please investigate the runtime ACL validation path for loaded DLLs and provide a supported desktop fix or recovery that preserves sandbox protections, configuration, project files, and conversation history. Please surface the underlying file and Windows error in the UI rather than only
helper_unknown_error.The access-mask diagnosis and proposed patch discussed by other reporters have not been independently tested on this user's machine. No claim is made here that an upstream fix has shipped.
Only this sanitized summary and necessary log excerpts are submitted. Full diagnostic files, private project contents, chat transcripts, session IDs, usernames, SIDs, credentials, and
auth.jsonare not attached.cuiqian34-tech commentedon Oct 7, 2026
Adding another affected Windows installation, observed October 7, 2026.
Environment:
Reproduction: request an ordinary PowerShell Get-Location through the desktop app. It fails before process creation with "helper_unknown_error: setup refresh had errors". Expected: sandbox setup completes and the command runs.
The sandbox log reports "runtime read/execute validation failed" for the runtime's bin\node_repl.exe; earlier entries also identify node.exe. The error chain includes:
"open ACL target for root-only update: 另一个程序正在使用此文件，进程无法访问。 (os error 32)"
The Chinese message means another process is using the file.
A full app exit/reopen, Windows app Repair, and narrowly terminating the two identified node_repl.exe processes did not restore execution. Process Explorer showed executable image mappings, but no third-party File handle was identified. This does not establish which process, if any, holds an exclusive file handle.
These observations are consistent with the MAXIMUM_ALLOWED explanation discussed here and in #51623. However, no controlled access-mask comparison was performed on this installation, and the installed helper was not matched to the public source. The cause is therefore not independently proven here. No manual ACL changes, sandbox weakening, data clearing, or self-built helper installation were performed.
Please identify a fixed, officially signed desktop/helper version, or a supported recovery procedure preserving sandbox protections, configuration, projects, and conversation history. Updating a standalone CLI would not establish that the desktop app's bundled helper has been replaced. The duplicate closure of #51623 does not establish that a desktop fix has shipped.
101 remaining items
rjjelley commentedon Oct 9, 2026
Same failure here, and I can confirm the exact cohort: Windows desktop MSIX 26.1002.7124.0, runtime cua_node\3dd31cfff853001c, sandbox elevated.
Error: "Failed to create unified exec process: exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors"
Sandbox log: setup fails "validating runtime read/execute access" and "opening an ACL target for a root-only update" on ...\runtimes\cua_node\3dd31cfff853001c\bin\node_repl.exe, "The process cannot access the file because it is being used by another process. (os error 32)". Setup exits status 1. A separate user-profile error 32 says setup is continuing (non-fatal), consistent with the diagnosis in this thread.
Last success 2026-10-09 09:00 ET; first failure 11:52 ET the same day, after the Oct 7 update.
Tried without success: app restart/reconnect, fresh delegated task, full Windows restart, Resource Monitor Associated Handles search for node_repl.exe (no matches, inconclusive). No processes killed, no files deleted, no ACL changes, no protections disabled.
This matches #51601's root cause exactly. Question for the team: which upcoming desktop build will bundle the PR #51822 fix (CLI 0.163.0-alpha.2)?
apdmid commentedon Oct 9, 2026
Request for official status and a Windows Desktop release ETA
I'm requesting a clear status update for this regression as an affected Windows Codex user. This is blocking active development across multiple local projects, not just one repository.
Observed failure: Local PowerShell commands fail before execution with
helper_unknown_error: setup refresh had errors. The associated Windows sandbox report identifies a sharing violation (os error 32) on the bundledcua_node/.../node_repl.exe. Chrome/Computer Use initialization is also affected. Repeated Codex restarts have not restored access.I understand that PR #51822 has been merged and that its correction is included in a newer CLI prerelease. However, that does not establish that the fix has reached the affected Windows Desktop app.
Could the Codex/Desktop release team please provide:
sandbox = "unelevated"works, but it reduces isolation, which matters for projects with production credentials.A brief response in this issue or a linked public status notice would help affected users decide whether to wait or use a documented workaround. Thank you.
v-bohoslov commentedon Oct 9, 2026
Data point: 26.1007.2314.0 fixes the runtime failure. The remaining profile warning comes from Codex's own service pin.
1. Runtime-file failure fixed for me after the Store update.
OpenAI.Codexfrom 26.1002.7124.0 to 26.1007.2314.0. The bundled CLI iscodex-cli 0.162.0-alpha.17.2;codex-windows-sandbox-setup.exeSHA25620AFDF07E34A879A78F3E35CC50E858DE9931DB549D8256228E119BF5A81CE20, which contains the Avoid sharing violations when repairing Windows runtime ACLs #51822 stringinspect ACL target.windows.sandbox=elevated,:workspace) with Desktop open and 21 runtime processes loaded (node_repl.exe×8,node.exe×12,codex-computer-use-swift.exe×1).setup refresh: … errors=[]andsetup binary completed. The child ran as the CodexSandboxOffline SID. Writes to the workspace and %TEMP% were allowed; writes to%USERPROFILE%\.codexwere denied.rust-v0.162.0stable tag does not contain Avoid sharing violations when repairing Windows runtime ACLs #51822 (itsacl.rsmatchesalpha.17.1). The fix is inalpha.17.2(cherry-picke9cb8a596f),alpha.19+, and0.163.0-alpha.*.2. The non-fatal warning that remains, and its actual cause
28 of 28 attempts failed on this machine, and no log has ever contained a
granted …line. #51822 intentionally keptMAXIMUM_ALLOWEDfor directories, and the holder is Codex itself:windows-sandbox-service/src/ipc/home.rspin_existing_ancestors/pin_directoryopens every ancestor ofCODEX_HOME(C:\,C:\Users,C:\Users\<user>,.codex) withFILE_READ_ATTRIBUTES | FILE_TRAVERSEand shareREAD | WRITE, deliberately withoutFILE_SHARE_DELETE.package_lifecycle.rskeeps those handles for the lifetime of the installation.FILE_TRAVERSE(0x20) is share-tracked. For a full-control owner,MAXIMUM_ALLOWEDresolves to0x1F01FF, which includesDELETE. So theacl.rsroot-only open always hitsERROR_SHARING_VIOLATIONwhileCodexSandboxService.OpenAI.Codexis running. Elevation does not bypass this.NtQueryInformationFile(FileProcessIdsUsingFileInformation)on%USERPROFILE%\.codexreturns onlycodex-windows-sandbox-service.exe. AMAXIMUM_ALLOWEDorDELETEopen fails with 32, andREAD_CONTROL|WRITE_DACsucceeds. Any process whose cwd is the profile has the same effect; here the WireGuard UI is also a holder.dacl_allow_mask_needs_refresh, so a pre-existing ACE would not silence the warning either. The check-before-open idea in Windows elevated sandbox: root-only ACL grants open loaded runtime files for write (os error 32), so every setup refresh fails #51623 / 2bd3cd5 still opensMAXIMUM_ALLOWEDwhenever the ACE is actually missing.3. Why "just drop DELETE" is not a fix (tested on scratch trees only)
SetSecurityInfothrough a handle that holdsDELETE(MAXIMUM_ALLOWED,FILE_ALL_ACCESS,RC|WD|DELETE) does not propagate.READ_CONTROL|WRITE_DAC, alone or with any other non-DELETE rights, it re-propagates over the whole subtree: it removes stale inherited ACEs, converts legacy ACEs toID, and turns aD:Proot intoD:PAI. It returns 0 either way. On a real profile that is about 7e5 objects.FILE_SHARE_READ, is open on the directory. That is consistent with MARTA reopening the directory to walk it and silently skipping on a sharing violation. This is inferred, not traced.4. Suggested fix
For root-only directory grants:
READ_CONTROL | WRITE_DAC(share R|W|D,FILE_FLAG_BACKUP_SEMANTICS). These rights are not share-tracked, so the open succeeds while the pins exist.Ok(false)if no entries are needed.SetKernelObjectSecurity/NtSetSecurityObject, which never propagates. PreserveSE_DACL_PROTECTED/SE_DACL_AUTO_INHERITEDfrom the current control and setSE_DACL_AUTO_INHERIT_REQ. Without REQ, aD:PAIroot becomesD:P.I checked this on scratch trees while holding a handle identical to the service's pin. The write succeeded, the children were byte-identical before and after, and the root SDDL matched what the current
MAXIMUM_ALLOWEDpath produces.Suggested regression test: extend
noninheriting_read_attributes_preserve_unprotected_child_daclto hold the parent open likepin_directorydoes (FILE_READ_ATTRIBUTES | FILE_TRAVERSE, share R|W), then assert that the grant succeeds and the child DACL is unchanged. Onmaintoday it should fail with os error 32.Impact. Non-fatal. With the default
C:\UsersACL (Everyone and Users get0x1200a9), sandboxed PowerShell keeps its cwd and resolves relative paths under the profile, so the ACE is not needed. I verified this with real launches. On machines where the profile's parent is not listable (the layout inwindows_elevated_powershell_preserves_relative_paths), the #49690 fix can never take effect while the service is installed.Related: #49690, #51822, #51896, #51623.
Yo4v commentedon Oct 9, 2026
Confirmed fixed for me in Windows Codex Desktop 26.1007.21434 (build 13901, production).
After updating from 26.1002.52244 (build 13536), with the elevated Windows sandbox unchanged:
CodexSandboxOffline.helper_unknown_error: setup refresh had errors/ Windows error 32 no longer reproduces while runtime processes are active.codex --versionreportscodex-cli 0.162.0-alpha.17.2, so the working repair appears to have arrived through the updated Desktop sandbox helper rather than requiring the bundled CLI version to be alpha.20.No sandbox downgrade, ACL modification, manual executable replacement, or other workaround was used.
This is one-machine confirmation rather than proof that every affected installation or rollout cohort is repaired. Other affected users should retest after receiving this version.
RFinal3 commentedon Oct 9, 2026
Follow-up to my earlier report: after restoring
[windows] sandbox = "elevated", restarting, and updating the Windows desktop app to 26.1007.21434, my dot successfully started a fresh local Codex task on October 9, 2026. That task ranGet-Locationsuccessfully with exit code 0, without a retry or permission escalation.The earlier setup-refresh failure did not recur in this test. This is a limited observation; we did not independently inspect the effective sandbox implementation or perform broader sandbox validation.
Written and posted by Luna, my AI assistant, with my explicit authorization.
Kadeluxe commentedon Oct 9, 2026
Fixed in 26.1007.21434.
564311742-spec commentedon Oct 9, 2026
Hi @Yo4v, after updating to the version you mentioned, are browser and mouse controls both working normally now? Did you do anything besides updating and restarting?
564311742-spec commentedon Oct 9, 2026
Also asking @v-bohoslov @RFinal3 @Kadeluxe: on the versions you reported, are actual browser and mouse operations working normally now? Were any additional steps needed beyond the updates, restarts, or settings you already mentioned?
Yo4v commentedon Oct 10, 2026
@564311742-spec Yes. On my machine, Browser Use and actual click controls are working normally after the update. I have now verified an end-to-end browser action: Codex opened issue #51601 and clicked the
codexbreadcrumb, successfully navigating to the repository page.No additional recovery steps were needed beyond installing Windows Codex Desktop 26.1007.21434 (build 13901) and allowing the app to restart. The elevated Windows sandbox remained unchanged. I did not modify ACLs, replace binaries, clear runtime folders, or apply any other workaround. No Windows reboot was needed after installing this fixed version.
This confirms the in-app browser/control path on my installation. I have not separately tested control of an existing authenticated Chrome tab.
amanojak commentedon Oct 10, 2026
Follow-up to my earlier report: #51601 (comment)
Retested on the same Windows PC on October 10, 2026. The app's About screen reports version 26.1007.21434.
Five separate PowerShell requests through the normal
use_defaultsandbox path returned timestamps and exit code 0:The previous pre-launch
helper_unknown_error: setup refresh had errorsdid not recur in these attempts. The configured Windows sandbox remainedelevated; no sandbox settings were changed for these tests.Scope and limitations: the sandbox log inspected did not contain entries matching these attempts, so I cannot confirm that the original setup-refresh/runtime ACL-repair path was exercised. This demonstrates successful basic command execution in these five attempts, not full recovery or attribution to a specific PR. Browser/Computer Use and Node REPL were not retested as part of this verification.
Personal identifiers and local paths are omitted; no raw logs or screenshots are attached. Thank you for the work on this issue.
bk74k5b5j2-arch commentedon Oct 11, 2026
Windows Codex — file editing restored after sandbox configuration change
Issue: Codex Desktop on Windows suddenly stopped creating and modifying local project files, despite having permissions.
Configuration before:
sandbox_mode = "danger-full-access"[windows] sandbox = "elevated"Successful workaround:
sandbox_modeto"workspace-write".[windows] sandboxto"unelevated".Result: Codex regained the ability to create and modify local files. Reinstallation was not required. Existing projects and conversations were preserved.
Important: Both settings were changed together, so the exact parameter responsible for restoring functionality has not been isolated.
Please investigate this Windows sandbox regression and provide a permanent fix that does not require switching away from elevated sandbox isolation.
Kadeluxe commentedon Oct 11, 2026
@564311742-spec yes, it works.
hanero-heiko commentedon Oct 11, 2026
Independent reproduction from a Windows 10 workstation, plus a release check showing which builds contain the fix from #51822.
Environment
OpenAI.Codex26.1002.7124.0codex-cli 0.162.0-alpha.2(%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\, binaries dated 2026-10-08, installed by the app's self-update on 2026-10-11)errors=[], no error 32[windows] sandbox = "elevated", trusted local NTFS workspace, sandbox service runningSymptom (Desktop): every local command fails on the first call —
Failed to create unified exec process: helper_unknown_error: setup refresh had errors, Node tool:windows sandbox failed: helper_unknown_error: setup refresh had errors→trusted Node process exited unexpectedly; kernel reset. Reading an attached file fails the same way. 96 occurrences insandbox.2026-10-11.login one day.Sandbox log (user name redacted):
Desktop app log, same second:
MCP server stderr (...\node_repl.exe): windows sandbox failed: helper_unknown_error: setup refresh had errors→node_repl kernel exited unexpectedly→kernel_status: exited(code=1).Minimal CLI reproduction (no model call):
ChatGPT.exe, nonode_repl.exe).codex sandbox cmd /c "cd && echo SANDBOX-OK"→ exit 0,setup refresh: processed 0 write roots (read roots delegated); errors=[],setup binary completed,setup_error.jsonremoved.node_repl.exemanually and keep it running → same command exits 1 with theos error 32line above,setup_error.jsonrecreated.node_repl.exechanges nothing (exit 1; ACE reverted afterwards, DACL byte-identical). After the successful run in step 2 the DACL ofnode_repl.exewas unchanged, i.e. the "root-only update" writes nothing here but still needs a write handle.node_repl.exe:GENERIC_READ|FILE_EXECUTEOK,WRITE_DACOK,GENERIC_WRITE/MAXIMUM_ALLOWED→ error 32 — consistent with the diagnosis in this thread and with Avoid sharing violations when repairing Windows runtime ACLs #51822.In the Desktop app
node_repl.exeis started at thread start, before the first command, so the validation never succeeds there. HTTP MCP servers are not affected (a streamable-HTTP MCPread_filefrom the same Desktop thread succeeded while every local exec failed).Which releases contain the fix (#51822, merge commit
dd12f892f1b857e5161abd33a2967125b265d550), checked via the GitHub compare API:dd12f89?So the app-managed 0.162.0-alpha.2 and the current stable 0.162.1 both still lack the fix; it is only in the 0.163.0 pre-releases so far. Nothing was changed on this machine (no ACL edits kept, no sandbox mode change, no manual update) — waiting for a Desktop-delivered build that includes #51822.
HCardenas101 commentedon Oct 12, 2026
Confirming the fix on Windows app 26.1007.21434 (package 26.1007.2314.0), ChatGPT for Business, using the elevated sandbox with a custom permission profile that has deny-read rules. The sandbox log shows the setup refresh completing with errors=[] and 16 deny-read ACLs applied. Commands run in the sandbox, a deny-listed folder is refused, and writes outside the allowed folders require approval. This failed on 26.1002.6548.0 and 26.1002.7124.0.
dyphn1 commentedon Oct 15, 2026
Still reproducible on 2026-10-15 when the desktop app is already fixed but the npm CLI is not:
OpenAI.Codex_26.1007.9446.0_x64__2p2nqsd0c76g0(newer than the 26.1007.2314.0 package reported fixed above)@openai/codex0.162.1 (currentlatesttag),codex exec --sandbox workspace-write(elevated sandbox)With the desktop app running, every shell command from the CLI fails with
helper_unknown_error: setup refresh had errors.~/.codex/.sandbox/sandbox.2026-10-15.log:So the CLI's own sandbox setup still tries to repair ACLs on the app-owned shared runtime while the app holds
node_repl.exe, which looks like the CLI side not yet having #51822. A separateCODEX_HOMEdoes not isolate it, because the runtime lives underAppData\Local\OpenAI\Codex, not underCODEX_HOME.Workaround that works here: quit every
ChatGPT.exeandAppData\Local\OpenAI\Codex\*process, then moveruntimes\cua_node\<hash>out ofruntimes\cua_node\(renaming it in place is not enough, because the directory is scanned).unelevateddid not help in an earlier attempt (cannot enforce split writable root sets).Could a stable CLI release carry #51822 (dd12f89)? Running the desktop app and the CLI at the same time is currently not possible on Windows.