`elevated_windows_sandbox` causing all agent commands to fail with `(no output)` (logs show `CreateProcessAsUserW failed: 5`)

Hi there @i4TsU - thanks for the detailed report and I'm sorry you're running into issues with the elevated sandbox. It appears that the sandbox is unable to execute your version of powershell. Can you run the following commands and let me know their output? That will help further diagnose the issue and lead me towards an appropriate fix:

* where.exe pwsh
* where.exe powershell
* Get-Command pwsh, powershell | Select-Object Name, Source, Path
* Get-AppxPackage -Name Microsoft.PowerShell -AllUsers | Select-Object Name, PackageFullName, InstallLocation
* icacls "C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe"
* C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -Command "$PSVersionTable.PSVersion"

No worries! :)

> where.exe pwsh
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe
C:\Users\username\AppData\Local\Microsoft\WindowsApps\pwsh.exe



> where.exe powershell
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe



> Get-Command pwsh, powershell | Select-Object Name, Source, Path

Name           Source                                                                                Path
----           ------                                                                                ----
pwsh.exe       C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe
powershell.exe C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe                             C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe



> Get-AppxPackage -Name Microsoft.PowerShell -AllUsers | Select-Object Name, PackageFullName, InstallLocation

Name                 PackageFullName                                 InstallLocation
----                 ---------------                                 ---------------
Microsoft.PowerShell Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe



> icacls "C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe"
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe BUILTIN\Users:(I)(Rc,S,RD,REA,X,RA)
                                                                                      S-1-15-3-3474344596-1361774275-169937050-1715369765-655753896-4292765343-1302149271:(I)(RX)
                                                                                      BUILTIN\Users:(I)(R)
                                                                                      NT SERVICE\TrustedInstaller:(I)(F)
                                                                                      S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(I)(RX)
                                                                                      NT AUTHORITY\SYSTEM:(I)(F)
                                                                                      NT AUTHORITY\LOCAL SERVICE:(I)(RX)
                                                                                      NT AUTHORITY\NETWORK SERVICE:(I)(RX)
                                                                                      NT AUTHORITY\RESTRICTED:(I)(RX)
                                                                                      S-1-19-512-4096:(RX,D,WDAC,WO,WA)

Successfully processed 1 files; Failed processing 0 files



> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -Command '$PSVersionTable.PSVersion'

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      26100  7462

thank you for the quick reply. I'm still working to reproduce/diagnose the issue. In the meantime, I think you have two options

1. continue to use the experimental_windows_sandbox feature instead of the elevated one. For nearly all use cases, it is just as good
2. One thing you could try is removing the pwsh that was installed via the Windows Store, and re-installing using winget. Totally optional, but if you go this route let me know if it works. It will provide some useful debugging information:

Get-AppxPackage -Name Microsoft.PowerShell | Remove-AppxPackage
winget install Microsoft.PowerShell

Reinstalling pwsh seems to have solved the issues with the sandbox :) I was able to do a little testing between other things - I just uploaded a "post-fix" session (Thread ID: 019c0d0d-f58f-7160-bbbe-9a0bf0364ce8), and linked this GitHub Issue in the feedback notes too, but I will try to summarise what I observed below, along with some additional info from before reinstalling pwsh:

---

• Further to your first message yesterday, I was able to confirm that - at the very least - attempting to run my main pwsh.exe as CodexSandboxOffline user via PsExec resulted in a similar failure:

```powershell
> psexec64 -u CodexSandboxOffline -p codex cmd /c "C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe" -Command "Get-ChildItem -Force"

PsExec v2.43 - Execute processes remotely
Copyright (C) 2001-2023 Mark Russinovich
Sysinternals - www.sysinternals.com

cmd exited with error code 1.
```

• After your most recent message, I installed pwsh using the native installer via scoop (scoop install pwsh --global).
• I then ran Get-AppxPackage -Name Microsoft.PowerShell | Remove-AppxPackage as suggested.
• Final state:

