Repository navigation
Windows App 26.1002.7124.0: sandbox runtime read/execute validation fails with sharing violation #51932
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.1002.7124.0, verified from the installed Windows package manifest (OpenAI.Codex, Store signature). The About dialog and bundled command-runner version were not collected.
What subscription do you have?
Not collected.
What platform is your computer?
Windows x64. Exact Windows edition/build was not collected.
What issue are you seeing?
Ordinary sandbox command execution fails before the requested process starts, including Get-Location and a small UTF-8 file read:
Failed to create unified exec process:
exec-server rejected request (-32603):
helper_unknown_error: setup refresh had errors
The failure persisted after reopening the desktop app and in a fresh local diagnostic task. Working directories on both C: and E: drives failed. This is a reproduction from one computer, not a claim that every Windows installation is affected.
The local sandbox log identifies a runtime read/execute validation failure with Windows error 32. Minimal excerpts below replace the user-profile prefix with an environment-variable placeholder; the localized OS message is represented in English.
2026-10-08T02:24:31.114710600+00:00
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:
[file is being used by another process] (os error 32)
2026-10-08T03:00:59.025763900+00:00
runtime read/execute validation failed:
validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll:
open ACL target for root-only update:
[file is being used by another process] (os error 32)
What steps can reproduce the bug?
- Open the affected Windows desktop installation and start or continue a local task.
- Request an ordinary sandbox
Get-Location. - Observe setup-refresh failure before command launch.
- A fresh task or changing the working-directory drive does not clear the failure in this installation.
What is the expected behavior?
Normal sandbox setup completes while the application's own bundled GUI/runtime helpers are running, and basic read-only commands execute without weakening sandbox checks.
Additional information
Approved host diagnostics were used because ordinary sandbox execution was blocked. Exact-path module enumeration found the private DLL loaded by the bundled codex-computer-use-swift.exe, owned by the current user and parented by the desktop application's ChatGPT.exe.
A narrowly scoped diagnostic reset stopped only three identity-checked node_repl.exe helpers; the blocking target then became the private DLL above. Stopping the identified computer-use helper also did not restore ordinary execution: it was replaced by a new process at 03:00:52.1701554 UTC under the same still-running desktop parent, immediately after the previous helper exited. The replacement loaded the same DLL, and the subsequent ordinary command still failed with error 32. This suggests that repeatedly stopping the helper is not a durable recovery method.
No ACLs, security configuration, internal databases, or runtime/helper binaries were manually changed. No full logs or session contents are attached.
Related reports and fix:
- Windows app 26.1002.51308: sandbox setup fails with sharing violation when validating its own active runtime #51601 appears to describe the same runtime-validation/sharing-violation category on another package version; this report adds the 26.1002.7124.0 reproduction and immediate helper-replacement observation. Happy to consolidate if preferred.
- Windows: dot-started tasks fail with “setup refresh had errors”, but direct local Codex chats work #51882 reports the same top-level error with a dot/local routing difference; I have not established the same underlying cause.
- Windows Codex App: unified exec fails with
helper_unknown_error: setup refresh had errors#40596 is an older report of the top-level setup-refresh failure. - Avoid sharing violations when repairing Windows runtime ACLs #51822 was merged on October 7 and addresses active EXE/DLL sharing violations during Windows runtime ACL repair. I cannot verify whether the installed desktop package contains that fix.
Please identify the first supported Windows desktop release containing #51822, or a supported recovery method for this installation. The exact cause in the installed binary remains unverified.
Activity
github-actions commentedon Oct 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
kevinee123 commentedon Oct 8, 2026
Additional sanitized reproduction evidence for the same Windows runtime sharing-violation category.
Environment verified locally:
Observed behavior:
exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors.%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exewith
open ACL target for root-only updateand Windows sharing violationos error 32....\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll.Read-only process-module enumeration confirmed that the bundled
codex-computer-use-swift.exeloaded this exact DLL. The desktop automatically replaced that helper after it was stopped.errors=[]) and read the project directory.node_repl.exeandos error 32. Thus local recovery was temporary and did not prove remote recovery.Minimal sanitized failure chain:
No manual ACL/security changes, binary modifications, data deletion, or reinstallation were used. Full logs and session transcripts are not attached. Usernames, company/project names, absolute private paths, host/task identifiers, process IDs and authentication information have been omitted.
This appears consistent with the category addressed by #51822, but its inclusion in this installed desktop/core combination has not been verified. Related dot/local routing report: #51882. Please identify the first supported desktop release containing the fix and/or a recovery procedure that preserves sandbox protections.
ljx719476856li commentedon Oct 8, 2026
Additional reproduction on Windows build 10.0.26200.9457 with desktop package 26.1002.7124.0 and bundled codex-cli 0.162.0-alpha.2.
With the desktop application and its bundled runtime helpers running, the following command from a normal host shell fails before the requested command starts:
The configured Windows sandbox mode is elevated. The desktop app-server uses features.prefer_mxc=true, but the command above tests the separate CLI sandbox entrypoint without that override. The desktop managed shell can still execute commands; this is not a claim that every backend is unavailable.
Observed error: helper_unknown_error: setup refresh had errors.
Runtime validation reports: open ACL target for root-only update: file is being used by another process (os error 32).
Affected bundled runtime filenames across attempts: node_repl.exe, node.exe, VCRUNTIME140_1.dll.
With explicit user approval, a bounded diagnostic briefly stopped the identified helpers while preventing immediate respawn. The same official sandbox command then exited 0. After restoring the helper parents, an independent repeat exited 1 with the DLL sharing violation again. All paused parents were restored. No runtime binaries were patched and sandbox protection was not disabled. Repeatedly stopping helpers is not a durable workaround.
PR #51822 appears relevant. Which supported Windows desktop release includes it? We have not verified that our installed binary contains that patch.
matsuokajuri commentedon Oct 8, 2026
Post-reboot retest (2026-10-08): after a full Windows reboot and reconnecting the computer, two ordinary exec attempts using existing working directories on the C: and E: drives both failed at process creation, before the requested command started:
A full reboot therefore did not restore ordinary execution on this computer. This retest used ordinary permissions, without elevation or permission changes.
The post-reboot sandbox logs have not been inspected for this retest, so the repeated top-level error alone does not establish that the underlying failure is still the same
os error 32.250124475-jpg commentedon Oct 8, 2026
Additional evidence specifically about availability of a supported desktop fix for dot / Local Work execution, checked on 2026-10-08 around 07:35 UTC.
PR #51822 is merged at dd12f89. Its active EXE/DLL sharing-violation fix appears consistent with the failure below. We need the exact desktop release and bundled executor version that include it.
Locally verified versions:
Official desktop distribution checks:
The post-restart dot command still failed during sandbox refresh, before the requested command launched. The relevant local log entry is at 2026-10-08T07:13:54.798157500+00:00 (15:13:54 UTC+8):
Windows Restart Manager previously confirmed the exact-file owner. After a narrowly scoped release cleared the file ownership, Local Work automatically recreated its own node_repl.exe helper before the next failed refresh. Repeated process termination or restarts are not a durable recovery method. This check did not repeat those operations.
No helper binaries were manually replaced; no ACL, sandbox protection, configuration, or chat data was changed. No full logs, private task identifiers, credentials, or session contents are attached.
Could an OpenAI maintainer please confirm:
Recovery will be accepted only after the original dot task executes one Get-Location successfully and the corresponding new sandbox log shows no setup-refresh failure. A rendezvous connection or up_to_date status alone is not recovery.
ManuelLopezC commentedon Oct 8, 2026
Additional reproduction on Windows after upgrading Codex from package 26.930.7945.0 to 26.1002.7124.0 on 8 October 2026.
Ordinary local command execution fails before the shell starts with:
helper_unknown_error: setup refresh had errors
runtime read/execute validation failed
open ACL target for root-only update: file is being used by another process (os error 32).
The blocking files are the bundled node_repl.exe and VCRUNTIME140_1.dll. Approved execution outside the sandbox can read the workspace. Stopping the identified auxiliary processes does not provide a durable fix because the desktop app recreates its helper.
The prior package is no longer available locally. Please identify a supported fixed desktop release or a supported rollback that preserves local chats and settings.
The update is temporally associated with the failure; causation has not been established. This report contains no private workspace paths, account identifiers, credentials, or full logs.
tkawamori commentedon Oct 8, 2026
Additional reproduction from the VS Code browser-tool path, verified on 2026-10-08 (JST).
node_repl kernel exited unexpectedly, with stderrwindows sandbox failed: helper_unknown_error: setup refresh had errors.runtime read/execute validation failedon%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe, thenopen ACL target for root-only updateand a sharing violation (os error 32).codex sandbox --include-managed-config --permission-profile :workspace -C <workspace> -- powershell.exe -NoProfile -Command <print-marker>also fails before printing the marker. The failure therefore reproduces without browser automation.The official Windows Store update manifest currently advertises 26.1002.7124.0, matching this installation. PR #51822 appears to address the observed failure category, but inclusion in these installed binaries has not been verified.
Please identify the first supported Windows desktop and VS Code extension releases containing #51822, and the supported update path. Recovery here requires a successful browser inventory with the sandbox protections retained; a successful shell run with its tool hosts stopped is insufficient.
No manual ACL changes, sandbox downgrade, binary replacement or full logs are included. Private paths, account identifiers, project names and credentials have been omitted.
BlindDevelopment commentedon Oct 8, 2026
Additional reproduction on Windows 10 Pro 22H2 (10.0.19045), x64, with a controlled stop/retry/restart test that recovered sandbox execution temporarily and reproduced the failure after restarting the app.
Environment
Reproduction and impact
The setup log reports runtime read/execute validation failing with Windows sharing violation 32. The same diagnostic commands succeed when individually approved outside the sandbox. Ordinary local shell work is blocked while the helpers are running.
Expected: sandbox setup and basic shell commands should work while the application's own bundled tool helpers are running, without weakening permissions or terminating app functionality.
Controlled diagnostic sequence
All times below are UTC on 8 October 2026 (local Europe/London time was UTC+1). Process identities and executable paths were checked before each stop; the main app and Codex core stayed running.
Thus: helpers running -> failure; identified runtime users stopped -> two successful sandbox launches; app restarted/helpers restored -> same failure.
Minimal redacted log excerpts
Long timestamps are preserved; only the user-profile prefix is replaced.
No manual ACL edits, configuration changes, runtime replacement, or security disabling were performed. Setup itself applied its normal permissions during the retries. Stopping the helpers is a diagnostic workaround with loss of app/tool functionality, not a durable fix.
The observations are consistent with the active-file ACL repair problem addressed by #51822. We have not verified inclusion of that fix in this installed desktop build. Please identify a supported desktop release containing the fix, or a supported recovery path that preserves both sandbox protections and the bundled tools.
hcogden commentedon Oct 8, 2026
Additional affected ChatGPT Work installation:
Windows desktop package: 26.1002.7124.0
Bundled command-runner: 0.162.0-alpha.2
On October 8, 2026 at 19:15:57 UTC, a basic Get-Location
request failed before PowerShell started:
helper_unknown_error: setup refresh had errors
The sandbox log identifies runtime permission validation
failing on the bundled 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)
Restarting Windows did not resolve it. No desktop update
is currently available to me. Local command execution
in Work remains blocked.
This matches the failure addressed by PR #51822.
Please prioritize releasing the correction and identify
the first supported Windows desktop build containing it,
or provide a supported recovery procedure.
toonai801 commentedon Oct 8, 2026
Additional affected Windows installation, verified October 8, 2026:
exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors.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).Please identify the supported Windows desktop/runtime release containing #51822 and how this affected installation can receive it, or provide a supported recovery procedure. We have not verified that the running desktop contains the fix. We have not disabled the sandbox/firewall or replaced bundled binaries. Ordinary project execution remains blocked.
Personal paths, project details, credentials, and full logs are intentionally omitted.
Al-Geroth commentedon Oct 8, 2026
Additional reproduction on Windows desktop package OpenAI.Codex_26.1002.7124.0_x64 with the same bundled runtime cua_node\3dd31cfff853001c.
Observed behavior:
Get-Locationfails before PowerShell starts withhelper_unknown_error: setup refresh had errors.setup refresh completed with errors/setup error: setup refresh had errorsentries repeat on every attempt.Diagnostics performed:
node_repl.exewas no longer running.FileShare.None; it succeeded, proving the file was not locked after cleanup.CodexSandboxService.OpenAI.Codex; service came back cleanly under a new PID.node_repl.exeprocesses from the same runtime.Get-Locationattempt failed again with the same os error 32.node_repl.exeprocesses temporarily unlocked the file, but a subsequent command caused Codex to respawn them and the failure returned.Observed process relationship after relaunch:
This makes the failure look deterministic in this installation: the desktop app starts helpers that lock
node_repl.exe, then sandbox setup attempts ACL validation on that already-running executable and fails with ERROR_SHARING_VIOLATION.No ACLs, runtime binaries, project files, or security settings were modified during the diagnosis.
4 remaining items
Hendra827 commentedon Oct 9, 2026
Could the team please prioritize shipping PR #51822 in a Windows Desktop release?
The fix has already been merged, but this issue is still blocking all local task execution for affected users. In my case, 100% of tasks fail before execution with:
helper_unknown_error: setup refresh had errorsThe sandbox logs report
OS error 32(sharing violation) while validating or repairing ACLs on runtime files that are currently in use, such asnode_repl.exe.Could you please clarify:
For affected users, this is a complete blocker rather than a minor inconvenience. Even a brief status update or estimated release window would be greatly appreciated.
Thank you for looking into this.
Hendra827 commentedon Oct 9, 2026
Could the team please provide a specific status update and timeline for the Windows Desktop fix for this regression?
This is still a complete blocker for me: 100% of local tasks fail before the requested command starts with
helper_unknown_error: setup refresh had errors. The sandbox log reports Windows OS error 32 (ERROR_SHARING_VIOLATION) while validating ACLs on Codex's bundled runtime files, includingnode_repl.exe/ runtime DLLs.PR #51822 has been merged, but affected users still need to know when the fix will reach the Windows Desktop app—not just the CLI source tree. Could you please clarify:
I have already reported this on related issue #51601 as well. Repeated retries and restarts do not help, so a concrete release status would be much more useful than general troubleshooting suggestions. Thank you.
goraebabjin-0109 commentedon Oct 9, 2026
Additional user-authorized report for the same Windows desktop failure, still reproduced on October 9.
User-reported evidence:
helper_unknown_error: setup refresh had errors.node_repl.exewith Windowsos error 32(sharing violation).An information-only update check performed by Codex in the current session returned:
The reproduction time and log signature above were provided by the user; this reporting session did not independently inspect the original sandbox log or reproduce that sandboxed failure. No full logs, private paths, session contents, or credentials are attached.
Please confirm:
PR #51822 appears relevant to this error category, but its inclusion in the installed desktop package and whether it resolves this installation have not been verified. Repeating the already-failed restart/new-task/process-termination steps has not provided a durable recovery.
goraebabjin-0109 commentedon Oct 9, 2026
Evidence clarification and regression history for #51932 (comment)
Update: this reporting session has now directly read the original PC sandbox log
CODEX_HOME/.sandbox/sandbox.2026-10-09.log. The sanitized excerpts below are extracted from that log, rather than reconstructed from the user's summary. Local START timestamps are KST (UTC+9); ISO timestamps explicitly use UTC.The log also records
setup error: setup refresh had errorsand setup exit status 1 following each of the 14:32, 15:01 and 15:41 failures. The setup working directory identifies Windows packageOpenAI.Codex_26.1002.7124.0_x64.The supplied user log-review summary identifies the 14:32 attempt as immediately after restart and the 15:01 attempt as coming from a new task. The sandbox log independently confirms those failures, but does not itself establish the app restart. A new task-specific write root is logged at 15:01; private workspace details are omitted.
The user additionally reports that the same command path worked on 26.930.x and began failing consistently after updating to 26.1002.7124.0 on October 8. This historical regression has not been independently reproduced by this reporting session.
The inspected sandbox log does not establish termination or immediate respawn of node_repl.exe. Those should not be treated as log-verified. PR #51822 addresses a matching mechanism, but its inclusion in the installed desktop package and this binary's exact cause remain unverified. No build date or fix inclusion is inferred from the version string.
The supplied summary reports an update check at 14:31 showing a 26.1007 version string while the Store reported no update available; its exact field and meaning are unverified.
Please confirm the first supported Windows desktop package AND app build containing #51822, production Microsoft Store availability/rollout, and the officially supported recovery procedure preserving sandbox protections, chats and browser sessions.
The separately mentioned
/mnt/user-data/outputs/codex_sandbox_setup_bug_evidence.txtwas not accessible here. Instead, the relevant original PC log excerpts have been supplied inline above. User-profile paths are redacted; no credentials, full logs or session contents are attached. No runtime files, ACLs, sandbox settings or processes were changed by this evidence collection.jakubruc commentedon Oct 9, 2026
We’ve been experiencing exactly the same issue since yesterday, October 8, on Windows 11 Home 25H2 (build 26200.9550), with app package 26.1002.7124.0. Even Get-Location fails with helper_unknown_error: setup refresh had errors, and the sandbox logs show os error 32 on node_repl.exe and VCRUNTIME140_1.dll. Restarting the app and Windows has not helped. Standalone PowerShell works normally.
brefledev commentedon Oct 9, 2026
I’m seeing this same failure on Windows 11 Home x64, build 26200.
My installed versions are:
A dot-created PC task fails before executing a read-only PowerShell command. The sandbox log identifies:
The task surfaces this as
helper_unknown_error: setup refresh had errors.A controlled diagnostic reproduced the failure with the installed CLI. A separately staged, official OpenAI-signed 0.162.0-alpha.20 passed the directory check using the native elevated sandbox and a read-only profile. Existing runtime processes stayed running, and the target executable’s ACL remained unchanged. Desktop and dot-created task recovery are still unverified.
[#51822](#51822) appears to address this exact problem. Microsoft Store currently offers me no update. The documented offline MSIX download serves 26.930.7945.0, older than my installed package.
Which supported Windows desktop release includes #51822, and how can I get it? Is there an officially supported way for my installed desktop executor (including dot-created PC tasks) to use the corrected helper while preserving configuration, conversation history, active work, and sandbox protections?
stanleyhoh79 commentedon Oct 9, 2026
I can reproduce the same Windows sandbox failure with OpenAI.Codex MSIX 26.1002.7124.0 and Codex CLI 0.162.0-alpha.2.
Even the read-only
Get-Locationcommand fails before execution withhelper_unknown_error: setup refresh had errors. The sandbox log identifies Windows error 32 (sharing violation) during ACL validation of the bundlednode_repl.exe.I fully closed ChatGPT Desktop and verified that no ChatGPT, Codex, or Node REPL processes remained. A single managed read-only CLI attempt still produced the same failure.
No permissions, security settings, runtime files, or sandbox protections were changed.
I understand that PR #51822 has been merged. Could you confirm which supported Windows Desktop/MSIX release includes this fix and recommend a safe update procedure that preserves local projects, configuration, and chat history?
ivettgamarra commentedon Oct 9, 2026
I am affected by the same Windows desktop failure.
My diagnostics recorded desktop package version 26.1002.7124.0 on Windows 10 Home Single Language, build 19045. Sandboxed Get-Location fails before execution with:
helper_unknown_error: setup refresh had errors
The sandbox log identifies runtime ACL validation failure on cua_node/3dd31cfff853001c/bin/node_repl.exe with Windows error 32.
The desktop update check reported that the app was up to date. A separate CLI 0.160.1 session launched with --no-daemon successfully executed Get-Location, but desktop recovery has not been established.
Desktop feedback ID:
no-active-thread-01a12040-1fea-7361-9f29-e1523d614cff
Please identify the supported Windows desktop release containing #51822 and how to obtain it. If it is not available yet, is there an officially supported recovery or rollback that preserves sandbox protections, settings, and conversation history?
This is blocking my local project work. I want to continue using the desktop app.
prototype956 commentedon Oct 9, 2026
Additional reproduction on Windows.
Both browser/Computer Use initialization and ordinary sandboxed terminal commands fail before starting with
helper_unknown_error: setup refresh had errors.The sandbox log reports a file-sharing violation (Windows OS error 32) when updating runtime access permissions for
node_repl.exeorVCRUNTIME140_1.dll.Restarting the app, resetting the browser kernel, and stopping the related auxiliary processes did not restore access; replacement auxiliary processes were observed. No ACLs or security configuration were manually changed.
Please provide a supported fix or recovery method that preserves sandbox protection.
marco-quicula commentedon Oct 9, 2026
Additional reproduction with Codex CLI 0.162.0 installed via npm (native Windows 11 Pro 26200, PowerShell 7.6,
[windows] sandbox = "elevated"), plus a CLI workaround that avoids the failure.Symptom: every sandboxed command fails with
Failed to create unified exec process: helper_unknown_error: setup refresh had errors, includingGet-Location.node_replfails withwindows sandbox failed: helper_unknown_error: setup refresh had errors. Rebooting Windows did not help.Sequence observed (process list +
%USERPROFILE%\.codex\.sandbox\sandbox.<date>.log):codex.exe(npm vendor binary) starts.node_repl.exefrom%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\in two ways:[mcp_servers.node_repl]inconfig.toml, written by the desktop app;unified-computer-use@openai-bundledplugin (.mcp.json→node.exe …\@oai\cua-repl\bin\cua-repl.mjs→node_repl.exe).codex-windows-sandbox-setup.exeruns a setup refresh and fails with:runtime read/execute validation failed: validate runtime read/execute access on …\cua_node\<hash>\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)This is consistent with PR #51822, which is not included in 0.162.0.
Workaround for the CLI (verified, both interactive and
codex exec): disable both sources ofnode_repl.exefor the session:With both overrides,
node_repl.exeis not started, the setup log showssetup refresh: processed 2 write roots ... errors=[], and shell commands work. Disabling onlymcp_servers.node_replis not enough, because the plugin still startsnode_repl.exethroughcua-repl. You losenode_repl, computer-use and browser control in that CLI session.Pitfall: in PowerShell 7, writing the plugin key with inner quotes (
-c 'plugins."unified-computer-use@openai-bundled".enabled=false') passes the quotes through literally. The override then does not match and the plugin stays enabled. The unquoted form above works.Observation: the desktop app (bundled CLI
0.162.0-alpha.2, sameworkspace-writepolicy, samecua_noderuntime,node_repl.exerunning) works on this machine. No setup-refresh entries were written to the sandbox log during the app session, so it seems to take a different sandbox preparation path from the standalone CLI.RickNeedsMoreCoffee commentedon Oct 9, 2026
Additional consumer-account reproduction and recovery evidence collected on October 9, 2026. This is a report from one Windows installation; no incident severity or broader affected population is asserted.
Environment:
Ordinary sandbox commands and node_repl initialization failed before executing. The sandbox log identified both an active node_repl.exe and, on another attempt, the computer-use Swift helper's loaded VCRUNTIME140_1.dll:
The affected paths were under %LOCALAPPDATA%/OpenAI/Codex/runtimes/cua_node/3dd31cfff853001c/bin/. Personal paths and full session logs are omitted.
Local diagnostic workaround, not an officially supported update procedure:
A separate Windows 10 screenshot failure remained after sandbox recovery and required a separate capture workaround; that evidence is being added to #50749. These should not be conflated.
Please identify the supported Windows desktop release incorporating #51822 and the recommended migration from this temporary runtime workaround back to the bundled runtime.
ivettgamarra commentedon Oct 10, 2026
Update — October 10, 2026: runtime reset did not resolve the failure.
On Windows 10 Home Single Language, build 19045, Codex was closed and the contents of
%LOCALAPPDATA%\OpenAI\Codex\runtimeswere deleted. After reopening the desktop app, it displayed “installing.”A subsequent sandboxed
Get-Locationattempt failed before command execution. No command result or exit code was returned.I have now inspected the post-reset sandbox log. It confirms the same underlying failure at 09:36:18 local time in Israel (06:36:18 UTC):
The sandbox setup helper subsequently exited with status 1. That is the helper’s exit status; the requested command never started.
No configuration, ACL, sandbox-policy, or antivirus settings were manually changed. The installed desktop version was not rechecked after this reset.
Please identify the supported Windows desktop release containing #51822 and the recommended update or recovery procedure that preserves sandbox protections, settings, and conversation history.
Technically-A-Mechanical-Engineer commentedon Oct 10, 2026
Follow-up — October 10, 2026, on the installation described in my earlier diagnostic comment.
Update and workaround retirement
3dd31cfff853001ctocfb32733c877621e. The old six targets are absent after updating; the six corresponding new-runtime files have zero current-user WriteData deny rules, including inherited rules. The workaround has not been reapplied.Verified post-update results
errors=[].This installation currently works without the temporary ACL workaround. This is a bounded post-update check, not proof against future intermittent failures or confirmation of which source fix shipped. Browser checks did not exercise authenticated editing or Save. Separate approval/context and message-submission problems were not retested. No full logs, screenshots, private paths, session contents, or study data are attached.
prototype956 commentedon Oct 10, 2026
Update: the issue I reported above is now resolved on my Windows installation after the latest Codex app update. Thank you for the fix!
yutigi commentedon Oct 13, 2026
Still reproducing on 2026-10-13 with the latest stable standalone CLI,
codex-cli 0.162.1. It looks like the fix from #51822 never reached a stable release.Environment
[windows] sandbox = "elevated",workspace-writecodex-cli 0.162.1(%USERPROFILE%\.codex\packages\standalone\releases\0.162.1-x86_64-pc-windows-msvc); the update check reports 0.162.1 as latestOpenAI.Codex_26.1007.2314.0, bundled core0.162.0-alpha.17.2, runtimecua_node\cfb32733c877621eSymptom
Every sandboxed command fails before the shell starts, including
Write-Output 'shell-test':%USERPROFILE%\.codex\.sandbox\sandbox.2026-10-13.log:Findings
0.162.0-alpha.17.2helper and the app-server-daemon's0.160.1helper complete witherrors=[].codex execunder a process monitor.codex.exelaunchednode_repl.exeat session start, both directly ([mcp_servers.node_repl], which the desktop app writes intoconfig.toml) and vianode.exe ...\@oai\cua-repl\bin\cua-repl.mjs(unified-computer-use@openai-bundled→cua_repl). The setup helper ran about 10 s later, while that image was mapped, and failed with error 32. No other process held the file (checked with the Restart Manager API).CreateFileWon the runningnode_repl.exesucceeds withREAD_CONTROL|WRITE_DAC, withFILE_READ_DATA, and with share mode 0. It fails withERROR_SHARING_VIOLATIONonly whenFILE_WRITE_DATAis requested. An idle.exein the samebinfolder opens fine. So the helper's "root-only update" asks for write-data access on a mapped image, which Windows always refuses.-coverride stops the spawn. With-c mcp_servers.node_repl.enabled=falseand-c 'plugins."unified-computer-use@openai-bundled".enabled=false',cua_replstill launchednode_repl.exeand the run still failed.codex exec --ignore-user-config -c 'windows.sandbox="elevated"' ...works. The helper payload then has no runtime entry, setup refresh ends witherrors=[], andWrite-Outputruns inside the elevated sandbox. The same--ignore-user-configrun plus a disabledmcp_servers.node_repl.commandoverride also passes, so the extranode_replMCP entry alone doesn't trigger validation. This matches @gary-gui's observation that loading the user config triggers it.CodexSandboxUsersalready inheritsReadAndExecuteonnode_repl.exe. This is error 32 (sharing violation), not error 5 (access denied).Release status
dd12f892(#51822) is an ancestor ofrust-v0.163.0-alpha.5, but not ofrust-v0.162.0orrust-v0.162.1. The0.162.0...0.162.1compare contains only #51866 and #52648, so the fix wasn't cherry-picked. Users on the stable 0.162.x CLI and on the app-server daemon have no fixed release. Could #51822 be backported in a 0.162.2, or could a stable 0.163.0 be shipped?