Windows: Codex sandbox cannot launch USER32-importing children from session 0 (0xC0000142 / STATUS_DLL_INIT_FAILED)

Codex CLI: 0.147.0 (npm) — also reproduced with the bundled codex-command-runner-0.152.0.exe and codex.exe
OS: Windows 11 x64
Sandbox config: [windows] sandbox = "unelevated"
Related upstream: #37722 (elevated / OpenSSH session-0 variant), #17847 (SSH-only variant), #20042 (PTY 0xc0000142 fix)

---

TL;DR

codex sandbox -P :read-only (and :workspace) cannot launch any child that statically imports
USER32.dll when the launching process runs in Windows session 0. The child dies at process start
with 0xC0000142 (STATUS_DLL_INIT_FAILED). Children with no USER32 import launch normally under
the same profiles.

The result is completely determined by the launcher's Windows session:

launcher session	where.exe	whoami.exe	pwsh.exe	cmd.exe	hostname.exe
session 0 (non-interactive)	0xC0000142	0xC0000142	0xC0000142	0	0
session 1 (interactive)	0	0	0	0	0

Reproduced 3/3 deterministically with identical commands. codex exec -s read-only shows the
same split at the tool layer — the model does invoke the shell tool, but the child exits
-1073741502 in session 0 and returns real output in session 1.

Import discriminator — 19/19 binaries, zero exceptions:

OK   & imports USER32 : 0
OK   & no USER32      : hostname.exe cmd.exe findstr.exe attrib.exe ipconfig.exe sort.exe more.com   (7)
DEAD & imports USER32 : where.exe whoami.exe tasklist.exe certutil.exe robocopy.exe cscript.exe
                        wscript.exe timeout.exe notepad.exe powershell.exe pwsh.exe node.exe        (12)
DEAD & no USER32      : 0

Mechanism reproduced with no sandbox involved: launching an ordinary child with a bogus
lpDesktop reproduces the exact failure with the same USER32 split (USER32 child → 0xC0000142;
non-USER32 child → rc 0). Codex's runners import USER32.dll and hardcode Winsta0\Default +
CreateDesktopW("CodexSandboxDesktop-*") + CreateProcessAsUserW; from session 0 that window
station is not reachable, so the child is placed on an unattachable desktop and user32's DLL init
fails at process start.

An ACL repair was tested: the interactive user was granted the missing window-station right on
WinSta0. The grant verifiably repaired the access (CreateDesktopW → OK) and the failure did not
change. Rollback verified clean. Note the scope limit: this tests the user-on-WinSta0 variant and
does not test the sandbox-account-on-inherited-session-0-objects variant described in #37722 —
we measured that the sandbox accounts have no ACE on the inherited session-0 objects here, and we
report that gap rather than closing it.

Full evidence follows.

---

UPSTREAM INCIDENT PACKAGE — Codex Windows sandbox: session-boundary child launch failure

Package ID: WSHSR001-UPSTREAM-2026-09-18
Prepared: 2026-09-18 (Asia/Bangkok, +07)
Prepared by: Hermes (orchestrator) on behalf of Owner (WSTERA / Free)
Subject: codex sandbox -P :read-only cannot launch USER32-importing children when the
launching process runs in Windows session 0; the identical command succeeds from session 1.
Status of our task: remediation attempt 2 FAILED, rollback verified clean, escalated upstream per Owner decision.
Prior art: same class as upstream #37722 / #17847; see §9.

---

1. Executive summary

On this host, the Codex Windows sandbox fails to launch any child process that statically imports
USER32.dll under the read-only and workspace permission profiles. The child dies at process start
with STATUS_DLL_INIT_FAILED (0xC0000142 / exit -1073741502). Children that do not import
USER32.dll launch normally under the same profiles.

The failure is completely determined by the Windows session of the launching process:

Launcher session	where.exe	whoami.exe	pwsh.exe	cmd.exe	hostname.exe
session 0 (service/non-interactive)	0xC0000142	0xC0000142	0xC0000142	0	0
session 1 (interactive console)	0	0	0	0	0

Reproduced 3/3 deterministically with identical commands. codex exec -s read-only shows the
same split at the tool layer: the model does invoke the shell tool, but the tool child exits
-1073741502 in session 0 and returns real output in session 1.