```powershell
> where.exe pwsh
X:\ProgramData\scoop\apps\pwsh\current\pwsh.exe
X:\ProgramData\scoop\shims\pwsh.exe

> where.exe powershell
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

> Get-Command pwsh, powershell | Select-Object Name, Source, Path

Name Source Path
---- ------ ----
pwsh.exe X:\ProgramData\scoop\apps\pwsh\current\pwsh.exe X:\ProgramData\scoop\apps\pwsh\current\pwsh.exe
powershell.exe C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe

> Get-AppxPackage -Name Microsoft.PowerShell -AllUsers | Select-Object Name, PackageFullName, InstallLocation

> icacls 'X:\ProgramData\scoop\apps\pwsh\current\pwsh.exe'
X:\ProgramData\scoop\apps\pwsh\current\pwsh.exe BUILTIN\Administrators:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\Authenticated Users:(I)(M)
BUILTIN\Users:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

> X:\ProgramData\scoop\apps\pwsh\current\pwsh.exe -NoProfile -Command '$PSVersionTable.PSVersion'

Major Minor Patch PreReleaseLabel BuildLabel
----- ----- ----- --------------- ----------
7 5 4

> scoop info pwsh

Name : pwsh
Description : Cross-platform automation and configuration tool/framework, known as Powershell Core, that works well with existing tools and is optimized for dealing with structured data.
Version : 7.5.4
Source : main
Website : https://github.com/PowerShell/PowerShell
License : MIT
Updated at : 21/10/2025 6:29:25 AM
Updated by : github-actions[bot]
Installed : 7.5.4 global
Binaries : pwsh.exe
Shortcuts : PowerShell Core
Notes : Since Scoop uses pwsh.exe internally, to update PowerShell Core itself,
run scoop update pwsh from Windows PowerShell, i.e. powershell.exe.

Add PowerShell Core as a explorer context menu by running: '<root>\install-explorer-context.reg'
For file context menu, run '<root>\install-file-context.reg'
```

---

This morning, I then tried running the same tests in a new codex session, using the same location + config as before:

• Initially sandboxed commands were failing with error 1326 as I forgot about changing the password of the sandbox local user for the earlier PsExec tests
• After removing both elevated_windows_sandbox = true and experimental_windows_sandbox = true from my config.toml and launching a new session + reenabling the elevated sandbox when prompted, everything worked as expected with no further issues (except for an "Access denied" error related to the oh-my-posh init in my $PROFILE)
• This final session, where I confirmed everything worked, is the only one I remembered to submit via /feedback unfortunately, but hopefully you have enough info from everything else to determine whether or not any further action is warranted :)
• Final results (using identical on-request/workspace-write permissions):
• Get-ChildItem inside workspace: now executes successfully inside of the sandbox (model no longer needs to escalate/request approval)
• 'Set-Content' succeeded both inside and outside of the workspace, without needing approval/escalation - not sure if that is intended or not ?
• However, the apply_patch tool behaved exactly as expected, requiring manual approval when modifying files outside of the workspace, and applying changes successfully and without approval

---

Hopefully that helps with repro/identifying the issue and whether or not it is worth safeguarding against lol - and, if not, hopefully you did not waste too much time on it :). Thanks for your help in any case, and let me know if you want me to share any other details/run any tests etc.!

I am experiencing the same issue here. Any PowerShell command that Codex attempts to run gives no output. It started with some of the latest codex updates. I can confirm that disabling elevated_windows_sandbox and enabling experimental_windows_sandbox fixes the issue.

What version of Codex is running?
codex-cli 0.94.0

Which model were you using?
gpt-5.2-codex

What platform is your computer?
Windows 11 25H2 10.0.26220.0 x64

What terminal emulator and version are you using (if applicable)?
Windows Terminal running PowerShell-7.5.4

Here's the output of the commands you requested above:

\> where.exe pwsh

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe
C:\Users\chris\AppData\Local\Microsoft\WindowsApps\pwsh.exe

\> where.exe powershell

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

\> Get-Command pwsh, powershell | Select-Object Name, Source, Path | fl Name : pwsh.exe Source : C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe Path : C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe Name : powershell.exe Source : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Path : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

