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

What version of Codex is running?

Codex CLI 0.144.1. The behavior reproduces through both Codex Desktop and Codex CLI because both use the same native Windows sandbox configuration.

Platform

Windows 11 Professional, x64, build 26200.

What issue are you seeing?

On native Windows, the elevated sandbox adds a large delay before every sandboxed shell command starts. The command, filesystem, Git, and PowerShell operations themselves are fast.

Changing only the Windows sandbox implementation from elevated to unelevated removes the command delay, but then apply_patch cannot update workspace files because the managed session includes split writable roots.

This leaves no sandbox mode in which both normal command execution and the preferred patch-editing path work reliably.

Sanitized timing evidence

A trivial local file-read command was measured in the same workspace and session configuration:

A direct sandbox startup comparison showed:

Repeated elevated runs remained slow after warm-up.

codex doctor reported the installation, configuration, authentication, databases, and connectivity as healthy. The slowdown occurred before the requested process performed meaningful work.

Steps to reproduce

1. On Windows, configure:

[windows]
sandbox = "elevated"

2. Restart Codex.
3. Run multiple trivial sandboxed commands, such as:

Write-Output "ok"

4. Compare wall time with the command's internal execution time.
5. Change only the sandbox implementation:

[windows]
sandbox = "unelevated"

6. Restart Codex and repeat the command. It completes immediately.
7. In a managed workspace-write session, try to update an existing file using apply_patch.
8. Observe:

windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed

The writable-root set includes the workspace plus runtime-managed temporary roots; no custom writable roots are required to reproduce the patch failure.

Expected behavior

At least one supported Windows sandbox configuration should allow both:

• ordinary sandboxed shell commands to start without multi-second or multi-tens-of-seconds orchestration delays; and
• apply_patch to create, update, and delete files inside the active workspace.

If elevated sandbox setup or ACL refresh is unhealthy, codex doctor should detect it and provide an actionable repair command.

Actual workaround

Using:

[windows]
sandbox = "unelevated"

restores normal shell-command performance, but it is a weaker sandbox and leaves apply_patch unusable with the managed split-root profile.

No dangerous/full-access mode was used.

Related issues

• Windows elevated sandbox delays every shell_command by ~88 seconds before process creation; unelevated is immediate #31958 — elevated sandbox delays commands before process creation
• Windows elevated sandbox: detached ReadAclsOnly codex-windows-sandbox-setup.exe helpers never exit after completing their work — each busy-spins ~25% of a core and they accumulate per command #32194 — detached elevated-sandbox ACL helpers can accumulate
• Windows Desktop sandbox forces choice between CreateProcessAsUserW 1312 and apply_patch split-root failure #31220 — incompatible shell/apply_patch capabilities between sandbox modes
• Codex desktop app on Windows injects split writable roots, causing apply_patch to fail before patching workspace files, forcing agents to fallback to bypass the sandbox and write files using powershell #30712 — managed split writable roots break apply_patch under unelevated sandbox

This report adds a complete measured reproduction on 0.144.1 across both Desktop and CLI, plus the interaction between the performance workaround and the split-root patch failure.