Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Oct 7, 2026
2. github-actions commented on Oct 7, 2026

   

   github-actionsbot

   on Oct 7, 2026 – with GitHub Actions

   Contributor

   More actions

   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: bundled 0.162.0-alpha.2 fails with sharing violation; separate stable 0.160.1 starts #51596
   • Windows sandbox fails opening running node_repl.exe for ACL update (error 32); Computer Use and shell blocked #51590
   • Sandbox initialization fails with error 32, blocking local commands, file reads and automation after update 26.1002.51308, build 13417 #51607
   • Windows ARM64: node_repl fails during sandbox runtime access validation with sharing violation after desktop update (26.1002.51308) #51633

   Powered by Codex Action
3. smmisha commented on Oct 7, 2026

   

   smmisha

   on Oct 7, 2026

   More actions

   Additional reproduction with a root-cause check against the source (Windows 11 Pro 10.0.26300, MSIX 26.1002.7124.0, bundled codex-cli 0.162.0-alpha.2, [windows] sandbox = "elevated").

   Access-mask comparison

   I opened the files with CreateFileW, using FILE_FLAG_BACKUP_SEMANTICS and share mode READ|WRITE|DELETE. Each handle was opened and closed with no changes. Targets:

   • the running cua_node\<hash>\bin\node_repl.exe
   • the user profile directory

   Desired access	running node_repl.exe	%USERPROFILE%
   MAXIMUM_ALLOWED	error 32	error 32
   READ_CONTROL | WRITE_DAC	OK	OK
   READ_CONTROL | WRITE_DAC | WRITE_OWNER	OK	OK
   FILE_WRITE_DATA	error 32	OK
   DELETE	OK	error 32

   For the owner, MAXIMUM_ALLOWED expands to include write and delete access:

   • FILE_WRITE_DATA conflicts with the mapped image section of a running EXE or DLL.
   • DELETE conflicts with any open handle on the profile directory that lacks FILE_SHARE_DELETE.

   Opening with only READ_CONTROL | WRITE_DAC is enough for GetSecurityInfo/SetSecurityInfo, and no sharing violation occurs.

   Code path

   • setup_runtime_bin.rs::ensure_runtime_tree_readable walks every file under runtimes\ and calls grant_read_execute_aces(path, .., 0) for each one.
   • When inheritance == 0, acl.rs::ensure_allow_mask_aces_with_inheritance_impl opens the target with .access_mode(MAXIMUM_ALLOWED) unconditionally. This happens before dacl_allow_mask_needs_refresh runs.

   As a result, the refresh fails even when nothing needs to change. In my case CodexSandboxUsers already had inherited (RX) on node_repl.exe. The refresh runs before every sandboxed command, and the app keeps the runtime processes alive, so every command fails. acl.rs and setup_runtime_bin.rs on main are still identical to rust-v0.162.0-alpha.2.

   Confirmation: with the app fully exited (no runtime processes running), codex sandbox -- cmd /c echo ok in elevated mode succeeds, and the refresh logs errors=[].

   Suggested fix: open with READ_CONTROL | WRITE_DAC instead of MAXIMUM_ALLOWED. Alternatively, read the DACL and check needs_refresh before requesting a write handle.

   Workaround verified here

   Setting [windows] sandbox = "unelevated" and fully restarting the app works. With the runtime processes running, all of these succeed without escalation:

   • a shell command
   • a node_repl evaluation
   • the in-app browser opening example.com
   • cua.getState()
4. sfdevlin43 commented on Oct 7, 2026

   

   sfdevlin43

   on Oct 7, 2026 – with ChatGPT Codex Connector

   More actions

   Reproduced on another Windows installation:

   • Codex desktop: 26.1002.52244, build 13536, production channel; the in-app updater reports up_to_date.
   • OS: Windows 11 Home, build 26200, x64.
   • Browser/Computer Use fails before it can list or inspect Chrome tabs. A cua.getState() attempt exits with node_repl kernel exited unexpectedly; stderr reports windows sandbox failed: helper_unknown_error: setup refresh had errors.
   • A minimal sandboxed PowerShell Get-Location also fails before starting with the same setup-refresh error. The same read-only command succeeds through an approved elevated execution path, isolating the failure to sandbox startup.
   • The October 7 sandbox log identifies the fatal step as runtime read/execute validation failed on %LOCALAPPDATA%\OpenAI\Codex\runtimes\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). It then records setup refresh completed with errors. An October 5 log on this machine recorded successful refreshes with errors=[].
   • Read-only process inspection found multiple running node_repl.exe instances from that runtime path.
   • Chrome was updated and restarted; Codex was restarted; Windows was rebooted. The failure persisted. No sandbox ACLs, runtime files, or app configuration were changed during this diagnosis.

   Please advise a supported fix that restores sandboxed execution and Browser/Computer Use while preserving local files, conversations, and sandbox protections.
5. rbrazier69 commented on Oct 7, 2026

   

   rbrazier69

   on Oct 7, 2026 – with ChatGPT Codex Connector

   More actions

   Additional affected Windows desktop user report, submitted with the user's explicit permission to publish anonymized diagnostics on this public GitHub issue (October 7, 2026).

   Verified bundled backend: codex-cli 0.162.0-alpha.2. Desktop app version and Windows release were not verified.

   Desktop Chrome is running. Read-only browser discovery through mcp__cua_repl.js with await cua.getState() fails before any browser or tab inventory is returned. Explicitly mentioning @chrome does not change the failure.

   Observed tool errors:

   trusted Node process exited unexpectedly; kernel reset, rerun your request
   node_repl kernel exited unexpectedly
   windows sandbox failed: helper_unknown_error: setup refresh had errors
   

   Ordinary sandboxed shell commands also fail before process creation with helper_unknown_error: setup refresh had errors. Separately approved execution outside that sandbox succeeds for read-only diagnostics.

   Anonymized fatal log entry:

   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
   

   Recovery attempts did not fix it: control-kernel reset, desktop app restart, and user-performed Task Manager cleanup followed by app restart. After the cleanup, read-only process inventory confirmed the previously observed older Codex/node_repl processes were gone; only newly started Codex and node_repl processes remained. The fatal log nevertheless reproduced at 10:22 EDT. This supports recurrence with new processes rather than only stale helpers. Which handle causes the failure has not been established.

   Impact: the user cannot inspect an existing desktop Chrome tab, even with the browser plugin explicitly selected. No browser/account actions were taken, and no cloud-browser fallback was used. No sandbox configuration, ACLs, credentials, or runtime files were changed. Please provide a supported repair or fixed build that preserves sandbox protections.