\> Get-AppxPackage -Name Microsoft.PowerShell -AllUsers | Select-Object Name, PackageFullName, InstallLocation | fl Name : Microsoft.PowerShell PackageFullName : Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe InstallLocation : C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe

\> icacls "C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe" C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.4.0_x64__8wekyb3d8bbwe\pwsh.exe VORDEFINIERT\Benutzer:(I)(Rc,S,RD,REA,X,RA)

S-1-15-3-3474344596-1361774275-169937050-1715369765-655753896-4292765343-1302149271:(I)(RX)
VORDEFINIERT\Benutzer:(I)(R)
NT SERVICE\TrustedInstaller:(I)(F)
S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(I)(RX)
NT-AUTORITÄT\SYSTEM:(I)(F)
NT-AUTORITÄT\Lokaler Dienst:(I)(RX)
NT-AUTORITÄT\Netzwerkdienst:(I)(RX)
NT-AUTORITÄT\EINGESCHRÄNKTER ZUGRIFF:(I)(RX)
S-1-19-512-4096:(I)(RX,D,WDAC,WO,WA)

\> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -Command "$PSVersionTable.PSVersion" Major Minor Build Revision ----- ----- ----- -------- 5 1 26100 7670

For anyone has problem, codex run without std output, i have success case to fix it fine.
It is dll windows missing. install

https://download.visualstudio.microsoft.com/download/pr/7ebf5fdb-36dc-4145-b0a0-90d3d5990a61/CC0FF0EB1DC3F5188AE6300FAEF32BF5BEEBA4BDD6E8E445A9184072096B713B/VC_redist.x64.exe

Then restart, it should work for you.

@jastranlove2020, thanks for sharing your solution. Much appreciated!

For anyone has problem, codex run without std output, i have success case to fix it fine. It is dll windows missing. install https://download.visualstudio.microsoft.com/download/pr/7ebf5fdb-36dc-4145-b0a0-90d3d5990a61/CC0FF0EB1DC3F5188AE6300FAEF32BF5BEEBA4BDD6E8E445A9184072096B713B/VC_redist.x64.exe Then restart, it should work for you.

Don't think this is the root cause in my case. I already had the latest version of the VC++ x64 Redistributable installed. In my case, it's probably related to PowerShell being installed via the Windows Store (see the earlier comments by @i4TsU).

