Windows sandbox runner fails with CreateProcessAsUserW 1312 after successful setup refresh

Open 💬 4 comments Opened Jul 10, 2026 by avocado-projectg

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

Codex Desktop for Windows: 26.707.3748.0
Windows: Windows 11 x64
Shell: PowerShell 7 via pwsh.exe
Command runner: codex-command-runner-0.144.0-alpha.4.exe

Problem

Every normal sandbox shell command fails before PowerShell executes, including a minimal command such as:

Write-Output 'POWERSHELL_OK'

The reported error is:

windows sandbox: runner failed: CreateProcessAsUserW failed: 1312
A specified logon session does not exist

The same PowerShell works normally when run directly in an interactive Windows PowerShell window.

The issue persists after restarting both Codex and Windows.

Relevant sandbox log

The recent log shows setup and ACL preparation succeeding:

setup refresh: processed 3 write roots (read roots delegated); errors=[]
setup binary completed
read ACL run completed
helper copy: reused command-runner
helper launch resolution: using copied command-runner path ...\\.codex\\.sandbox-bin\\codex-command-runner-0.144.0-alpha.4.exe

For the failing command, the log then contains:

START: ...\\pwsh.exe -NoProfile -Command ...
setup refresh: processed 3 write roots (read roots delegated); errors=[]
setup binary completed
read ACL run completed
helper launch resolution: using copied command-runner path ...\\.codex\\.sandbox-bin\\codex-command-runner-0.144.0-alpha.4.exe

There is no subsequent runner launch, runner launch failed, child process exit, stdout, or stderr entry.

What has been ruled out

The interactive Windows user is active in session 1.
Codex and the interactive shell use the same Windows user.
Direct PowerShell execution works.
The sandbox setup binary reports no ACL errors.
The issue remains after a full Windows reboot.
The failure occurs for read-only and minimal commands, not just Git or project-specific commands.

Expected behavior

A minimal read-only PowerShell command should run in the normal Codex sandbox after successful setup refresh.

Request

Please investigate the command-runner launch/token path on Windows and improve the logging around the boundary after helper launch resolution, especially failures between launching codex-command-runner.exe and its internal CreateProcessAsUserW call.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#31768
#31220

Powered by Codex Action

martinmclee · 1 month ago

I have been having this same issue for over a month with my elevated sandbox

9raoka · 1 month ago

I was able to isolate this failure to the Microsoft Store/MSIX build of PowerShell 7 rather than the elevated Windows sandbox in general.

Environment:

Codex Desktop: 26.707.3748.0
Codex CLI: 0.144.1
Windows: build 26200.8655
Windows sandbox: elevated
PowerShell: 7.6.3

The failing Codex shell resolved pwsh.exe through the per-user App Execution Alias / Store package:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.3.0_x64__8wekyb3d8bbwe\pwsh.exe

Normal Codex shell execution failed before PowerShell started:

CreateProcessAsUserW failed: 1312
A specified logon session does not exist

The sandbox setup itself appeared healthy:

CodexSandboxOffline and CodexSandboxOnline were enabled.
Both users were members of CodexSandboxUsers.
The offline user's LastLogon updated during the failing test.
The machine was not domain joined.
Credential Guard was not running.

I then ran controlled A/B tests by passing executables directly to the elevated Codex sandbox:

C:\Windows\System32\cmd.exe -> succeeded.
Windows PowerShell 5.1 (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe) -> succeeded.
Store/MSIX PowerShell 7.6.3 under Program Files\WindowsApps -> failed with the same CreateProcessAsUserW 1312.
MSI PowerShell 7.6.3 under C:\Program Files\PowerShell\7\pwsh.exe -> succeeded.

After installing the MSI/WiX package and allowing Codex to resolve:

C:\Program Files\PowerShell\7\pwsh.exe

both ordinary Codex shell commands and apply_patch updates worked successfully with the elevated sandbox.

The working installation command was:

winget install --id Microsoft.PowerShell --source winget --installer-type wix

The --installer-type wix part matters because WinGet installs the MSIX package by default beginning with PowerShell 7.6.

This suggests the 1312 failure can be caused by trying to launch the per-user Store/MSIX PowerShell package under the dedicated Codex sandbox user. The MSI build provides a system-wide ordinary executable and avoids that package/logon-session boundary.

arviphd · 1 month ago

I can independently reproduce this and confirm the Microsoft Store/MSIX PowerShell 7 boundary described above.

Environment

VS Code extension: openai.chatgpt-26.707.41301-win32-x64
Codex CLI: 0.144.0-alpha.4
Windows 11 Enterprise x64, build 26100
Windows sandbox: elevated
PowerShell 7: 7.6.3, installed as the Microsoft Store/MSIX package
Resolved pwsh.exe: C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.3.0_x64__8wekyb3d8bbwe\pwsh.exe

The normal Codex shell wrapper uses the App Execution Alias under %LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe and fails before PowerShell executes:

windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW failed: 1312
(A specified logon session does not exist. It may already have been terminated.)

Controlled A/B test

From a fresh Codex CLI process, using the same elevated sandbox:

C:\Windows\System32\cmd.exe                                      -> succeeds
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe      -> succeeds
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.3...\pwsh.exe -> fails with 1312

The system-wide MSI/WiX path C:\Program Files\PowerShell\7\pwsh.exe is not installed on this machine.

Other observations:

codex doctor --json reports overall status ok, including readable sandbox configuration.
The same 1312 failure occurs for a single sequential minimal command, so it is not caused by parallel tool calls.
It affects unrelated commands (Git, Python, GCC, and plain Get-Content) because Codex fails while launching the PowerShell wrapper, before the requested command starts.
Execution outside the sandbox succeeds.
A fresh process still fails when directly asked to launch the MSIX pwsh.exe, which rules out the failure being limited to a stale long-lived extension process.