Skip to content

Windows sandbox setup refresh fails on inaccessible old cua_node runtime after update #49433

Open

Description

@bradyong

What version of the Codex App are you using (From “About Codex” dialog)?

26.928.20755

What subscription do you have?

ChatGPT Pro

What platform is your computer?

"$([Environment]::OSVersion.VersionString) $($(if ([Environment]::Is64BitOperatingSystem) { 'x64' } else { 'x86' }))"

What issue are you seeing?

All normal sandboxed shell commands fail before execution.

The error is:

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

The latest sandbox log repeatedly shows:

runtime read/execute validation failed on:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\f53823cd54b14f45\bin\node_repl.exe

CreateFileW failed, and setup refresh exits with status 1.

The current configuration references a newer cua_node runtime:
1b30f7d4d73226ca

The newer runtime's node_repl.exe can be opened for reading, but the older runtime referenced by sandbox setup returns Access Denied when read or when its ACL is queried.

This affects all normal local command execution. Restarting the Codex app, updating the app, and opening a new chat did not resolve the issue.

No project files, permissions, security settings, or Codex configuration were changed.
No matching Defender, Code Integrity, or AppLocker blocking event was found.

McAfee is installed, but there is currently no evidence that it caused the block.

What steps can reproduce the bug?

  1. Open Codex desktop app on Windows.

  2. Open any existing project or a new chat.

  3. Ask Codex to run a simple command such as:

    Write-Output 'LOCAL_EXEC_OK'

  4. The command never starts.

  5. Codex returns:

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

  6. Restart the Codex app and repeat.

  7. Open a new chat and repeat.

  8. The same failure occurs.

Additional observations:

  • Current config references cua_node runtime 1b30f7d4d73226ca.
  • Sandbox setup still validates old runtime f53823cd54b14f45.
  • The new runtime file is readable.
  • The old runtime node_repl.exe returns Access Denied.
  • Parent directories are accessible.

What is the expected behavior?

Sandbox setup should use the current valid cua_node runtime referenced by the current Codex configuration.

Old or stale runtime versions should not prevent all local shell commands from starting.

A simple command such as:

Write-Output 'LOCAL_EXEC_OK'

should execute normally without the sandbox setup refresh failing.

Additional information

Additional diagnostics:

  • Current config.toml references the newer cua_node runtime:
    1b30f7d4d73226ca

  • The newer runtime's node_repl.exe is readable.

  • Sandbox setup still repeatedly validates the older runtime:
    f53823cd54b14f45

  • The older runtime's node_repl.exe returns Access Denied even when its ACL is queried.

  • Parent directories are accessible and include inherited permissions for the current user, SYSTEM, Administrators, and CodexSandboxUsers.

  • Restarting Codex, updating Codex, and opening a new chat did not resolve the issue.

  • No matching Windows Defender, Code Integrity, or AppLocker block was found in the checked logs.

  • McAfee is installed, but it has not been confirmed as the cause.

  • No application configuration, project files, permissions, ACLs, or security settings were changed during diagnosis.

I also submitted the same diagnostic summary to OpenAI Support.
Possibly related to #46326, but this case specifically shows sandbox setup validating an inaccessible OLD cua_node runtime even though the current configuration references a newer readable runtime.

Activity

  1. added
    appIssues related to the Codex desktop app
    on Sep 30, 2026
  2. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    on Sep 30, 2026
  3. skyout457-cmyk commented on Oct 1, 2026

    @skyout457-cmyk

    Adding a corroborating reproduction with new build and recovery-test details. This matches the inaccessible cua_node/.../bin/node_repl.exe symptom in this issue, but I have not established whether the affected runtime is stale or whether another runtime is currently configured.

    Environment and impact

    • Windows 11, x64.
    • ChatGPT desktop package version 26.928.3736.0, verified in Windows Installed apps.
    • Observed on 2026-10-01 in dot-started local tasks on a connected, authorized Windows computer.
    • Local command execution is blocking work that depends on dot's local tools. The same development application still runs manually outside dot.

    Minimal reproduction

    1. Start or resume a dot task using the connected Windows computer.
    2. Request only the read-only PowerShell command Get-Location.
    3. The requested process does not start. Existing and newly created tasks fail in the same way.

    Top-level error:

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

    The sandbox log reports:

    runtime read/execute validation failed:
    validate runtime read/execute access on
    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe:
    CreateFileW failed for
    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe
    
    setup error: setup refresh had errors
    

    The path above is sanitized. No native Win32 error code was included with the CreateFileW failure.

    Additional observations

    • The target node_repl.exe exists. File Explorer lists it as an Application, 33,250 KB.
    • File Properties → Security cannot display its permissions and says read permission is required.
    • Advanced Security Settings also cannot display the owner/permissions. After using its administrator Continue prompt, Windows still says the object's permission settings cannot be viewed or edited.
    • Smart App Control was already Off when checked; it was not turned off as a troubleshooting action.
    • These observations point to a file/ACL-access problem worth investigating, but do not establish a specific ACL entry, file owner, security-product cause, or stale-runtime cause.

    Recovery attempts

    • Fully exited and reopened the desktop app: no recovery.
    • Retested in existing and new local tasks: same failure.
    • Ran Windows Settings → Installed apps → ChatGPT → Advanced options → Repair, then retried: local command execution still failed.
    • No ownership takeover, ACL reset, deny removal, or runtime deletion was used.

    Requested help

    Please provide a supported recovery or runtime-reprovisioning procedure that preserves conversations, local projects, and other user data. Please also preserve the native Windows error code in this failure so that inaccessible files, missing paths, and other causes can be distinguished.

    Could the team investigate why inability to inspect one runtime file prevents even an unrelated read-only shell command from starting? We rely on these local capabilities for ongoing work and would appreciate a data-preserving workaround and a tracked fix.

    This comment intentionally excludes usernames, computer names, email addresses, private project paths, and raw screenshots.

  4. yktn3110 commented on Oct 4, 2026

    @yktn3110

    I encountered the same issue on Windows and found a workaround in my environment.

    Restarting both Windows and the desktop app did not help.

    My current configuration referenced cua_node runtime 45309f9050f7314b, but sandbox setup failed with Access Denied on node_repl.exe in an older runtime, b63ee7ee40c23b77.

    I moved that old runtime directory to another location outside cua_node, keeping it as a backup rather than deleting it. The next test failed on another older runtime, 32a57e0f41f3a96a, with the same error.

    After moving the second old runtime directory out as well, normal sandboxed shell commands and browser initialization succeeded. Reading an existing Chrome tab also worked.

    This is only a workaround observed on my machine, not a confirmed root cause or general fix. I hope the sequence helps with the investigation.

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