This is still an issue with Codex 0.116. I can confirm the issue disappears when uninstalling pwsh via the Microsoft Store and installing it instead via the MSI (https://github.com/PowerShell/PowerShell/releases/download/v7.6.0/PowerShell-7.6.0-win-x64.msi).

This is still an issue with Codex 0.116. I can confirm the issue disappears when uninstalling pwsh via the Microsoft Store and installing it instead via the MSI (https://github.com/PowerShell/PowerShell/releases/download/v7.6.0/PowerShell-7.6.0-win-x64.msi).

True. The same sandbox issue can be solved by updating powershell to 7.6.0.

Today, it was announced that the MSI installer of PowerShell has been deprecated and will no longer be available for future PowerShell releases: https://devblogs.microsoft.com/powershell/powershell-msi-deprecation/

This might mean that the workaround presented here will not be feasible in the future anymore.

I can confirm that uninstalling powershell from store and installing it from msi fixed the issue.

Installing pwsh via scoop finally fixed it for me.

Installing via winget did not work - had the same permissions issue as powershell from store

I can also confirm that uninstalling the PowerShell from m store and installing the MSI version was the right fix for me.

I ahad Powershell 5 and tried to update to 7 using winget, that is when I got the sandbox error.
The msi fix did it.

Additional affected user report from Codex Desktop on Windows.

Codex Desktop is unusable for local project work because every shell command fails before PowerShell starts.

Error:

windows sandbox: runner error: CreateProcessAsUserW failed: 5

Minimal repro command attempted from a Codex Desktop project session:

Get-Location

Workspace path:

C:\Users\xxxx\Documents\Codex\myproject (anonymized) 

What was tried:

• Reinstalled Codex Desktop
• Relaunched Codex
• Ran Codex as Administrator
• Checked Windows Security / Protection History: no Codex-related blocks shown
• Confirmed Secondary Logon service is running and set to Manual
• Retried shell commands from inside the Codex Desktop project session
• Failure persists before any project command executes

This is a dead-end user experience: the app presents shell/workspace access, but the runner fails globally before invoking the shell. The surfaced message is not actionable for an end user. CreateProcessAsUserW failed: 5 may be meaningful internally, but Codex Desktop does not show a diagnosis, log path, helper executable path to allowlist, user/elevation context, or next remediation step.

Requested improvements:

1. Add a built-in shell runner diagnostics panel or command.
2. Surface the exact process Codex is trying to spawn and as which user.
3. Include exact log file locations in the error message.
4. Detect common causes: token/elevation mismatch, Controlled Folder Access, AppLocker/WDAC, missing user rights, disabled services, blocked helper executable.
5. Provide a one-click copyable diagnostic bundle.
6. Provide a fallback mode that can at least inspect workspace files without requiring the sandbox shell runner.
7. Improve Windows Desktop vs CLI vs WSL2 troubleshooting docs.

As-is, reinstalling, running as Administrator, confirming Secondary Logon, and checking Windows Security do not resolve it or reveal the next diagnostic step.

Codex Desktop Windows 26.429.3425.0

Browser Use / in-app browser cannot open google.com.

Initial failure:
failed to execute Node: Access is denied. (os error 5)

Confirmed:
C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\resources\node.exe
→ Access is denied

C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\resources\rg.exe
→ Access is denied

Confirmed working:
C:\Users\mmggr\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe
→ v24.14.0

Workaround tried:
Copied the working node.exe into recent:
C:\Users\mmggr\.codex\tmp\...\codex-arg*

Result:
node_repl minimal calls started working and Browser Use could detect an about:blank tab.

New failure:
Trying to open https://www.google.com causes node_repl/kernel to close and Codex falls back to:
windows sandbox failed: runner error: CreateProcessAsUserW failed: 5

Also tried:
[windows]
sandbox = "unelevated"

Result:
Does not fix Browser Use. node_repl / Browser Use still fail.

Tried enabling runCodexInWindowsSubsystemForLinux manually in:
C:\Users\mmggr\.codex\.codex-global-state.json

Result:
Codex hangs indefinitely when running pwd, so WSL agent mode is not usable from this build/UI.

Conclusion:
This appears to combine the WindowsApps packaged helper execution failure with the Windows sandbox CreateProcessAsUserW failed: 5 issue. Browser Use remains unusable on this Windows Desktop build.

I reproduced a closely related elevated sandbox failure where setup completed, but command launch failed with:

CreateProcessAsUserW failed: 5

In my case the root cause appeared to be PowerShell resolution through a Microsoft Store/App Execution Alias path.

Relevant details:

• Codex sandbox log showed it was launching:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

• That file was a 0-byte reparse point/App Execution Alias.
• ACL inspection showed access for the interactive user, but not for the CodexSandbox* users.
• As a result, the sandbox runner could start, but the child shell could not.

Then I uninstalled Store PowerShell and the failure changed to:

CreateProcessAsUserW failed: 2

That matched the now-missing pwsh path.

Installing PowerShell 7 via the x64 MSI fixed this part:

• pwsh now resolves to:

C:\Program Files\PowerShell\7\pwsh.exe

• sandboxed whoami now returns:

<machine>\CodexSandboxOffline

• workspace read/write/delete works
• offline network blocking works as expected

Adding a current Codex Desktop Windows data point where this same PowerShell / WindowsApps alias failure was fixed by installing the real MSI/WiX PowerShell and making PATH precedence deterministic.

Environment:

• Codex Desktop package: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
• Bundled Codex CLI: codex-cli 0.136.0-alpha.2
• Platform: Windows x64
• Config at the time used Windows sandboxing through Codex Desktop with workspace-write tool execution.

Initial symptom:

• PowerShell-backed shell tool calls were unreliable / failing under the sandbox.
• The important clue was that pwsh resolved to the WindowsApps app-execution alias instead of a normal executable:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

That matches the failure family in this thread: sandbox runner/setup may be healthy enough to start, but the actual shell process path is the WindowsApps/MSIX alias path that does not behave like a normal executable for the Codex sandbox users.

What I changed:

1. Installed PowerShell 7.6.2 via the MSI/WiX installer path using winget with the WiX installer type.
2. Verified the real executable existed and could run explicitly:

C:\Program Files\PowerShell\7\pwsh.exe
PowerShell 7.6.2

1. Updated the persistent user Path so C:\Program Files\PowerShell\7 appears before C:\Users\<user>\AppData\Local\Microsoft\WindowsApps.

The user PATH after the fix was shaped like:

C:\Program Files\PowerShell\7;...;C:\Users\<user>\AppData\Local\Microsoft\WindowsApps;...

One detail: before restarting Codex Desktop, the running Codex process still had a stale environment snapshot, so where.exe pwsh still showed the WindowsApps alias. After a full Codex Desktop restart, the new process inherited the fixed PATH.

Post-restart verification:

where.exe pwsh
C:\Program Files\PowerShell\7\pwsh.exe

$PSVersionTable.PSVersion.ToString()
7.6.2

A sandboxed PowerShell write/read in the workspace also succeeded:

$p = Join-Path (Get-Location) 'work\sandbox-after-restart.txt'
Set-Content -LiteralPath $p -Value ('ok ' + (Get-Date -Format o))
Get-Content -LiteralPath $p

Result:

ok 2026-06-02T07:04:03.3585224-04:00

So for this machine, the durable fix was not just installing PowerShell via MSI/WiX; it was also ensuring C:\Program Files\PowerShell\7 wins PATH resolution over the WindowsApps app-execution alias, then fully restarting Codex Desktop. After that, sandboxed PowerShell tool execution worked again.

PR-ready fork branch updated after local Codex app repair.

Fork PR: https://github.com/Nicolas0315/codex/pull/1
Upstream compare: https://github.com/openai/codex/compare/main...Nicolas0315:codex/doctor-windows-pwsh-alias-warning?expand=1
Latest branch commit: 1b3c6a5 Clarify rollout inventory recovery in doctor

What this now covers:

• WindowsApps/MSIX pwsh detection in codex doctor for Windows sandbox shell failures.
• Large logs_2.sqlite / WAL / SHM detection in codex doctor.
• Actionable recovery guidance when rollout files are missing from the threads state DB.

Local repair evidence from the affected Windows installation:

• Removed a failing notify hook after backup; this stopped new os error 206 hook failures.
• Normalized local plugin manifests to satisfy defaultPrompt constraints.
• Pruned low-value TRACE/DEBUG/noisy INFO diagnostic rows after backup; logs_2.sqlite shrank from ~729 MB to ~5.8 MB.
• codex doctor --summary --no-color --ascii: 16 ok, 1 idle, 3 notes, 1 warn, 0 fail. Remaining warn is rollout/thread inventory drift and now has explicit safe recovery guidance in the branch.
• New WARN/ERROR after repair window: 0.

Validation on the branch:

• cargo test -p codex-cli --bin codex windows_shell_check: passed 2 tests.
• cargo test -p codex-cli --bin codex large_sqlite_log_issue: passed 1 test.
• cargo test -p codex-cli --bin codex thread_inventory_check_warns_for_missing_stale_and_mismatched_rows: passed 1 test.
• git diff --check: passed.
• just fmt: Rust/Python formatting completed; Bazel/Starlark buildifier still fails on this Windows host with [WinError 2].

Upstream PR creation blocker is still repo policy, not branch/auth/body: openai/codex reports pull_request_creation_policy: collaborators_only, and this account only has pull:true. A maintainer needs to invite Nicolas0315 as collaborator or open/cherry-pick the fork branch.

Same root problem (elevated_windows_sandbox unusable on Windows 10.0.26200), but I'm seeing several distinct failure signatures across two builds, so adding data in case it helps triage.

Environment

• Codex: 0.142.3 (npm global) and 0.143.0-alpha.29 — both affected
• OS: Windows 11, 10.0.26200 (x64)
• Shell: PowerShell 7; also reproduced from Git Bash
• Sandbox users already provisioned by an earlier version: CodexSandboxOnline, CodexSandboxOffline, group CodexSandboxUsers all present
• model_reasoning_effort = xhigh, sandbox = workspace-write

Observed signatures (all with features.elevated_windows_sandbox = true)

1. Non-elevated, 0.142.3 — every model command dies immediately:

``
exec_command failed ... CreateProcess { message: "Rejected(\"Failed to create unified exec process:
orchestrator_helper_exit_nonzero: setup helper exited with status Some(-1073741502)\")" }
`
-1073741502 = 0xC0000142 (**STATUS_DLL_INIT_FAILED**). Note this differs from the CreateProcessAsUserW failed: 5` in the original report — here the child is created but fails during DLL init.

1. Elevated (admin shell), 0.142.3 — does not crash; instead codex-windows-sandbox-setup.exe hangs in a CPU spin-loop: 4 instances accumulating 260–350 CPU-seconds while codex blocks behind them. Had to kill them manually.
2. 0.143.0-alpha.29 — neither crash nor spin; the run silently stalls ~230s then exits -1 with no command ever executing (setup helper reports status Some(143)).
3. Historical (~/.codex/.sandbox/sandbox.log) — 38× over prior weeks:

``
setup refresh: failed to spawn ...\codex-windows-sandbox-setup.exe:
The requested operation requires elevation. (os error 740)
``
i.e. non-elevated Codex cannot launch the elevated setup helper at all.

Extra diagnostics

• The helper binary is not itself broken: run standalone it loads fine and only rejects the missing b64 payload (helper_request_args_failed: failed to decode payload b64) — so signature (1) is a DLL-init failure of the spawned-as-sandbox-user process, consistent with a missing window-station/desktop grant for the CodexSandbox* users rather than a corrupt binary.
• A one-time elevated re-provision (running Codex from an admin shell) did not fix it — it produced signature (2).
• The base restricted-token sandbox is unaffected and works: with elevated_windows_sandbox = false, commands run and out-of-workspace writes are still blocked (e.g. write to C:\ → access denied). So this is isolated to the elevated layer.

Net effect / workaround

With elevated_windows_sandbox = true, all agent commands fail (crash / spin / stall depending on build & elevation). Setting elevated_windows_sandbox = false restores a working agent while keeping restricted-token write-confinement; you lose only the separate sandbox-user identity and per-user firewall egress. That's the only usable configuration here today.

I can reproduce this in Codex Desktop on Windows, and I isolated the behavior by testing the relevant settings separately.

Environment:

• Codex Desktop: 26.707.31428
• Windows: Microsoft Windows NT 10.0.26200.0
• PowerShell: 7.6.3
• I separately keep the Codex CLI updated to the latest version.
• I also use classic ChatGPT alongside Codex Desktop.

Reproduction/result:

• With [windows] sandbox = "elevated", even a minimal Write-Output OK command never reaches command execution or an approval/escalation gate. No error, stdout, or stderr is returned; the tool call simply hangs indefinitely and must be terminated. The requested command timeout is not honored normally.
• With [windows] sandbox = "unelevated", the identical command succeeds consistently in approximately 0.5 seconds.
• PowerShell works normally outside Codex.
• Changing shell_environment_policy.inherit independently does not determine the result. The behavior consistently follows the elevated versus unelevated sandbox setting.
• Reinitializing the Codex sandbox did not fix elevated mode.
• Reinstalling from Codex Settings did not fix elevated mode this time.

I encountered similar behavior a few Codex versions ago, but previously it would usually resolve after a Codex CLI update or reinstall. This occurrence persists despite the in-app reinstall.

Current workaround:

[windows]
sandbox = "unelevated"

The most important distinction in this reproduction is that the command does not fail after reaching PowerShell or an approval gate: it never gets that far from the user's perspective. Codex returns no diagnostic at all and remains hung.