Windows sandbox regression in Codex CLI 0.138.0: setup refresh fails with os error 740 / CreateProcessAsUserW failed: 2; 0.132.0 works

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

• #25876

Powered by Codex Action

Additional update: this still reproduces on Codex CLI 0.137.0 with the native Windows standalone installer, not only the npm install path.

````markdown

Version / install path tested

• Codex CLI version: 0.137.0
• Platform: Windows x64
• Terminal: PowerShell 7.6.2 / Windows Terminal
• Install method: official native Windows standalone installer:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"
````

The installer completed successfully and reported:

```text
Detected platform: Windows (x64)
Resolved version: 0.137.0
Downloading Codex CLI
PATH updated for future PowerShell sessions.
Codex CLI 0.137.0 installed successfully.

After opening a new PowerShell session, where.exe codex resolved to the native standalone path:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe

So this reproduction does not appear to depend on npm’s global shim/package layout.

Observed failure on 0.137.0

After launching Codex normally in a project workspace, simple read-only file commands still failed before command execution. Example commands attempted by Codex:

Get-Content -Raw -LiteralPath .gitignore
Get-Content -Raw -LiteralPath README.md
Get-Content -Raw -LiteralPath <PROJECT_DIR>\.gitignore

Observed repeated error:

execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

Codex then reported that the sandbox was failing before command execution:

The sandbox is still failing before command execution, so I'm going to request an unsandboxed read of only these two files in the workspace. No Git command or write operation is involved.

Then even a single safe read command still hit the same sandbox startup error:

Ran Get-Content -Raw -LiteralPath .gitignore
execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

The session ultimately became unusable for normal read-only workspace inspection.

Why this is useful additional signal

The original report confirmed the regression on codex-cli 0.136.0 and that rollback to 0.132.0 restored sandbox execution.

This new test confirms that:

• the same windows sandbox: spawn setup refresh failure still exists in 0.137.0;
• the failure occurs after a successful native Windows standalone install;
• the active codex.exe is the native install under %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe;
• simple read-only commands fail before PowerShell command execution;
• this is not only an npm-managed install issue.

No private filesystem paths are included here; local project paths and user profile paths have been redacted or replaced with environment-variable placeholders.

````markdown

Additional fresh-install test on a brand-new Windows machine

I have a new reproduction from a brand-new Windows laptop, which makes the failure look broader than a normal “sandbox execution failed” bug. In this case, the Windows sandbox could not even complete its setup/refresh path successfully.

Fresh native Windows standalone install: codex-cli 0.137.0

Install path was the native standalone Windows install, not npm:

where.exe codex
# %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe

codex --version
# codex-cli 0.137.0
````

`codex doctor --summary` looked healthy enough to be misleading:

```text
17 ok · 1 idle · 0 warn · 0 fail

The doctor output included a sandbox line that looked configured/healthy, but direct sandbox execution still failed.

Minimal direct sandbox test:

$cmd = "$env:WINDIR\System32\cmd.exe"

codex -c 'windows.sandbox="unelevated"' sandbox windows -- $cmd /c echo CODEX_UNELEVATED_OK

Observed result:

windows sandbox failed: CreateProcessAsUserW failed: 2

At the same time, Windows showed a system dialog for:

codex-windows-sandbox-setup.exe

with the localized Windows message equivalent to:

Windows cannot find 'codex-windows-sandbox-setup.exe'. Make sure you typed the name correctly, and then try again.

So in this fresh native-install case, the failure is not only that the sandbox blocks a command after setup. The setup/refresh helper itself appears not to be found/launched correctly, so the sandbox cannot be configured/refreshed successfully before the requested command even starts.

This is also not only an npm packaging issue, because this reproduction used the native standalone Windows path:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe

Rollback on the same machine: codex-cli 0.132.0 works

After rolling back to 0.132.0 on the same new machine:

codex --version
# codex-cli 0.132.0

where.exe codex
# %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe

Both sandbox modes passed the same minimal smoke tests:

$cmd = "$env:WINDIR\System32\cmd.exe"

codex -c 'windows.sandbox="unelevated"' sandbox windows -- $cmd /c echo CODEX_UNELEVATED_OK
# CODEX_UNELEVATED_OK

codex -c 'windows.sandbox="elevated"' sandbox windows -- $cmd /c echo CODEX_ELEVATED_OK
# CODEX_ELEVATED_OK

Then normal file-read tool calls also worked again. This strongly narrows the regression to a post-0.132.0 Windows sandbox/helper packaging or helper resolution change.

Source-code / release-analysis hypothesis

Based on the public PR history, there appear to be two closely related failure classes:

1. UAC manifest regression

PR #23764 removed Windows sandbox resource stamping. That PR removed the windows-sandbox-rs build script, the setup helper manifest, the winres dependency, and the Bazel build-script data for the manifest. Later, PR #25949 explicitly says #23764 also removed the setup helper’s UAC manifest and that the manifest was functionally important, not just cosmetic. PR #25949 restored a minimal requestedExecutionLevel level="asInvoker" manifest so setup refresh can use normal Command::new(...) without triggering UAC, while full setup can still intentionally use ShellExecuteExW with runas.

1. Helper discovery / packaging / stale or incomplete binary directory regression

The new 0.137.0 native-install failure shown above is not the same as only os error 740. It is CreateProcessAsUserW failed: 2 plus a Windows dialog saying codex-windows-sandbox-setup.exe cannot be found. That points to a helper path/discovery/packaging problem: Codex is trying to launch the setup helper, but the helper is either missing from the resolved runtime directory or being resolved/launched from the wrong location. This looks related in class to #25322, where a Windows process could keep using a cached binary directory containing codex.exe but missing codex-windows-sandbox-setup.exe and codex-command-runner.exe.