6. LFwinds commented on Oct 7, 2026

   

   LFwinds

   on Oct 7, 2026

   More actions

   Additional confirmation from a Windows 10 machine, with a deterministic minimal reproduction and an interim mitigation that does not disable any feature. Diagnostics were collected on the owner's machine and posted with their approval.

   Environment

   • OS: Windows 10 Pro 22H2 (10.0.19045, x64) — so this is not Windows 11 specific.
   • Codex desktop app: OpenAI.Codex_26.1002.7124.0_x64
   • Bundled helper / command runner: 0.162.0-alpha.2, helper bin dir 9691020b546a15b2
   • Runtime tree: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c
   • Config: [windows] sandbox = "elevated"

   Deterministic minimal reproduction

   Holding a single handle is enough to break every command:

   1. Open ...\runtimes\cua_node\<hash>\bin\node_repl.exe for read access with share mode read only (i.e. deny write sharing; this is what the loader's own handle looks like).
   2. Run any command in the terminal → rejected before start with helper_unknown_error: setup refresh had errors, and setup_error.json reappears.
   3. Close the handle → the very next command succeeds and the log shows setup refresh: processed 3 write roots ...; errors=[].

   The same holds for any process whose image lives in the runtime tree. Starting node.exe from that tree (node.exe -e "setTimeout(function(){},60000)") is sufficient to reproduce; the first fatal target is whichever mapped file the walk reaches first (bin\node.exe, then bin\node_repl.exe, then bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll, loaded by codex-computer-use-swift.exe).

   Consistent with the MAXIMUM_ALLOWED analysis above

   • With a holder present, elevating icacls "<running exe>" /grant <sandbox group>:(RX) still succeeds (exit 0) — as does icacls on the running VCRUNTIME140_1.dll. So an open requesting READ_CONTROL | WRITE_DAC is fine against a running image; only the helper's open fails. This matches the access-mask matrix already posted.
   • Pre-granting does not help: explicit (RX) ACEs for CodexSandboxUsers were applied recursively to the whole runtime tree (2702 files, icacls /T, 0 failures) and the next refresh failed byte-for-byte identically on the same file. The refresh is unconditional, not a missing-ACE check.
   • The app re-creates holders by itself (the node_repl MCP host and codex-computer-use-swift.exe come back without an app restart), so a quiescent runtime tree is not reliably reachable while the app runs. A full reboot reproduces the failure within ~30 seconds of app start.

   Interim mitigation that keeps all features enabled

   Rather than changing configuration, we run a small background watcher (a per-logon scheduled task, no network, read-only, touches no app files). It acts only while %USERPROFILE%\.codex\.sandbox\setup_error.json exists: it terminates processes whose image lives under runtimes\cua_node\, and then leaves them alone.

   • The next command's refresh completes with errors=[], so the sandbox is provisioned cleanly.
   • Observed recovery time: 2–7 seconds.
   • node_repl and Computer Use still work: the app re-spawns those helpers on demand (verified — a killed codex-computer-use-swift.exe reappeared within ~12 s, and the node_repl MCP host was relaunched later in the same session).
   • Cost: at most one command may fail at the moment the app breaks provisioning again, and a Computer Use action that coincides with such a failure may be restarted.

   For reference, the [windows] sandbox = "unelevated" workaround mentioned earlier looks like the cleaner interim fix for users who can restart the app; we have not applied it here, so this machine continues to exercise the elevated path.
7. youseemenot commented on Oct 7, 2026

   

   youseemenot

   on Oct 7, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on Windows 10 Pro x64 build 19045, plus a candidate patch that preserves directory ACL propagation semantics.

   Environment: desktop reports 26.1002.52244 (build 13536), bundled CLI/helper 0.162.0-alpha.2, [windows] sandbox = "elevated". Source inspected and patched at tag rust-v0.162.0-alpha.2, commit 74e804deeb1241d5fe699b31fb319f7d46454c42.

   The fatal runtime validation fails on running node_repl.exe, node.exe, or loaded VCRUNTIME140_1.dll with open ACL target for root-only update ... (os error 32). The affected shared runtime also hosts code-review and codex-app-tools, so disabling Computer Use alone does not remove all holders.

   A live CreateFileW probe on the same running node_repl.exe, using FILE_FLAG_BACKUP_SEMANTICS and share mode READ|WRITE|DELETE, confirmed:

   Desired access	Result
   MAXIMUM_ALLOWED (0x02000000)	ERROR_SHARING_VIOLATION (32)
   READ_CONTROL (0x00020000)	Success
   `READ_CONTROL	WRITE_DAC` (0x00060000)

   This probe only opened and closed handles; it did not modify ACLs. The sandbox group already had read/execute access. Stopping runtime helpers temporarily allowed provisioning, but automatic startup reproduced the failure.

   Important constraint on the fix

   A blanket replacement of MAXIMUM_ALLOWED for directories can change behavior: SetSecurityInfo documents that this access mode suppresses ACE propagation to children. The existing noninheriting_read_attributes_preserve_unprotected_child_dacl regression test protects that behavior.

   The candidate below preserves the original successful path. Only on sharing violation does it retry with READ_CONTROL | WRITE_DAC, and only accepts the retry when metadata from the opened handle identifies a regular file. It retains that same handle for reading and updating the DACL. Directory behavior, existing grant/deny/null-DACL checks, and network/firewall code are unchanged.

   Validation limits

   • The live Windows access-mask comparison above was executed successfully.
   • git diff --check passed.
   • A Rust regression test is included for the original sharing failure, adding read/execute without content-write permission, idempotence, and unchanged content.
   • The Rust patch and tests have NOT been compiled or run locally: the Rust/C++ toolchain is absent. This is a candidate for maintainer review, not a verified end-to-end fix.
   • Installed signed Codex binaries were not modified. Configuration is currently elevated; the issue remains unresolved locally.
   • Please run existing directory, deny/null-DACL, long-path and runtime traversal tests, then verify elevated sandbox startup with active runtimes and filesystem/network restrictions enforced.

   Candidate patch against rust-v0.162.0-alpha.2 (uncompiled)

   diff --git a/codex-rs/windows-sandbox-rs/src/acl.rs b/codex-rs/windows-sandbox-rs/src/acl.rs
   index 0ef5e44..ebf241d 100644
   --- a/codex-rs/windows-sandbox-rs/src/acl.rs
   +++ b/codex-rs/windows-sandbox-rs/src/acl.rs
   @@ -553,6 +553,25 @@ unsafe fn ensure_allow_mask_aces_with_inheritance_impl(
                    .share_mode(FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE)
                    .custom_flags(FILE_FLAG_BACKUP_SEMANTICS)
                    .open(path)
   +                .or_else(|error| {
   +                    if error.raw_os_error()
   +                        != Some(windows_sys::Win32::Foundation::ERROR_SHARING_VIOLATION as i32)
   +                    {
   +                        return Err(error);
   +                    }
   +                    // Loaded files can reject MAXIMUM_ALLOWED because it includes
   +                    // content-write access. Keep directory grants on the original
   +                    // path: MAXIMUM_ALLOWED suppresses descendant propagation.
   +                    let file = OpenOptions::new()
   +                        .access_mode(READ_CONTROL | WRITE_DAC)
   +                        .share_mode(FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE)
   +                        .custom_flags(FILE_FLAG_BACKUP_SEMANTICS)
   +                        .open(path)?;
   +                    if !file.metadata()?.is_file() {
   +                        return Err(error);
   +                    }
   +                    Ok(file)
   +                })
                    .context("open ACL target for root-only update")?,
            )
        } else {
   @@ -646,7 +665,7 @@ unsafe fn ensure_allow_mask_aces_with_inheritance_impl(
            // For inheriting grants, request ACL-write access only when an update
            // is needed. Use the same long-path support as the read handle.
            let handle = match directory {
   -            // MAXIMUM_ALLOWED suppresses propagation of existing inheritable ACEs too.
   +            // Directory handles retain MAXIMUM_ALLOWED to suppress descendant propagation.
                Some(directory) => directory,
                None => OpenOptions::new()
                    .access_mode(READ_CONTROL | WRITE_DAC)
   diff --git a/codex-rs/windows-sandbox-rs/src/acl_tests.rs b/codex-rs/windows-sandbox-rs/src/acl_tests.rs
   index 44a1cd9..cb5973e 100644
   --- a/codex-rs/windows-sandbox-rs/src/acl_tests.rs
   +++ b/codex-rs/windows-sandbox-rs/src/acl_tests.rs
   @@ -195,3 +195,40 @@ fn noninheriting_read_attributes_preserve_unprotected_child_dacl() {
        });
        assert_eq!(acl_snapshot(&child), before);
    }
   +
   +#[test]
   +fn root_only_read_execute_grant_works_while_file_denies_write_sharing() {
   +    let directory = tempfile::tempdir().expect("temporary runtime directory");
   +    let path = directory.path().join("runtime.exe");
   +    std::fs::write(&path, b"runtime content").expect("runtime fixture");
   +    let sid = LocalSid::from_string("S-1-5-21-10-20-30-40").expect("test SID");
   +    let _loaded_file = OpenOptions::new()
   +        .read(true)
   +        .share_mode(super::FILE_SHARE_READ | super::FILE_SHARE_DELETE)
   +        .open(&path)
   +        .expect("hold runtime without write sharing");
   +    let maximum_access_error = OpenOptions::new()
   +        .access_mode(super::MAXIMUM_ALLOWED)
   +        .share_mode(super::FILE_SHARE_READ | super::FILE_SHARE_WRITE | super::FILE_SHARE_DELETE)
   +        .open(&path)
   +        .expect_err("fixture must reproduce the original maximum-access sharing failure");
   +    assert_eq!(
   +        maximum_access_error.raw_os_error(),
   +        Some(windows_sys::Win32::Foundation::ERROR_SHARING_VIOLATION as i32),
   +    );
   +
   +    assert!(unsafe { super::grant_read_execute_aces(&path, &[sid.as_ptr()], 0) }
   +        .expect("grant ACL access without requesting content-write access"));
   +    assert!(super::path_mask_allows(
   +        &path,
   +        &[sid.as_ptr()],
   +        super::FILE_GENERIC_READ | super::FILE_GENERIC_EXECUTE,
   +        true,
   +    )
   +    .expect("read/execute grant"));
   +    assert!(!super::path_mask_allows(&path, &[sid.as_ptr()], super::FILE_WRITE_DATA, true)
   +        .expect("content write must not be granted"));
   +    assert!(!unsafe { super::grant_read_execute_aces(&path, &[sid.as_ptr()], 0) }
   +        .expect("unchanged ACL must also work while runtime is loaded"));
   +    assert_eq!(std::fs::read(&path).expect("runtime content"), b"runtime content");
   +}
8. genchbench76 commented on Oct 7, 2026

   

   genchbench76

   on Oct 7, 2026

   More actions

   Same issue on 26.1002.6548.0 and 26.1002.7124.0. Clean reinstall (removed .codex, %LOCALAPPDATA%\OpenAI\Codex,
   .cache\codex-runtimes; reboot; Store reinstall) reproduces it. On 6548.0 the locked file was also
   cua_node...\swift\x64\VCRUNTIME140_1.dll (codex-computer-use-swift.exe); on 7124.0 it is bin\node_repl.exe.
9. JScottHenderson commented on Oct 8, 2026

   

   JScottHenderson

   on Oct 8, 2026

   More actions

   Additional reproduction: Dot local execution fails; unsandboxed local execution succeeds

   Observed October 7, 2026. Adding a correlated sandbox log and Process Monitor capture to this existing report instead of creating a duplicate.

   Environment

   • Windows 11 Enterprise Insider Preview, version 10.0.26220, build 26220, x64 (queried locally).
   • Installed MSIX package: OpenAI.Codex 26.1002.7124.0 (queried with Get-AppxPackage; this is the package version, not an About-dialog version).
   • Sandbox log names codex-command-runner-0.162.0-alpha.2.exe; helper binary directory 9691020b546a15b2.
   • CUA runtime directory: cua_node\3dd31cfff853001c\bin\node_repl.exe.
   • Affected workflow: ChatGPT Dot requests a local command on its connected Windows computer. Exact model and subscription were not independently checked for this report.

   Reproduction and impact

   1. With the desktop app running and the computer connected/authorized for the Dot, request a single read-only local command: hostname (Get-Location also failed in earlier attempts).
   2. Sandbox initialization fails before the command executes:

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

   3. The Dot reports the computer as connected, attached, and authorized. A fresh Dot task after a Dot reboot still failed. This connection state and reboot sequence were reported in the Dot conversation; the local logs independently confirm the subsequent failures.
   4. A separate local Codex chat on the same desktop successfully ran commands and authenticated to an existing LAN SSH server. That chat has filesystem sandboxing disabled. This isolates the comparison to different execution paths; it does NOT demonstrate that the sandbox works, and disabling it is not a recommended fix.

   Expected: authorized local tasks initialize successfully and run hostname without changing security settings or requiring the runtime processes to be stopped.
   Actual: sandbox setup exits 1; the requested command and downstream SSH test do not execute through the Dot path.

   Timeline

   All times below are America/Los_Angeles (UTC-07:00) on October 7, 2026.

   • Sandbox logs record repeated setup failures at 17:32:47, 17:46:20, 18:57:51, 19:09:14, and 19:22:36.
   • At 19:05:22, the separate unsandboxed local chat successfully authenticated to the LAN SSH server and received hostname/user/uptime, exit 0. Hostnames, usernames and addresses are omitted.
   • The Dot conversation reports that a Dot reboot did not fix execution; the 19:22:36 failure followed that reboot.
   • One coordinated hostname test was made while Process Monitor was capturing. Sandbox log command start: 19:42:09.952. Fatal file-open event: 19:42:10.6968205 (2026-10-08 02:42:10.6968205 UTC).
   • The saved CSV spans approximately 19:40:54.6429831 to 19:42:39.0464661. No further retries were requested after this capture.

   Correlated Process Monitor evidence

   The failing process is codex-windows-sandbox-setup.exe, PID 40428. %USERPROFILE% replaces the personal profile path. Timestamps and event details are preserved.

   Local time	Operation / target	Result / detail
   19:42:10.6734623	CreateFile: %USERPROFILE%	SHARING VIOLATION; Desired Access: Read Attributes, Synchronize, Maximum Allowed; ShareMode: Read, Write, Delete
   19:42:10.6966397	CreateFile: %USERPROFILE%\AppData\Local\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_repl.exe	SUCCESS; Desired Access: Read Attributes, Synchronize; Options include Open Reparse Point; ShareMode: Read, Write, Delete
   19:42:10.6967134	CloseFile: same runtime executable	SUCCESS
   19:42:10.6968205	CreateFile: same runtime executable	SHARING VIOLATION; Desired Access: Read Attributes, Synchronize, Maximum Allowed; Options: Synchronous IO Non-Alert; ShareMode: Read, Write, Delete
   19:42:10.6970051	CreateFile: same runtime executable	SUCCESS; Desired Access: Read Attributes, Synchronize; Options include Open Reparse Point; ShareMode: Read, Write, Delete
   19:42:10.7176525	Process Exit: PID 40428	Exit Status: 1
   19:42:10.7918215	Process Exit: separate setup helper PID 43668	Exit Status: 0; separate read-ACL phase, not recovery of the failed request

   Sanitized sandbox log excerpt

   [2026-10-07 19:42:09.952 codex.exe] START: %USERPROFILE%\.cache\codex-runtimes\codex-primary-runtime\dependencies\native\powershell\pwsh.exe -NoProfile -Command hostname
   [2026-10-07 19:42:10.598 codex.exe] setup refresh: spawning %USERPROFILE%\AppData\Local\OpenAI\Codex\bin\9691020b546a15b2\codex-windows-sandbox-setup.exe (cwd=C:\Program Files\WindowsApps\OpenAI.Codex_26.1002.7124.0_x64__2p2nqsd0c76g0\app\resources, payload_len=5220)
   [2026-10-08T02:42:10.674438300+00:00] failed to grant non-inheriting read-attributes ACE on user profile %USERPROFILE%: open ACL target for root-only update: The process cannot access the file because it is being used by another process. (os error 32); continuing setup
   [2026-10-08T02:42:10.697258900+00:00] runtime read/execute validation failed: validate runtime read/execute access on %USERPROFILE%\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)
   [2026-10-08T02:42:10.709617500+00:00] setup refresh: processed 2 write roots (read roots delegated); errors=["runtime read/execute validation failed: validate runtime read/execute access on %USERPROFILE%\\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)"]
   [2026-10-08T02:42:10.709669700+00:00] setup refresh completed with errors: ["runtime read/execute validation failed: validate runtime read/execute access on %USERPROFILE%\\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)"]
   [2026-10-08T02:42:10.709730400+00:00] setup error: setup refresh had errors
   [2026-10-07 19:42:10.709 codex-windows-sandbox-setup.exe] setup error: setup refresh had errors
   [2026-10-07 19:42:10.719 codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))
   [2026-10-08T02:42:10.735498400+00:00] read-acl-only mode: applying read ACLs
   [2026-10-08T02:42:10.789264400+00:00] read ACL run completed
   

   Interpretation and limits

   The capture confirms a sharing conflict during sandbox setup. Metadata opens succeed, while the open requesting Maximum Allowed fails. The successful and failing opens also differ in Open Reparse Point, so this capture alone is not a controlled access-mask experiment. This is consistent with other reports here, but we did not independently validate the source-level root cause or regression range.

   Existing node_repl processes were present, but this capture does not identify a specific conflicting handle or prove which process causes the conflict. It does not establish antivirus responsibility. A separate helper exiting 0 does not reverse the main setup failure. No ACL changes, sandbox-setting changes, process termination, file deletion, runtime replacement, or third-party patches were performed in this coordinated investigation.

   Please investigate the runtime ACL validation/open path and provide an official fix that preserves sandbox protections.

   Privacy / evidence handling

   The original sandbox log and approximately 440 MB Process Monitor CSV remain local. This report includes the relevant sanitized evidence only. Personal names, hostnames, network addresses, private repositories, organization-specific paths, task/conversation identifiers, unrelated process activity, and credentials are excluded. Raw captures and full conversation transcripts are not uploaded.