Mechanism (proven independently of ACLs): pointing a child at a desktop that cannot be attached
reproduces the exact failure, with the same USER32 split, using an ordinary duplicated primary
token and no Codex sandbox involved at all:

lpDesktop                            where.exe (imports USER32)   hostname.exe (no USER32)
<null>                               rc=0                         rc=0
Default                              rc=0                         rc=0
WinSta0\Default                      rc=0                         rc=0
NoSuchDesktop-<random>               0xC0000142                    rc=0
WinSta0\NoSuchDesktop-<random>       0xC0000142                    rc=0

Codex's runner hardcodes Winsta0\Default and calls CreateDesktopW("CodexSandboxDesktop-*")
plus CreateProcessAsUserW. From session 0 that window station is not reachable, so the child is
launched onto an unattachable desktop and USER32's initialisation fails.

A WinSta/Desktop ACL repair (for the interactive user) was implemented and tested, and did not fix it. See §6 — which also states the scope limit: the sandbox-account variant described in upstream #37722 was not tested and is not refuted by us.

---

2. Exact versions and host context

Codex CLI (npm)          : 0.147.0
  codex.js               : D:\AI-Workspace\runtime\npm-global\npm\node_modules\@openai\codex\bin\codex.js
Codex sandbox bootstrap  : C:\Users\<user>\.codex\.sandbox-bin\
  codex.exe                     sha256 935a1911ed2556e4ffcec995f4886ac2ac425863ba26fed264df62e30272ad9d
  codex-command-runner-0.147.0  sha256 3a70491d8d588afa459a42816f05b8c2fdd6bddb0ef318f3dfccc963a30b420a
  codex-command-runner-0.152.0  sha256 40f6bebdcb6b795e5763785b8801dc4f4704ce2bfa0b37e3d7d5723a1b35128c
  (both runner versions fail identically)
Codex desktop app (MSIX) : OpenAI.Codex 26.911.7940.0 (runs in session 1 - and works)
Host OS                  : Windows 11 (build 10.0.26100 family; see §7 for the reported build)
Host                  1  : single-machine reproduction
Sandbox accounts         : CodexSandboxOffline (…-1003), CodexSandboxOnline (…-1004), group CodexSandboxUsers (…-1002)
Sandbox account state    : Enabled=True, PwdLastSet 2026-08-31 19:32:44 (unchanged across all attempts)

Launcher context that fails:

Hermes gateway (python -m hermes_cli.main gateway run)  -> session 0
  -> bash.exe -> node.exe -> codex.js (npm)             -> session 0

Launcher context that works:

interactive console session (session 1), e.g. scheduled task with /IT or the Codex desktop app

---

3. Minimal reproduction

All commands use the npm Codex CLI through node.exe (the codex on PATH is a .cmd shim that
cannot be spawned directly by some launchers).

# 1. Show which session you are in
(Get-CimInstance Win32_Process -Filter "ProcessId=$PID").SessionId

# 2. A child that imports USER32 - expected to FAIL from session 0
node.exe "D:\AI-Workspace\runtime\npm-global\npm\node_modules\@openai\codex\bin\codex.js" `
  sandbox -P :read-only -C "D:\AI-Workspace\runtime\reviews\relay-controller-privilege-001" -- where cmd
# observed rc = 3221225794 (-1073741502) from session 0

# 3. A child that does NOT import USER32 - expected to PASS from either session
node.exe "...\codex.js" sandbox -P :read-only -C "<same-workspace>" -- cmd /c "echo MX_OK"
# observed rc = 0

# 4. The acceptance case: does the model's shell tool actually run?
node.exe "...\codex.js" exec -s read-only -C "<same-workspace>" `
  "Run the shell command  cmd /c echo WSH_SHELL_OK_9271  and report its exact output."

Observed from session 0 (codex exec -s read-only, full transcript):

exec
"<...>\pwsh.exe" -Command 'cmd /c echo WSH_SHELL_OK_9271' in <workspace>
2026-09-18T07:22:19.426680Z ERROR codex_core::tools::router: error=Exit code: -1073741502
  exited -1073741502 in 238ms:
Output:

Observed from session 1, the same command:

exec
"<...>\pwsh.exe" -Command 'cmd /c echo WSH_SHELL_OK_9271' in <workspace>
  succeeded in 426ms:
WSH_SHELL_OK_9271

Running the same probe from a scheduled task with /IT (so it lands in session 1) is sufficient
to flip the result. No Codex configuration change is required.

---

4. The USER32 correlation (19/19, zero exceptions)

22 binaries swept; 19 had a determinate outcome. Import table read directly from the PE headers.

OK   and imports USER32      : 0
OK   and no USER32           : hostname.exe, cmd.exe, findstr.exe, attrib.exe,
                               ipconfig.exe, sort.exe, more.com                (7)
DEAD and imports USER32      : where.exe, whoami.exe, tasklist.exe, certutil.exe,
                               robocopy.exe, cscript.exe, wscript.exe, timeout.exe,
                               notepad.exe, powershell.exe, pwsh.exe, node.exe   (12)
DEAD and no USER32           : 0

Additionally, all three Codex bootstrap binaries statically import USER32.dll:

codex-command-runner-0.147.0.exe  imports: USER32.dll, shell32.dll, advapi32.dll, bcrypt*, ntdll, KERNEL32
codex-command-runner-0.152.0.exe  same
codex.exe                         same + userenv.dll

USER32 initialisation attaches the process to a window station and desktop; if the desktop cannot
be reached, user32's DLL init fails — which is exactly 0xC0000142 at process start, before the
child runs any code.

---

5. Winsta0\Default / CreateDesktopW("CodexSandboxDesktop-*") evidence

Strings recovered from Codex's own binaries (codex.exe, 298 MB; and the command runners):

CreateProcessAsUserW failed: .. (..) | cwd=.. | cmd=.. | env_u16_len=.. | si_flags=.. | creation_flags=..
Winsta0\Default
Winsta0\
CodexSandboxDesktop-
CreateDesktopW failed for ..: .. (..)
CreateDesktopW failed: ..,SetSecurityInfo failed for private desktop: ..
SetEntriesInAclW failed for private desktop: ..
private desktop
SetTokenInformation(TokenDefaultDacl) failed
Logon SID not present on token
AdjustTokenPrivileges error ..no capability SIDs provided
windows-sandbox-rs\src\token.rs
windows-sandbox-rs\src\stdio_bridge.rs

Imports and API surface actually used by the runner:

CreateProcessAsUserW, CreateRestrictedToken, CreateDesktopW, SetSecurityInfo,
SetEntriesInAclW, GetSecurityInfo, SetTokenInformation, TokenDefaultDacl,
SetNamedSecurityInfoW, ConvertStringSidToSidW, CopySid, CreateWellKnownSid,
AdjustTokenPrivileges, LookupPrivilegeValueW, SeChangeNotifyPrivilege

Runtime corroboration that the sandbox actually manipulates window-station security itself:

- the runner binaries contain SetSecurityInfo + "Winsta" strings
- nested launch (cmd /c <binary>) moves the failure LATER: direct DLL_INIT  ->  nested rc 1
  with "CreateFileMapping S-1-5-21-...-1001.1, Win32 error 5"
- Windows' own restricted token (runas /trustlevel:0x20000) launches every failing binary
  successfully -> host restricted-token machinery is healthy

Session-0 window station observed while a sandbox child is launched:

current window station         : Service-0x0-<hex>$
OpenWindowStation("WinSta0", WINSTA_ALL)         -> DENIED err=5  (before the ACL test)
OpenWindowStation("WinSta0", WINSTA_CREATEDESKTOP)-> DENIED err=5 (before the ACL test)
desktops reachable in session-0 WinSta0          : 2 entries, each open -> err=2 (not attachable)

---

6. The WinSta ACL experiment and its clean rollback

Scope correction (important, and it is a correction to our own earlier framing).
Upstream issue #37722 describes this same failure class and locates the missing ACE on the
sandbox accounts (CodexSandboxOffline / CodexSandboxOnline) on the inherited session-0
Window Station / Desktop, because the runner bootstras is launched with lpDesktop NULL via
CreateProcessWithLogonW. Our experiment granted the interactive user on the object named
WinSta0. Those are different object/principal pairs. So:

