Windows app 26.1002.51308: sandbox setup fails with sharing violation when validating its own active runtime #51601

Title: Windows app 26.1002.51308: sandbox setup fails with sharing violation when validating its own active runtime

Summary

After updating the Windows Codex app to 26.1002.51308 (build 13417), all command execution fails before the requested command starts:

helper_unknown_error: setup refresh had errors

Node REPL also fails:

trusted Node process exited unexpectedly

Sandbox logs show that runtime ACL validation attempts to open files currently used by Codex itself and fails with Windows error 32 (ERROR_SHARING_VIOLATION).

Environment

• OS: Windows
• Codex app: 26.1002.51308, build 13417
• Windows sandbox: elevated
• Previous helper directory: Codex\bin\5ea220ae823df3d7
• Previous command-runner version: 0.160.1
• Current helper directory: Codex\bin\979a96ce184041d1
• Current runtime: cua_node\2c9e75c4e9c71beb

Expected behavior

Sandbox setup should complete while Codex's own runtime processes are running. Commands and Node REPL should start normally.

Actual behavior

Every command fails during sandbox setup refresh. The relevant log entry is:

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

After stopping the two node_repl.exe processes during an earlier diagnostic test, validation passed that file but failed with the same error on:

...\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll

Stopping those processes did not resolve the issue.

Regression evidence

From %USERPROFILE%\.codex\.sandbox\sandbox.2026-10-07.log:

• Previous helper: 50 successful setup refreshes, no failures.
• Current helper: 13 failed setup refreshes, no successes.
• Latest recorded failure: October 7, 2026, 15:05 JST.
• Logs from October 6 and earlier contain no runtime read/execute validation entries.

Both restarting the app and rebooting Windows failed to resolve the problem. No newer app update was available when checked.

Diagnostic findings

• There is only one runtime under runtimes: cua_node\2c9e75c4e9c71beb.
• There are no old runtime directories or .staging-* directories.
• Therefore, the stale-runtime workaround described in Windows sandbox helper fails with helper_unknown_error: setup refresh had errors on every exec_command and file read #44696 does not apply here.
• Processes using the affected runtime include Codex's own node_repl.exe, node.exe, and codex-computer-use-swift.exe.
• Read and execute permissions for the sandbox group are already present.
• The earlier, separate error 5 / helper_sandbox_lock_failed issue has been resolved.
• A separate error 32 involving C:\Users\<USER> is followed by continuing setup; it is not the fatal failure described above.

The latest investigation was read-only. No files, configuration, or permissions were changed.

Suspected cause — not confirmed

Based on the public openai/codex main branch inspected on October 7, 2026:

In codex-rs/windows-sandbox-rs/src/acl.rs, ensure_allow_mask_aces_with_inheritance_impl opens a target with OpenOptions and access_mode(MAXIMUM_ALLOWED) when inheritance == 0, using the context:

open ACL target for root-only update

In setup_provisioning/setup_runtime_bin.rs, ensure_runtime_tree_readable calls grant_read_execute_aces(..., 0) for files throughout the runtime tree.

My hypothesis is that requesting MAXIMUM_ALLOWED may include write access when opening running executables or loaded DLLs, causing a sharing violation. That validation error then causes the entire setup refresh to fail, blocking all command execution.

This is an inference from the logs and public source, not a confirmed root cause. I have not verified that the public main branch exactly matches the installed app build.

Possible fix directions

Please consider whether ACL inspection can open targets with READ_CONTROL only, requesting WRITE_DAC separately only when an ACL change is actually needed.

It may also be worth reviewing how validation handles files already in use by Codex. Any handling of sharing violations should preserve the required sandbox access checks rather than simply bypassing them.

Related issue

#44696 reports runtime validation failures, but its stale-runtime workaround does not match this environment.