10. SebastianKohler commented on Oct 8, 2026

    

    SebastianKohler

    on Oct 8, 2026

    More actions

    Same issue, there is also a thread about this on the OpenAI Developer Community: https://community.openai.com/t/windows-desktop-app-has-broken-sandbox-after-the-latest-update/1403995
11. fjsxcsh0525-spec commented on Oct 8, 2026

    

    fjsxcsh0525-spec

    on Oct 8, 2026 – with ChatGPT Codex Connector

    More actions

    Additional reproduction on Windows: after a normal desktop restart, the same setup-stage error 32 recurred, but the failing target changed from node_repl.exe to the active CUA runtime's VCRUNTIME140_1.dll.

    Environment

    • Windows 11 Pro 26H2, build 26300.9457, x64.
    • Desktop application: 26.1002.52244, startup build 13536.
    • Windows application package: OpenAI.Codex 26.1002.7124.0.
    • Actual bundled executable: codex-cli 0.162.0-alpha.2.
    • Current CUA runtime directory: 3dd31cfff853001c.
    • The executing codex.exe and sandbox helper matched their installed-package counterparts by SHA-256; the helper had a valid OpenAI signature.

    Reproduction

    1. Normally exit and reopen the desktop application, keeping the project, configuration and proxy unchanged.
    2. In an existing dot-delegated task, request only:
       Get-Location