• our experiment does correctly show that user-on-WinSta0 ACL deficit is not sufficient;
• our experiment does not test and does not refute the #37722 claim
  (sandbox-account ACE on the inherited session-0 objects is the fix).

We re-measured this read-only afterwards and confirm the #37722 shape is present on this host:

inherited session-0 window station : Service-0x0-<hex>$
  DACL contains interactive user    : True
  DACL contains CodexSandboxOffline : False
  DACL contains CodexSandboxOnline  : False
inherited session-0 desktop        : Default
  DACL contains interactive user    : True
  DACL contains CodexSandboxOffline : False
  DACL contains CodexSandboxOnline  : False

Testing the #37722 hypothesis (sandbox-account ACE on the inherited objects) would be a new
bounded hypothesis test with its own authorization; it was not authorized in this task and
was not performed. We are reporting the gap rather than implying we closed it.

6.1 What we actually changed, and what it proved

A concrete missing right was found for the user principal and was granted, to test whether
the hypothesis "a WinSta/Desktop ACL deficit is the sufficient cause" held.

Missing right (session 0, before mutation):

session-0 WinSta0 (opened by name, from session 0) DACL for user S-1-5-21-...-1001 : NO ACE
  OpenWindowStation(WinSta0, WINSTA_CREATEDESKTOP=0x8) -> DENIED err=5
  OpenWindowStation(WinSta0, WINSTA_ENUMDESKTOPS=0x1)  -> DENIED err=5
  OpenWindowStation(WinSta0, WINSTA_ALL=0x37F)         -> DENIED err=5
session-0 WinSta0\Default desktop DACL            : already granted ...-1001 full desktop access
                                                    (CCDCLCSWDTLOSDRCWDWO) - no change needed

Mutation (bounded, reversible, exactly one ACE, first position, no inherit-only entries):

added : (A;NP;0x37f;;;S-1-5-21-...-1001)
        0x37f = window-station-specific rights only
        NOT granted: WRITE_DAC, WRITE_OWNER, DELETE, GENERIC_ALL
ACE count before/after : 11 -> 12
backup sha256          : 49c025ae22d18340db23bef70f4bce334275a31b0312ba8c7b94c52235c04e35

Post-mutation: the right was genuinely repaired -

