Windows Desktop node_repl fails with os error 740 due to UAC installer detection on codex-windows-sandbox-setup.exe

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #25419
• #25362
• #25366
• #26110
• #26398

Powered by Codex Action

I can reproduce what looks like the same issue on another Windows Codex Desktop machine.

Environment

• Codex Desktop Store package observed in logs: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
• Runtime cache helper path: %LOCALAPPDATA%\OpenAI\Codex\bin\fb2111b91430cb17\codex-windows-sandbox-setup.exe
• node_repl.exe path: %LOCALAPPDATA%\OpenAI\Codex\bin\34ab3e1324cc55b5\node_repl.exe
• Node used by node_repl path in sandbox log: %LOCALAPPDATA%\OpenAI\Codex\bin\5b9024f90663758b\node.exe
• OS version from PowerShell: Microsoft Windows NT 10.0.26200.0
• Get-ComputerInfo reported WindowsProductName: Windows 10 Pro, WindowsVersion: 2009 (build field was blank in this environment)

Symptom

Even a minimal node_repl smoke test fails before running any JavaScript:

nodeRepl.write(JSON.stringify({ ok: true, cwd: nodeRepl.cwd }))

Tool result:

node_repl kernel exited unexpectedly
node_repl diagnostics: {"kernel_status":"running","kernel_stderr_tail":"windows sandbox failed: spawn setup refresh","reason":"stdout_eof"}

This prevents the Browser runtime from bootstrapping because the Browser plugin depends on the trusted node_repl path.

Relevant sandbox log evidence

Sanitized log excerpt:

START: %LOCALAPPDATA%\OpenAI\Codex\bin\5b9024f90663758b\node.exe --experimental-vm-modules ...\kernel.js ...
setup refresh: spawning %LOCALAPPDATA%\OpenAI\Codex\bin\fb2111b91430cb17\codex-windows-sandbox-setup.exe (...)
setup refresh: failed to spawn ...\codex-windows-sandbox-setup.exe: The requested operation requires elevation. (os error 740)

Ordinary shell sandbox setup in the same session succeeds via the packaged WindowsApps helper:

setup refresh: spawning C:\Program Files\WindowsApps\OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe
setup refresh: processed 3 write roots (read roots delegated); errors=[]
setup binary completed

Diagnostics tried

• Cleared/rebuilt %LOCALAPPDATA%\OpenAI\Codex\bin by moving cache directories to a backup folder and restarting Codex.
• Confirmed the cache was regenerated, including fb2111b91430cb17.
• Confirmed the AppData helper and packaged WindowsApps helper were byte-identical in the earlier cache: same length and SHA256.
• Confirmed system Node itself works (node --version and node -e succeed), so the failure is specific to the Codex-managed node_repl sandbox setup path.
• Confirmed an elevated Windows Terminal has Mandatory Label\High Mandatory Level.
• Launching Codex from elevated Terminal still resulted in Codex tool execution reporting medium integrity / non-admin token in this session, and node_repl continued to fail with the same os error 740 sandbox setup path.

This matches the suspected UAC installer-detection behavior for codex-windows-sandbox-setup.exe and the current Store Desktop runtime path.

I am seeing the same issue again on another Windows machine, and the path churn makes the current RUNASINVOKER workaround quite fragile.

Additional reproduction

Environment observed in logs:

• Windows 11, build 10.0.26200, zh-CN locale
• Codex Desktop Store package observed: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
• VS Code extension helper paths observed:
• %USERPROFILE%\.vscode\extensions\openai.chatgpt-26.602.30954-win32-x64\bin\windows-x86_64\codex-windows-sandbox-setup.exe
• %USERPROFILE%\.vscode\extensions\openai.chatgpt-26.602.40724-win32-x64\bin\windows-x86_64\codex-windows-sandbox-setup.exe
• AppData runtime helper path observed:
• %LOCALAPPDATA%\OpenAI\Codex\bin\fb2111b91430cb17\codex-windows-sandbox-setup.exe

On 2026-06-06, multiple parallel Codex threads failed before running their requested commands. The sandbox log showed repeated setup-refresh failures such as:

setup refresh: spawning %USERPROFILE%\.vscode\extensions\openai.chatgpt-26.602.30954-win32-x64\bin\windows-x86_64\codex-windows-sandbox-setup.exe (...)
setup refresh: failed to spawn ...\codex-windows-sandbox-setup.exe: 请求的操作需要提升。 (os error 740)

setup refresh: spawning %LOCALAPPDATA%\OpenAI\Codex\bin\fb2111b91430cb17\codex-windows-sandbox-setup.exe (...)
setup refresh: failed to spawn ...\codex-windows-sandbox-setup.exe: 请求的操作需要提升。 (os error 740)

After adding ~ RUNASINVOKER under HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers for the current helper paths, direct sandbox smoke tests succeeded for both AppData and VS Code extension runtimes:

%LOCALAPPDATA%\OpenAI\Codex\bin\fb2111b91430cb17\codex.exe sandbox powershell -NoProfile -Command "Write-Output ok"
=> ok

%USERPROFILE%\.vscode\extensions\openai.chatgpt-26.602.30954-win32-x64\bin\windows-x86_64\codex.exe sandbox powershell -NoProfile -Command "Write-Output ok"
=> ok

%USERPROFILE%\.vscode\extensions\openai.chatgpt-26.602.40724-win32-x64\bin\windows-x86_64\codex.exe sandbox powershell -NoProfile -Command "Write-Output ok"
=> ok

The important practical problem is that this workaround is path-specific. When Codex updates and the helper path changes, for example from a previous AppData hash to fb2111b91430cb17 or from VS Code extension 26.602.30954 to 26.602.40724, the failure returns until every new codex-windows-sandbox-setup.exe path is patched again.

This makes the local workaround unreliable for normal users. I agree with the suggested fix in the issue body: the helper should either ship with an explicit asInvoker manifest, or be renamed so it does not trigger Windows installer detection heuristics. Maintaining AppCompatFlags entries for versioned/hash-based helper paths is not a sustainable fix.

I just updated to Codex for Windows version 26.609.30741, and it's still spamming me with UAC prompts for every single command. I've tried adding RUNASINVOKER, but as previously mentioned, it seems to only work temporarily. Starting a new thread still prompts at least two more UAC prompts. This simply will not go away. This is SO frustrating!

this is now fixed

this is now fixed

Codex for Windows Version 26.609.41114 • Released Jun 12, 2026 is still generating one UAC prompt per command it tries to run, per thread. This is better than it was where it would spam UAC for every single command in every thread always. So it's better, but as I click to my various threads and keep doing work, it is still generating one UAC prompt per command it tries to run, but then it doesn't generate another for the same command again in that thread. If I switch to a different thread, I have to do the same thing. Is this expected now?

(I'm using Approve for me mode with [windows] sandbox = "elevated" - Approval policy On request - Sandbox settings Workspace write)

[Update: it's only older threads. If I go back to an existing thread that was created and had the UAC spam problem, it continues doing that with Approve for me selected. If I start a new thread and use Approve for me, it works and doesn't trigger UAC prompts.]

This is still reproducible for me on Windows with Codex Desktop Store package OpenAI.Codex_26.616.6631.0

The failure mode matches this issue: shell/tool execution failed with Windows error 740 until applying RUNASINVOKER to codex-windows-sandbox-setup.exe. After adding the AppCompatFlags Layers entry for the helper and restarting Codex Desktop, local shell execution worked again.

The workaround codex created:

$key = "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"
New-Item -Path $key -Force | Out-Null

$helpers = Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\bin" `
  -Recurse `
  -Filter "codex-windows-sandbox-setup.exe" `
  -ErrorAction SilentlyContinue

foreach ($helper in $helpers) {
  New-ItemProperty `
    -Path $key `
    -Name $helper.FullName `
    -Value "~ RUNASINVOKER" `
    -PropertyType String `
    -Force | Out-Null

  Write-Host "Applied RUNASINVOKER to $($helper.FullName)"
}

So this does not appear fully fixed in the current Store build. The workaround is effective, but the packaged helper still appears vulnerable to Windows installer/UAC detection unless the binary gets an explicit asInvoker manifest or is renamed to avoid setup-style installer heuristics.