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

What version of Codex CLI is running?

codex -- version 0.133.0

What subscription do you have?

ChatGPT Plus account using Codex CLI

Which model were you using?

gpt-5.4

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

Windows PowerShell launched from taskbar shortcut. No terminal multiplexer in use.

Codex doctor report

{
  "schemaVersion": 1,
  "generatedAt": "1779466710s since unix epoch",
  "overallStatus": "ok",
  "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>",
        "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, workspace_dependencies",
        "feature flag overrides": "none",
        "feature flags enabled": "27",
        "log dir": "C:\\Users\\<USERNAME>\\.codex\\log",
        "mcp servers": "0",
        "model": "gpt-5.4",
        "model provider": "openai",
        "sqlite home": "C:\\Users\\<USERNAME>\\.codex"
      },
      "remediation": null,
      "durationMs": 0
    },
    "installation": {
      "id": "installation",
      "category": "install",
      "status": "ok",
      "summary": "installation looks consistent",
      "details": {
        "PATH codex #1": "C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\codex",
        "PATH codex #2": "C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\codex.cmd",
        "PATH codex entries": "2",
        "current executable": "C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin\\codex.exe",
        "install context": "npm (package C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc, bin C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin, resources C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-resources, path C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\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:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex",
        "npm update target": "C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex"
      },
      "remediation": null,
      "durationMs": 196
    },
    "mcp.config": {
      "id": "mcp.config",
      "category": "mcp",
      "status": "ok",
      "summary": "no MCP servers configured",
      "details": {},
      "remediation": null,
      "durationMs": 0
    },
    "network.env": {
      "id": "network.env",
      "category": "network",
      "status": "ok",
      "summary": "network-related environment looks readable",
      "details": {
        "proxy env vars": "none"
      },
      "remediation": null,
      "durationMs": 0
    },
    "network.provider_reachability": {
      "id": "network.provider_reachability",
      "category": "reachability",
      "status": "ok",
      "summary": "active provider endpoints are reachable over HTTP",
      "details": {
        "ChatGPT base URL": "https://chatgpt.com/backend-api/ reachable (HTTP 403)",
        "reachability mode": "ChatGPT auth"
      },
      "remediation": null,
      "durationMs": 107
    },
    "network.websocket_reachability": {
      "id": "network.websocket_reachability",
      "category": "websocket",
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded",
      "details": {
        "DNS": "2 IPv4, 2 IPv6, first IPv6",
        "auth mode": "chatgpt",
        "connect timeout": "15000 ms",
        "endpoint": "wss://chatgpt.com/backend-api/<redacted>",
        "handshake result": "HTTP 101 Switching Protocols",
        "model provider": "openai",
        "models etag present": "true",
        "provider name": "OpenAI",
        "proxy env vars": "none",
        "reasoning header": "false",
        "server model present": "false",
        "supports websockets": "true",
        "wire API": "responses"
      },
      "remediation": null,
      "durationMs": 914
    },
    "runtime.provenance": {
      "id": "runtime.provenance",
      "category": "runtime",
      "status": "ok",
      "summary": "running npm on windows-x86_64",
      "details": {
        "commit": "unknown",
        "current executable": "C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin\\codex.exe",
        "install method": "npm (package C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc, bin C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin, resources C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-resources, path C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-path)",
        "platform": "windows-x86_64",
        "version": "0.133.0"
      },
      "remediation": null,
      "durationMs": 0
    },
    "runtime.search": {
      "id": "runtime.search",
      "category": "search",
      "status": "ok",
      "summary": "search is OK (bundled)",
      "details": {
        "search command": "C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-path\\rg.exe",
        "search command readiness": "file exists",
        "search provider": "bundled"
      },
      "remediation": null,
      "durationMs": 0
    },
    "sandbox.helpers": {
      "id": "sandbox.helpers",
      "category": "sandbox",
      "status": "ok",
      "summary": "sandbox configuration is readable",
      "details": {
        "approval policy": "OnRequest",
        "codex-linux-sandbox helper": "none",
        "execve wrapper helper": "none",
        "filesystem sandbox": "restricted",
        "network sandbox": "restricted"
      },
      "remediation": null,
      "durationMs": 0
    },
    "state.paths": {
      "id": "state.paths",
      "category": "state",
      "status": "ok",
      "summary": "state paths and databases are inspectable",
      "details": {
        "CODEX_HOME": "C:\\Users\\<USERNAME>\\.codex (dir)",
        "active rollout files": "305 files, 43287081 total bytes, 141924 average bytes",
        "archived rollout files": "0 files, 0 total bytes, 0 average bytes",
        "goals DB": "C:\\Users\\<USERNAME>\\.codex\\goals_1.sqlite (file)",
        "goals DB integrity": "ok",
        "log DB": "C:\\Users\\<USERNAME>\\.codex\\logs_2.sqlite (file)",
        "log DB integrity": "ok",
        "log dir": "C:\\Users\\<USERNAME>\\.codex\\log (dir)",
        "sqlite home": "C:\\Users\\<USERNAME>\\.codex (dir)",
        "state DB": "C:\\Users\\<USERNAME>\\.codex\\state_5.sqlite (file)",
        "state DB integrity": "ok"
      },
      "remediation": null,
      "durationMs": 5751
    },
    "terminal.env": {
      "id": "terminal.env",
      "category": "terminal",
      "status": "ok",
      "summary": "terminal metadata was detected",
      "details": {
        "color output": "enabled",
        "stderr is terminal": "true",
        "stdin is terminal": "true",
        "stdout is terminal": "true",
        "terminal": "unknown",
        "terminal size": "120x30"
      },
      "remediation": null,
      "durationMs": 0
    },
    "updates.status": {
      "id": "updates.status",
      "category": "updates",
      "status": "ok",
      "summary": "update configuration is locally consistent",
      "details": {
        "cached latest version": "0.133.0",
        "check for update on startup": "true",
        "last checked at": "2026-05-22T01:37:07.004640500Z",
        "latest version": "0.133.0",
        "latest version status": "current version is not older",
        "npm update target": "C:\\Users\\<USERNAME>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex",
        "update action": "npm install -g @openai/codex",
        "version cache": "C:\\Users\\<USERNAME>\\.codex\\version.json"
      },
      "remediation": null,
      "durationMs": 765
    }
  }
}