OpenWindowStation(WinSta0, CREATEDESKTOP)  DENIED -> OK
OpenWindowStation(WinSta0, ENUMDESKTOPS)   DENIED -> OK
OpenWindowStation(WinSta0, WINSTA_ALL)     DENIED -> OK
CreateDesktopW on WinSta0 (Codex's own mechanism)  -> OK

- and the failure did not change:

codex exec -s read-only : still "exited -1073741502 in 238ms"
where.exe / whoami.exe / pwsh.exe : still 0xC0000142 from session 0

Plausible reading, stated as an interpretation and not as a proven step: the runner bootstrap needs
the sandbox accounts to reach the inherited objects (as #37722 says), and a grant to the
interactive user does not transfer to those accounts. Our data is consistent with that and does not
contradict it - but we did not test it.

6.2 Rollback - verified clean

restore result        : OK
live DACL after       : identical to backup (11 ACEs)
IDENTICAL_TO_BACKUP   : True
mutation ACE present  : False
access after          : CREATEDESKTOP DENIED err=5, ENUMDESKTOPS DENIED err=5, ALL DENIED err=5
sandbox matrix after  : where/whoami = 0xC0000142, cmd/hostname = rc 0  (== pre-state)
sandbox persisted state (.sandbox*, .sandbox-bin, .sandbox-secrets) : 0 non-log files changed
config.toml           : IDENTICAL
accounts/group        : unchanged (Enabled=True, PwdLastSet 2026-08-31 19:32:44)
scheduled tasks / ProgramData / profile dirs / private desktops      : no residue

---

7. Earliest observed onset

first 0xC0000142 marker on this host : 2026-09-16 12:57:15.999  (sandbox.2026-09-16.log)
last clean run before it             : 2026-09-16 12:53:14.028  (3x pwsh SUCCESS, same log)
onset window                         : ~4 minutes

Onset is dated by the -1073741502 marker only. Counting SUCCESS/FAILURE lines is not
valid for dating: the sandbox log does not record which permission profile ran, and a
:danger-full-access run of pwsh produces no log line at all while the :read-only run of the
same binary logs START: and dies.

Note: a Windows servicing update (KB5129195) was installed on this host on 2026-09-15, in the same
window. We explicitly did not pursue a KB correlation (not authorized), and the session finding
above is evidence against a patch-shaped cause: the identical command still succeeds in session 1
today, long after the update, whereas a servicing change that broke USER32 initialisation would
affect both sessions equally.

---

8. What we ruled out (so you do not have to)

Hypothesis	Result
Sandbox persisted host-side state corrupted	not the cause (removal + rollback; re-provisioning never rebuilt it in our test)
Leftover sandbox DENY ACEs on System32 binaries/DLLs	none (30 files scanned, 0 DENY, 0 Codex entries)
Failure bound to a specific workspace	no (identical in 5 workspaces incl. a fresh temp dir)
Parent PATH (MSYS vs clean native)	no effect (byte-identical outcome)
Runner binary corrupted / stale vs vendor	no (.sandbox-bin hashes == vendor)
Mandatory ASLR / IFEO / AppCompat layers	all NOTSET, 0 IFEO entries
Pending reboot / servicing inconsistency	reboot flags clear
Sandbox accounts / group / token rights	correct and unchanged; no missing user right
Windows restricted-token capability in general	healthy (runas /trustlevel:0x20000 launches every failing binary)
WinSta/Desktop ACL deficit	tested: right granted, CreateDesktopW OK, failure unchanged (§6)
Workspace / env policy (inherit, readable roots, disk-full-read-access)	no effect
MSIX/AppX PowerShell alias path, nested-vs-direct launch	no effect
:danger-full-access	works, but is unusable as a fix (it removes the sandbox)

---

9. Related upstream issues (prior art, consulted after our measurements)

This is not a novel report. The same failure class is already tracked upstream, and one of those
issues reaches a conclusion that matches our session finding:

Issue / PR	What it says	Relation to our data
#37722 — missing inherited Window Station/Desktop access in a Windows OpenSSH Session 0	Deterministic on Codex CLI 0.147.0; the elevated sandbox bootstrap runner is launched with lpDesktop NULL (via CreateProcessWithLogonW), and the sandbox account has no ACE on the inherited session-0 Window Station/Desktop → runner fails 0xC0000142. Reports a reversible A-B-A test: add the sandbox-account ACE → PROBE_EXIT=0; restore DACL → failure returns. Suggests codex-rs/windows-sandbox-rs/src/elevated/runner_client.rs should add/remove the minimal ACEs around the bootstrap.	Same version (0.147.0), same failure code, same session split we measured. Their principal/object pair is sandbox account on inherited session-0 objects; we tested interactive user on WinSta0 (see §6). Our session 0-vs-1 result is independent corroboration of the session dimension.
#17847 — error=Exit code: -1073741502	Fails only over SSH, works when run locally on the same machine under the same user.	Same shape as ours: the variable is the interactive/session context, not the command.
#16401 — shell_command can fail globally with 0xC0000142 due to helper materialization/fallback	Windows Desktop app; helper materialization/resolution for packaged (WindowsApps) installs; freshness check used size+mtime only.	Different layer (helper materialization), but the same user-visible symptom. We ruled out our runner-copy integrity (hashes == vendor) so this is not our layer.
#20042 / commit 5cac3f8 — Fix Windows pseudoconsole attribute handling for sandboxed PTY sessions	PTY path passed a pointer instead of the pseudoconsole handle value → child start 0xc0000142. Fixed and validated with windows.sandbox_private_desktop=true.	Evidence that 0xC0000142 at child start has several independent causes in this subsystem; not our path (we are non-PTY, codex exec).
#40089 — apply_patch fs sandbox helper exits with 0xc0000142 on update/delete	Remote SSH on Windows Server 2022, CLI 0.148.0; happens even with danger-full-access.	Same status code, different helper (fs sandbox helper).

Our configuration difference, stated explicitly

#37722 is on windows.sandbox = "elevated" with sandbox_private_desktop = true. This host records:

[windows]
sandbox = "unelevated"

so the bootstrap path may not be identical. We are not claiming our case is the same defect; we
are reporting a reproducible instance of the session-0 class on an unelevated configuration, plus the
USER32 discriminator (§4) which we have not seen stated upstream in this form.

9.1 What we are asking upstream

1. Confirm or refute the USER32-import discriminator. We measure 19/19 with zero exceptions:
   under :read-only/:workspace from session 0, a child dies 0xC0000142 iff it statically
   imports USER32.dll. This makes the failure precise and cheap to test. Is that the expected
   mechanism for "child attached to an unreachable desktop", and does it hold on other hosts?
2. Is session 0 a supported launch context for the Windows sandbox? If not, please say so in the
   sandbox documentation — an agent-relay/orchestrator service naturally runs in session 0 and
   currently has no signal that the sandbox cannot work there.
3. Improve the diagnostic. Today the CLI prints nothing on the failing path: stdout and
   stderr are empty and the sandbox log stops at START: (the child is created and dies before
   running any code). A single line naming the desktop/window-station failure would have saved hours.
4. For the unelevated path, does the same bootstrap-ACE requirement described in #37722 apply,
   or is a different mechanism expected? Our data rules out the user-on-WinSta0 variant but does
   not test the sandbox-account-on-inherited-objects variant.
5. If the intended answer is "run the sandbox from the user's interactive session", that is workable
   for us — we measured codex exec -s read-only succeeding there with the identical command. We
   would ask for it to be documented rather than diagnosed per-host.

10. Sanitization statement

This package contains no secrets and no private credentials:

• no passwords, tokens, API keys, or DPAPI blobs;
• the sandbox account password store (sandbox_users.json) was never printed or included — only its
  file hash and metadata appear in our internal evidence, and it is not part of this package;
• machine SIDs / account SIDs appear only in the form recorded above, which is required to describe
  the ACL experiment; the S-1-5-21-… machine portion is redacted to … in this document;
• user paths are shown with the user name redacted (<user>, <workspace>);
• no Codex session transcripts, prompts, or repository contents are included beyond the single
  echo-probe output shown in §3.

---

11. Artifact index (internal, not part of the submission)

Full internal evidence set (46 artifacts + index) lives at:

D:\AI-Workspace\runtime\reviews\windows-sandbox-host-state-remediation-001-evidence\
  SHASUMS-attempt2.txt                     (index of all 46 artifacts)
  P18-PRE-STATE.json                       attempt-2 pre-state matrix
  P21-BOOTSTRAP-IMPORTS.json               runner binaries import USER32
  P24-CODEX-EXE-STRINGS.json               Winsta0\Default + CodexSandboxDesktop-* strings
  P29-ONSET-VALIDITY.json                  onset dating + log-confounding proof
  P31-SESSION-TEST.txt                     session 0 FAIL / session 1 PASS
  P32-SESSION-REPRODUCIBILITY.txt          3/3 deterministic + final state hashes
  P33-MECHANISM-PROOF.txt                  bogus lpDesktop reproduces it iff USER32
  P35-ACCEPTANCE-TRANSCRIPT.txt            full codex transcripts, both sessions
  P36-WHY-SESSION0-FAILS.txt               session-0 WinSta0 unreachable
  P37-SESSION-ACL-COMPARISON.txt           same token, same object, different session
  P38B-MUTATION-V2.txt                     the bounded ACE grant, applied and verified
  P39-WHY-STILL-FAILS.txt                  post-mutation characterisation
  P41-ROLLBACK-AND-FINAL-VERIFY.txt        rollback + clean-state proof

Task report:

D:\AI-Workspace\runtime\reviews\wstera-native-bot-proposal-001\tasks\
  WINDOWS-SANDBOX-HOST-STATE-REMEDIATION-001\
    REMEDIATION-ATTEMPT-2-2026-09-18.md    (the full attempt-2 report)
    REMEDIATION-ATTEMPT-1-2026-09-18.md    (attempt 1: re-provisioning, inconclusive, rolled back)
    TASK.md                                (task definition + reproduction commands)

Reproduce the session-0 versus session-1 behavior with the documented codex sandbox commands and inspect the Windows runner references to windows-sandbox-rs\src\token.rs and windows-sandbox-rs\src\stdio_bridge.rs. Trace the CreateDesktopW and CreateProcessAsUserW path described in the report. Done means USER32-importing children launch successfully from session 0 without regressing the working session-1 and non-USER32 cases.