Windows: local runner cannot start, CreateProcessAsUserW failed: 5

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

• #24416
• #25162
• #24259

Powered by Codex Action

I ran into a similar CreateProcessAsUserW failed: 5 issue. In my case, the problem was not the target file permission or the command itself. The failure happened earlier: the Codex/Windows sandbox failed to create the PowerShell child process.

This started after I changed the default shell from Windows PowerShell 5 to PowerShell 7. The issue disappeared after I switched PowerShell 7 to the standard MSI installation and made sure Codex was using the real pwsh.exe path, not a WindowsApps alias or MSIX path.

Useful check:

Get-Command pwsh -All

One important detail: avoid the Microsoft Store version of PowerShell 7, and avoid installing the MSIX package via winget. Those installations usually resolve to WindowsApps-related paths, for example:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

or the corresponding WindowsApps package path. Such paths may not be launchable by CreateProcessAsUserW under a restricted sandbox token.

A simple workaround is to download the .msi installer from the PowerShell GitHub Releases page. The MSI installer lets you choose the installation directory, and its default path is usually:

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

My understanding is that the sandbox uses CreateProcessAsUserW to spawn the shell process. Some PowerShell 7 MSIX / Store / WindowsApps installations may be rejected by Windows under the restricted token, which results in:

windows sandbox: runner error: CreateProcessAsUserW failed: 5

Additional note: after running conda init in PowerShell 7, I also hit a separate issue:

Invoke-Expression: Missing '{' in configuration statement.

This is not the same root cause as CreateProcessAsUserW failed: 5. It is caused by a compatibility issue between PowerShell 7 native command argument passing and the older conda PowerShell initialization script. A workaround is to add this before the conda initialization block in the PowerShell profile:

if ($PSVersionTable.PSVersion.Major -ge 7) {
    $PSNativeCommandArgumentPassing = 'Legacy'
}

The longer-term fix is to update conda and regenerate the PowerShell initialization:

conda init --reverse powershell
conda init powershell

yes the issue resolved after I uninstalled PowerShell and reinstalled from the .msi . The prior install was in a nonstandard location.

One thing that would make this much easier to diagnose is separating "command failed" from "runner never started."

In threads like this, people naturally go chase file ACLs, workspace permissions, or the exact shell command, but CreateProcessAsUserW failed: 5 means the failure happened before any of that mattered.

A better product response would be something like:

• runner launch failed under the current Windows token
• workspace access was never attempted
• shell path detected: X
• launch mode detected: Y
• next checks: shell install path, token/sandbox mode, known WindowsApps/MSIX pitfalls

That would stop a lot of false debugging.

Also feels worth logging a structured fingerprint for this error family so Codex can stop retrying the same launch path over and over once it knows the runner is dead. When local execution is unavailable, the fastest path is usually a crisp fail, not another hopeful spawn attempt.

@Keesan12, please stop posting bot-generated slop to our issue tracker. It's not useful, and it's creating noise for maintainers and users. If you do not stop, I'll ask GitHub to block your account.

A simple workaround is to download the .msi installer from the PowerShell GitHub Releases page. The MSI installer lets you choose the installation directory, and its default path is usually: `` C:\Program Files\PowerShell\7\pwsh.exe ``

This resolved the issue ``windows sandbox: runner error: CreateProcessAsUserW failed: 5`` for me. Thanks!

我也遇到过类似的CreateProcessAsUserW failed: 5问题。我的情况并非出在目标文件权限或命令本身，而是更早之前：Codex/Windows 沙箱未能创建 PowerShell 子进程。 这个问题是在我将默认 shell 从 Windows PowerShell 5 更改为 PowerShell 7 之后出现的。当我将 PowerShell 7 切换到标准 MSI 安装并确保 Codex 使用的是真实pwsh.exe路径而不是 WindowsApps 别名或 MSIX 路径后，问题就消失了。 有用的检查： Get-Command pwsh -All 一个重要的细节：避免使用 Microsoft Store 版本的 PowerShell 7，也避免通过 winget 安装 MSIX 包。这些安装通常会指向与 WindowsApps 相关的路径，例如： `` C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe ` 或相应的 WindowsApps 包路径。此类路径可能无法通过CreateProcessAsUserW受限沙盒令牌启动。 一个简单的解决方法是从 PowerShell GitHub Releases 页面下载.msi安装程序。MSI 安装程序允许您选择安装目录，其默认路径通常为： ` C:\Program Files\PowerShell\7\pwsh.exe ` 我的理解是，沙箱用于CreateProcessAsUserW生成 shell 进程。某些 PowerShell 7 MSIX / Store / WindowsApps 安装可能会因受限令牌而被 Windows 拒绝，从而导致： ` windows sandbox: runner error: CreateProcessAsUserW failed: 5 ` 补充说明：conda init在 PowerShell 7 中运行后，我还遇到了另一个问题： ` Invoke-Expression: Missing '{' in configuration statement. ` 这并非与之前提到的根本原因相同CreateProcessAsUserW failed: 5`。这是由于 PowerShell 7 原生命令参数传递方式与旧版 conda PowerShell 初始化脚本之间的兼容性问题导致的。一种解决方法是在 PowerShell 配置文件中的 conda 初始化代码块之前添加以下代码： if ($PSVersionTable.PSVersion.Major -ge 7) { $PSNativeCommandArgumentPassing = 'Legacy' } 长远来看，解决办法是更新 conda 并重新生成 PowerShell 初始化程序： conda init --reverse powershell conda init powershell

Love you babe. Problem perfectly solved.

I can reproduce this on native Windows Codex Desktop after updating and fully reopening the app (2026-07-22).

A fresh, normal sandboxed read-only probe fails before PowerShell begins:

windows sandbox: runner failed during SpawnChild:
CreateProcessAsUserW failed: 5 (Access is denied)

The attempted child is the user-local Microsoft\WindowsApps\pwsh.exe; Get-Location never starts. The same pre-launch failure has affected multiple fresh tasks and a minimal read-only probe, so it does not appear specific to the repository, Git worktrees, or an individual command.

The recent Windows sandbox work in #34423 / 0.145.0 was a strong candidate, but the update did not resolve this particular error on this machine. No credentials, protected data, or project contents are involved.

I can reproduce this on native Windows Codex Desktop after updating and fully reopening the app (2026-07-22).

A fresh, normal sandboxed read-only probe fails before PowerShell begins:

windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW failed: 5 (Access is denied.)

The attempted child is the user-local Microsoft\\WindowsApps\\pwsh.exe; Get-Location never starts. The same pre-launch failure has affected multiple fresh tasks and a minimal read-only probe, so it does not appear specific to the repository, Git worktrees, or an individual command.

The recent Windows sandbox work in #34423 / 0.145.0 was a strong candidate, but the update did not resolve this particular error on this machine. No credentials, protected data, or project contents are involved.

I can reproduce this same failure in Codex Desktop's managed workspace-write restricted runner on Windows 11.

Additional bounded diagnosis

• Feedback session ID: 019f0576-bd6b-7572-88be-6e79e6915ec0.
• Failure occurs before the requested command begins, at SpawnChild / CreateProcessAsUserW.
• Windows error: 5 (Access is denied).
• The runner's diagnostic names the literal selected executable:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe.

• That path is a healthy zero-byte App Execution Alias reparse point registered by the installed Microsoft.PowerShell Store package (package status Ok; manifest declares the pwsh.exe alias).
• The alias has inherited access rules, no explicit deny rule, and starts successfully as the same non-admin interactive user outside the Codex restricted runner.
• Effective AppLocker inspection found no rule collections, and user-mode code-integrity enforcement was not active.
• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe also starts successfully outside the restricted boundary.
• The same runner failure intercepts harmless read-only commands and local Git commands before execution.

This strongly isolates the failure to the Codex restricted child-process/token boundary rather than a broken PowerShell package, alias registration, filesystem ACL, AppLocker rule, or repository.

A useful product correction would be for the Windows-native runner to launch the registered alias correctly under its restricted token, use system PowerShell directly, or expose a supported explicit shell-executable setting. The current workaround is one approved retry through the full system Windows PowerShell path.

No Windows ACL, alias, package, PATH, registry, sandbox-policy, or security setting was changed during diagnosis. Codex app version was not available from the bounded process metadata.

Companion app-server path fails, but direct CLI sandbox succeeds

• OS: Windows
• Codex CLI: 0.146.0
• Codex Companion plugin: 1.0.4
• Authentication: ChatGPT login active
• Workspace: local Git repository under C:\<REDACTED>\...

When Claude Code delegates a task through Codex Companion, the task fails while spawning the sandbox child process:

``text
CreateProcessAsUserW failed: -1073283067
0xC0070005
Win32 error 5: Access is denied
``

This persists after a full Windows reboot.

However, the same machine, account, workspace, and read-only sandbox succeed with direct Codex CLI:

cd C:\<REDACTED>\repository
codex exec --sandbox read-only "Reply exactly READY."

Result:

codex
READY

So the failure appears limited to the Claude Code Codex Companion / app-server delegation path, rather than Codex CLI
authentication, workspace access, or the read-only sandbox itself.

Expected behavior: Codex Companion should be able to launch the same read-only sandbox task that succeeds via direct
CLI.