Windows elevated sandbox fails with “spawn setup refresh” after Codex CLI update; unelevated sandbox works

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

• #24050

Powered by Codex Action

This looks very close to #24050, but your repro is useful because it shows the mode split the other way around: elevated fails while unelevated succeeds.

The failing layer is before the target command runs. In current source, sandboxed execution calls a setup refresh helper first; the user-facing windows sandbox failed: spawn setup refresh message usually means Codex could not spawn codex-windows-sandbox-setup.exe or that helper exited before it could refresh the sandbox ACLs.

A few checks that would help distinguish UAC/manifest detection from a stale/broken helper path:

# Find the helper that this npm install shipped
Get-ChildItem $env:APPDATA\npm\node_modules\@openai\codex -Recurse -Filter codex-windows-sandbox-setup.exe |
  Select-Object FullName,Length,LastWriteTime

# Search the sandbox setup logs for the underlying Win32 error
Get-ChildItem $env:USERPROFILE\.codex\.sandbox -Recurse -File -ErrorAction SilentlyContinue |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 20 FullName,LastWriteTime

Select-String -Path $env:USERPROFILE\.codex\.sandbox\* `
  -Pattern 'setup refresh: failed to spawn','setup refresh: exited','os error 740','codex-windows-sandbox-setup.exe' `
  -ErrorAction SilentlyContinue

If the log shows os error 740, it is the same class as #24050: Windows is treating the setup helper as elevation-required, likely because the helper name contains setup.exe and lacks an explicit asInvoker manifest. If it shows a different error, the exact line after setup refresh: failed to spawn ... should point to the real cause.

Your current workaround, windows.sandbox=unelevated, is the right low-risk workaround while this is investigated. I would avoid switching to no-sandbox just to work around this.

Product-side, I think two fixes would help:

• embed an explicit requestedExecutionLevel level=asInvoker manifest in codex-windows-sandbox-setup.exe as suggested in #24050
• have codex doctor run or validate the setup-refresh spawn path directly, because sandbox.helpers: ok is too weak here: it says configuration is readable, but not that the helper can actually be spawned.

Thanks. I checked the sandbox files locally.

I am not going to upload the full sandbox log because it contains private local paths and a lot of unrelated historical project/workspace entries.

Summary of what I found:

• codex-windows-sandbox-setup.exe exists under my npm Codex install.
• Sandbox log files exist under my local .codex\.sandbox directory.
• The log search output contains many historical setup refresh: spawning ... codex-windows-sandbox-setup.exe entries followed by setup binary completed.
• I did not find a clean os error 740 match in the searched output.
• My current minimal repro remains:

codex -c windows.sandbox="elevated" sandbox windows cmd /c echo CODEX_ELEVATED_SANDBOX_TEST_OK

Result:

windows sandbox failed: spawn setup refresh

And the matching unelevated test still succeeds:

codex -c windows.sandbox="unelevated" sandbox windows cmd /c echo CODEX_UNELEVATED_SANDBOX_TEST_OK

Result:

CODEX_UNELEVATED_SANDBOX_TEST_OK

So my case may be related to #24050, but I do not currently have the same os error 740 evidence from my local search output.

Same here lots errors like below. Codex is unusable for me at the moment. Suggested workaround seems to be working but keeps asking for everything so still making the cli practically unusable

 Ran Get-ChildItem -Recurse -Directory monolith\cmd,monolith\internal -ErrorAction SilentlyContinue | Select-Object FullName
  └ execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

Adding a related Codex Desktop / Chrome browser-client data point.

Environment observed in Codex Desktop:

• Windows Codex App package: OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0
• Codex CLI used by the node_repl MCP environment: codex-cli 0.133.0
• Bundled Browser / Chrome plugin cache: 26.519.81530
• Codex Chrome Extension: installed and enabled in the Default Chrome profile, extension version 1.1.5_0
• Native Messaging Host manifest: present and registry path matches the manifest; allowed origin matches the extension id
• Windows native validator: passed; User / Machine / Process CODEX_CLI_PATH were unset; Playwright MCP had --headless; no WSL project entries were detected

Symptom:
In Codex Desktop, attempting a lightweight Chrome Extension backend check through the bundled Chrome plugin browser-client caused the Node REPL kernel to exit before agent.browsers.get("extension") / browser.user.openTabs() could be reached.

Observed twice after a full PC reboot:

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

This happened after Chrome-side static checks passed. I did not read or include any tab URLs, tab titles, page contents, cookies, local storage, or profile data.

Why this seems relevant to this issue:
Most discussion here is about direct codex ... sandbox windows ... CLI repros. This appears to be the same spawn setup refresh failure surfacing inside Codex Desktop's browser-client / Node REPL path, so it can make the Chrome Extension backend look unavailable even when Chrome, the extension, and the native host manifest are healthy.

Expected:
The Chrome backend bootstrap should either reach openTabs() or return an actionable runtime / sandbox setup error. It should not look like a Chrome Extension install or native-host failure when those static checks pass.

Adding one more data point that matches the os error 740 branch described above.

Environment:

• Windows Codex Desktop app, updated recently
• Bundled Codex CLI used by the desktop/browser runtime: codex-cli 0.133.0
• Bundled Browser/Chrome plugin runtime present
• The in-app browser backend itself appears to start normally

Symptom:
Browser / Node REPL startup fails before any browser automation, target URL, or site-specific code runs.

A minimal Node REPL call fails with:

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

I reproduced the lower-level failure by invoking the bundled Codex CLI used by the Node REPL environment directly:

codex.exe sandbox windows -- powershell -NoProfile -Command "Write-Output sandbox-smoke"

Expected:

sandbox-smoke

Actual:

windows sandbox failed: spawn setup refresh

The sandbox log contains the concrete failure:

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

So this looks like the same class of failure described above: the sandbox setup refresh path cannot spawn codex-windows-sandbox-setup.exe because Windows treats that helper launch as elevation-required.

Why this matters for Codex Desktop / Browser:
This failure surfaces before the browser-client can connect to the already-started browser backend. That can make Browser/Chrome/Node REPL look broken even when the browser backend, extension/static setup, and target URL are unrelated to the failure. The failing layer appears to be the sandboxed Node kernel setup through the bundled Codex CLI.

This also seems consistent with the proposed product-side fixes:

• give codex-windows-sandbox-setup.exe an explicit asInvoker manifest
• have codex doctor validate the actual setup-refresh spawn path, not only that sandbox helper configuration is readable

Additional local result after re-testing on Windows Codex Desktop:

• Codex App package: OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0
• Bundled plugin version observed in cache: 26.519.81530
• codex command resolves to WindowsApps Desktop CLI path.
• User / Machine / Process scope CODEX_CLI_PATH are unset.
• The thread's node_repl MCP env still has a tool-owned CODEX_CLI_PATH under C:\Users\n-kei\AppData\Local\OpenAI\Codex\bin\...\codex.exe, and that executable reports codex-cli 0.133.0.

Changing user config from:

[windows]
sandbox = "elevated"

to:

[windows]
sandbox = "unelevated"

resolved the node_repl kernel exited unexpectedly / windows sandbox failed: spawn setup refresh path for the bundled browser runtime in this environment.

After the change, capability-only checks succeeded:

• node_repl baseline JS execution succeeded.
• setupBrowserRuntime({ globals: globalThis }) succeeded using the bundled browser client.
• agent.browsers.list() returned both Chrome Extension and Codex In-app Browser backends.
• agent.browsers.get("extension") succeeded.
• extensionBrowser.user.openTabs() succeeded and returned a tab count. I did not print tab URLs, titles, page bodies, cookies, or session data.

I also added --isolated to @playwright/mcp@0.0.68 args to avoid persisted mcp-chrome profile locks, but the sandbox-refresh fix above was specifically the [windows] sandbox = "unelevated" change.

I’m seeing a related but slightly different failure mode on Codex CLI 0.134.0.

Environment:

• OS: Microsoft Windows 11 Pro, version 10.0.26200.8457, x64

• systeminfo: OS Version: 10.0.26200 N/A Build 26200
• cmd /c ver: Microsoft Windows [Version 10.0.26200.8457]
• PowerShell: 7.5.5
• Codex CLI: 0.134.0
• Install method: npm
• Shell: elevated Windows PowerShell
• net session: There are no entries in the list.
• codex doctor: installation/auth/config/network/websocket/sandbox.helpers are OK
• Windows optional features:

• Windows Sandbox (Containers-DisposableClientVM): Disabled
• Virtual Machine Platform: Enabled
• Windows Subsystem for Linux: Enabled

One additional data point: the Windows Sandbox optional feature (Containers-DisposableClientVM) is disabled on my machine, while Virtual Machine Platform and WSL are enabled. I’m not sure whether Codex’s native Windows sandbox is expected to depend on that Windows optional feature, but I’m including it because this issue appears to be in the Windows sandbox setup path.

Minimal repro from a clean directory:

New-Item -ItemType Directory -Force C:\tmp\codex-sandbox-test | Out-Null
Set-Location C:\tmp\codex-sandbox-test

$cmd = "$env:WINDIR\System32\cmd.exe"
$ps = "$env:WINDIR\System32\WindowsPowerShell\v1.0\powershell.exe"

codex -c 'windows.sandbox="unelevated"' sandbox windows -- "$cmd" /c echo CODEX_UNELEVATED_CMD_ABS_OK
codex -c 'windows.sandbox="elevated"' sandbox windows -- "$cmd" /c echo CODEX_ELEVATED_CMD_ABS_OK
codex -c 'windows.sandbox="unelevated"' sandbox windows -- "$ps" -NoProfile -Command "Write-Output CODEX_UNELEVATED_PS_ABS_OK"
codex -c 'windows.sandbox="elevated"' sandbox windows -- "$ps" -NoProfile -Command "Write-Output CODEX_ELEVATED_PS_ABS_OK"

Observed CLI output:

windows sandbox failed: CreateProcessAsUserW failed: 2
windows sandbox failed: runner error: CreateProcessAsUserW failed: 2
windows sandbox failed: CreateProcessAsUserW failed: 2
windows sandbox failed: runner error: CreateProcessAsUserW failed: 2

However, ~/.codex/.sandbox/sandbox.log shows a lower-level setup refresh failure:

setup refresh: spawning ...\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 verified that the setup helper exists and is runnable directly from the same elevated PowerShell session:

$helper = "$env: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"

Test-Path $helper
# True

& $helper
# Error: helper_request_args_failed: expected payload argument

$LASTEXITCODE
# 1

So the helper binary itself appears to be present and not globally blocked. Running it directly does not produce ERROR_ELEVATION_REQUIRED (740); it reaches the helper’s own argument validation path.

The ERROR_ELEVATION_REQUIRED (740) only appears when Codex spawns the helper during setup refresh. This suggests the user-visible CreateProcessAsUserW failed: 2 may be a secondary/lossy surface error, while the more actionable root signal is the setup helper spawn failing with os error 740.

Potentially useful diagnostics:

• surface the setup-helper os error 740 directly instead of the later CreateProcessAsUserW failed: 2
• distinguish setup-helper launch/elevation failure from target-command launch failure
• clarify whether setup refresh is expected to run through an already-elevated token, trigger UAC, or use a separate helper launch path

I’m not opening an unsolicited PR due to the contribution policy, but I’m happy to provide more logs or test a diagnostic patch if maintainers think it would help.

I think the real mismatch is that doctor is proving "config is readable" while the failing user path is "the setup-refresh helper can actually spawn." Those are very different checks.

If elevated mode depends on codex-windows-sandbox-setup.exe surviving that setup-refresh spawn, doctor should exercise that exact path and print the helper binary, elevation context, and raw Win32 failure when it breaks. Otherwise users get an all-clear from doctor and then a runtime-only failure, which sends them chasing workspace ghosts instead of the helper path.

