Repository navigation
[Windows] Elevated sandbox error 32 in 26.1002.51308; rollback to 26.930.7945.0 restores execution #51668
Description
Summary
Related to #51601. This report adds a verified rollback/recovery sequence on a separate Windows installation.
After the Windows desktop update to app version 26.1002.51308 / MSIX package 26.1002.6548.0, the original elevated Windows sandbox failed before local commands could run. Rolling back to MSIX 26.930.7945.0 (app 26.930.61225, bundled CLI 0.160.1) restored elevated sandbox execution. After switching the default sandbox back to elevated and fully restarting the app, an actual chat tool command succeeded and the sandbox refresh log recorded errors=[].
This strongly supports a version-dependent regression on this machine, but does not establish the exact code-level root cause.
Environment
- Windows NT build reported by .NET:
10.0.26100.0. - Failing desktop app:
26.1002.51308. - Failing MSIX:
OpenAI.Codex 26.1002.6548.0, x64. - Working rollback MSIX:
OpenAI.Codex 26.930.7945.0. - Working bundled CLI / command runner:
0.160.1. - Original and restored sandbox mode:
elevated. - A temporary
unelevatedfallback allowed troubleshooting. - Observations: October 7, 2026, Asia/Shanghai (UTC+08:00).
Failure evidence
The generic error was:
helper_unknown_error: setup refresh had errors
The sandbox log identifies the underlying failure, with the username redacted:
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)
The same fatal failure repeated, including at 2026-10-07T11:03:01Z. Several node_repl.exe processes were running from that same runtime directory during diagnosis.
Recovery and verification
- Downloaded the previous official package from:
https://persistent.oaistatic.com/codex-app-prod/releases/26.930.7945.0/ChatGPT-x64.msix - Verified its Microsoft Marketplace signature, package identity, and version.
- Backed up configuration and local chat/index databases before the attempted replacement. The user completed the rollback manually; the exact manual installer procedure was not captured.
- Verified that both the registered package and running desktop executable were from
26.930.7945.0. - Tested elevated execution from a normal Windows PowerShell, outside the agent's existing sandbox, using a per-invocation override:
& $codexExe -c 'windows.sandbox="elevated"' sandbox -- powershell.exe -NoProfile -Command 'Get-Location; Write-Output "ELEVATED_SANDBOX_TEST_OK"'Here $codexExe is the rollback package's app\resources\codex.exe. The test returned:
Package: 26.930.7945.0
Test time: 2026-10-07T19:47:09.8180895+08:00
ELEVATED_SANDBOX_TEST_OK
Exit code: 0
- Changed only
windows.sandboxinconfig.tomlfromunelevatedback toelevated, then fully restarted the desktop app. - An actual chat
Get-Locationtool call succeeded after the restart. Its initialization log recorded:
[2026-10-07T11:51:32.777887900+00:00]
setup refresh: processed 4 write roots (read roots delegated); errors=[]
setup binary completed
helper launch resolution: using copied command-runner path
C:\Users\<USER>\.codex\.sandbox-bin\codex-command-runner-0.160.1.exe
A subsequent refresh at 11:58:34Z also recorded errors=[].
Limits of this evidence
This was a recovery investigation, not a clean-room A/B test: the sandbox mode was temporarily changed and scoped write permissions were granted for troubleshooting. Nested sandbox tests inside the agent's existing restricted environment failed, so those failures are not treated as evidence that the rollback sandbox was broken. The decisive successful checks were the external PowerShell test and the post-restart chat tool call.
Expected behavior / requested investigation
Please investigate the sharing violation during runtime ACL validation in the newer Windows build, and provide a supported fix that preserves the sandbox boundary, local history, configuration, and projects. The setup UI should expose the underlying failing file and Win32 error rather than only the generic setup-refresh message.
No authentication files, sandbox secrets, full logs, or unredacted personal paths are included.
Activity
github-actions commentedon Oct 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Hendra827 commentedon Oct 7, 2026
I can reproduce this on Windows 10 Pro, build 19045.
The issue persists after updating to app version 26.1002.52244, build 13536. The in-app update checker reports up_to_date.
Elevated sandbox setup still fails with:
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)
Built-in apply_patch fails. Running the actual apply_patch executable through unelevated successfully creates, updates, and deletes a temporary file with the updated CLI.
Runtime ACLs already grant CodexSandboxUsers read/execute access.
musiqblack commentedon Oct 8, 2026
have the same problem today ,after several check and try . I just rollback to old version ,and it got fixed.
dave58914 commentedon Oct 8, 2026
Confirmed workaround on Windows 10 2004 (build 19041)
I encountered a Windows sandbox failure in Codex Desktop version
26.1002.7124.0.Environment
26.1002.7124.026.930.7945.0Symptoms
Sandbox commands failed before execution with:
The sandbox log repeatedly reported runtime read/execute validation failures involving
node_repl.exe, with Windowsos error 32(file sharing violation).Both
exec_commandandapply_patchwere affected across multiple workspaces.Troubleshooting
cua_noderuntime directory into quarantine did not resolve the issue.Successful workaround
.codexdirectory and Codex Desktop package data.26.930.7945.0MSIX package.10.0.19041.0.Add-AppxPackage -ForceUpdateFromAnyVersion, without first uninstalling the existing package.The first downgrade attempt failed with
0x80073D02becausecodex-windows-sandbox-service.exewas still running in the background. After stopping that remaining process, the downgrade completed successfully.Verification after rollback
26.930.7945.0— OKexec_commandrunningGet-Location— PASSapply_patchcreating a temporary file — PASSapply_patchdeleting the temporary file — PASSNo sandbox errors occurred during these verification tests.
Conclusion
Rolling back from
26.1002.7124.0to26.930.7945.0restored the affected sandbox functionality on Windows 10 build 19041.This is a confirmed workaround in my environment, not a permanent fix. The underlying regression in the newer version still needs investigation.
Automatic updates may also reintroduce the issue if the affected version is installed again.
marcoortizr commentedon Oct 8, 2026
Confirmed workaround: Codex Desktop Windows sandbox failure (os error 32)
Status: Workaround successfully tested — October 8, 2026
Environment
26.1002.7124.026.930.7945.0elevatedSymptoms
Codex Desktop worked for normal conversations, but
@Browserfailed to initialize with:windows sandbox failed: helper_unknown_error: setup refresh had errorsNode REPL diagnostics reported:
node_repl kernel exited unexpectedlykernel_status: exited(code=1)The sandbox log at
%USERPROFILE%\.codex\.sandbox\sandbox.YYYY-MM-DD.logidentified the underlying failure:runtime read/execute validation failednode_repl.exe: open ACL target for root-only updateThe process cannot access the file because it is being used by another process. (os error 32)Troubleshooting attempted
unelevated.None of these resolved the original browser functionality. With
unelevated, the error changed to:privileged native pipe bridge is not available; browser-client is not trustedThe original configuration was restored.
Successful workaround
1. Download the previous Codex Desktop Windows x64 release:
https://persistent.oaistatic.com/codex-app-prod/releases/26.930.7945.0/ChatGPT-x64.msix
2. Verify the MSIX digital signature and back up the local Codex profile before proceeding.
3. Close Codex Desktop completely, including any remaining application processes.
4. Install the previous version using PowerShell:
Add-AppxPackage -Path "$HOME\Downloads\ChatGPT-x64.msix" -ForceUpdateFromAnyVersion -ErrorAction Stop5. Verify the installed version:
Get-AppxPackage OpenAI.Codex | Select-Object Name, Version, Status6. Keep the original elevated sandbox setting:
[windows]sandbox = "elevated"Verified result
After installing version
26.930.7945.0, Codex Desktop successfully executed@Browser, openedhttps://example.com, and returned the correct page title:Example Domain
Existing conversation sessions and local configuration were preserved.
Important notes
Kamille55-star commentedon Oct 8, 2026
Me ensina? Tô com um problema bem assim hoje
memberuser33-bit commentedon Oct 8, 2026
Codex Windows: Node REPL and integrated browser fail — fixed by changing sandbox mode
Environment
Windows 10 x64
Codex package: OpenAI.Codex 26.1002.7124.0
Desktop application: 26.1007.11041
Symptoms
Both Node REPL and the integrated browser failed with:
trusted Node process exited unexpectedly; kernel reset, rerun your request
An earlier sandbox error was:
windows sandbox failed: helper_unknown_error: setup refresh had errors
Working solution
In %USERPROFILE%.codex\config.toml, change:
[windows]
sandbox = "elevated"
to:
[windows]
sandbox = "unelevated"
Restart the Codex desktop application.
Verified results
Node REPL successfully executed console.log("NODE_REPL_OK", 2 + 2).
Integrated browser successfully opened https://example.com and confirmed the title Example Domain.
Existing conversations and projects remained accessible.
No application reinstallation was required.
Important
This is a confirmed workaround for one Windows 10 installation, not a guaranteed fix for every environment. Changing sandbox mode may alter security isolation, so users should consult the official documentation before applying it.
Recommendation
For users experiencing these exact errors, consider checking the Windows sandbox configuration before attempting destructive repairs, runtime modifications, or reinstallation.
Windows Codex Desktop 26.1007.21434.
Browser and unified-computer-use enabled.
In-app browser visually functional.
cua_repl initializes correctly.
The manifest enables js / js_reset.
However, those tools do not appear in the chat inventory.
There was a previous "MCP server startup failed... OS error 3" event, but the server is re-initializing today.
Current result: server initialized, tools not exposed to session.
pauloxrt commentedon Oct 9, 2026
Additional confirmed reproduction on the newer Windows release. This comment is submitted at the affected user's explicit request; usernames, machine names, workspace paths, account details, credentials, and raw logs are omitted.
Environment
OpenAI.Codex 26.1002.7124.0, x6426.1002.52244, build13536, channelprod, reportedup_to_date[windows] sandbox = "elevated"Reproduction
Even a minimal read-only command fails before PowerShell starts:
The same result was reproduced twice while attempting to read one local Markdown file. No requested command reached PowerShell.
Local evidence
The current sandbox log identifies the underlying failure:
Process inspection at the time of failure showed Codex-owned
ChatGPT.exe,codex.exe,node.exe,node_repl.exe, andcodex-computer-use-swift.exeprocesses active from the installed package/runtime.Sanitized aggregate counts from the dated logs:
setup refresh had errors(os error 32)linesThe inspected logs for October 2, 5, 6, and 7 contained zero occurrences of both patterns. This provides a same-machine before/after signal around the update.
Computer/browser control also failed to initialize in the current task because its trusted Node kernel exits with the same sandbox setup error:
Assessment and current status
This reproduction matches the runtime ACL sharing-violation mechanism described in #51623 and confirms that the regression is still present in app
26.1002.52244/ MSIX26.1002.7124.0, not only the earlier26.1002.51308/26.1002.6548.0build documented here.The rollback package identified in this issue (
26.930.7945.0) has not yet been installed on this machine, so this comment does not claim an additional rollback A/B result. The current installation remains affected.Please prioritize a corrected Windows package and expose the underlying file path and Win32 error in the user-facing failure instead of only
helper_unknown_error.pauloxrt commentedon Oct 9, 2026
Follow-up: I completed the rollback and verified that it restores functionality on this affected machine.
Working rollback
26.1002.52244/ MSIX26.1002.7124.026.930.61225/ MSIX26.930.7945.00.160.1[windows] sandbox = "elevated"Steps
Save any active work and fully quit Codex/ChatGPT from the system tray. Closing only the window may leave package processes running.
Back up the relevant local state before changing the package.
Download the previous official x64 MSIX:
Verify the package signature:
Continue only if
StatusisValidand the package was downloaded from the officialpersistent.oaistatic.comURL.Open PowerShell as Administrator and install the older package over the current one:
MSIX supports downgrading without uninstalling the application first, which preserves the app's local data.
Verify the registered package:
Expected version on x64:
26.930.7945.0.Reopen Codex and verify that the intended sandbox configuration is still present:
Run several minimal commands and inspect the current sandbox log:
The new setup-refresh entries should report
errors=[]and should not add anotherruntime read/execute validation failed/os error 32entry.Verification results on this machine
26.930.7945.0, x64, package statusOk.errors=[], zero newos error 32lines, and zero newsetup refresh had errorslines.One caution: the in-app updater currently reports
restart_required. This may indicate that a newer package has already been staged and could replace the rollback on a later full restart. Recheck the registered and running versions after restarting, and temporarily control automatic updates if your deployment policy allows it.Official OpenAI Windows sandbox documentation: https://learn.chatgpt.com/docs/windows/windows-sandbox