What issue are you seeing?

After accepting a Codex CLI update, the Windows elevated sandbox consistently fails before executing even a basic command.

The failure is:

windows sandbox failed: spawn setup refresh

This happens with Codex CLI 0.133.0 on Windows when running the elevated Windows sandbox. The same command using the unelevated Windows sandbox succeeds.

Codex doctor reports overallStatus: ok, including sandbox.helpers: ok and updates.status: current/latest version 0.133.0, so the installation and configuration appear healthy, but the elevated sandbox runtime path still fails.

This appears specific to elevated Windows sandbox execution, not the project workspace, because I reproduced it from a clean scratch directory outside my project.

What steps can reproduce the bug?

Open Windows PowerShell.
Create and enter a clean scratch directory outside any project workspace:

New-Item -ItemType Directory -Force D:\Codex_Sandbox_Diag | Out-Null
Set-Location D:\Codex_Sandbox_Diag
Get-Location

Confirm Codex is installed and check versions:

where.exe codex
codex --version
npm view @openai/codex version

Observed output:

C:\Users<USERNAME>\AppData\Roaming\npm\codex
C:\Users<USERNAME>\AppData\Roaming\npm\codex.cmd

codex-cli 0.133.0

0.133.0

Run a basic command through the elevated Windows sandbox:

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

Observed output:

windows sandbox failed: spawn setup refresh

Run the same basic command through the unelevated Windows sandbox:

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

Observed output:

CODEX_UNELEVATED_SANDBOX_TEST_OK

Optional sanity check: run Codex doctor:

codex doctor --json

Observed summary:

overallStatus: ok
codexVersion: 0.133.0
sandbox.helpers: ok
updates.status: latest version 0.133.0 / current version is not older

Result:
The elevated Windows sandbox fails before executing the command, while the unelevated Windows sandbox succeeds from the same clean scratch directory.

What is the expected behavior?

The elevated Windows sandbox should successfully execute the basic command and print:

CODEX_ELEVATED_SANDBOX_TEST_OK

Because the same command works in unelevated mode, I would expect elevated mode to either:

run the command successfully, or
return a clear actionable setup/configuration error explaining what Windows setting or permission needs to be repaired.

Instead, elevated mode fails before the command executes with:

windows sandbox failed: spawn setup refresh

Expected elevated command:

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

Expected output:

CODEX_ELEVATED_SANDBOX_TEST_OK

Additional information

Additional notes:

This began after I accepted a Codex CLI update. I do not know whether the update caused the issue, but the timing is why I am reporting it as a possible regression.

The issue persists today with Codex CLI 0.133.0, which appears to be the latest available npm version.

Codex doctor reports overallStatus: ok. Relevant doctor checks include:

codexVersion: 0.133.0
config.load: ok
installation: ok
auth.credentials: ok
sandbox.helpers: ok
updates.status: ok / latest version 0.133.0 / current version is not older

The failure appears specific to elevated Windows sandbox execution:

Elevated sandbox fails in both my project workspace and a clean scratch directory.
Unelevated sandbox succeeds in both my project workspace and a clean scratch directory.
PowerShell and cmd both failed under elevated sandbox during earlier troubleshooting.
This does not appear to be caused by the project repo path.

Current workaround:
codex -c windows.sandbox="unelevated" --sandbox workspace-write --ask-for-approval untrusted

I have not used dangerous/no-sandbox mode.
I have not changed global Codex config.
I am avoiding broad changes and only using the unelevated workaround temporarily for narrow, explicitly authorized tasks.

Platform:
Microsoft Windows NT 10.0.26200.0 x64

Terminal:
Windows PowerShell launched from taskbar shortcut.
No terminal multiplexer in use.

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

Windows sandbox setup helper triggers UAC installer detection (os error 740) #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 Windows sandbox setup helper triggers UAC installer detection (os error 740) #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.

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:

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.
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.

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: #25419 (comment)

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

@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

@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:

[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

fix(daemon): fail closed on undecidable Windows sandbox config, honor…

fix(daemon): run Codex unsandboxed on Windows to stop reject-by-polic…

chore(upstream): backport Codex Windows fail-closed + desktop tab ide…

fix(daemon): run Codex unsandboxed on Windows to stop reject-by-polic…

Navigation Menu

Repository navigation

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

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on May 22, 2026

tungdd2710 commented on May 22, 2026

JoeGideon1979 commented on May 22, 2026

cemremengu commented on May 22, 2026

NemuKei commented on May 27, 2026

jrf1001 commented on May 27, 2026

NemuKei commented on May 27, 2026

geonusp commented on May 27, 2026

Keesan12 commented on May 28, 2026

geonusp commented on May 28, 2026

uyoufu commented on May 28, 2026

2 remaining items

xiucaicoder commented on Jun 3, 2026

roofpropaul commented on Jun 3, 2026

ryancom16 commented on Jun 6, 2026

iceweasel-oai commented on Jun 12, 2026

roofpropaul commented on Jun 13, 2026

BaseBlank commented on Jun 13, 2026

roofpropaul commented on Jun 15, 2026

michalbieniek-arch commented on Jul 16, 2026

michalbieniek-arch commented on Jul 16, 2026

buyeXX commented on Jul 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions