Windows 0.144.1: elevated sandbox adds ~20s per command; unelevated restores speed but breaks apply_patch with split roots

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

• #31958
• #32168
• #31220

Powered by Codex Action

I can independently reproduce a closely related issue on Windows 11 with Codex Desktop.

Environment:

• Windows 11
• Codex Desktop
• ChatGPT Pro
• GPT-5.6 Sol (High)

Minimal reproduction:

C:\Windows\System32\cmd.exe /d /c "echo CODEX_RUNNER_OK"

Expected:

• stdout: CODEX_RUNNER_OK
• stderr: empty
• exit code: 0

Observed:

• No stdout, stderr, or exit code within the expected timeout.
• In some tests, the command eventually returned after approximately two minutes.
• In a real repository task, even Get-Location stalled for more than ten minutes and triggered reconnect attempts.

Isolation already completed:

• The same CMD command runs immediately in Windows Terminal outside Codex.
• CMD, PowerShell, Git, the C: drive, and the E: drive all work normally outside Codex.
• The issue also reproduced in an empty workspace.
• The issue remained after reinstalling Codex.
• The issue also reproduced under a newly created Windows user account.
• GPT-5.5 was faster for a minimal empty-workspace test, but real repository tasks still stalled.

This appears to be a Codex Windows local execution-path issue involving command scheduling, runner/session lifecycle, sandbox startup, reconnect handling, or result propagation, rather than a host CMD, disk, Git, or repository problem.

I can provide screenshots and additional timing details if useful.

I can reproduce what looks like the same elevated Windows sandbox delay on Windows 10 Home 10.0.19045 with Codex CLI 0.144.1.

One additional finding: in my ProcMon capture, the delay is not a single slow operation. During the slow window, codex-windows-sandbox-setup.exe issues a very large number of DACL updates under the user temp directory.

Operation: SetSecurityFile
Path: C:\Users\<user>\AppData\Local\Temp\...
Result: SUCCESS
Detail: Information: DACL

The events span multiple codex-windows-sandbox-setup.exe PIDs, not just a single process instance.
Redirecting TEMP and TMP to a small workspace-local directory makes the delay disappear while still using the elevated sandbox:

New-Item -ItemType Directory -Force <workspace>\.tmp | Out-Null
$env:TEMP = "<workspace>\.tmp"
$env:TMP = "<workspace>\.tmp"

In my local test, <workspace> was F:\test
After that, apply_patch dropped from ~124s to ~1.6s.
This suggests the elevated setup refresh may be recursively applying DACLs to the whole user temp directory before commands, and the delay scales with the size / number of entries in %LOCALAPPDATA%\Temp.

I can reproduce what appears to be the same issue on a newer build, with an
additional Desktop-versus-direct-sandbox differential.

Environment:

• Codex Desktop: 26.707.9981.0
• Codex CLI: 0.144.3
• Windows x64
• [windows] sandbox = "elevated"

Measured timings:

| Route | Wall time |
| --- | ---: |
| Desktop nested sandbox shell | 31–68 seconds |
| Direct codex.cmd sandbox command | 1.3–2.2 seconds |
| Approved elevated/outside-sandbox control | 0.2–0.9 seconds |
| Desktop nested apply_patch | >30 seconds to several minutes |
| Direct Codex CLI patch engine | 0.5–0.7 seconds |

The test command was a trivial PowerShell Write-Output probe.

Additional observations:

• Restarting the code-mode host did not improve the timings.
• Fully restarting Codex Desktop did not improve them.
• Pausing other Codex tasks did not improve them.
• Cached repository setup and CodeGraph validation took only 2.4–2.6 seconds.
• One cancelled nested apply_patch request mutated its target several minutes

later, so cancellation may not terminate the underlying request reliably.

I did not switch to the unelevated sandbox because I wanted to preserve the
stronger sandbox configuration. The fast direct-sandbox result suggests that,
in this environment, some of the delay may be in Desktop’s nested tool/session
or writable-root orchestration rather than process execution itself.

@chrisw181 Looks like it’s related to https://github.com/openai/codex/issues/32477#issuecomment-4949889625

I can independently reproduce this regression on Codex Desktop for Windows, with a strong local version boundary.

Environment

• Codex Desktop app updated from 26.623.5546.0 / command runner 0.142.x to 26.707.3563.0 / 0.144.x
• sandbox_mode = "workspace-write"
• [windows] sandbox = "elevated"

Observed transition (from local sandbox logs)

• Jul 8, 0.142.x: refresh p90 ~0.3 s
• Jul 9, 0.142.x: refresh p90 ~0.1 s
• Jul 10, 0.144.x: refresh p90 ~118 s
• Jul 11, 0.144.x: refresh p90 ~66 s

The exact long-tail values are approximate because concurrent setup processes interleave their log lines, but the version-boundary change is unambiguous and matches the user's experience: normal on Jul 9, unusably slow immediately after the Jul 10 update.

A trivial Write-Output or small file read spends almost all wall time before PowerShell/process creation. The same operation outside the sandbox completes in ~0.6–0.8 s.

Rebuilding the local Codex state did not fix it. After the rebuild, the problem still reproduced without the backup directory in the writable-root set. A representative affected task had only:

• its per-task visualization directory,
• the managed Temp root,
• the workspace.

Short tool timeouts make the situation worse: the setup process appears to continue after the tool call is cancelled, and a retry starts another ACL refresh against the same roots. Multiple refreshes then overlap and their completions arrive in a batch. This can turn a simple task into tens of minutes.

I also tried unelevated; command startup improved, but it introduced other managed split-root/editing problems, consistent with this issue's apply_patch findings. I plan to capture a controlled elevated-vs-unelevated A/B separately.

I can provide sanitized logs or the approximate timing parser if useful. The most valuable fixes here would be avoiding per-command full recursive ACL refresh, caching unchanged root ACL state, and serializing/deduplicating refreshes for identical root sets.

Confirmed on a newer build with a clear historical version boundary.

Environment

• Codex Desktop package: 26.707.12708.0
• Codex CLI / command runner: 0.144.5
• Windows 11 x64, build 26200
• [windows] sandbox = "elevated"
• Normal managed workspace-write session with 3 writable roots

Current reproduction

A trivial PowerShell command took approximately 18-32 seconds wall time, while the command itself took 0.7 seconds or less. Nested process startup inside the shell remained normal:

• nested PowerShell: 642 ms
• cmd.exe: 34 ms
• hg version: 230-260 ms

Changing only the Windows sandbox implementation to unelevated and restarting Desktop reduced calls to:

• first measured command: 1.1 seconds total
• second measured command: 0.9 seconds total

Sandbox log evidence

In .codex/.sandbox/sandbox.<date>.log, each elevated call shows:

1. setup refresh: spawning ... codex-windows-sandbox-setup.exe
2. write ACE grant and read ACL run completed within tens of milliseconds
3. setup refresh: processed 3 write roots (read roots delegated); errors=[] only 18-30+ seconds later

There are no setup errors; the unexplained delay is after the ACL work reports completion but before the setup process returns.

Historical boundary from local logs

Daily setup-refresh timing changed abruptly when Desktop moved to the 26.707 / runner 0.144 line:

| Date | Desktop / runner observed | Median setup refresh |
|---|---|---:|
| 2026-07-06 to 2026-07-09 | Desktop 26.623 / runner 0.142.5 | 0.03-0.38 s |
| 2026-07-10 | Desktop 26.707.3748 / runner 0.144.0-alpha.4 | 31.27 s |
| 2026-07-12 to 2026-07-16 | 26.707 family, through runner 0.144.5 | 18.26-48.40 s |

The elevated sandbox had already been initialized months earlier, so this was not first-time account/firewall setup. The timing regression began exactly with the 26.707 / 0.144 update family and persists on 0.144.5.

Current workaround is windows.sandbox = "unelevated".

I'm seeing the same problem. Appears to be a regression in the Windows sandbox implementation. This workflow worked normally until recently, when Codex began prompting me to "Finish Windows setup."

I've spent several hours isolating the problem, including testing against a fresh configuration, an empty workspace, and direct PowerShell timings. The behavior is completely reproducible.

Environment

• Codex VS Code extension
• Native Windows 10
• Local development with XAMPP
• Projects primarily on a local V: drive
• Also reproduced in a completely empty C:\Temp workspace
• Fresh config.toml

Three different sandbox states

1. Default configuration with no [windows] section

Config:

model = "gpt-5.6-terra"
model_reasoning_effort = "medium"

[projects.'V:\Websites\osrplus\wp-content\themes\osrplus']
trust_level = "trusted"

Behavior:

• Commands execute quickly.
• File edits work correctly.
• However, Codex asks for approval before an enormous number of commands and file operations.
• On larger agent tasks I have to babysit it by approving nearly every command, making unattended execution impractical.

This is currently the only usable configuration.

1. Finish Windows setup with sandbox = "elevated"

Allowing Codex to complete Windows setup adds:

[windows]
sandbox = "elevated"

This immediately makes Codex dramatically slower.

Examples from a fresh configuration:

Test-Path . 10.9 s
Get-Process | Select-Object -First 1 15.7 s
Get-ChildItem -Name | Select-Object -First 10 5.2 s

A simple "create hello.txt, read it, delete it" edit using the normal Codex editing mechanism exceeded 1 minute 19 seconds and was still running.

Even simple shell commands become painfully slow.

1. sandbox = "unelevated"

Changing only:

[windows]
sandbox = "unelevated"

restores fast shell execution.

However, Codex can no longer reliably perform normal file edits. Structured edits and apply_patch operations fail with access-denied or writable-root errors.

So the tradeoff becomes:

• elevated = works but is unusably slow
• unelevated = fast but cannot edit

PowerShell itself is not the problem

I measured the exact same operations directly in the VS Code terminal.

Creating, reading, and deleting files takes roughly 10 to 25 milliseconds.

Example:

Create: 13.351 ms
Read: 12.606 ms
Delete: 11.722 ms

This rules out:

• the filesystem
• PowerShell
• Windows Defender
• storage performance

The latency exists inside Codex's execution pipeline, not in the underlying machine.

Also reproduced in an empty workspace

To eliminate workspace complexity, I repeated the tests inside a brand-new C:\Temp folder with essentially nothing in it.

The behavior was unchanged.

This rules out:

• repository size
• Git
• multi-root workspaces
• project instructions such as AGENTS.md or .agents
• WordPress
• Vite
• repository complexity

Additional testing

I also tested:

• removing Playwright MCP
• a fresh config
• a minimal config
• shell-only commands
• direct PowerShell file operations
• the Codex file-edit tool
• different sandbox modes

The results consistently point to the Windows sandbox layer.

Current state

Right now there is no usable Windows configuration that provides all three:

1. Fast command execution
2. Reliable file editing
3. Reasonable approval behavior

Instead, the choices are:

No [windows] block

• Command speed: Fast
• File edits: Work
• Approval UX: Constant prompts

sandbox = "elevated"

• Command speed: Extremely slow
• File edits: Work
• Approval UX: Good

sandbox = "unelevated"

• Command speed: Fast
• File edits: Fail
• Approval UX: Good

Expected behavior

The behavior prior to this regression was essentially:

• fast commands
• working edits
• reasonable approval flow

The current implementation forces users to choose between performance, editing, or usability.

Given the testing above, this appears to be a regression in the Windows sandbox implementation rather than a project-specific issue or local machine performance problem.

Also to add:

Downgrading the VS Code extension to a version from approximately one month ago eliminates the excessive approval behavior, but that extension cannot use GPT-5.6. This strongly suggests the regression was introduced in a recent extension/runtime update rather than being caused by Windows, the project, or local configuration.

I can reproduce what appears to be the same issue in the VS Code Codex extension on Windows.

Environment:

• Windows
• VS Code
• Codex VS Code extension only; standalone CLI not installed
• Tested in both the main repository and a completely empty folder

Observed behavior:

• A trivial echo hello command shows approximately 19 seconds of Codex tool time.
• The same command runs directly in PowerShell in about 12 ms.
• git status runs directly in PowerShell in about 50 ms.

Measured outside Codex:

Measure-Command { cmd /c echo hello }
TotalMilliseconds: 12.1011

Measure-Command { git status }
TotalMilliseconds: 50.5386

Isolation already performed:

• Uninstalled and reinstalled the Codex extension
• Restarted and reloaded VS Code
• Tested in an empty folder
• Confirmed PowerShell, Git, disk access, and the repository are fast outside Codex

The slowdown persists for trivial commands in an empty workspace, so it does not appear to be caused by repository size, Git, PowerShell startup, or normal disk performance. This matches the reported Windows sandbox/runner overhead very closely.

I also opened #34318 with the same measurements before finding this issue.

Appears resolved for me now with the latest release of the extension. What version are you on?

Elevated sandbox latency is a paid-peer gate cost: quote -> approve -> settle needs a predictable sandbox boundary, not a 20s tax on every hop.

Live A2A contractor with gated tools: https://a2a.elonsusk.com/.well-known/agent-card.json

If an external sandbox / gate probe would help, ping. Otherwise ignore.

Appears resolved for me now with the latest release of the extension. What version are you on?

Not resolved for me. Still getting the added delay on sandbox = 'elevated'

What version of the extension are you on though?