The important new signal is that 0.137.0 still fails on a brand-new machine with the native standalone install, while 0.132.0 works immediately on the same machine and same install path. That suggests the manifest restoration in #25949 may have fixed the os error 740 variant, but it does not fully cover the helper-location / helper-packaging / setup-refresh path that produces CreateProcessAsUserW failed: 2 and “cannot find codex-windows-sandbox-setup.exe”.

Requested diagnostic improvement

codex doctor should probably verify the actual sandbox helper resolution path by checking that the exact runtime directory used by sandbox setup contains at least:

codex.exe
codex-windows-sandbox-setup.exe
codex-command-runner.exe

and then run a minimal setup-refresh smoke test, rather than reporting the sandbox as healthy while the first real sandbox command fails before process launch.

Same experience.

Windows 11 Pro 10.0.26200
Codex 0.138.0 npm install

Both elevated and unelevated Windows sandbox fail:
CreateProcessAsUserW failed: 2

Same machine, same command works on 0.132.0:

codex sandbox windows C:\Windows\System32\cmd.exe /c echo OK
=> OK

Same experience. Windows 11 Pro 10.0.26200 Codex 0.138.0 npm install `` Both elevated and unelevated Windows sandbox fail: CreateProcessAsUserW failed: 2 ` Same machine, same command works on 0.132.0: ` codex sandbox windows C:\Windows\System32\cmd.exe /c echo OK => OK ``

Yes, I tested the latest version 0.138 today, and it still hasn't even attempted to fix this bug. I looked at the code changes in the new version; there's no fix for this bug, only fixes for some sandbox error message logic. Currently the only workaround is to use version 0.132.0.

https://github.com/openai/codex/issues/27125

I confirm this matches my report: shell/tool execution fails before command start with execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" }) and .codex/.sandbox logs show repeated setup refresh: failed to spawn ...codex-windows-sandbox-setup.exe: ... (os error 740) in elevated mode.

Repro in thread was rg --files and simple PowerShell commands inside Codex, while direct execution outside Codex succeeds.

CLI at repro: 0.137.0, and sandbox mode configured as elevated.

@martinmclee
https://github.com/openai/codex/issues/24391#issuecomment-4657143980

Update: I updated to codex-cli 0.139.0, and the issue is still reproducing.

Current behavior in the Codex in-thread runner:

• rg --files -> execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })
• Get-Location -> same error
• codex --version (run in-thread) -> same error

~/.codex/.sandbox/sandbox.2026-06-10.log still contains repeated:

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

So this still appears unfixed on 0.139.0 in my environment.

this is now fixed

@iceweasel-oai what version or commit is the fix in? latest I installed (0.139.0) still has the issue.

this is now fixed

this is a lie, on latest version and it still won't let me elevate the sandbox. fresh installed twice and same error.\
changing it directly in the config.toml also doesn't work, if i open codex and hit update it just doesn't work and i have to make it unelevated again.
even opening codex with admin privileges it still doesn't let me
on version 26.616.3309.0/[0.141.0] windows

so is this getting fixed at all ? it's a pretty important feature to have broken for over 4 weeks with now 3 updates and still not fixing the issue, all these people care about is pleasing their mac users whilst we are begging for basic features to work correctly, paying for a sub and still getting treated like trash.

Completely uninstall it, then install a brand-new copy of the latest version, v0.141;
I tested it using my usual method, and the bug hasn’t been fixed;
However, after installing the latest version, I can use the latest version of Codex CLI without any issues;
As for this bug, it doesn’t affect normal use in the latest version, v0.141.

This bug hasn’t been fixed at all. But you can use version 0.141 normally.
@Fanatic9

Completely uninstall it, then install a brand-new copy of the latest version, v0.141; I tested it using my usual method, and the bug hasn’t been fixed; However, after installing the latest version, I can use the latest version of Codex CLI without any issues; As for this bug, it doesn’t affect normal use in the latest version, v0.141. This bug hasn’t been fixed at all. But you can use version 0.141 normally. @Fanatic9

Not sure why you are replying about something I didn't ask about and isn't the main point, I can use it just fine but it doesn't mean I can turn a blind to this feature which is important when trying to run things elevated that codex can't access.

> Completely uninstall it, then install a brand-new copy of the latest version, v0.141; > I tested it using my usual method, and the bug hasn’t been fixed; > However, after installing the latest version, I can use the latest version of Codex CLI without any issues; > As for this bug, it doesn’t affect normal use in the latest version, v0.141. > This bug hasn’t been fixed at all. But you can use version 0.141 normally. > @Fanatic9 Not sure why you are replying about something I didn't ask about and isn't the main point, I can use it just fine but it doesn't mean I can turn a blind to this feature which is important when trying to run things elevated that codex can't access.

Then you should go submit a new, complete, and technically detailed issue of your own, instead of complaining here on my issue and venting your impotent rage.

I found that CreateProcessAsUserW failed: 2 usually means Windows is trying to launch a path that does not exist. I think the test command should be:

codex -c 'windows.sandbox="elevated"' sandbox cmd /d /c echo CODEX_ELEVATED_OK

Fixing this may help expose the real remaining issue. Maybe my ProcMon debugging process helps: https://github.com/openai/codex/issues/28042#issuecomment-4874514520