Skip to content

Windows sandbox provisioning always fails: setup tries to ACL runtime binaries Codex itself is executing (os error 32) #52735

Open
Open
Windows sandbox provisioning always fails: setup tries to ACL runtime binaries Codex itself is executing (os error 32)#52735
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@dilireba666999
dilireba666999
opened on Oct 10, 2026

Bug report: Windows sandbox setup fails because Codex's own helpers occupy the runtime binaries it tries to ACL

Suggested title: Windows sandbox provisioning always fails: setup tries to update ACLs on runtime binaries that Codex itself is executing (os error 32)

Summary

On Windows, the sandboxed (default / "ask for approval") execution mode is unusable: every command fails with

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

The sandbox provisioning step (codex-windows-sandbox-setup.exe) aborts because it cannot open runtime
executables for an ACL update while those same executables are running:

runtime read/execute validation failed: validate runtime read/execute access on
C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node.exe:
open ACL target for root-only update: 另一个程序正在使用此文件，进程无法访问。 (os error 32)

Windows does not allow modifying the security descriptor of a file that is currently mapped as an image
(a running executable). Because Codex itself launches several helper processes out of that same runtime
directory, this is a permanent conflict, not a transient race.

Environment

  • App: display name ChatGPT, package identity OpenAI.Codex 26.1002.7124.0 (x64, Microsoft Store build)
  • OS: Windows 11 (10.0.26200), display language zh-CN
  • Config: ~/.codex/config.toml → [windows] sandbox = "elevated"; default permission profile (workspace-write)
  • Not reproducible in Full access mode (that path does not perform sandbox provisioning)
  • No third-party endpoint protection installed (codex doctor reports no supported endpoint protection detected)

Steps to reproduce

  1. Install the app from the Microsoft Store and leave the execution mode at its default (sandboxed / ask-for-approval).
  2. Open any chat and ask the agent to run a trivial command, e.g. echo hi.
  3. The command fails immediately with helper_unknown_error: setup refresh had errors.

Reproduced consistently across app restarts, and also on a fresh install.

Evidence

~/.codex/.sandbox/sandbox.<date>.log — the provisioning run aborts on the runtime validation:

[2026-10-09 19:19:41.575 codex.exe] setup refresh: spawning ...\codex-windows-sandbox-setup.exe (cwd=..., payload_len=3196)
[2026-10-09T11:19:41.642+00:00] failed to grant non-inheriting read-attributes ACE on user profile C:\Users\<user>:
    open ACL target for root-only update: 另一个程序正在使用此文件，进程无法访问。 (os error 32); continuing setup
[2026-10-09T11:19:41.676+00:00] runtime read/execute validation failed: validate runtime read/execute access on
    ...\runtimes\cua_node\<hash>\bin\node_repl.exe: open ACL target ...
[2026-10-09T11:19:41.680+00:00] setup refresh completed with errors: [...]
[2026-10-09T11:19:41.680+00:00] setup error: setup refresh had errors
[2026-10-09 19:19:41.680 codex-windows-sandbox-setup.exe] setup error: setup refresh had errors
[2026-10-09 19:19:41.688 codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))

Processes running out of the same runtime directory at that moment (all launched by the app itself):

node_repl.exe                                             × 5
node.exe  ...\@oai\cua-repl\bin\cua-repl.mjs              × 2
codex-computer-use-swift.exe  ...\@oai\sky\bin\...        × 1

The failure target moves between files as different helpers start and stop — we first observed it on
bin\node.exe, later on bin\node_repl.exe — which confirms the mechanism: whichever runtime binary
Codex is currently executing cannot also be ACL-updated by the setup step.

The ACL itself is already correct on these files (BUILTIN\Users/CodexSandboxUsers already have inherited
read+execute), so the update is not needed for correctness — but the code path still treats the failed open
as fatal.

Root cause

codex-windows-sandbox-setup.exe performs a fatal "runtime read/execute validation" that opens each runtime
binary with a root-only ACL update (WRITE_DAC). For a running image that open fails with
ERROR_SHARING_VIOLATION (32). Since the app always keeps helper processes alive from the cua_node runtime
(the app-tools MCP server, the node REPL server, the cua-repl server, computer-use helper), the provisioning
step has no reliable window in which it can succeed.

Suggested fix

  1. Treat ERROR_SHARING_VIOLATION / ERROR_ACCESS_DENIED during the runtime ACL validation as non-fatal
    when the effective ACL already grants the required read/execute access (i.e., verify access instead of
    unconditionally re-applying it).
  2. Avoid running helper processes from a directory whose executables the sandbox setup needs to modify —
    e.g. run the MCP servers/helpers from the primary runtime bundle (~/.cache/codex-runtimes/...), or
    copy the sandbox runtime binaries to a per-provisioning location.
  3. Alternatively, validate ACLs by reading the DACL rather than opening the file for update.

Workaround (user side)

  • No configuration change fixes it. Once the mode is set to Full access (no sandbox), commands work
    normally — that path does not perform provisioning.
  • Killing the helper processes unlocks the files, but the app restarts them, so the sandbox breaks again
    within minutes. Not a stable workaround.

Notes

  • Related: the store package's AppxManifest.xml declares only <Resource Language="en-US" />, while the
    package ships locales/zh-CN.pak and native-menu-locales/zh-CN.json; the UI therefore stays English on a
    Chinese system even with [desktop] localeOverride = "zh-CN" set. (Separate issue, may be worth a look.)
  • codex doctor on this machine reports: ✗ sandbox elevated Windows sandbox provisioning recorded a structured failure.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    on Oct 10, 2026

  2. github-actions commented on Oct 10, 2026

    @github-actions
    github-actionsbot
    on Oct 10, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. zhangmin101900-spec commented on Oct 11, 2026

    @zhangmin101900-spec
    zhangmin101900-spec
    on Oct 11, 2026

    Additional independent reproduction (Windows 11, zh-CN; 2026-10-11 UTC+08:00). Local profile and runtime identifiers are redacted.

    • Bundled CLI: codex-cli 0.162.0-alpha.2.
    • Before workaround, config was [windows] sandbox = "elevated" with workspace-write permissions.
    • Ordinary local commands failed before process creation with helper_unknown_error: setup refresh had errors.
    • The sandbox log identifies the active Computer Use helper under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node<runtime-id>\bin\node_modules@oai\sky\bin\windows\codex-computer-use.exe. The fatal error was: “open ACL target for root-only update: 另一个程序正在使用此文件，进程无法访问。 (os error 32)”.
    • A read-only process inventory showed Codex-owned node.exe, node_repl.exe, and codex-computer-use.exe processes running from that same runtime while setup repeatedly failed.
    • A one-shot command with windows.sandbox="unelevated" succeeded. After changing only the saved backend to unelevated, the same echo without an override succeeded too. This restores command execution while retaining sandboxing, with weaker isolation than elevated.

    Could you confirm which supported Windows Desktop build will include the merged runtime ACL fix in #51822? This installation's bundled CLI is 0.162.0-alpha.2, and the failure is still reproducible.

  4. zhangmin101900-spec commented on Oct 11, 2026

    @zhangmin101900-spec
    zhangmin101900-spec
    on Oct 11, 2026

    Follow-up (2026-10-11): the desktop update checker currently reports installedVersion 26.1002.52244, build 13536, release channel prod, status restart_required. The desktop's ordinary exec_command still fails with the same setup refresh error after the saved windows.sandbox setting was changed to unelevated; a separate codex.exe sandbox probe without an override succeeds. This suggests the running desktop process has not picked up the saved config yet. Please confirm the supported desktop update/restart path and the first desktop build that bundles #51822.

  5. zhangmin101900-spec commented on Oct 11, 2026

    @zhangmin101900-spec
    zhangmin101900-spec
    on Oct 11, 2026

    Update after a full desktop restart (2026-10-11, UTC+08): the desktop unified exec still fails before process creation with helper_unknown_error: setup refresh had errors; even a minimal read-only command and sandbox log read are rejected by the same setup error. The update checker reports installedVersion 26.1002.52244, build 13536, channel prod, status restart_required. This confirms the issue persists after restart; the previous note that the running desktop may not have picked up config was only a hypothesis and is superseded. The separately invoked bundled CLI probe with saved windows.sandbox = "unelevated" succeeds, so the failure is specific to the desktop execution/setup path. Could maintainers confirm the supported recovery/update path and which Desktop build includes merged PR #51822?

  6. zhangmin101900-spec commented on Oct 11, 2026

    @zhangmin101900-spec
    zhangmin101900-spec
    on Oct 11, 2026

    New local validation (2026-10-11, UTC+08): the official 0.162.0-alpha.20 Windows release archive matched its published SHA-256, and the CLI Authenticode signature is valid for OpenAI OpCo, LLC. With the Codex Desktop 26.1002.7124.0 process and its runtime helpers still running, the alpha.20 CLI completed a sandboxed command successfully with windows.sandbox=elevated; a second probe also succeeded using the saved elevated config. The Desktop built-in executor remains on 0.162.0-alpha.2 and still fails with helper_unknown_error: setup refresh had errors. This confirms the newer fixed CLI can work on this installation while preserving the elevated sandbox; the remaining gap is the Desktop-managed runner/update path. Could you confirm whether CODEX_CLI_PATH is a supported override for the Store Desktop app and which signed production Desktop build will include #51822? A community report says alpha.20 may require [features] content_item_kinds = false for Desktop protocol compatibility (#52488); this should be documented if that remains the recommended interim route.

  7. zhangmin101900-spec commented on Oct 11, 2026

    @zhangmin101900-spec
    zhangmin101900-spec
    on Oct 11, 2026

    Correction and channel-specific validation (2026-10-11, UTC+08):

    The independently reproduced host is Windows 10 Pro 22H2, build 19045.6466, confirmed by registry, CIM, and .NET. My earlier Windows 11 wording was incorrect.

    With the saved [windows] sandbox = "unelevated" configuration:

    • The actual CUA/browser-control tool starts. An isolated loopback HTTP test passed reading, input, clicking, and visible result verification without restarting Desktop.
    • GitHub native accessibility reading timed out at the default tool limit; the documented Playwright DOM snapshot successfully read this issue.
    • Desktop unified exec still fails before command creation with helper_unknown_error: setup refresh had errors.
    • The existing standalone CLI passes an elevated sandbox echo probe.

    This is a temporary workaround with weaker isolation, not confirmation that all Desktop channels are fixed. Please confirm the first signed production Windows Desktop package containing #51822 and the supported Desktop recovery path. No business-page content, account information, or raw logs are attached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions