Windows elevated sandbox: CreateProcessAsUserW denies launch (error 5), then fails with 'no such logon session' (1312) after registering the target MSIX package

Windows sandbox: CreateProcessAsUserW fails launching Store-packaged PowerShell (error 5), then error 1312 after registering the package for the sandbox identity — same command never succeeds

Environment

• codex-cli version: 0.144.5
• OS: Windows 11 (Home edition)
• Target executable under test:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\pwsh.exe
(Microsoft Store / MSIX-packaged PowerShell 7.6.4)

• Sandbox mode: workspaceWrite, elevated Windows sandbox (codex sandbox setup --elevated --current-user)
• App Server invoked via the documented JSON-RPC stdio protocol

(initialize → initialized → thread/start → turn/start), using an
independently-built, source-verified client that reproduces the exact
documented handshake.

Summary

Every attempt to launch the elevated Windows sandbox's allowed in-root
command (Store-packaged pwsh.exe) fails before the child process is
created. The failure mode is stable, reproducible, and was narrowed across a
long diagnostic session (~17 independently-verified rounds) that ruled out
every plausible cause on our side:

1. Initially: every attempt failed identically with

windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW
failed: 5 (Access is denied.) — before a process ID was ever assigned
(exitCode: -1, durationMs: 0, processId: null).

1. After registering the target MSIX package for the sandbox identity

(Add-AppxPackage -Register under the sandbox's own non-admin logon
context — see "The one lead that changed anything" below), the error
changed to CreateProcessAsUserW failed: 1312 (A specified logon
session does not exist. It may already have been terminated.) — and has
remained 1312 on every subsequent attempt, including after a clean
reboot with no intervening logon activity on the sandbox account.

The command has never once succeeded. windowsSandbox/readiness reports
{"status":"ready"} throughout.

What we ruled out (with evidence)

• General sandbox setup/readiness: windowsSandbox/readiness returns

ready, not notConfigured/updateRequired.

• Our own request shape: our client sends the documented restrictive

policy exactly — workspaceWrite, one disposable writableRoots entry,
networkAccess:false, excludeTmpdirEnvVar:true, excludeSlashTmp:true —
confirmed against the installed stable/experimental JSON schemas.

• Missing/absent provisioning: the version-5 setup marker, encrypted

credential artifact, CodexSandboxOffline/CodexSandboxOnline accounts,
and CodexSandboxUsers group all exist and are correctly configured
(created 2026-07-11, confirmed present in every later check).

• Stale/drifted provisioning: re-running `codex sandbox setup --elevated

--current-user completed cleanly (exit 0, refreshed passwords/marker,
persisted [windows] sandbox = "elevated"`) but did not change the
failure.

• Desktop/session lock state: reproduced with the interactive session

confirmed Active/unlocked (WTS SessionFlags:1) immediately before and
after the attempt.

• Account privileges: an elevated, read-only LSA audit of BUILTIN\Users,

Everyone, Authenticated Users, both sandbox accounts, and
CodexSandboxUsers found no explicit deny rule and no
SeAssignPrimaryTokenPrivilege/SeIncreaseQuotaPrivilege grant anywhere —
but per Microsoft's own CreateProcessAsUserW documentation, a restricted
token derived from the caller's own token (via CreateRestrictedToken,
which is what the sandbox runner appears to do) is exempt from the usual
SeAssignPrimaryTokenPrivilege requirement, and a genuinely missing
privilege should surface as ERROR_PRIVILEGE_NOT_HELD (1314), not 5.

• WinSta0 ACLs: the current-session interactive window station has a

present, non-null DACL with 15 allow ACEs and zero deny ACEs; no explicit
ACE for either sandbox account, but no deny either.

• AppLocker / WDAC / Code Integrity: no configured AppLocker policy found

across GP-registry, PolicyManager, MDM CSP, and rule-match surfaces; five
enforced CI policies present, none with an active Store-enforcement
option; 130 event-log queries around the exact failure timestamps found
zero application-control or package-denial events.

• The target binary itself: launched manually, outside the sandbox,

under the normal interactive account — opens cleanly to an interactive
PowerShell 7.6.4 prompt every time. The package is not corrupted.

