Windows sandbox setup helper triggers UAC installer detection (os error 740)

Resolved 💬 10 comments Opened May 22, 2026 by daleydeng Closed Jun 12, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

On Windows, non-elevated sandboxed tool execution started failing before the command itself was launched. Even trivial commands such as rg --version or cmd /c ver failed with:

windows sandbox: spawn setup refresh

The sandbox log showed the underlying failure:

setup refresh: spawning C:\Users\vision\AppData\Local\Microsoft\WinGet\Links\codex-windows-sandbox-setup.exe (...)
setup refresh: failed to spawn C:\Users\vision\AppData\Local\Microsoft\WinGet\Links\codex-windows-sandbox-setup.exe: 请求的操作需要提升。 (os error 740)

os error 740 is Windows reporting that the requested operation requires elevation.

Environment

  • OS: Windows 10.0.26200.8457
  • Codex CLI: codex-cli 0.133.0
  • Install source: WinGet package OpenAI.Codex 0.133.0
  • Package release: rust-v0.133.0
  • Config had [windows] sandbox = "elevated"

Reproduction

After installing/updating Codex 0.133.0 from WinGet, run any sandboxed command from Codex without require_escalated, for example:

rg --version
cmd /c ver

Expected: command runs in the Codex Windows sandbox.

Actual: command fails before launch with windows sandbox: spawn setup refresh.

Diagnosis

The target exists and is signed:

C:\Users\vision\AppData\Local\Microsoft\WinGet\Links\codex-windows-sandbox-setup.exe
  -> C:\Users\vision\AppData\Local\Microsoft\WinGet\Packages\OpenAI.Codex_Microsoft.Winget.Source_8wekyb3d8bbwe\codex-windows-sandbox-setup.exe

Authenticode signature verified as valid.

The failure appears to be caused by Windows UAC installer detection: the helper filename contains setup.exe, and the binary did not appear to have an embedded requestedExecutionLevel manifest. Windows therefore treated it as requiring elevation and CreateProcess returned error 740.

Workaround that confirmed the diagnosis

Embedding an asInvoker manifest into codex-windows-sandbox-setup.exe fixed the issue locally:

<requestedExecutionLevel level="asInvoker" uiAccess="false"/>

After embedding the manifest, the same non-elevated sandboxed commands succeeded:

cmd /c ver
rg --version

The sandbox log then showed successful setup refresh:

setup refresh: processed 3 write roots (read roots delegated); errors=[]
SUCCESS ... rg --version

Suggested fix

Please embed an explicit application manifest into codex-windows-sandbox-setup.exe, likely with:

<requestedExecutionLevel level="asInvoker" uiAccess="false"/>

Alternatively, rename the helper so it does not match Windows installer-detection heuristics, but an explicit manifest is probably safer.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #23712

Powered by Codex Action

apocalx · 1 month ago

I can confirm this on another Windows machine with the npm-installed Codex package, not WinGet, so the issue does not appear to be specific to the WinGet link/package layout.

Environment observed:

  • Windows, non-elevated user process (IsElevatedAdmin: False)
  • Codex CLI: codex-cli 0.133.0
  • Install path shape: %APPDATA%\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
  • Sandboxed modes observed failing: read-only and workspace-write
  • danger-full-access did not fail, consistent with it skipping setup refresh

The sandbox log showed the same underlying error before the requested command executed:

setup refresh: spawning ...\codex-resources\codex-windows-sandbox-setup.exe (...)
setup refresh: failed to spawn ...\codex-windows-sandbox-setup.exe: The requested operation requires elevation. (os error 740)

I also reproduced it outside the agent/session layer with a direct non-elevated CreateProcess-style launch:

$psi = [Diagnostics.ProcessStartInfo]::new('...\codex-windows-sandbox-setup.exe')
$psi.UseShellExecute = $false
[Diagnostics.Process]::Start($psi)

Result:

NativeErrorCode : 740
Message         : The requested operation requires elevation