Get-Date -Format o
    3. The requested PowerShell process never starts. The tool reports:
       exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors

    Post-restart evidence

    Relevant entries from sandbox.2026-10-08.log, all times UTC on October 8:

    • 07:07:15.085: request starts for pwsh.exe -NoProfile -Command with the two commands above.
    • 07:07:15.142: sandbox setup helper starts.
    • 07:07:15.1844276: read-acl-only mode starts.
    • 07:07:15.1900032: read ACL run completes.
    • 07:07:27.4779741: runtime read/execute validation fails with error 32.
    • 07:07:27.4789675: setup refresh had errors.
    • 07:07:27.481: helper exits with status 1.

    Sanitized failing path:
    %USERPROFILE%\AppData\Local\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll

    The log operation is open ACL target for root-only update, followed by the localized Windows message meaning “The process cannot access the file because it is being used by another process” (os error 32).

    Before/after comparison and limits

    • Before restart, failures at 05:47:59 and 05:48:15 UTC targeted the same current runtime's bin\node_repl.exe with error 32.
    • After restart, the desktop application, app-server, exec-server and CUA Swift had new process IDs and start times. The runtime directory and executable/helper identities were unchanged. The sandbox service itself was not restarted.
    • Subsequent read-only module inspection confirmed that the new Swift process loaded the exact DLL named in the failure. That process had started before the failure. This does not identify a unique conflicting handle or reconstruct all handles at the failure instant.
    • The currently observed node_repl process started after this particular failure, so it is not evidence of the holder at that time.
    • The log contains the matching command and time, but no task/turn ID; unique RPC-to-log correlation has not been independently established.

    Important control qualification

    Read-only commands succeed in the existing manual desktop Codex session. That session uses pre-existing full-access configuration, while the delegated request goes through sandbox setup. This is not a same-permission-mode comparison and does not prove sandboxed execution works.

    No ACL/owner changes, sandbox/proxy changes, runtime deletion, force termination, helper replacement or further restart were performed. A separate existing-thread placement-format/NOT_FOUND problem is being kept separate.

    Please investigate the runtime validation file-open/access/share behavior and advise a supported fix preserving sandbox protections. The source-level cause and an effective fix on this installation remain unconfirmed.
12. sungmichael22-BHF commented on Oct 8, 2026

    

    sungmichael22-BHF

    on Oct 8, 2026 – with ChatGPT Codex Connector

    More actions

    Additional confirmed reproduction from ChatGPT Desktop Work / Computer Use on Windows.

    Symptoms:

    • Browser control / Computer Use cannot start.
    • Visible error: windows sandbox failed: helper_unknown_error: setup refresh had errors.
    • Local page itself is reachable in the desktop app, but Work cannot read/click it because the browser-control runtime fails before execution.

    Confirmed sandbox log cause:

    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
    

    Troubleshooting already performed:

    • Restarted ChatGPT Desktop.
    • Restarted Windows.
    • Verified no residual OpenAI/Codex runtime processes were running before retry.
    • Renamed the entire affected cua_node\3dd31cfff853001c runtime directory so the app had to recreate it.
    • Removed the stale %USERPROFILE%\.codex\.sandbox\setup_error.json.
    • Relaunched ChatGPT Desktop / Work.

    After relaunch, the runtime was freshly recreated under the same runtime ID and the exact same failure reproduced. The log shows node.exe starting immediately before two sandbox setup-refresh launches; those setup-refresh attempts then fail on the newly recreated node_repl.exe with error 32.

    This strongly suggests a startup/order race in which the app starts the Computer Use runtime before the sandbox refresh finishes validating/updating ACLs.

    Impact:

    • Blocks ChatGPT Desktop Work browser control / Computer Use.
    • Prevents clicking or reading an otherwise reachable localhost page.
    • Restarting Windows and recreating the runtime do not recover the feature.

    Submitted with the affected user's explicit permission. User/profile names and private project content are intentionally omitted.
13. 11 remaining items

    Load more

14. ixaelo commented on Oct 9, 2026

    

    ixaelo

    on Oct 9, 2026 – with ChatGPT Codex Connector

    More actions

    Confirming the same os error 32 regression on another Windows installation with the bundled Codex CLI 0.162.0-alpha.2.

    A minimal Get-Location fails before PowerShell actually runs:

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

    The sandbox log shows the same underlying failure reported in this issue:

    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
    

    One detail that may help confirm the race described here:

    • With Codex fully closed, there are no Codex node.exe / node_repl.exe processes.
    • Immediately after opening Codex, it creates multiple runtime processes itself, including node.exe, several node_repl.exe instances, and codex-computer-use-swift.exe.
    • The next sandbox setup refresh then fails while validating ACL access on that same in-use node_repl.exe.
    • Stopping the Codex runtime processes does not provide a persistent workaround because they are recreated when the app starts again.

    I also checked the relevant project/workspace ownership and ACLs. The directories are owned by my normal Windows account, and CodexSandboxUsers has access, so this does not appear to be a workspace ownership or .git ACL problem.

    There is also a potentially relevant earlier sandbox failure on the same machine. Before reaching the os error 32 failure, this file:

    %USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json
    

    had become exactly 22 bytes of NUL (0x00) data rather than valid JSON. That produced the separate:

    helper_unknown_error: apply deny-read ACLs
    

    failure. Moving the corrupted state file out of the active path changed the failure from the deny-read ACL parse/setup path to the runtime read/execute validation / os error 32 failure described in this issue.

    This 22-NUL-byte state-file corruption has already been reported independently in:

    • Windows sandbox fails before every shell command: deny_read_acl_state.json contains null bytes #51605
    • Windows sandbox setup fails when deny_read_acl_state.json contains null bytes #48094
    • Corrupted deny_read_acl_state.json causes persistent "apply deny-read ACLs" sandbox failures #34276

    I do not know whether the state-file corruption and the runtime sharing violation have the same root cause, so I am not asserting that they do. But on this installation they occurred consecutively in the same Windows sandbox provisioning subsystem, and fixing/bypassing the first immediately exposed the second.

    This looks consistent with the app starting processes from the cua_node runtime tree before the elevated sandbox refresh has finished validating/updating access to that same tree.

    Is there a fixed build available to test, or a supported workaround that preserves the elevated sandbox?
