Skip to content

Windows sandbox: bundled 0.162.0-alpha.2 fails with sharing violation; separate stable 0.160.1 starts #51596

Open
Open
Windows sandbox: bundled 0.162.0-alpha.2 fails with sharing violation; separate stable 0.160.1 starts#51596
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@Immtar
Immtar
opened on Oct 7, 2026

Environment

  • Windows x64; exact Windows build and subscription tier not collected.
  • Desktop package recorded in setup log: OpenAI.Codex_26.1002.6548.0_x64__2p2nqsd0c76g0.
  • Bundled CLI, verified with --version: codex-cli 0.162.0-alpha.2.
  • Separate official portable Windows CLI: codex-cli 0.160.1.
  • Observed October 5–7, 2026; latest comparison October 7, 07:57 Europe/Berlin (UTC+02).

Actual behavior and reproduction

On the affected existing installation, ask the desktop chat or its programming subagent to run a normal PowerShell Get-Location. Execution fails before the command starts:

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

User-provided sandbox logs identify the fatal runtime-validation failure:

runtime read/execute validation failed
open ACL target for root-only update
The process cannot access the file because it is being used by another process. (os error 32)
setup refresh: exited with status ExitStatus(ExitStatus(1))

The target was first VCRUNTIME140_1.dll under the bundled cua_node/sky Swift runtime, then node_repl.exe under the same runtime. A separate profile-directory error was marked continuing setup; executable validation was in the fatal errors list.

Repeated app updates and reported restarts/reboots did not restore this chat. A single targeted stop of codex-computer-use-swift did not restore it; a later instance was observed. No kill loop was performed. An earlier, distinct helper_sandbox_lock_failed on .sandbox-bin temporarily responded to a backed-up, directory-only SYSTEM-WDAC addition; setup removed that right again. This was not a lasting fix for the current sharing violation. No recursive ACL reset, owner change, runtime replacement or sandbox disabling was performed.

Separate stable comparison

The user ran the official portable 0.160.1 package:

codex.exe sandbox --permission-profile ':read-only' --include-managed-config --cd <test-directory> -- powershell.exe -NoProfile -Command Get-Location

Output: C:\; exit code: 0. Immediately afterwards, one normal probe each in the original chat and subagent still failed before execution. These are different execution contexts, not a controlled identical A/B test. No Git/compiler/engine readiness or permanent desktop repair is inferred. A separate programming chat has since resumed work according to the user; its runtime was not independently verified here.

Source hypothesis, not proven root cause

The exact 0.162.0-alpha.2 acl.rs contains a root-only open using MAXIMUM_ALLOWED before the DACL/no-op check and the matching error context. That additional branch is absent from the checked 0.160.1 acl.rs. Please investigate access requirements for live runtime files. The installed setup-helper binary has not been hash/debugger-matched to that source.

Impact and requested outcome

Basic commands are blocked, while repeated manual log collection and unsuccessful recovery consume substantial user time and chat context. Exact token/cost totals have not been measured. The user considers this burden unacceptable for routine tasks.

Please provide a supported desktop fix or stable-runtime route, surface the actual file/Win32 failure directly, and offer a single sanitized diagnostic export instead of repeated manual diagnosis and generic restart advice.

Related report: #51590. This report adds the separate stable comparison; the other reporter's measurements are not attributed to this installation. No clean-install reproduction established.

Personal paths, account identifiers, private project links, credentials and full chat transcripts are omitted.

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 7, 2026

  2. github-actions commented on Oct 7, 2026

    @github-actions
    github-actionsbot
    on Oct 7, 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. jedismj commented on Oct 8, 2026

    @jedismj
    jedismj
    on Oct 8, 2026

    I can reproduce this on codex-cli 0.162.0-alpha.2 with the elevated Windows sandbox. Attached are my report, sandbox log excerpt, and Process Monitor screenshots. The capture shows Codex starting node_repl.exe before the sandbox setup helper attempts the failing MAXIMUM_ALLOWED open approximately five seconds later. It persists after reboot and reinstall.

    Codex Windows sandbox setup fails with a sharing violation on its own node_repl.exe

    Summary

    On Windows, every sandboxed codex exec command fails before it runs:

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

    The sandbox setup refresh fails on …\runtimes\cua_node\<hash>\bin\node_repl.exe with os error 32 ("being used by another process"). Process Monitor shows the conflict comes from Codex itself:

    1. In the same run, codex.exe starts node_repl.exe from that path.
    2. node.exe then starts a second node_repl.exe from the same path.
    3. About 5 s later, codex-windows-sandbox-setup.exe opens that file with Desired Access = MAXIMUM_ALLOWED.
    4. Because the user owns the file, MAXIMUM_ALLOWED includes write access. Windows refuses write access to an executable image that is mapped by a running process, so the open fails with SHARING VIOLATION.

    Environment

    Item Value
    OS Windows 11 Home, version 26H2, build 26300.9457 (NT 10.0.26300, EditionID Core)
    Codex CLI codex-cli 0.162.0-alpha.2
    codex.exe %LOCALAPPDATA%\OpenAI\Codex\bin\9691020b546a15b2\codex.exe
    Sandbox setup %LOCALAPPDATA%\OpenAI\Codex\bin\9691020b546a15b2\codex-windows-sandbox-setup.exe
    Failing file %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_repl.exe (installed with the app update on 2026-10-08, ~19:28 local)
    ~/.codex/config.toml [windows] sandbox = "elevated"; sandbox_mode = "workspace-write"; [mcp_servers.node_repl] command = '…\cua_node\3dd31cfff853001c\bin\node_repl.exe'; notify = [ "…\cua_node\3dd31cfff853001c\bin\node_modules\@oai\sky\bin\windows\codex-computer-use.exe", "turn-ended" ]
    Time zone ACDT (UTC+10:30). Log lines show both local and UTC times.

    Reproduction (exact command)

    From Windows PowerShell 5.1:

    $c = "$env:LOCALAPPDATA\OpenAI\Codex\bin\9691020b546a15b2\codex.exe"
"Run the shell command 'git log --oneline -1' in the working directory and report its exact output, then stop. Do not modify anything." |
  & $c exec -m gpt-6.1-sol -c model_reasoning_effort=low -s read-only `
    -C "C:\Projects\Invoice Hub\invoicehub-cash-s2-2026-10-07" --ephemeral -o out.md -

    Result: exit code 0, but the model reports that the shell tool failed with the error above. This happens on every run, with any working directory and any prompt that needs a command.

    Persists after

    • killing every Codex process;
    • a Windows restart;
    • uninstalling and reinstalling Codex (the same build came back);
    • per-run overrides -c features.computer_use=false -c features.browser_use=false -c features.browser_use_external=false -c features.in_app_browser=false;
    • -c mcp_servers.node_repl.enabled=false (Process Monitor still shows codex.exe starting node_repl.exe);
    • copying the helper executables into %LOCALAPPDATA%\OpenAI\Codex\bin as described in a community workaround. The copies were removed afterwards.

    -c features.code_mode_host=false removes the command tool entirely ("code-mode host is disabled").

    Process Monitor evidence (22:33 run; filter: Path = the node_repl.exe above)

    Time (local) Process (PID) Operation Result Detail
    22:33:02.9029 codex.exe (37728) CreateFile, then CreateFileMapping FILE LOCKED WITH ONLY READERS Read Data/Execute; SyncTypeCreateSection, PAGE_EXECUTE
    22:33:02.9081 codex.exe (37728) Process Create SUCCESS PID 30380, …\node_repl.exe
    22:33:02.9120 node_repl.exe (30380) Load Image SUCCESS Image Base 0x7ff6063c0000
    22:33:02.91–.93 MsMpEng.exe (5856) CreateFile / CloseFile SUCCESS read-only, ShareMode Read/Write/Delete, closed straight away
    22:33:02.94 conhost.exe (20276) CreateFile, then CreateFileMapping FILE LOCKED WITH ONLY READERS Generic Read/Execute, ShareMode Read/Delete, PAGE_READONLY
    22:33:03.0407 node.exe (33488) Process Create SUCCESS PID 13256, …\node_repl.exe (a second instance)
    22:33:03.0459 node_repl.exe (13256) Load Image SUCCESS
    22:33:08.1530 codex-windows-sandbox-setup.exe (27800) CreateFile SHARING VIOLATION Desired Access: Read Attributes, Synchronize, Maximum Allowed; ShareMode Read, Write, Delete; impersonating THE-AMD\jedis

    The sandbox log for the same run (sandbox-log-excerpt.txt) shows setup refresh: spawning …codex-windows-sandbox-setup.exe at 22:33:08.087, then os error 32 at 22:33:08.155 (12:03:08 UTC). That is 66 ms apart, matching the Process Monitor row.

    An earlier capture of the same failure, at 22:24:36–42, shows the same pattern: codex.exe PID 20176 starts node_repl PID 14744, then node.exe PID 33156 starts node_repl PID 10444.

    Ruled out:

    • Windows Defender (MsMpEng) only performs read-only opens with full sharing and closes immediately.
    • svchost.exe (PID 27216) polls attributes about once a minute, read-only with full sharing, and closes immediately.
    • No other process touches the file.

    Likely fix

    Either of these should avoid the conflict:

    • In the setup refresh's "open ACL target for root-only update", request only the rights needed to read and update the security descriptor (READ_CONTROL | WRITE_DAC, plus WRITE_OWNER if required) instead of MAXIMUM_ALLOWED. These rights don't conflict with a mapped running image.
    • Run the runtime ACL refresh before starting node_repl.exe (and its child node.exe → node_repl.exe), or skip the refresh when the ACL is already correct.

    sandbox-log-excerpt.txt

    setup_error.json

    Image Image Image Image Image Image
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