Windows sandbox command runner fails with CreateProcessAsUserW failed: 1312

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

• #28878

Powered by Codex Action

I’m seeing the same failure on Windows 11 in the Codex desktop app:

CreateProcessAsUserW failed: 1312

Even a harmless command such as:

Get-Location

fails before PowerShell starts.

My environment:

• Agent environment: Windows native
• Shell: PowerShell
• Sandbox: Workspace write
• Approval policy: On request
• Codex Workspace version: 26.623.12021
• Project folder is detected correctly

Troubleshooting already completed:

• Codex Diagnose reports healthy
• Codex Workspace bundle reinstalled
• Codex fully closed and reopened
• New Codex threads tested
• Windows fully restarted
• Error persists

The issue does not appear related to the selected project folder because Codex correctly identifies the workspace path, but the local command runner fails before launching PowerShell.

I also submitted a performance trace.

Feedback ID:

019effb7-0ad1-74e1-87d9-e65a722c4a99

I encountered a Windows sandbox command execution failure in the Codex desktop app on Windows 11:

CreateProcessAsUserW failed: 1312

Even a harmless read-only command such as:

Get-ChildItem -Force

fails before PowerShell starts.

Environment:

• Agent environment: Windows Native (English)
• Shell: PowerShell
• Sandbox mode: workspace-write
• Approval policy: On Request
• Codex workspace version: 26.727.6591.0
• The project folder is detected correctly

Observed behavior:

The command fails under normal permissions with:

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

The same command succeeds when run with elevated permissions, and Codex can then read files from the workspace normally.

This does not appear to be related to the command or project files, since the same read-only command works with elevated permissions. The issue seems to be that the Windows Native sandbox cannot create a PowerShell user session when running without elevation.

Expected behavior:

Codex should be able to execute read-only PowerShell commands under normal permissions without requiring elevation.

Verified workaround on one Windows 11 / Codex Desktop machine

I reproduced the exact failure from this issue:

windows sandbox: runner failed during SpawnChild:
CreateProcessAsUserW failed: 1312

Even a trivial Write-Output command failed before execution.

Environment

• Windows 11 x64
• Codex Desktop package: OpenAI.Codex_26.803.5235.0
• Bundled runner/app-server: approximately 0.147.0-alpha.6.5
• CodexSandboxOnline and CodexSandboxOffline existed and were enabled
• The sandbox setup log completed its refresh with errors=[]

What was different on this machine

pwsh resolved to:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe

That path was a tiny App Execution Alias / activation stub rather than a standalone PowerShell executable. This matches the explanation in openai/codex-plugin-cc#336.

Workaround that restored command execution

1. Downloaded the official Microsoft-signed PowerShell 7.6.4 x64 ZIP from the PowerShell 7.6.4 release.
2. Extracted it to %LOCALAPPDATA%\Programs\PowerShell\7.
3. Prepended that directory to the user PATH, so where.exe pwsh selected the real executable before the WindowsApps alias.
4. Fully exited and relaunched Codex Desktop so the app-server inherited the new PATH.

The Store alias was left installed. I did not reset the sandbox users or delete Codex state/databases.

Verification after the restart

• Get-Command pwsh resolved to the standalone PowerShell 7.6.4 executable.
• A direct shell call returned RUNNER_OK.
• A nested codex exec smoke test used the standalone pwsh.exe path and returned NESTED_RUNNER_OK.
• A fresh log window contained no new error 1312 entries.

On this machine, having a real PowerShell executable first in PATH plus a full Codex process restart was the important combination. This is a verified workaround for this environment, not proof that every 1312 report has the same root cause.

A robust product-side fix may be to reject Windows App Execution Alias targets for the sandbox shell and retry with a standalone pwsh.exe when process creation returns 1312.

I can reproduce the same CreateProcessAsUserW failed: 1312 failure with a minimal read-only PowerShell command.

Environment:

• Codex CLI: 0.147.0
• Windows 11 Home 25H2, build 26200.8973
• [windows] sandbox = "elevated"
• command: Write-Output CODEX_TOOLSTART_OK

The child process fails before PowerShell executes. The parent codex exec process may still return exit code 0, while the session correctly reports:

Toolstart: FAIL
Io/Windows sandbox SpawnChild
CreateProcessAsUserW failed: 1312

I reproduced this in three fresh ephemeral/read-only sessions:

1. project wrapper from an existing Codex session;
2. direct CLI with the same sandbox and agent limits;
3. project wrapper from a normal interactive Windows PowerShell login.

The first two failures attempted to launch the Windows Store package executable:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__...\pwsh.exe

The interactive reproduction attempted to launch the App Execution Alias:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe

Both paths failed with 1312. There is currently no standalone PowerShell executable at C:\Program Files\PowerShell\7\pwsh.exe or %LOCALAPPDATA%\Programs\PowerShell\7\pwsh.exe on this machine.

This makes the standalone-PowerShell workaround reported in the latest comment plausible, but it has not been tested here. The alias alone may not explain every failure because two reproductions used the Store package executable directly.

The workspace remained unchanged and the failure is independent of the project command or files. The existing CODEX_HOME/.sandbox/sandbox.log is stale (last updated 2026-05-29) and contains no matching 1312 entry, so I am not attaching it as current evidence.

I can provide the three session IDs privately if useful. No .sandbox-secrets, tokens, environment values, or local user paths are included.