Skip to content

[Windows] Elevated sandbox error 32 in 26.1002.51308; rollback to 26.930.7945.0 restores execution #51668

Open

Description

@W-BangBang

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 unelevated fallback 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

  1. Downloaded the previous official package from:
    https://persistent.oaistatic.com/codex-app-prod/releases/26.930.7945.0/ChatGPT-x64.msix
  2. Verified its Microsoft Marketplace signature, package identity, and version.
  3. 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.
  4. Verified that both the registered package and running desktop executable were from 26.930.7945.0.
  5. 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
  1. Changed only windows.sandbox in config.toml from unelevated back to elevated, then fully restarted the desktop app.
  2. An actual chat Get-Location tool 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

  1. 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. Hendra827 commented on Oct 7, 2026

    @Hendra827

    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.

  3. musiqblack commented on Oct 8, 2026

    @musiqblack

    have the same problem today ,after several check and try . I just rollback to old version ,and it got fixed.

  4. dave58914 commented on Oct 8, 2026

    @dave58914

    Confirmed workaround on Windows 10 2004 (build 19041)

    I encountered a Windows sandbox failure in Codex Desktop version 26.1002.7124.0.

    Environment

    • OS: Windows 10 Pro 2004, build 19041 (x64)
    • Affected Codex Desktop version: 26.1002.7124.0
    • Working version after rollback: 26.930.7945.0

    Symptoms

    Sandbox commands failed before execution with:

    exec_command failed:
    Rejected("Failed to create unified exec process:
    helper_unknown_error: setup refresh had errors")
    

    The sandbox log repeatedly reported runtime read/execute validation failures involving node_repl.exe, with Windows os error 32 (file sharing violation).

    Both exec_command and apply_patch were affected across multiple workspaces.

    Troubleshooting

    • Closing and restarting Codex did not resolve the issue.
    • Moving the affected cua_node runtime directory into quarantine did not resolve the issue.
    • Codex automatically recreated the runtime directory, and the same failure returned.

    Successful workaround

    1. Backed up the local .codex directory and Codex Desktop package data.
    2. Downloaded the 26.930.7945.0 MSIX package.
    3. Verified its Authenticode signature and checked the package manifest.
    4. Confirmed that its minimum supported Windows build was 10.0.19041.0.
    5. Downgraded using Add-AppxPackage -ForceUpdateFromAnyVersion, without first uninstalling the existing package.

    The first downgrade attempt failed with 0x80073D02 because codex-windows-sandbox-service.exe was still running in the background. After stopping that remaining process, the downgrade completed successfully.

    Verification after rollback

    • Installed version: 26.930.7945.0 — OK
    • Existing local projects and PM/SA conversations — accessible
    • exec_command running Get-Location — PASS
    • apply_patch creating a temporary file — PASS
    • File content verification — PASS
    • apply_patch deleting the temporary file — PASS
    • Verification that the temporary file no longer existed — PASS

    No sandbox errors occurred during these verification tests.

    Conclusion

    Rolling back from 26.1002.7124.0 to 26.930.7945.0 restored 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.

  5. marcoortizr commented on Oct 8, 2026

    @marcoortizr

    Confirmed workaround: Codex Desktop Windows sandbox failure (os error 32)

    Status: Workaround successfully tested — October 8, 2026

    Environment

    • Operating system: Windows
    • Affected Codex Desktop version: 26.1002.7124.0
    • Working version after rollback: 26.930.7945.0
    • Windows sandbox mode: elevated

    Symptoms

    Codex Desktop worked for normal conversations, but @Browser failed to initialize with:

    windows sandbox failed: helper_unknown_error: setup refresh had errors

    Node REPL diagnostics reported:

    node_repl kernel exited unexpectedly

    kernel_status: exited(code=1)

    The sandbox log at %USERPROFILE%\.codex\.sandbox\sandbox.YYYY-MM-DD.log identified the underlying failure:

    runtime read/execute validation failed

    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)

    Troubleshooting attempted

    • Restarted Codex Desktop.
    • Rebuilt the local Codex profile.
    • Temporarily moved existing conversation sessions.
    • Tested a different network.
    • Changed Windows sandbox mode to 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 trusted

    The 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 Stop

    5. Verify the installed version:

    Get-AppxPackage OpenAI.Codex | Select-Object Name, Version, Status

    6. Keep the original elevated sandbox setting:

    [windows]
    sandbox = "elevated"

    Verified result

    After installing version 26.930.7945.0, Codex Desktop successfully executed @Browser, opened https://example.com, and returned the correct page title:

    Example Domain

    Existing conversation sessions and local configuration were preserved.

    Important notes

    • This is a verified workaround on one affected computer, not a universal fix.
    • The evidence suggests a version-related Windows sandbox regression, but does not establish the exact underlying software defect.
    • Downgrading may be restricted by organizational policies.
    • Future versions may contain a permanent fix.
    • Back up local conversation data before attempting a rollback.
    • Do not disable Windows security controls or modify filesystem ACLs to bypass the error.
  6. Kamille55-star commented on Oct 8, 2026

    @Kamille55-star

    Hoje estou com o mesmo problema, depois de várias verificações e tentativas. Simplesmente voltei para a versão antiga e o problema foi resolvido.

    Me ensina? Tô com um problema bem assim hoje

  7. memberuser33-bit commented on Oct 8, 2026

    @memberuser33-bit

    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.

  8. pauloxrt commented on Oct 9, 2026

    @pauloxrt

    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

    • Observed: 2026-10-08 (America/Mexico_City)
    • OS: Windows Server 2025 Standard, build 26100, x64
    • Installed MSIX: OpenAI.Codex 26.1002.7124.0, x64
    • In-app updater: 26.1002.52244, build 13536, channel prod, reported up_to_date
    • Sandbox: [windows] sandbox = "elevated"

    Reproduction

    Even a minimal read-only command fails before PowerShell starts:

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

    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:

    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
    

    Process inspection at the time of failure showed Codex-owned ChatGPT.exe, codex.exe, node.exe, node_repl.exe, and codex-computer-use-swift.exe processes active from the installed package/runtime.

    Sanitized aggregate counts from the dated logs:

    Log date setup refresh had errors (os error 32) lines
    2026-10-08 460 782
    2026-10-09 UTC (partial) 8 16

    The 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:

    node_repl kernel exited unexpectedly
    windows sandbox failed: helper_unknown_error: setup refresh had errors
    

    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 / MSIX 26.1002.7124.0, not only the earlier 26.1002.51308 / 26.1002.6548.0 build 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.

  9. pauloxrt commented on Oct 9, 2026

    @pauloxrt

    Follow-up: I completed the rollback and verified that it restores functionality on this affected machine.

    Working rollback

    • Broken app: 26.1002.52244 / MSIX 26.1002.7124.0
    • Working app after rollback: 26.930.61225 / MSIX 26.930.7945.0
    • Bundled CLI after rollback: 0.160.1
    • Sandbox remained: [windows] sandbox = "elevated"

    Steps

    1. Save any active work and fully quit Codex/ChatGPT from the system tray. Closing only the window may leave package processes running.

    2. Back up the relevant local state before changing the package.

    3. Download the previous official x64 MSIX:

      https://persistent.oaistatic.com/codex-app-prod/releases/26.930.7945.0/ChatGPT-x64.msix
      
    4. Verify the package signature:

      $rollbackMsix = "$env:USERPROFILE\Downloads\ChatGPT-x64.msix"
      Get-AuthenticodeSignature -FilePath $rollbackMsix |
        Select-Object Status, StatusMessage, SignerCertificate

      Continue only if Status is Valid and the package was downloaded from the official persistent.oaistatic.com URL.

    5. Open PowerShell as Administrator and install the older package over the current one:

      Add-AppxPackage -Path $rollbackMsix `
        -ForceUpdateFromAnyVersion `
        -ForceApplicationShutdown

      MSIX supports downgrading without uninstalling the application first, which preserves the app's local data.

    6. Verify the registered package:

      Get-AppxPackage -Name OpenAI.Codex |
        Select-Object Name, Version, Architecture, Status, InstallLocation

      Expected version on x64: 26.930.7945.0.

    7. Reopen Codex and verify that the intended sandbox configuration is still present:

      [windows]
      sandbox = "elevated"
    8. Run several minimal commands and inspect the current sandbox log:

      Get-Location
      Write-Output "CODEX_SANDBOX_OK"

      The new setup-refresh entries should report errors=[] and should not add another runtime read/execute validation failed / os error 32 entry.

    Verification results on this machine

    • Registered and running package: 26.930.7945.0, x64, package status Ok.
    • Three consecutive sandboxed PowerShell executions succeeded.
    • Workspace write/read verification succeeded.
    • Computer Use initialized successfully again.
    • The most recent sandbox-log sample contained 14 successful refreshes with errors=[], zero new os error 32 lines, and zero new setup refresh had errors lines.

    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

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