15. pnmcguire480 commented on Oct 9, 2026

    

    pnmcguire480

    on Oct 9, 2026 – with ChatGPT Codex Connector

    More actions

    Additional confirmation on Windows 10 Home, x64, build 19045.

    Environment:

    • Codex app-reported version: 26.1002.52244, build 13536, production channel.
    • MSIX package version: OpenAI.Codex 26.1002.7124.0.
    • Bundled core: codex-cli 0.162.0-alpha.2.
    • Configuration: [windows] sandbox = "elevated".

    Every normal sandboxed command fails before PowerShell starts with helper_unknown_error: setup refresh had errors. Explicitly approved read-only diagnostics outside the sandbox work. Codex Doctor passes authentication, desktop app-server initialization, HTTP/WebSocket connectivity, and database integrity; sandbox.helpers fails.

    Sanitized error:

    runtime read/execute validation failed:
    validate runtime read/execute access on
    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe:
    open ACL target for root-only update:
    The process cannot access the file because it is being used by another process. (os error 32)
    

    Windows event logs establish this timeline on October 8, 2026 (EDT):

    • 17:19:07: Windows starts.
    • 17:20:20–21: AppX records the update from 26.930.7945.0 to 26.1002.7124.0 and successful registration.
    • 17:35:04: the new copied core and sandbox setup helper are created.
    • 17:43:21: first recorded runtime ACL sharing violation.

    The validation error does not appear in any of the 51 earlier sandbox log files inspected. SHA256 comparisons confirm that the copied core, sandbox setup helper, and node_repl.exe match their originals in the installed MSIX package.

    Stopping the identified Node helpers moves the failure to VCRUNTIME140_1.dll, loaded by Codex's Swift helper. Codex recreates these helpers, and the executable error returns. Restarting Codex and rebooting did not resolve it. No manual ACL changes or persistent sandbox bypass were applied during this investigation.

    This matches the problem addressed by merged PR #51822. Which supported Windows desktop release includes that fix? Microsoft Store update eligibility could not be determined by the app's read-only update check.
16. liee23 commented on Oct 9, 2026

    

    liee23

    on Oct 9, 2026

    More actions

    Additional Windows reproduction: sandbox setup fails with os error 32 on node_repl.exe

    I am experiencing the same Windows sandbox initialization failure and would like to provide an additional reproduction with diagnostic evidence.

    Environment

    • Product: Codex Windows desktop app
    • Windows app package version last verified: 26.1002.7124.0
    • Workspace dependencies version: 26.1007.11041
    • Windows version: not yet recorded
    • Sandbox: normal sandbox execution, not unsandboxed PowerShell

    Issue

    Codex receives prompts normally, but any attempt to execute a command in the normal sandbox fails before the shell process starts.

    Error:

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

    The sandbox log repeatedly reports:

    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
    

    Timeline and troubleshooting

    • October 7, 2026: Codex local command execution was working normally.
    • October 8: The issue appeared, possibly after an application update.
    • Restarted Windows and reopened Codex. The issue persisted.
    • Created new Codex conversations. The normal sandbox still failed.
    • Windows PowerShell outside the Codex sandbox works.
    • Codex's built-in workspace diagnostics reported healthy.
    • Workspace dependencies show version 26.1007.11041, but the failure persists.
    • October 9: Sandbox logs reproduced the same node_repl.exe sharing violation at approximately 10:10 and 10:12 China Standard Time.

    Several node_repl.exe processes were observed under the Codex process tree, but I have not confirmed which process, if any, is responsible for the conflicting file access.

    I have not modified ACLs, deleted runtime files, disabled sandbox protections, or reinstalled the workspace dependencies.

    Expected behavior

    Simple read-only commands such as Get-Location should execute successfully inside the normal Windows sandbox.

    Actual behavior

    Sandbox initialization fails before any command is executed. This blocks ordinary local file inspection and development tasks.

    Questions

    1. Is this the same underlying issue addressed by PR Avoid sharing violations when repairing Windows runtime ACLs #51822?
    2. Which Windows desktop application release first includes that fix?
    3. Is there an officially supported recovery procedure that preserves existing chats, workspaces, configuration, and sandbox protections?

    I can provide additional sanitized sandbox logs if needed. Thank you for investigating.
17. uropb9h-dot commented on Oct 9, 2026

    

    uropb9h-dot

    on Oct 9, 2026 – with ChatGPT Codex Connector

    More actions

    Confirmed on Windows 10 Pro 22H2, build 19045.6466, with ChatGPT/Codex app 26.1002.52244 (build 13536), MSIX package 26.1002.7124.0, and bundled codex-cli 0.162.0-alpha.2.

    With windows.sandbox = "elevated", browser runtime initialization fails. Resetting the browser runtime alone does not help. The fresh sandbox log reports a sharing violation on node_repl.exe (os error 32), followed by "setup refresh had errors".

    Changing only windows.sandbox to "unelevated" and resetting the browser runtime restores Chrome page reading. Restoring "elevated" reproduces the failure; switching back to "unelevated" restores page reading again.

    No manual Windows ACL changes or runtime-file deletions were made. This is a temporary workaround with weaker isolation. Which supported Windows desktop release includes the fix from PR #51822?
18. suinian0309 commented on Oct 9, 2026

    

    suinian0309

    on Oct 9, 2026 – with ChatGPT Codex Connector

    More actions

    Independent confirmation from another Windows desktop installation.

    Environment:

    • Codex app: 26.1002.52244 (build 13536, production)
    • MSIX package: 26.1002.7124.0
    • Windows sandbox: elevated

    Every sandboxed command fails before the shell starts with:

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

    The sandbox log first points to %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe with os error 32. Restart Manager identified two live node_repl.exe holders under the Codex/CUA process tree. After terminating both, the next refresh advanced to @oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll; module inspection showed that DLL loaded by codex-computer-use-swift.exe, which the desktop app immediately respawned after termination.

    A full Windows reboot did not help. Temporarily disabling the CUA/Node entries in config.toml also did not help: after restart the desktop app regenerated the runtime entries and started those helpers before the sandbox refresh. Approved unsandboxed execution succeeds, which isolates the failure to elevated sandbox provisioning.

    This is consistent with the root cause fixed by merged PR #51822. Please publish which Windows desktop build first includes the fix; affected users currently need either an unsandboxed/full-access session or the weaker unelevated sandbox workaround.
19. lluo-octet commented on Oct 9, 2026

    

    lluo-octet

    on Oct 9, 2026

    More actions

    confirmed having the issue on windows wiht 0.162.0