The one lead that changed anything

An Get-AppxPackage -User <SID> query found the current interactive account
has the Microsoft.PowerShell package registered (Status: Ok), while
both sandbox accounts (CodexSandboxOffline, CodexSandboxOnline)
returned zero registered packages, despite the package being installed
system-wide and visible in WindowsApps. AppX/MSIX packages require
per-user registration even when the package files are shared on disk.

We registered the package for CodexSandboxOffline only, using a normal
(non-admin) process running under that account's own loaded profile
(CreateProcessWithLogonW(LOGON_WITH_PROFILE) → Add-AppxPackage
-MainPackage 'Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe' -Register
-Confirm:$false -ErrorAction Stop). This succeeded cleanly (exit 0, package
count 0 → 1, Status: Ok, no drift in provisioning/marker/credential state).

Immediately after registration, the sandbox's failure mode changed from
error 5 to error 1312 — and this was confirmed stable, not a timing
artifact: we re-ran the identical AC-19-equivalent attempt after a full
machine reboot (no CodexSandboxOffline logon since boot, profile confirmed
unloaded, LastLogon predating boot by ~51 minutes), and it still failed
with exactly the same CreateProcessAsUserW failed: 1312.

Interpretation (ours, not confirmed against your source)

This looks like a two-stage problem:

1. Without package registration: the restricted-token launch of a

Store-packaged executable is denied outright (error 5), independent of
classic account rights/ACLs — plausibly because MSIX/AppX package
activation involves additional security checks (package identity,
app-container/capability requirements) beyond what a plain
CreateRestrictedToken-derived token satisfies for an unregistered
package under that identity.

1. With package registration: launch now gets further, but fails with

"no such logon session" — plausibly because the runner's own
CreateProcessAsUserW call path expects (or references) a logon session
for the sandbox identity that isn't actually established yet at that
point in the sequence, on a cold/clean account state.

We were not able to go further without instrumenting the closed
codex-command-runner.exe binary at the exact CreateProcessAsUserW call
site — the SpawnChild stage confirms the runner has already completed its
own CreateProcessWithLogonW/pipe handshake by the time this fails, so the
denial is specific to the child-launch call itself, not the runner's own
startup.

Reproduction

1. codex sandbox setup --elevated --current-user on a Windows 11 Home

machine.

1. Start an App Server session, turn/start with

sandboxPolicy: {type: "workspaceWrite", writableRoots: [<any disposable
folder>], networkAccess: false, excludeTmpdirEnvVar: true,
excludeSlashTmp: true}.

1. Ask the model to run one command via exec_command/the default shell

that writes a marker file inside the writable root (any simple PowerShell
one-liner).

1. Observe the commandExecution item report status: "failed",

exitCode: -1, durationMs: 0, processId: null, and
windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW
failed: 5 (Access is denied.).

1. Register the Store PowerShell package for the sandbox identity

(CodexSandboxOffline by default under networkAccess:false) and repeat
step 3 — observe the error change to
CreateProcessAsUserW failed: 1312 (A specified logon session does not
exist. It may already have been terminated.).

What would help us most

• Confirmation of whether Codex's own setup flow (`codex sandbox setup

--elevated`) is expected to register any packages the sandboxed
environment needs for the sandbox identities, and if so, why that
didn't happen for PowerShell itself.

• Instrumentation or a debug build that logs the exact access check and

logon-session reference codex-command-runner.exe uses immediately before
the failing CreateProcessAsUserW call, so we can tell whether it's
looking for a pre-existing session that's supposed to be created
elsewhere in the sequence.

• Does the elevated Windows sandbox require Windows Pro/Enterprise? This

machine is Windows 11 Home. We couldn't find anything in the public docs
or the parts of codex-rs we reviewed suggesting an edition dependency —
every API involved (CreateProcessAsUserW, CreateRestrictedToken, local
account/window-station management) is available on Home — but we haven't
been able to test on a Pro machine to rule it out empirically, and it
would save everyone time if this is a known requirement.

Happy to provide the full evidence trail (source citations, exact
request/response transcripts with hashes, LSA/WinSta0/AppLocker audit
output) on request — trimmed here for length.