[Windows][CLI 0.150.1] unelevated sandbox spends ~15.4s in CreateFile on NUL path before every command

Summary

On Windows 11, every command executed through the unelevated Windows sandbox incurs a highly repeatable ~15.6 second delay before the actual command starts.

Microsoft Process Monitor isolates almost the entire delay to a single CreateFile performed by codex.exe against the NUL device path. Procmon reports:

Process:   codex.exe
Operation: CreateFile
Path:      \\NUL\\\
Result:    OBJECT PATH INVALID
Duration:  15.4168792 s

Immediately after this event returns, Codex proceeds to create the pipe / launch cmd.exe, and the command completes normally.

This is not a slow shell, slow project directory, or broken Windows Null driver.

Environment

• Codex CLI: 0.150.1
• Windows: Windows 11 x64, 10.0.26200.9278
• Sandbox configuration:

[windows]
sandbox = "unelevated"

• Reproduces from a local PowerShell session
• No SSH/RDP involved

Minimal reproduction

$start = Get-Date
codex.cmd sandbox "$env:WINDIR\System32\cmd.exe" /c echo TIME_TEST
$end = Get-Date
($end - $start).TotalSeconds

Observed repeatedly:

TIME_TEST
15.6033242

A separate stopwatch run produced ~15.59 s, and running from an empty temp directory produced ~15.58 s.

Controls

Native Windows shell is fast

Measure-Command { cmd.exe /d /c echo ok }

Observed: ~22 ms.

Windows NUL device is healthy

sc.exe query Null
sc.exe qc Null
Test-Path "$env:WINDIR\System32\drivers\null.sys"
Measure-Command { cmd.exe /d /c "echo test > nul" }

Observed:

Null service: RUNNING
null.sys: True
echo test > nul: ~28 ms

Sandbox disabled is fast

A danger-full-access control executes the actual trivial command in ~122 ms.

So the slowdown is specific to the Windows sandbox path.

Process Monitor evidence

Procmon was filtered to the CLI codex.exe process. The dominant event is:

Operation : CreateFile
Path      : \\NUL\\\
Result    : OBJECT PATH INVALID
Duration  : 15.4168792 s

The stack for that event shows the call flowing through:

codex.exe
KernelBase.dll!CreateFileW
KernelBase.dll!GetDriveTypeW
ntdll.dll!ZwCreateFile
ntoskrnl.exe
FLTMGR.SYS

No third-party antivirus/minifilter module appeared in the captured stack for the 15.4 s event.

The trace also showed LanmanWorkstation-related registry activity around the slow path, which may indicate the path is being interpreted through a network/UNC resolution path before failing.

Suspected area

The Windows sandbox source contains allow_null_device() logic that opens the NUL device with CreateFileW() in the ACL setup path. It may be worth checking the exact device-path string passed there and how it is normalized before GetDriveTypeW / CreateFileW.

The key point is that, on this machine, the normal Windows NUL device responds in ~28 ms, while the NUL-related CreateFile issued by Codex takes ~15.4 s and returns OBJECT PATH INVALID.

Impact

This delay is paid repeatedly during agent work. A normal code-review/edit workflow can invoke the sandbox many times, so 20-30 tool calls can add roughly 5-8 minutes of pure waiting before normal model/tool execution time is counted.

The user-visible result is that Codex feels dramatically slower than other local coding agents even though the underlying commands themselves are fast.

Related issue

Possibly related to #38665, which reports a fixed 15,000 ms Windows sandbox delay where danger-full-access works. However, this reproduction is on CLI 0.150.1 with windows.sandbox = "unelevated", and Procmon identifies a specific ~15.4 s CreateFile on the NUL path rather than a spawn_ready timeout.

Additional information

A sanitized Procmon CSV and screenshots of the event properties / stack are available if maintainers want them. No project source, credentials, or private Codex session data are required to reproduce the timing issue.

Start in the Windows sandbox source at the allow_null_device() ACL setup path and reproduce the delay with the provided PowerShell command. Trace the exact device-path string through normalization and CreateFileW/GetDriveTypeW, using the Procmon evidence to compare the slow path with native NUL access. Done means unelevated sandbox commands no longer incur the repeated ~15-second delay.