20. alecwardd commented on Oct 9, 2026

    

    alecwardd

    on Oct 9, 2026

    More actions

    Adding a few data points from a single Windows 11 machine (build 26200) that I haven't seen in this thread yet. Desktop is 26.1002.7124.0, which bundles CLI 0.162.0-alpha.2.

    1. Which builds contain the fix (PR #51822)

    Several people asked which build has the fix. I checked the release tags. The fix commit (dd12f89, which adds inspect ACL target {} in windows-sandbox-rs/src/acl.rs) is:

    • in rust-v0.162.0-alpha.20 and rust-v0.163.0-alpha.2;
    • not in rust-v0.162.0-alpha.2, which is what desktop 26.1002.7124.0 bundles;
    • not in stable rust-v0.162.0 either.

    So a desktop build that bundles 0.162.0-alpha.20+ or 0.163.x should be the first desktop build with the fix. Stable 0.162.0 still has the bug.

    2. Same machine, same conditions: CLI 0.156.1 passes and 0.162.0-alpha.2 fails

    I ran the standalone npm CLI 0.156.1 with codex sandbox -P :workspace -C <new empty folder> -- powershell.exe ....

    • Conditions: a brand-new write root, codex-computer-use-swift.exe alive and holding VCRUNTIME140_1.dll, and the desktop app running.
    • Its setup logged granting write ACE to <new folder>, then processed 2 write roots; errors=[], then setup binary completed, and the command ran.
    • There is no "runtime read/execute validation" step at all in 0.156.1.
    • Two minutes later, under the same conditions, the 0.162.0-alpha.2 setup failed on the swift DLL.

    3. The swift helper runs even with every Computer Use setting disabled

    In my config.toml, these are all enabled = false:

    • computer-use@openai-bundled
    • unified-computer-use@openai-bundled
    • chrome@openai-bundled
    • [mcp_servers.cua_repl]

    codex-computer-use-swift.exe --parent-pid <desktop pid> still starts with the app. It also survives a backend restart.

    So even after node_repl is gone, the swift DLL keeps the 0.162.0-alpha.2 validation failing, and turning off Computer Use doesn't help. (Settings → Plugins → MCP servers → node_repl off does stop node_repl.exe from spawning. It restarts the app-server and the exec-server.)

    Process data comes from the Restart Manager API (RmGetList). Before and after each failure, the only holders of the failing file were node_repl.exe helpers, or for the DLL, the swift helper.
21. dede383 commented on Oct 9, 2026

    

    dede383

    on Oct 9, 2026 – with ChatGPT Codex Connector

    More actions

    Additional reproduction: elevated Windows sandbox fails with os error 32 after reinstall

    I am experiencing the same Windows sandbox provisioning failure described in this issue.

    Environment

    • Windows 11, x64
    • ChatGPT/Codex desktop MSIX package: OpenAI.Codex
    • Desktop version before reinstall: 26.1002.7124.0
    • Bundled Codex CLI before reinstall: 0.162.0-alpha.2
    • Windows sandbox configuration: sandbox = "elevated"

    Error

    helper_unknown_error: setup refresh had errors
    runtime read/execute validation failed
    open ACL target for root-only update
    os error 32 (ERROR_SHARING_VIOLATION)
    

    The failing runtime file is:

    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe
    

    The sandbox setup also reports os error 32 when attempting to grant a read-attributes ACE on the user profile directory.

    Troubleshooting already performed

    • Restarted Windows and the Codex sandbox service.
    • Repaired the Windows application.
    • Uninstalled Tencent PC Manager and restarted Windows.
    • Reinstalled the desktop application.
    • Confirmed with Process Monitor that codex-windows-sandbox-setup.exe encounters SHARING VIOLATION while opening node_repl.exe.

    None of these steps resolved the elevated sandbox failure.

    Important comparison

    • elevated: sandbox provisioning fails.
    • unelevated: a simple PowerShell command executes successfully.
    • Outside-sandbox execution with one-time approval also works.

    This strongly suggests that the issue is specific to the elevated sandbox provisioning path.

    I understand that PR #51822 addresses the runtime ACL sharing violation. Could a maintainer confirm which Windows desktop build first includes this fix and how affected users can obtain it?

    I would like to restore the normal elevated sandbox rather than rely on a weaker sandbox mode or unsandboxed execution.
22. he862195343-sys commented on Oct 9, 2026

    

    he862195343-sys

    on Oct 9, 2026 – with ChatGPT Codex Connector

    More actions

    Additional Windows 10 reproduction with before/after update timeline (October 9, 2026)

    I am reporting an independently observed work-blocking regression on behalf of an affected Codex Desktop user. This supplements #51634 rather than opening a duplicate. Local usernames, private project names, and absolute workspace paths have been redacted.

    Environment

    • OS: Windows 10 22H2, build 19045, x64.
    • Codex Desktop app version marker: 26.1002.52244 (from BROWSER_USE_CODEX_APP_VERSION in the local config; About dialog / installed MSIX version not independently read).
    • Codex Windows sandbox: sandbox_mode = "workspace-write", [windows] sandbox = "elevated".
    • Runtime tree: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\.
    • Sandboxed ordinary PowerShell commands such as Get-Date and Get-Location fail before the shell process is created.

    Exact error, anonymized

    runtime read/execute validation failed:
    validate runtime read/execute access on
    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe:
    open ACL target for root-only update:
    The process cannot access the file because it is being used by another process. (os error 32)
    
    setup error: setup refresh had errors
    

    Later failures point to the bundled Swift helper's node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll instead of node_repl.exe. In the latest available log, the 21:08:44 and 21:14:29 failures on October 9 both target that DLL.

    Read-only ACL setup is logged as successful (read-acl-only mode: applying read ACLs; read ACL run completed); failure occurs in the subsequent runtime read/execute validation step. This is ERROR_SHARING_VIOLATION (32), not evidence of incorrect workspace ownership or a general ACL permission denial. Runtime processes/modules associated with CUA/Swift were observed, but the precise incompatible file-handle owner PID has not been independently established.

    Strong local regression timing

    A scan of 47 daily sandbox logs found:

    • August 20 – October 6: zero runtime read/execute validation failed occurrences in 40 logs; setup refresh was active on those dates.
    • October 7: 54 occurrences.
    • October 8: 114 occurrences.
    • October 9: 246 occurrences.

    On October 7 at 18:02:39, setup with helper directory Codex\bin\5ea220ae823df3d7 succeeded (processed 3 write roots ... errors=[]). A different helper directory, Codex\bin\9691020b546a15b2, was materialized around 21:05:48, followed by the first observed runtime validation sharing violation at 21:18:32. This is strong evidence of a regression coinciding with the installed binary change, though not a controlled A/B test.

    Impact and attempted recovery

    • Basic local file inspection, repo checks, tests, and development tasks in the ordinary sandbox are unavailable; even trivial read-only commands fail before launch.
    • Multiple Codex host restarts and retries from different working directories did not resolve it.
    • The user reports that an attempted sandbox-mode workaround did not restore their workflow; exact post-switch diagnostics were not captured here.
    • WSL2 is not currently an operational alternative on this computer (no usable distribution was found). Installing it requires system changes and is disproportionate as the only recovery path for a native Windows regression.
    • Please do not interpret this as a request for broader ACLs, administrator elevation, or relaxed sandbox protection.

    Request to maintainers

    1. Please identify which stable Windows Desktop/MSIX release includes the fix from PR Avoid sharing violations when repairing Windows runtime ACLs #51822, or provide an ETA / supported installer channel.
    2. Provide an official, low-risk recovery path for currently blocked Windows 10 users that preserves sandbox isolation, local repositories, and conversation data.
    3. Ensure regression coverage for setup refresh while the desktop's own CUA/Node/Swift runtime executables/DLLs are loaded; ideally return an actionable error instead of a generic helper_unknown_error.

    This failure has interrupted the user's daily development workflow since the October 7 update. Thank you for prioritizing a supported production fix.
23. CelsoTeixeira commented on Oct 9, 2026

    

    CelsoTeixeira

    on Oct 9, 2026

    More actions

    Same failure with the standalone npm CLI, no desktop app running, on stable 0.162.0.

    Environment

    • Windows 11 Pro 10.0.26200 x64, pt-BR locale
    • @openai/codex installed globally via npm; codex-cli 0.162.0
    • [windows] sandbox = "elevated"

    Version check (same machine, same config)

    • 0.160.1 works: the sandbox log has no runtime read/execute validation step, and refresh ends with errors=[]
    • 0.161.0 fails (since 2026-10-07)
    • 0.162.0 fails

    Repro, no model involved

    > codex sandbox -- cmd /c echo ok
    windows sandbox failed: helper_unknown_error: setup refresh had errors
    (exit code 1)
    

    • codex doctor --summary: ✗ sandbox elevated Windows sandbox provisioning recorded a structured failure
    • ~/.codex/.sandbox/setup_error.json: {"code": "helper_unknown_error", "message": "setup refresh had errors"}

    Sandbox log (~/.codex/.sandbox/sandbox.2026-10-09.log). The Windows message is pt-BR for "The process cannot access the file because it is being used by another process".

    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: O arquivo já está sendo usado por outro processo. (os error 32)
    setup refresh: processed 0 write roots (read roots delegated); errors=["runtime read/execute validation failed: ..."]
    setup error: setup refresh had errors
    setup refresh: exited with status ExitStatus(ExitStatus(1))
    

    What holds the lock: the CLI's own codex app-server
    The desktop app was not running. Every session the npm app-server serves starts node_repl.exe from the cua_node runtime, both directly and through cua-repl.mjs:

    node_repl.exe  <- codex.exe app-server   (npm vendor binary)
    node_repl.exe  <- node.exe ...\cua_node\3dd31cfff853001c\bin\node_modules\@oai\cua-repl\bin\cua-repl.mjs
    

    There were 8 such processes at repro time, all ...\cua_node\3dd31cfff853001c\bin\node_repl.exe. Once one app-server session has started, sandbox setup fails for that server and for every other codex exec or codex sandbox on the machine.

    codex exec hides the failure
    On 0.161.0, codex exec exits 0 even when every exec_command was rejected. The log repeats:

    exited -1 in 0ms:
    Failed to create unified exec process: helper_unknown_error: setup refresh had errors
    ERROR codex_core::tools::router: error=exec_command failed: CreateProcess { message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")" }
    

    Then the agent writes a final message saying it couldn't run anything, and the process exits 0. Scripted callers can't detect the failure without parsing logs. A non-zero exit, or aborting early when the sandbox can't be set up, would help.

    Workaround: npm i -g @openai/codex@0.160.1
24. irat25 commented on Oct 9, 2026

    

    irat25

    on Oct 9, 2026 – with ChatGPT Codex Connector

    More actions

    Update: partial MXC workaround; browser access is still broken

    Follow-up to my reports #6058169335 and #6059452056, posted at the affected user's request.

    Verified environment: installed MSIX OpenAI.Codex 26.1002.7124.0 (package inspection, rather than the earlier updater version marker), bundled CLI 0.162.0-alpha.2, Windows 11 26200.9457. The original elevated sandbox log records os error 32 during runtime ACL validation of an in-use node_repl.exe.

    Partial workaround tested on this installation: switch to mxc and use a named profile that inherits workspace permissions but removes broad root reads. The actual configuration below is anonymized; replace <user> with the local profile directory and adapt runtime paths to the installation. Back up the existing config and preserve unrelated settings.

    # Top-level key, before any [section]:
    default_permissions = "mxc-workspace-recovery"
    
    [windows]
    sandbox = "mxc"
    
    [permissions.mxc-workspace-recovery]
    extends = ":workspace"
    
    [permissions.mxc-workspace-recovery.filesystem]
    ":root" = "deny"
    ":minimal" = "read"
    "C:/Users/<user>/.codex" = "read"
    "C:/Users/<user>/.agents" = "read"
    "C:/Users/<user>/AppData/Local/OpenAI/Codex" = "read"
    "C:/Users/<user>/.cache/codex-runtimes/codex-primary-runtime" = "read"

    The ordinary broad :workspace MXC probe did not finish within the test window. Some mapped network drives are unavailable; their involvement is a hypothesis, not a confirmed cause of the browser failure.

    Results, including after a full desktop-app restart:

    • codex doctor --json: sandbox.helpers=ok, backend mxc, filesystem/network restricted; overall result remains warning. The helper check reports “sandbox configuration is readable.”
    • Explicit CLI probes under the saved profile returned exit 0:
      codex sandbox --include-managed-config --permission-profile mxc-workspace-recovery -- cmd.exe /d /c echo AFTER_RESTART_MXC_OK
      and a plain bundled Node executable. This is not a successful node_repl or browser-tool test.
    • Workspace reads and denial of an outside-workspace write were verified.
    • Ordinary app shell tools still have long startup delays; PowerShell also reports InitializeDefaultDrives.
    • Browser/Computer Use remains unusable: a fresh cua.getState() timed out after 30 seconds; after an explicit kernel reset, another attempt timed out after 60 seconds. No tab or page state was returned.

    This only restores the tested CLI execution path. It does not restore browser automation, and the issue is not resolved for this user. We have not established the remaining browser failure's cause. Could a maintainer provide supported browser-recovery steps or identify the Windows desktop build that fixes this path?
25. yamayamashi1031-hub commented on Oct 10, 2026

    

    yamayamashi1031-hub

    on Oct 10, 2026

    More actions

    Still reproduces on codex-cli 0.162.1 (stable, npm) with desktop app runtime cua_node\3dd31cfff853001c (installed by the 26.1002.52244 auto-update), Windows 11 Pro 26200.

    • codex exec -s workspace-write that runs any shell command fails with setup refresh had errors; the sandbox log shows runtime read/execute validation failed ... node_repl.exe ... (os error 32). It fails even when no other Codex process is running beforehand: the run's own node_repl.exe is enough to trigger it.
    • A plain "reply only" prompt passes, so it is easy to get a false "fixed" result when testing. A test has to execute at least one shell command.
    • danger-full-access runs are unaffected.
    • Workaround we use: set enabled = false under [mcp_servers.node_repl] in ~/.codex/config.toml (browser/computer-use is lost). We re-test automatically whenever the CLI version or the runtime path changes, and re-enable once the test passes.
26. franklin202204-hub commented on Oct 10, 2026

    

    franklin202204-hub

    on Oct 10, 2026

    More actions

    Independent reproduction on a different machine (confirms #51634)

    Adding a second data point with a different helper build and a few findings that may help narrow the fix.

    Environment

    Item	Value
    Desktop app	OpenAI.Codex 26.1002.7124.0 (MSIX)
    CLI	codex-cli 0.160.0
    Sandbox helper build	9691020b546a15b2 (materialized 2026-10-08 19:55)
    Runtime	%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c
    OS	Windows 11 (10.0.22631), zh-CN
    Config	[windows] sandbox = "elevated", sandbox_mode = "workspace-write"
    Endpoint protection	none detected (codex doctor)

    Regression is visible locally too

    Same machine, same config, .codex/.sandbox/sandbox.<date>.log:

    Date	errors=[]	setup error	runtime read/execute occurrences
    2026-10-05	1	0	0
    2026-10-07	13	0	0
    2026-10-10	12	36	many

    The failing step simply does not exist in the pre-0.162 helper — matching #51634's finding.

    Failure target moves with whichever helper is alive

    Distinct targets observed in one day:

    ...\cua_node\3dd31cfff853001c\bin\node_repl.exe
    ...\cua_node\3dd31cfff853001c\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll
    

    Holders (all launched by the desktop app):

    codex-computer-use-swift.exe      (parent = ChatGPT.exe)
    node.exe  ...\@oai\cua-repl\bin\cua-repl.mjs
    node_repl.exe
    

    Killing the holder does not help: codex-computer-use-swift.exe was back within ~0.4 s and the refresh failed on the same DLL.

    Pre-granting permissions does not help (independently confirmed)

    Matched the ACL of a known-good runtime file byte-for-byte:

    O:...-1001 G:...-513
    D:AI(A;ID;0x1200a9;;;...-1003)(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;FA;;;...-1001)
    

    Deny ACEs left behind by earlier failed runs were also removed from the whole tree (336 dirs, changes propagated). The failure was unchanged — confirming this is about being able to open the target, not about the resulting ACE shape.

    New evidence: the runtime path does not come from config.toml

    Repointing every runtime reference in config.toml (4 occurrences) to a healthy, idle runtime had no effect — setup still validated the new runtime. The path is referenced from:

    %USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\<ver>\.mcp.json   (6 refs)
    %USERPROFILE%\.codex\chrome-native-hosts-v2.json                                          (3 refs)
    

    So "just point it at another runtime" is not a viable workaround.

    Proof that the only blocker is the in-use files

    Manually terminating every process under the runtime directory and immediately triggering provisioning succeeded:

    setup refresh: processed 2 write roots (read roots delegated); errors=[]
    setup binary completed
    

    …and a real command then executed inside the sandbox (succeeded in 95ms).

    43 seconds later the app's own refresh failed again on the same DLL — i.e. a successful provisioning pass is not enough; the app re-occupies the tree immediately.

    Verified workaround: [windows] sandbox = "unelevated"

    Switching to the documented fallback avoids the failing step entirely. Log during the unelevated run:

    04:52:28  read-acl-only mode: applying read ACLs
    04:52:28  read ACL run completed
    04:52:28  setup refresh: processed 3 write roots; errors=[]
              ← "runtime read/execute" occurrences during this window: 0
              setup binary completed
    

    The command executed successfully. All app functionality is retained (filesystem ACL boundary still applies); isolation is weaker than elevated, as documented.

    Possible fix directions

    1. Tolerate in-use targets: when opening a runtime binary for the ACE grant returns ERROR_SHARING_VIOLATION, skip it and continue (log a warning) rather than failing the whole refresh — the ACE is typically already present.
    2. Open with a compatible share mode: the shipped ACEs are already correct, so a read-only/FILE_SHARE_READ|WRITE|DELETE verification would avoid the exclusive open entirely.
    3. Order the work: apply/verify runtime ACLs before launching the CUA/MCP helpers that map those images.
    4. Defer: if a target is in use, mark the refresh as "provisioned with warnings" so command execution still proceeds; retry the ACE grant on next idle refresh.

    Happy to provide full logs or run additional diagnostics if that helps.

    Still broken as of 0.162.1 (verified same day)

    After aligning versions (the app auto-upgraded the shared daemon to 0.162.1, so I also upgraded the CLI from 0.160.0 → 0.162.1 via codex update), I re-tested elevated:

    codex exec -c 'windows.sandbox="elevated"' --sandbox workspace-write --skip-git-repo-check "run: echo elevated-ok"

    Result — unchanged:

    setup refresh: processed 3 write roots (read roots delegated); errors=["runtime read/execute validation failed: ..."]
    setup error: setup refresh had errors
    

    Failing target again: ...\runtimes\cua_node\<hash>\bin\node_repl.exe (same file as before).

    So the regression is not fixed in 0.162.1 — unelevated remains the only workable mode.

    Post-upgrade state (for reference)

    Item	Value
    CLI	0.162.1
    app-server daemon	0.162.1 (aligned)
    Sandbox mode in use	unelevated
    Commands	working
    Workspace write	allowed
    Write outside workspace	denied (boundary intact)
    codex doctor sandbox	✓ restricted fs + enabled network

    Side note: CLI/daemon feature-flag skew

    While the CLI was still 0.160.0 against a 0.162.1 daemon, every CLI start showed:

    Background server has incompatible feature settings
    This session requires api_key_model_discovery to be disabled
      1. Run without daemon this time
      2. Restart with these settings
      3. Cancel
    

    Choosing 2 rewrites the shared daemon's feature flags to the older CLI's set (the prompt itself warns: "These settings persist and can disable functionality for other clients"). Aligning versions via codex update made this disappear — probably worth surfacing as a hint rather than an offer to mutate shared state, since the shared daemon is also used by the desktop app.
27. cpaulk87 commented on Oct 10, 2026

    

    cpaulk87

    on Oct 10, 2026 – with ChatGPT Codex Connector

    Last edited by cpaulk87

    More actions

    Additional reproduction on October 10, 2026. The failure persists after restarting the application/session.

    The sandbox log identifies the setup helper used by the failing shell calls as:

    %USERPROFILE%\.codex\packages\standalone\releases\0.162.1-aarch64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
    

    The same log also records earlier failures through the corresponding app-server-daemon\releases\0.162.1-aarch64-pc-windows-msvc helper. These are versions/architecture labels from the helper paths, not independently verified app or OS versions.

    The affected runtime is:

    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\0e05c28d766e39e5\bin\node_repl.exe
    

    Sanitized diagnostic excerpt from sandbox.2026-10-10.log, matching the shell test at 14:59 UTC:

    runtime read/execute validation failed: validate runtime read/execute access on
    C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\0e05c28d766e39e5\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
    setup refresh: exited with status ExitStatus(ExitStatus(1))
    

    Observed impact:

    • PowerShell commands fail before execution with Failed to create unified exec process: helper_unknown_error: setup refresh had errors.
    • Retrying with an explicit Windows PowerShell executable and login handling disabled produces the same failure.
    • apply_patch cannot create a small test file in the authorized workspace.
    • Access is partial: the Node REPL can read a known file under .codex and create/read/delete a temporary file under %LOCALAPPDATA%\Temp, but listing or writing directly under the workspace root returns EPERM.

    Process inspection showed two node_repl.exe processes using the affected runtime executable (PIDs 15720 and 19124; parent PIDs 19144 and 17120 respectively). Fully exiting Codex releases every observed node_repl.exe instance. Restarting had already been attempted before this reproduction, and the failure returned. This argues against orphaned runtime processes surviving app exit, but does not independently identify the exact conflicting handle or establish the full root cause.

    No manual ACL changes or sandbox-mode changes were made during these tests.

    Environment details supplied by the affected user:

    • Codex version: 0.162.1 (also matches the setup helper release paths above).
    • Windows 11, version 25H2, OS build 26200.9457.

    A separate desktop UI/package version has not been independently verified.

    Could you confirm which supported app/runtime release includes the fix from #51822, and whether the 0.162.1 setup helper should contain it?
28. thebetterfarhan commented on Oct 18, 2026

    

    thebetterfarhan

    on Oct 18, 2026

    More actions

    Reproduced 2026-10-18 with desktop CLI codex.exe 0.162.1 (helper from 0.162.1-x86_64-pc-windows-msvc) and Store app 26.1007.9446.0.

    Same signature: runtime read/execute validation failed on ...\cua_node\a9ba6825a525118c\bin\node_repl.exe (os error 32) during codex exec --sandbox read-only; exec rejected with Failed to create unified exec process: helper_unknown_error: setup refresh had errors.

    Additional data points:

    • ACLs already correct: FARHANSLAPTOP\CodexSandboxUsers:(I)(RX) inherited on the file and its bin dir — matches the report that pre-granting does not help.
    • With the desktop app fully stopped (all OpenAI.Codex processes + daemons ended, no process from the runtime tree visible), the CLI-only run still failed on the same file — then a later setup in the same window reported errors=[] with no changes in between. So the open handle can come from the CLI session itself, not only the desktop app, and it is not purely deterministic.
    • codex exec with config sandbox_mode = "danger-full-access" (no --sandbox flag, so no setup refresh) works — the validation step is the only blocker.
    • npm @openai/codex@0.160.0 with --sandbox read-only: works (helper predates the new validation step).
    • npm @openai/codex@0.163.0 with --sandbox read-only: works, in the same CLI-only condition where 0.162.1 failed. So the fix may already be in 0.163 — but the desktop app still ships the 0.162.1 helper, so desktop sessions remain broken.

    Workaround: use CLI 0.163+ (npm) for sandboxed runs until the desktop app ships an updated helper.