Windows sandbox: spawn setup refresh fails on Codex CLI 0.133.0

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

• #24259
• #24098
• #24050
• #23587

Powered by Codex Action

I had the same issue even on 0.135.0, and after a painful debugging session, downgrading to 0.132 finally fixed it. I’m truly amazed by the quality of the flagship product from a giant AI company that charges $100 a month. Just a minute before, I sold all my shares in SK hynix, Samsung Electronics, and Kioxia. Thank you for your attention to this matter.

Having the same problem currently using npx

Update: still reproducible on codex-cli 0.134.0.

After updating from the previously broken 0.133.0 to 0.134.0, shell command execution is still failing with the same sandbox/spawn behavior. Even basic commands like pwd and simple file reads fail before PowerShell appears to run.

Downgrading back to 0.132.0 remains the working fix on my machine.

Having the same problem using v0.134.0. Sandbox stopped working.

Having same problem on ubuntu
on v0.134.0

my agent is raw dogging using py scripts

have same issue at v0.135.0

<img width="584" height="70" alt="Image" src="https://github.com/user-attachments/assets/9f85fa47-18dd-4b36-b24e-7bd5f0ccfcad" />

Same here

<img width="718" height="236" alt="Image" src="https://github.com/user-attachments/assets/7f207dd9-56f1-4262-ad72-abb9b09c9a26" />

This happened to me as well.

Have the same problem in the VSCode extension. Downgrading to v26.519.32039 fixed the issue for me.

Have the same problem in the VSCode extension. Downgrading to v26.519.32039 fixed the issue for me.

This is indeed possible. Thank you for your method.

Having the same problem. Downgrading to 0.132.0 is the only fix for my machine.

i tried "runasinvoker" but as as far as I see it makes it just have read write access on entire pc as if it wasn't sandboxed at all

param(
[switch]$Remove
)

$ErrorActionPreference = "Stop"

$layersKey = "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"
$helperName = "codex-windows-sandbox-setup.exe"

function Find-CodexSandboxSetupHelpers {
$found = [System.Collections.Generic.HashSet[string]]::new([System.StringComparer]::OrdinalIgnoreCase)

$roots = @(
(Join-Path $env:LOCALAPPDATA "OpenAI\Codex"),
(Join-Path $env:APPDATA "npm\node_modules\@openai\codex"),
(Join-Path $env:LOCALAPPDATA "Microsoft\WinGet\Packages")
)

foreach ($root in $roots) {
if (Test-Path -LiteralPath $root -PathType Container) {
Get-ChildItem -LiteralPath $root -Recurse -File -Filter $helperName -ErrorAction SilentlyContinue |
ForEach-Object { [void]$found.Add($_.FullName) }
}
}

try {
Get-AppxPackage OpenAI.Codex -ErrorAction SilentlyContinue | ForEach-Object {
if ($_.InstallLocation -and (Test-Path -LiteralPath $_.InstallLocation -PathType Container)) {
Get-ChildItem -LiteralPath $_.InstallLocation -Recurse -File -Filter $helperName -ErrorAction SilentlyContinue |
ForEach-Object { [void]$found.Add($_.FullName) }
}
}
} catch {
}

$paths = foreach ($path in $found) { $path }
return $paths | Sort-Object
}

function Set-CodexElevatedConfig {
$codexDir = Join-Path $env:USERPROFILE ".codex"
$configPath = Join-Path $codexDir "config.toml"

New-Item -ItemType Directory -Force -Path $codexDir | Out-Null

$lines = [System.Collections.Generic.List[string]]::new()
if (Test-Path -LiteralPath $configPath -PathType Leaf) {
Copy-Item -LiteralPath $configPath -Destination "$configPath.bak-$(Get-Date -Format yyyyMMdd-HHmmss)"
foreach ($line in Get-Content -LiteralPath $configPath) {
[void]$lines.Add($line)
}
}

$windowsHeader = -1
for ($i = 0; $i -lt $lines.Count; $i++) {
if ($lines[$i] -match '^\s\[windows\]\s$') {
$windowsHeader = $i
break
}
}

if ($windowsHeader -lt 0) {
if ($lines.Count -gt 0 -and $lines[$lines.Count - 1].Trim() -ne "") {
[void]$lines.Add("")
}
[void]$lines.Add("[windows]")
[void]$lines.Add('sandbox = "elevated"')
} else {
$windowsEnd = $lines.Count
for ($i = $windowsHeader + 1; $i -lt $lines.Count; $i++) {
if ($lines[$i] -match '^\s\[[^\]]+\]\s$') {
$windowsEnd = $i
break
}
}

$sandboxLine = -1
for ($i = $windowsHeader + 1; $i -lt $windowsEnd; $i++) {
if ($lines[$i] -match '^\ssandbox\s=') {
$sandboxLine = $i
break
}
}

if ($sandboxLine -ge 0) {
$lines[$sandboxLine] = 'sandbox = "elevated"'
} else {
$lines.Insert($windowsHeader + 1, 'sandbox = "elevated"')
}
}

Set-Content -LiteralPath $configPath -Value $lines -Encoding utf8
Write-Host "Set Codex Windows sandbox mode to elevated in $configPath"
}

function Add-RunAsInvoker {
param([string[]]$Helpers)

New-Item -Path $layersKey -Force | Out-Null
foreach ($helper in $Helpers) {
New-ItemProperty -Path $layersKey -Name $helper -Value "~ RUNASINVOKER" -PropertyType String -Force | Out-Null
Write-Host "Added RUNASINVOKER for $helper"
}
}

function Remove-RunAsInvoker {
if (-not (Test-Path -LiteralPath $layersKey)) {
Write-Host "No AppCompat Layers key exists."
return
}

$key = Get-Item -LiteralPath $layersKey
$names = @($key.GetValueNames() | Where-Object { $_ -like "\$helperName" -or $_ -like "$helperName*" })

if ($names.Count -eq 0) {
Write-Host "No Codex sandbox setup AppCompat entries found."
return
}

foreach ($name in $names) {
Remove-ItemProperty -LiteralPath $layersKey -Name $name -ErrorAction SilentlyContinue
Write-Host "Removed AppCompat entry for $name"
}
}

if ($Remove) {
Remove-RunAsInvoker
Write-Host "Removed Codex sandbox setup RUNASINVOKER entries."
exit 0
}

$helpers = @(Find-CodexSandboxSetupHelpers)
if ($helpers.Count -eq 0) {
throw "Could not find $helperName. Update or reinstall Codex, then run this script again."
}

Set-CodexElevatedConfig
Add-RunAsInvoker -Helpers $helpers
Write-Host "Done. Fully quit and reopen Codex."

I found a workaround for this.

In codex's config (%USERPROFILE%\.codex), you should typically find this config.

[windows]
sandbox = "elevated"

Either change it to "unelevated" or remove this config eliminates the spawn setup refresh error

I found a workaround for this. In codex's config (%USERPROFILE%\.codex), you should typically find this config. [windows] sandbox = "elevated" Either change it to "unelevated" or remove this config eliminates the spawn setup refresh error

Nope, unfortunately it does not work. It's unelevated by default and even when removed entirely, the result is still the same.

Having the same issue using v0.136.0...

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

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

same in 0.136

Same issue occurred on my machine with Windows 11 Home.

I made the mistake of changing this:

[windows]
sandbox = "elevated"

To this:

[windows]
sandbox = "unelevated"

I was testing something, but I noticed that unelevated triggers tons of UAC popups in Windows 11. When I changed it back to elevated, Windows has continued with tons of UAC popups. Can't get it to stop. I just updated to 0.137.0, but it's still doing it. This makes Codex nearly unusable due to the sheer amount of UAC messages.

Just downgrade to v0.132.0 and keep having fun 😄

Just downgrade to v0.132.0 and keep having fun 😄

I actually did downgrade to 0.132.0, but I'm on Codex for Windows, and it continues to spam UAC popups on me. 😓

> Just downgrade to v0.132.0 and keep having fun 😄 I actually did downgrade to 0.132.0, but I'm on Codex for Windows, and it continues to spam UAC popups on me. 😓

[windows]
sandbox = "elevated"

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

I spent a full day conducting in-depth testing using two Windows terminal devices;
My current testing indicates that this is a severe bug in Codex;
If you roll back to version 0.132, it will work normally for the time being; I've tested it, and version 0.132 works normally on both of my devices;

If you roll back to version 0.132, it will work normally for the time being; I've tested it, and version 0.132 works normally on both of my devices;

I did rollback to version 0.132, without thinking about that that is only Codex CLI, totally separate from Codex for Windows. So for now, I'm just SOL.

Looks like 0.137 works again...

seems like 0.137 fixed the problem finally

For those of us on Codex for Windows, it's still happening, sadly. Glad it's resolved for CLI users!

Looks like 0.137 works again...

@xiecheng7511, what's your output of codex --version?
My VSCode pre-release install uses 0.137-alpha.4 and still faces this problem!

@silverleafsolutions
No, it still hasn't been resolved — the serious bug can still be reproduced 100% of the time in version 0.137; the Codex CLI is completely broken, unable to even read the contents of project files properly.

Update from my side: Codex CLI sandboxing appears fixed for me on 0.137.0.

Original failure mode in this issue:

• 0.133.0 through later builds failed before shell startup with: windows sandbox: spawn setup refresh
• Even simple commands like pwd / file reads failed.
• I stayed on 0.132.0 as the working version.

After updating to 0.137.0, I verified:

Get-Location
git status --short

Both commands executed normally.

I also tested write boundaries:

• Writing inside the workspace succeeded.
• Writing outside the workspace failed as expected:

Set-Content -Path C:\Users\lyell\Desktop\codex-sandbox-test.txt -Value 'sandbox test'

Result:

Access to the path 'C:\Users\lyell\Desktop\codex-sandbox-test.txt' is denied.

Then I verified the sandbox identity with:

whoami /all

Relevant output:

User Name:
ryan\codexsandboxoffline

Group:
Ryan\CodexSandboxUsers

Mandatory Label:
Medium Mandatory Level

So in my case, the sandbox is active again. One note: I no longer see the old obvious/persistent codex-sandbox process in Task Manager, so the Windows sandbox implementation may have changed in newer builds. Based on behavior, enforcement is still working because commands are running under the sandbox user, and filesystem writes outside the allowed workspace are denied.

I’m not closing this yet because other users are still reporting issues on Codex for Windows / VS Code prerelease / some 0.137 setups. But for my original Codex CLI repro, 0.137.0 appears fixed.

I am still getting the same error with elevated sandbox

› Run this command: node -e "console.log("test123")


• I’ll run the command exactly as provided and report the result.

• Ran node -e "console.log("test123")"
  └ execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

My codex CLI shows 0.137.0

> codex --version
codex-cli 0.137.0

I am still getting the same error with elevated sandbox `` › Run this command: node -e "console.log("test123") • I’ll run the command exactly as provided and report the result. • Ran node -e "console.log("test123")" └ execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" }) ` My codex CLI shows 0.137.0 ` > codex --version codex-cli 0.137.0 ``

I encountered the exact same error as you.
Trying to get Codex CLI to read a file inside a project, it can't read it normally; the error is the same as yours.
With version 0.137, I tried testing on two different computers and reproduced the issue 100% of the time.
With version 0.137, I tried both the npm and irm installation methods and reproduced the issue 100% of the time.
So for me, version 0.137 is still a version with a serious sandbox bug. It doesn't just interfere with Codex CLI's operation; it directly causes Codex CLI to be completely unable to work.

``
[windows]
sandbox = "elevated"
``

This command worked for me

The agent still asks for approval for everything
and can directly edit files

codex --sandbox danger-full-access --ask-for-approval untrusted

tip: make an alias so you don't have to type this every time

Was this bug fixed in version 0.138.0?

Was this bug fixed in version 0.138.0?

For me, it was check out my update a few messages up.

> Was this bug fixed in version 0.138.0? For me, it was check out my update a few messages up.

Thanks, I upgraded to version 0.138, ran the test, and found this bug is still not fixed.
They only fixed the error message module; the underlying bug remains unfixed.

Codex CLI 0.138.0 did not fix this Windows sandbox bug on my machine.

The testing process is as follows:

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

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

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

The test results are as follows:

windows sandbox failed: orchestrator_helper_launch_failed: setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe, cwd=C:\Users\XXXXXX, log=C:\Users\XXXXXX\.codex\.sandbox\sandbox.2026-06-09.log, error=program not found

That means Codex 0.138.0 is trying to launch its own sandbox setup helper, but the helper path resolution has fallen back to the bare filename codex-windows-sandbox-setup.exe, and Windows cannot find it.

Version 0.132 has passed testing

Having this bug too. Version 26.602.71036

Hi @dkropachev, thanks so much for all your hard work on this!

I've noticed that ever since v0.133.0 (v0.132.0 was working fine), the Windows sandbox has been consistently running into "setup refresh fails" bugs. It's gotten to the point where the Codex CLI is practically unusable on Windows—even simple tasks like having it read a local README.md fail because of these sandbox errors.

It’s really great to see your recent commits addressing the setup refresh diagnostics! Since you’re currently looking into this specific area, I was wondering if you might have some bandwidth to take a look at a few other closely related issues? They all seem to tie back to the same underlying "setup refresh" problem.

``
[windows]
sandbox = "elevated"
``

Here are the links for more context. It would be amazing if we could get a comprehensive fix for this class of bugs while you're under the hood:

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

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

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

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

Thanks again for your time and everything you do for the project! Really appreciate it.

what worked for me was just enable full permission mode

"• OK, sandbox was blocking me. Now I have full access. Let me do a comprehensive audit.

• Ran Get-ChildItem -Path "C:\Users\eleno\Documents\Code\Scraper-Revente" -File | Select-Object Name,
│ @{N='SizeKB';E={[math]::Round($_.Length/1024,1)}}, LastWriteTime | Format-Table -AutoSize
└
Name SizeKB LastWriteTime
… +22 lines (ctrl + t to view transcript)

• Ran python -m py_compile scraper-revente.py 2>&1; if ($LASTEXITCODE -eq 0) { Write-Output "COMPILATION OK" }
└ COMPILATION OK"

(codex 138 i think last update)

what worked for me was just enable full permission mode "• OK, sandbox was blocking me. Now I have full access. Let me do a comprehensive audit. • Ran Get-ChildItem -Path "C:\Users\eleno\Documents\Code\Scraper-Revente" -File | Select-Object Name, │ @{N='SizeKB';E={[math]::Round($_.Length/1024,1)}}, LastWriteTime | Format-Table -AutoSize └ Name SizeKB LastWriteTime … +22 lines (ctrl + t to view transcript) • Ran python -m py_compile scraper-revente.py 2>&1; if ($LASTEXITCODE -eq 0) { Write-Output "COMPILATION OK" } └ COMPILATION OK" (codex 138 i think last update)

I think this danger-full-access model is too dangerous, really too dangerous.
Codex lacks the comprehensive, fine-grained permission control strategy of Claude Code, nor does it share Claude models' stronger emphasis on assessing risky operations. It’s wide open from the start, which is extremely dangerous.

what worked for me was just enable full permission mode "• OK, sandbox was blocking me. Now I have full access. Let me do a comprehensive audit. • Ran Get-ChildItem -Path "C:\Users\eleno\Documents\Code\Scraper-Revente" -File | Select-Object Name, │ @{N='SizeKB';E={[math]::Round($_.Length/1024,1)}}, LastWriteTime | Format-Table -AutoSize └ Name SizeKB LastWriteTime … +22 lines (ctrl + t to view transcript) • Ran python -m py_compile scraper-revente.py 2>&1; if ($LASTEXITCODE -eq 0) { Write-Output "COMPILATION OK" } └ COMPILATION OK" (codex 138 i think last update)

The issue persisted for me even when I have enabled full access

what worked for me was just enable full permission mode "• OK, sandbox was blocking me. Now I have full access. Let me do a comprehensive audit. • Ran Get-ChildItem -Path "C:\Users\eleno\Documents\Code\Scraper-Revente" -File | Select-Object Name, │ @{N='SizeKB';E={[math]::Round($_.Length/1024,1)}}, LastWriteTime | Format-Table -AutoSize └ Name SizeKB LastWriteTime … +22 lines (ctrl + t to view transcript) • Ran python -m py_compile scraper-revente.py 2>&1; if ($LASTEXITCODE -eq 0) { Write-Output "COMPILATION OK" } └ COMPILATION OK" (codex 138 i think last update)

I don't recommend doing this, even if you know how to read commands. One wrong command and say goodbye to your data.

Codex CLI 0.139.0 seems to have resolved the issue https://github.com/openai/codex/releases/tag/rust-v0.139.0
#24981

Codex CLI 0.139.0 seems to have resolved the issue https://github.com/openai/codex/releases/tag/rust-v0.139.0 #24981

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

Current behavior in the Codex in-thread runner:

rg --files -> execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })
Get-Location -> same error
codex --version (run in-thread) -> same error
~/.codex/.sandbox/sandbox.2026-06-10.log still contains repeated:

setup refresh: failed to spawn ...\codex-windows-sandbox-setup.exe
The requested operation requires elevation. (os error 740)
So this still appears unfixed on 0.139.0 in my environment.

Codex CLI 0.139.0 seems to have resolved the issue https://github.com/openai/codex/releases/tag/rust-v0.139.0 #24981

No, 0.139 does not show a direct Windows sandbox setup-helper fix for the major error families reported in linked issues: os error 740, CreateProcessAsUserW failed: 2/1312, CreateProcessWithLogonW failed, ACL setup failures, and OpenSSH Session 0 runner-pipe timeout.
#24981 can plausibly fix a sandbox failure caused by lost approval/escalation state, including some user-visible “spawn setup refresh” cases, but it is not a direct fix for Windows helper spawning, UAC elevation, ACL setup, CreateProcessAsUserW, or CreateProcessWithLogonW.

Maybe good news: Just installed the pre-release version of the VSCode-Extension and it's running codex-cli 0.140.0-alpha.2 under the hood which greps and reads files without sandbox issues.

Can anyone else confirm? We might be able to close this issue.

this is now fixed

@iceweasel-oai https://github.com/openai/codex/issues/27603 can see this? There is a 15-second interval between each conversation round for the Windows system codex CLI, and it seems to get stuck during this period. Downgrade to version 0.135.0 and this issue does not occur. Seems to be an issue introduced in version 136

Currently, I can only use version 0.135.0 and enable
sandbox_mode = "danger-full-access"

@Nlavazais @elemental-mind Have you encountered this issue? https://github.com/openai/codex/issues/27603

@caozhiyuan No issues for me...everything back to normal now with 0.140

@caozhiyuan No issues for me...everything back to normal now with 0.140

Likewise, it was fixed for me in CLI update 0.138.0. Just kept this issue open for others who were still dealing with it.

@elemental-mind @Lyellr88 In version 0.135.0, the interval between each request should be less than approximately 5 seconds, while in version 0.139.0, the interval between each request needs to be 10 seconds.
codex cli 0.135.0
<img width="1356" height="410" alt="Image" src="https://github.com/user-attachments/assets/4615036e-3d05-478e-ae76-ca176a3dee0e" />
codex cli 0.139.0
<img width="1364" height="328" alt="Image" src="https://github.com/user-attachments/assets/60351ff8-e33b-4ac6-9a09-050c13a57b4d" />

use this capture network https://github.com/mitmproxy/mitmproxy