A byte-string scan of the installed helper did not find requestedExecutionLevel, asInvoker, requireAdministrator, requestedPrivileges, or trustInfo. That matches the installer-detection diagnosis in this issue. The v0.133.0 source path codex-rs/windows-sandbox-rs/src/setup.rs also explicitly says refresh should not request elevation before launching this helper via Command::new(...).status(), so the failure is occurring below the tool/session caller and before the requested shell command starts.

ofek · 1 month ago

We are also affected by this on the latest version 0.133.0, confirmed by installation via Scoop.

kalineh · 1 month ago

same issue since 0.133 update. can confirm -s danger-full-access works fine

{
"schemaVersion": 1,
"generatedAt": "1779581178s since unix epoch",
"overallStatus": "warning",
"codexVersion": "0.133.0",
"checks": {
"app_server.status": {
"id": "app_server.status",
"category": "app-server",
"status": "ok",
"summary": "background server is not running",
"details": {
"control socket": "C:\\Users\\<USERNAME>\\.codex\\app-server-control\\app-server-control.sock",
"daemon state dir": "C:\\Users\\<USERNAME>\\.codex\\app-server-daemon",
"mode": "ephemeral",
"pid file": "C:\\Users\\<USERNAME>\\.codex\\app-server-daemon\\app-server.pid (missing)",
"settings": "C:\\Users\\<USERNAME>\\.codex\\app-server-daemon\\settings.json (missing)",
"status": "not running",
"update-loop pid file": "C:\\Users\\<USERNAME>\\.codex\\app-server-daemon\\app-server-updater.pid (missing)"
},
"remediation": null,
"durationMs": 0
},
"auth.credentials": {
"id": "auth.credentials",
"category": "auth",
"status": "ok",
"summary": "auth is configured",
"details": {
"auth file": "C:\\Users\\<USERNAME>\\.codex\\auth.json",
"auth storage mode": "File",
"stored API key": "false",
"stored ChatGPT tokens": "true",
"stored agent identity": "false",
"stored auth mode": "chatgpt"
},
"remediation": null,
"durationMs": 0
},
"config.load": {
"id": "config.load",
"category": "config",
"status": "ok",
"summary": "config loaded",
"details": {
"CODEX_HOME": "C:\\Users\\<USERNAME>\\.codex",
"config.toml": "C:\\Users\\<USERNAME>\\.codex\\config.toml",
"config.toml parse": "ok",
"cwd": "C:\\Users\\<USERNAME>\\Documents\\Codex\\2026-05-23\\execution-error-io-custom-kind-other",
"enabled feature flags": "shell_tool, shell_snapshot, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_suggest, plugins, plugin_hooks, in_app_browser, browser_use, browser_use_external, computer_use, plugin_sharing, image_generation, skill_mcp_dependency_install, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, personality, fast_mode, tui_app_server",
"feature flag overrides": "workspace_dependencies=false",
"feature flags enabled": "26",
"log dir": "C:\\Users\\<USERNAME>\\.codex\\log",
"mcp servers": "0",
"model": "gpt-5.5",
"model provider": "openai",
"sqlite home": "C:\\Users\\<USERNAME>\\.codex"
},
"remediation": null,
"durationMs": 0
},
"installation": {
"id": "installation",
"category": "install",
"status": "warning",
"summary": "npm-managed launch could not inspect npm global root",
"details": {
"PATH codex #1": "c:\\path\\codex.cmd",
"PATH codex #2": "C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0\\app\\resources\\codex",
"PATH codex #3": "C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0\\app\\resources\\codex.exe",
"PATH codex entries": "3",
"current executable": "C:\\dev\\node\\node-v22.18.0-win-x64\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin\\codex.exe",
"install context": "npm (package C:\\dev\\node\\node-v22.18.0-win-x64\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc, bin C:\\dev\\node\\node-v22.18.0-win-x64\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin, resources C:\\dev\\node\\node-v22.18.0-win-x64\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-resources, path C:\\dev\\node\\node-v22.18.0-win-x64\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-path)",
"managed by bun": "false",
"managed by npm": "true",
"managed package root": "C:\\dev\\node\\node-v22.18.0-win-x64\\node_modules\\@openai\\codex",
"npm root -g failed": "program not found"
},
"remediation": null,
"durationMs": 33
},
"sandbox.helpers": {
"id": "sandbox.helpers",
"category": "sandbox",
"status": "ok",
"summary": "sandbox configuration is readable",
"details": {
"approval policy": "Never",
"filesystem sandbox": "restricted",
"network sandbox": "enabled"
},
"remediation": null,
"durationMs": 0
},
"runtime.provenance": {
"id": "runtime.provenance",
"category": "runtime",
"status": "ok",
"summary": "running npm on windows-x86_64",
"details": {
"commit": "unknown",
"current executable": "C:\\dev\\node\\node-v22.18.0-win-x64\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin\\codex.exe",
"platform": "windows-x86_64",
"version": "0.133.0"
},
"remediation": null,
"durationMs": 0
},
"updates.status": {
"id": "updates.status",
"category": "updates",
"status": "warning",
"summary": "npm update target could not be inspected",
"details": {
"cached latest version": "0.133.0",
"latest version": "0.133.0",
"latest version status": "current version is not older",
"npm root -g failed": "program not found"
},
"remediation": null,
"durationMs": 509
}
}
}

sergeliatko · 1 month ago

Adding another confirmed repro that closely matches this issue.

Environment:

  • Windows 11 Home, build 10.0.26200
  • AMD64
  • Codex CLI 0.135.0
  • npm global install
  • Node v24.12.0, npm 11.12.1
  • PowerShell 5.1.26100.8521
  • Runtime user is not elevated/admin
  • Config includes [windows] sandbox = "elevated"

From a clean scratch folder, host process launch works:

cmd /c echo HOST_CMD_OK

But the direct elevated Windows sandbox probe fails before the requested command starts:

windows sandbox failed: spawn setup refresh

The underlying sandbox log line is:

setup refresh: failed to spawn ...\codex-windows-sandbox-setup.exe: The requested operation requires elevation. (os error 740)

The unelevated fallback does not work on this machine either:

windows sandbox failed: CreateProcessAsUserW failed: 2

I also did a bounded read-only inspection of the local helper without launching it. The helper path shape is:

%APPDATA%\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe

Observed helper facts:

  • PE machine: x64 / AMD64 (0x8664)
  • No obvious requestedExecutionLevel, asInvoker, requestedPrivileges, or trustInfo strings found in a basic ASCII/UTF-16 string scan
  • The binary does contain installer-like strings including setup, install, and update

The local result supports the same general diagnosis as this issue: normal setup refresh is trying to launch a helper that Windows classifies as elevation-required, and because Codex launches it through CreateProcess-style semantics, it fails with ERROR_ELEVATION_REQUIRED / 740 before the command can run.

One nuance: Microsoft currently documents UAC Installer Detection as applying to 32-bit executables without a requested execution level, while my local helper is AMD64. So I do not want to overclaim that the filename alone is the entire mechanism in this specific repro. Still, the practical fix direction looks the same:

  • Ship the non-elevating setup-refresh helper with an explicit requestedExecutionLevel level="asInvoker" uiAccess="false" manifest.
  • Consider renaming or splitting the helper so the normal refresh path is not a setup.exe-named binary.
  • Keep intentional admin provisioning behind an explicit path such as codex sandbox setup --elevated.
  • Have codex doctor run the same minimal sandbox spawn path used by normal commands, because doctor can otherwise look healthy while direct sandbox probes fail.

I have a sanitized diagnostic zip with logs, probe results, helper inspection, and UAC references, but I will share that privately with OpenAI Support rather than attach local environment details publicly here.

sergeliatko · 1 month ago

the v0.137.0 seems to have solved it? Did not notice those errors any more.

lee62839459595929-blip · 1 month ago

I’m seeing a related Windows Computer Use failure on Codex Desktop as well.

Environment:

  • Codex Desktop: 26.602.4764.0
  • Bundled Computer Use plugin: 26.602.40724
  • Windows user profile: C:\Users\Administrator

Initial failure:

  • Computer Use failed with:

windows sandbox failed: spawn setup refresh
stdout_eof

  • Sandbox log showed os error 740 while spawning:

C:\Users\Administrator\AppData\Local\OpenAI\Codex\bin\fb2111b91430cb17\codex-windows-sandbox-setup.exe

Workaround applied:

  • Added AppCompatFlags RUNASINVOKER for the setup helper path above.
  • After that, os error 740 disappeared.
  • Sandbox setup now completes successfully:

setup refresh: processed 1 write roots (read roots delegated); errors=[]
setup binary completed

Remaining failure:

  • Computer Use still fails with:

Computer Use native pipe path is unavailable

  • Desktop logs show:

computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable"
computer_use_native_pipe_thread_config_skipped platform=win32 reason=not-ready

Additional check:

  • The plugin cache originally only had:

C:\Users\Administrator\.codex\plugins\cache\openai-bundled\computer-use\26.602.40724

  • I created a junction:

C:\Users\Administrator\.codex\plugins\cache\openai-bundled\computer-use\latest -> 26.602.40724

  • This helper now exists through latest:

C:\Users\Administrator\.codex\plugins\cache\openai-bundled\computer-use\latest\node_modules\@oai\sky\bin\windows\codex-computer-use.exe

  • But after restarting Codex, the desktop app still reports missing-helper-path and does not start the Computer Use native pipe.

So RUNASINVOKER fixes the 740 part, but the app still cannot resolve/start the Computer Use helper paths afterward.

Cibersino · 1 month ago

I can reproduce this from the VS Code extension build openai.chatgpt-26.602.71036-win32-x64.

In my case the failing helper is shipped inside the VS Code extension:

C:\Users\manue\.vscode\extensions\openai.chatgpt-26.602.71036-win32-x64\bin\windows-x86_64\codex-windows-sandbox-setup.exe
````

Local binary check:

SHA256: C1FE23AAAC3439F73CEA122BA703ECE302ACA5BB356CAB8C7FAEB894DF69CC30
HasRequestedExecutionLevel: False
HasAsInvoker: False
HasRequireAdministrator: False


Runtime behavior:

Normal VS Code + [windows] sandbox="elevated"
→ setup refresh fails before command execution with:
setup refresh: failed to spawn ... codex-windows-sandbox-setup.exe:
La operación solicitada requiere elevación. (os error 740)

VS Code launched as Administrator + [windows] sandbox="elevated"
→ setup refresh succeeds
→ sandboxed commands show SUCCESS


Additional local state:

UAC:
EnableLUA=1
ConsentPromptBehaviorAdmin=5
ConsentPromptBehaviorUser=3
PromptOnSecureDesktop=1

Sandbox users exist:
CodexSandboxOffline Enabled=True
CodexSandboxOnline Enabled=True

Codex firewall rules exist and are enabled:
codex_sandbox_offline_block_outbound
codex_sandbox_offline_block_loopback_udp
codex_sandbox_offline_block_loopback_tcp


This looks like the VS Code extension package still ships a `codex-windows-sandbox-setup.exe` without the `requestedExecutionLevel level="asInvoker"` manifest discussed here / fixed upstream.
ofek · 1 month ago

@iceweasel-oai Can you please provide a link to where this was resolved?

alexzhuustc · 1 month ago

I was experiencing same issue with Codex in VS Code on version 26.601.20914-win32-x64. After upgrading to 26.609.30741-win32-x64, the problem is completely gone. codex-windows-sandbox-setup.exe no longer requires administrator privileges.