I think the real mismatch is that doctor is proving "config is readable" while the failing user path is "the setup-refresh helper can actually spawn." Those are very different checks. If elevated mode depends on codex-windows-sandbox-setup.exe surviving that setup-refresh spawn, doctor should exercise that exact path and print the helper binary, elevation context, and raw Win32 failure when it breaks. Otherwise users get an all-clear from doctor and then a runtime-only failure, which sends them chasing workspace ghosts instead of the helper path.

Yes, I think that’s the right distinction.

In my case, codex doctor also made the environment look healthy, but the actual sandbox execution path failed later during setup refresh. The lower-level signal in ~/.codex/.sandbox/sandbox.log was:

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

So I would split this into two related issues:

1. Diagnostic coverage gap:

codex doctor checks that the config/helper state is readable or inspectable, but it does not appear to exercise the actual setup-refresh path that spawns codex-windows-sandbox-setup.exe.

1. Runtime setup-refresh failure:

During real sandbox execution, Codex fails while spawning codex-windows-sandbox-setup.exe. In my case, the lower-level Win32 signal is ERROR_ELEVATION_REQUIRED (os error 740).

I also verified that the helper binary exists and is directly runnable from the same elevated PowerShell session. Running it directly reaches its own argument validation path:

& $helper
# Error: helper_request_args_failed: expected payload argument

That makes the doctor/runtime gap more noticeable, because the failure only appears when Codex spawns the helper during setup refresh.

Additionally One more timeline detail from my local sandbox log: this was not failing from the beginning. At 2026-05-22 03:50:13, the setup-refresh path successfully spawned codex-windows-sandbox-setup.exe and reached setup binary completed. Starting at 2026-05-22 04:44:22, the same setup-refresh path started failing with os error 740.

I also checked file timestamps around that transition. There were no modified files under the npm package root between 2026-05-22 03:45 and 04:50, but under %USERPROFILE%\.codex I saw .sandbox-bin\codex-command-runner-0.133.0.exe created at 03:49:48, a successful session around 03:49/03:50, and a failing session starting at 04:44.

So this looks less like an environment that was broken from the beginning, and more like a setup-refresh/runtime state transition after a previously successful setup refresh.

A useful doctor check should either exercise the setup-refresh path that spawns codex-windows-sandbox-setup.exe, or at least report the helper path, elevation/integrity context, and raw Win32 error when that helper cannot be spawned.

I also encountered the same problem. I started pwsh as an administrator, and then launched codex within it. The error message disappeared.
I don't know if there are any risks in using it this way.

The problem appears to be that, despite having a sandbox setup phase complete successfully in an elevated/UAC context, the _later_ actual execute command also tries to re-apply the sandbox setup. This fails, because it is not elevated and can't.

I'm guessing the solution is to either:

• Fix the detection of the already applied ACLS (sandbox setup completes without errors), in the command executor

_or_

• Ensure the second sandbox setup also triggers elevation.

This also explains why @uyoufu's work around works, since in this case, the second setup will execute with elevation.

Relevant sandbox logs from an e2e test of my own software:

[permission-e2e][sandbox.log] [2026-05-28T09:22:40.454207700+00:00] WFP setup succeeded for CodexSandboxOffline with 12 installed filters
[permission-e2e][sandbox.log] [2026-05-28T09:22:40.460763800+00:00] granting write ACE to C:\Users\user\.agent-control-codex-home\agent-control-codex-home_18b3b053fb37f6600002\memories for sandbox group and capability SID
[permission-e2e][sandbox.log] [2026-05-28T09:22:40.461679400+00:00] granting write ACE to C:\Users\user\AppData\Local\Temp\agent-control-permission-e2e_18b3b053fae913100001\workspace for sandbox group and capability SID
[permission-e2e][sandbox.log] [2026-05-28 11:22:40.467 codex-windows-sandbox-setup.exe] setup binary completed
[permission-e2e][sandbox.log] [2026-05-28T09:22:40.494938700+00:00] read-acl-only mode: applying read ACLs
[permission-e2e][sandbox.log] [2026-05-28T09:22:40.506653700+00:00] read ACL run completed
[permission-e2e][sandbox.log] [2026-05-28 11:22:40.509 codex.exe] START: powershell.exe -NoProfile -NonInteractive -Command $ErrorActionPreference = 'Stop'; Write-Output 'permission-e2e: attempting workspace write'; try { Set-Content -LiteralPath 'C:\Users\user\AppData\Loc
[permission-e2e][sandbox.log] [2026-05-28 11:22:40.630 codex.exe] setup refresh: spawning C:\ProgramData\nvm\v22.19.0\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe (cwd=C:\Users\user\AppData\Local\Temp\agent-control-permission-e2e_18b3b053fae913100001\workspace, payload_len=3796)
[permission-e2e][sandbox.log] [2026-05-28 11:22:40.632 codex.exe] setup refresh: failed to spawn C:\ProgramData\nvm\v22.19.0\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe: The requested operation requires elevation. (os error 740)
Error: command/exec failed: {"code":-32603,"message":"exec failed: windows sandbox: spawn setup refresh"}
test codex::tests::real_codex_permission_profile_enforces_workspace_write_disk_read ... FAILED

At [permission-e2e][sandbox.log] [2026-05-28T09:22:40.506653700+00:00] read ACL run completed an elevated sandbox setup completes

At [permission-e2e][sandbox.log] [2026-05-28 11:22:40.630 codex.exe] setup refresh: spawning C: the unelevated command runner/executor tries to install the sandbox _again_ and fails, because it did not ask for elevation.

As a work around, running the entire thing elevated _seems_ safe, since the commands will still execute in the sandbox, even if the parent codex is elevated. _But_ I don't know if there are ways for codex to execute commands/processes outside the sandbox anyway? In that case this work around would massively increase the blast radius...

codex windows sandbox: spawn setup refresh problem persists on new version 0.134.0, fallback to 0.132.0 version problem solved.

This was useful for me too. Changing the user config from [windows] sandbox = "elevated" to [windows] sandbox = "unelevated" and restarting fixed the node_repl kernel exited unexpectedly / windows sandbox failed: spawn setup refresh issue, and restored both Chrome extension and in-app browser control.

I’m seeing a very similar Windows elevated sandbox failure, now on Codex CLI 0.136.0, after extensive troubleshooting.

Feedback ID from Codex:
no-active-thread-019e8b74-fe59-70c1-b2a1-39da9677aaf

Environment:

• Windows 11 Home / Windows NT 10.0.26200 x64
• Codex Windows Store app: OpenAI.Codex 26.601.2237.0
• Codex CLI: 0.136.0
• Git: C:\Program Files\Git\cmd\git.exe, git version 2.51.0.windows.1
• Repo path tested: C:\PRKC\acculynx-mcp
• Stable config:

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true
writable_roots = ["C:\\PRKC"]

[windows]
sandbox = "unelevated"
sandbox_private_desktop = true

What works:

unelevated sandbox works.
Git works in unelevated mode.
Repo is clean and synced: ## main...origin/main.
codex doctor reports 0 fail on CLI 0.136.0.
Git is detected correctly by codex doctor.

Earlier failure before updating/setup repair:

elevated mode failed Git commands with:
CreateProcessAsUserW failed: 5
setup_error.json originally contained:
{
  "code": "helper_unknown_error",
  "message": "read ACL run had errors"
}

After updating to 0.136.0:

Default setup command path failed first with:
orchestrator_helper_launch_failed: failed to launch setup helper (non-elevated): program not found
The helper binary did exist at:
C:\Users\silve\.codex\packages\standalone\releases\0.136.0-x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
Running the direct release binary with helper folders temporarily added to PATH completed elevated setup:
Windows elevated sandbox setup completed for DESKTOP-51UF7HS\silve at C:\Users\silve\.codex.
After that, setup_error.json was gone and no sandbox.log was created.

Current failure after setup completed:

When switching config back to:

[windows]
sandbox = "elevated"
sandbox_private_desktop = true

and running read-only checks in Codex, simple commands such as Get-Location work, but Git commands fail before execution with:

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

Commands that fail:

git status --porcelain=v1 -b
git branch --show-current
git rev-parse HEAD
git rev-parse origin/main

Commands that work:

Get-Location
codex --version

The final narrowed behavior appears to be:

unelevated runtime works.
elevated setup can be completed manually via direct release binary + helper PATH workaround.
elevated runtime still fails when Git commands trigger setup refresh.
This does not appear to be caused by the repo path, Git install, or a bad config parse.
codex doctor reports a healthy install/config/repo/Git state.

Current workaround:

[windows]
sandbox = "unelevated"
sandbox_private_desktop = true

I’m avoiding danger-full-access and using unelevated as the temporary workaround.

Adding a cross-reference to a confirmed Codex Desktop / node_repl / Browser / Chrome recovery case: https://github.com/openai/codex/issues/25419#issuecomment-4639724031

Summary: with [windows] sandbox = "elevated", the AppData codex-windows-sandbox-setup.exe helper failed during setup refresh with os error 740. A per-user AppCompat RUNASINVOKER entry for the exact failing helper path restored node_repl, the in-app Browser, and Chrome extension backend control without switching to unelevated or no-sandbox.

Caveat: this is path-keyed and should be user-approved because it is a persistent per-user compatibility override. If a Codex update changes the helper path/hash, the entry may need to be added for the new path. The linked comment includes a prompt users can give Codex to verify the exact failure and request approval before changing anything.

this is now fixed

@iceweasel-oai I retested after updating to codex-cli 0.139.0.

Correct Windows identity:

whoami: pauls-home-pc\silve
hostname: Pauls-Home-PC
COMPUTERNAME: PAULS-HOME-PC
USERNAME: silve

First, I retried elevated setup with the corrected identity.

Both of these still failed:

codex sandbox setup --codex-home "C:\Users\silve\.codex" --elevated --current-user
codex sandbox setup --codex-home "C:\Users\silve\.codex" --elevated --user "PAULS-HOME-PC\silve"

Both returned:

orchestrator_helper_launch_failed: failed to launch setup helper (non-elevated): program not found

Then I validated runtime elevated sandbox behavior on 0.139.0.

Config used for validation:

[windows]
sandbox = "elevated"
sandbox_private_desktop = true

Read-only checks in C:\PRKC\acculynx-mcp:

Get-Location

worked and returned:

C:\PRKC\acculynx-mcp

But these all failed:

git status --porcelain=v1 -b
git rev-parse --is-inside-work-tree
git rev-parse HEAD
git rev-parse origin/main

with:

windows sandbox: runner error: CreateProcessAsUserW failed: 5

codex --version inside the session returned:

codex-cli 0.139.0

So on my machine, the issue is not fixed in stable 0.139.0.

Current workaround remains:

[windows]
sandbox = "unelevated"
sandbox_private_desktop = true

Question: when you said “this is now fixed,” is the fix expected to be in 0.139.0, the Windows Store app update, or a newer alpha/pre-release build such as 0.140.0-alpha.*?

@roofpropaul
is now fixed in 0.140;
0.140.0-alpha.2

please wait 0.140

@roofpropaul is now fixed in 0.140; 0.140.0-alpha.2 please wait 0.140

Confirmed the fix works for me when launching directly from 0.140.0-alpha.19.

What I did:

• Downloaded codex-package-x86_64-pc-windows-msvc.tar.gz
• Extracted it to:

C:\Users\silve\Downloads\codex-alpha-test\rust-v0.140.0-alpha.19

• Ran elevated setup with:

C:\Users\silve\Downloads\codex-alpha-test\rust-v0.140.0-alpha.19\bin\codex.exe

• Switched config to:

```toml
[windows]
sandbox = "elevated"
sandbox_private_desktop = true

Validation succeeded inside elevated sandbox:

git status --porcelain=v1 -b returned ## main...origin/main
git rev-parse --is-inside-work-tree returned true
git rev-parse HEAD matched origin/main
No windows sandbox: spawn setup refresh
No CreateProcessAsUserW failed: 5
No os error 740

Caveat:

The normal PATH codex --version still resolves to stable 0.139.0.
Calling the alpha directly returned codex-cli 0.140.0-alpha.19.
The alpha codex --version command printed warnings about failing to clean up/create C:\Users\silve\.codex\tmp\arg0 PATH aliases due to access denied, but the command exited successfully and Git worked.

Additional data from a native Windows 11 10.0.26200 x64 machine on standalone Codex CLI 0.144.4:

• codex doctor --json reported overallStatus: ok and sandbox.helpers: ok.
• A real elevated sandbox probe with the normal user TEMP still took 27.1 s and failed with helper_unknown_error: setup refresh had errors.
• Elevated mode with a project-local TEMP succeeded, but took 22.3 s.
• Changing only [windows] sandbox to "unelevated" reduced the same probe to 2.3 s with project-local TEMP and 3.5 s with normal TEMP.
• sandbox_mode remained "workspace-write"; a write outside the workspace was correctly denied (Access denied, about 4.0 s).
• With unelevated mode, internal apply_patch succeeded twice, most recently in 20.599 s and 13.814 s. This is usable compared with the earlier 60–210 s behavior, but still much slower than raw filesystem writes.

This suggests that doctor checking that the sandbox configuration/helpers are readable is not sufficient to detect the elevated setup-refresh failure. A real spawn/write/isolation probe would catch it.

I am going to retest after updating from 0.144.4 to 0.144.5 and will post the post-update measurements separately.

Post-update result for Codex CLI 0.144.5 on the same Windows 11 machine:

Working path ([windows] sandbox = "unelevated"):

• launcher smoke: 0.661 s
• sandbox write/isolation probe: 0.671 s
• apply_patch calls: 13.040 / 12.148 s immediately after update, then 16.159 / 14.220 s in an independent final run
• outside-workspace write: correctly denied

Forced elevated comparison, without changing the global config:

• normal user TEMP: failed after 19.838 s with CreateProcessWithLogonW failed: 2
• project-local TEMP: failed after 2.277 s with the same error

The project-local TEMP case is a regression from 0.144.4 on this machine: it previously allowed elevated mode to start after about 22.3 s. In 0.144.5 both TEMP variants fail in elevated mode.

codex doctor still reports overall OK / installation consistent, so a real elevated spawn probe is still needed to detect this state.

Update-path note: built-in codex update invoked Windows PowerShell and failed because the installer could not resolve Get-FileHash. Running the same official https://chatgpt.com/codex/install.ps1 through MSI PowerShell 7 completed the 0.144.5 installation successfully.

Reproduced again on July 17, 2026 with a current Codex Desktop build:

• Codex Desktop: 26.715.2305.0
• Bundled CLI: codex-cli 0.145.0-alpha.18
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Top-level sandbox mode remained sandbox_mode = "workspace-write"

With:

[windows]
sandbox = "elevated"

the first ordinary workspace read command did not reach PowerShell and had to be terminated after more than 30 seconds. During troubleshooting, six lingering codex-windows-sandbox-setup.exe processes were present (both the packaged WindowsApps helper path and one LocalAppData helper path). The current test created another helper that did not exit automatically.

The sandbox log reached the setup/ACL phase (helper spawned, workspace write ACE applied, read ACL run completed), but never logged setup binary completed. No probe file was created, and the leftover setup helpers had to be terminated manually.

After changing only the Windows implementation to:

[windows]
sandbox = "unelevated"

and restarting Codex Desktop:

• an ordinary sandboxed command completed normally (about 0.8 s);
• a workspace probe file was created, read back correctly, and deleted;
• codex-windows-sandbox-setup.exe process count remained 0;
• danger-full-access was not needed.

This looks like either a regression after the reported 0.140 fix or a separate elevated-helper hang after ACL work finishes. The issue is still reproducible in Desktop/bundled CLI 0.145.0-alpha.18. I can provide a sanitized sandbox-log excerpt and an in-product Feedback ID if useful.

In-product Feedback ID: 019f6df6-f568-7122-8354-a33e5039658a