Windows sandbox spawn fails with SetTokenInformation(TokenDefaultDacl) error 1344 when workdir is the home directory (and 1920 via per-user WindowsApps pwsh)

Start at the Windows sandbox SpawnChild path that calls SetTokenInformation(TokenDefaultDacl), then trace write-root enumeration and shell resolution for pwsh.exe. Reproduce from the home directory and a narrow project directory, with and without the per-user WindowsApps PATH entry; done means headless execution no longer fails with 1344 or 1920, or reports an actionable cause.

What version of Codex CLI is running?

Reproduced on 0.144.0, 0.145.0, and 0.146.0 (identical behavior on all three).

Platform

Windows 11 Pro (10.0.22000), x64. codex exec (headless, approval: never).

What happened?

Any model-generated shell command fails before the child process starts:

windows sandbox: runner failed during SpawnChild: SetTokenInformation(TokenDefaultDacl) failed: 1344

Error 1344 is ERROR_ALLOTTED_SPACE_EXCEEDED — the default DACL being set does not fit the token's fixed dynamic buffer.

Root cause (isolated)

The failure is working-directory dependent, not version dependent:

• Launching codex with the workdir set to the user's home directory (C:\Users\<user>), the sandbox setup enumerates ~147 write roots (setup refresh: processed 147 write roots in ~/.codex/.sandbox/sandbox.<date>.log). The DACL composed from that many roots exceeds the sandbox token's allotted space → 1344 on every spawn, both windows.sandbox = "elevated" and "unelevated".
• Launching from a normal, narrower project directory, 1344 disappears.

A second, independent failure then surfaces:

windows sandbox: runner error: CreateProcessAsUserW failed: 1920 (The file cannot be accessed by the system.)

because codex resolves pwsh.exe from the per-user Store alias directory (C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe), which the sandbox's separate user account cannot read by design. Removing WindowsApps from PATH for the codex process (so it falls back to a machine-wide shell) fixes it.

Interactive TUI sessions mask both failures: the sandbox error triggers an approval escalation and the command runs unsandboxed after user approval. Headless exec with approval: never has no escalation path and hard-fails.

Repro steps

1. On Windows, cd %USERPROFILE% (a home directory with a typical number of subdirectories).
2. echo "Run the shell command 'echo hello' and report its output." | codex exec -
3. Observe 1344 before the child starts. Repeat from a small project directory → 1344 gone; if pwsh resolves from per-user WindowsApps, observe 1920 instead.

Expected behavior

The sandbox should either cap/aggregate write-root ACEs so the token DACL fits (or fail with an actionable message naming the workdir breadth as the cause), and should not select a shell binary the sandbox user cannot access.

Workaround (verified)

• Launch codex exec from a scoped project directory, never the home directory.
• Strip per-user WindowsApps entries from PATH for the codex process.

With both applied, the sandbox works fully (verified with large multi-hour headless workloads).

Logs

~/.codex/.sandbox/sandbox.<date>.log shows the 147-write-root setup passes and repeated hide users: failed to hide current user profile dir ... 5 (Access is denied.) warnings preceding the spawn failures. Happy to attach full logs on request.