Windows: PowerShell fails with error 8009001d (NTE_PROVIDER_DLL_FAIL) in sandbox

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

• #13917

Powered by Codex Action

I've implemented a fix for this issue. The root cause is in shell.rs where
default_user_shell() hardcodes ShellType::PowerShell on Windows. The fix
changes Session::new in codex.rs to use ShellType::Cmd when
windows_sandbox_level != Disabled.

The fix includes regression tests and cargo fmt passes:
https://github.com/Sequela02/codex/tree/fix/windows-powershell-8009001d

I can reproduce this on Windows as well, and I found one additional data point that may help narrow the problem down.

Environment:

• Windows 10.0.19045
• Codex CLI bundled with Codex Desktop: codex-cli 0.126.0-alpha.8
• ~/.codex/config.toml:

[windows]
sandbox = "unelevated"

The important part is that the Windows sandbox itself is not completely broken. cmd.exe works inside the sandbox:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\codex.exe sandbox windows C:\Windows\System32\cmd.exe /d /c echo OK

Output:

OK

Windows PowerShell 5.1 fails inside the same sandbox:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\codex.exe sandbox windows C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoProfile -NonInteractive -Command "Write-Output OK"

Result:

exit code: 4294901760
stderr contains: 8009001d

However, PowerShell 7 works inside the same Codex Windows sandbox:

where pwsh

Output:

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

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\codex.exe sandbox windows C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe -NoLogo -NoProfile -NonInteractive -Command "Write-Output OK"

Output:

OK

So on this machine the behavior is:

cmd.exe inside Codex Windows sandbox             => works
pwsh.exe / PowerShell 7 inside Codex sandbox     => works
powershell.exe / Windows PowerShell 5.1 sandbox  => fails with 8009001d
normal powershell.exe outside Codex sandbox      => works

This seems to point specifically at Windows PowerShell 5.1 initialization under the Codex Windows restricted token/sandbox, rather than a general sandbox failure or a broken PowerShell installation.

From a user-impact perspective, the built-in tool execution path still appears to use powershell.exe, so shell_command fails even though cmd.exe and pwsh.exe are viable in the same sandbox. A practical workaround would be to allow Windows users to configure the tool execution shell path, for example to pwsh.exe or cmd.exe, until the underlying Windows PowerShell 5.1 sandbox issue is fixed.

I would prefer a proper fix in Codex if possible, but exposing a configurable Windows tool shell would also unblock this class of failures.

I seem to be having the same issue. Right now, I can't use PowerShell with either the Codex app or the Codex CLI.

Codex -> PowerShell crashes during initialization. However, it works fine on my machine with both PowerShell 5.1 and 7.

GitHub Issue #14057 Comment (English)

Additional evidence: PowerShell 7 comparison + Node direct CSPRNG test

Further diagnosis on Windows 11 + Codex Desktop 26.721.4979.0 (MSIX, Microsoft Store) confirms the failure scope is broader than initially expected.

Environment

• OS: Windows 11
• Codex: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0 (Microsoft Store MSIX)
• Config: [windows].sandbox = "unelevated", no custom [shell_environment_policy]
• System Node: v24.18.0 (crypto works outside sandbox)
• Newly installed PowerShell 7.6.4 MSI (C:\Program Files\PowerShell\7\pwsh.exe)

Test 1: PowerShell 5.1 inside Codex sandbox — FAILED

codex sandbox "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -Command 'Write-Output "ps5-ok"'

Result: exit code -65536, error 8009001d (NTE_PROVIDER_DLL_FAIL).

Test 2: PowerShell 7 inside Codex sandbox — SUCCESS

codex sandbox "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -NonInteractive -Command 'Write-Output "pwsh7-ok"'

Result: output pwsh7-ok, exit code 0.

Test 3: PowerShell 7 LanguageMode

codex sandbox "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -NonInteractive -Command '$ExecutionContext.SessionState.LanguageMode'

Result: ConstrainedLanguage, exit code 0.

Test 4: System Node directly inside Codex sandbox — CSPRNG CRASH

Without PowerShell wrapper, directly launching system Node in the sandbox:

codex sandbox "C:\Program Files\nodejs\node.exe" -e 'console.log(require("crypto").randomBytes(16).toString("hex"))'

Result:

Assertion failed: ncrypto::CSPRNG(nullptr, 0)
Exit: 134

Test 5: Codex UI Full Access mode — STILL FAILS

Switched to Full Access in Codex UI, ran cmd / PowerShell / Node minimal tests — all 8009001d / -65536.

ProcMon evidence summary

ProcMon captured PowerShell 5.1 launching inside the sandbox:

• Read Crypto provider config (rsaenh.dll) → SUCCESS
• Load rsaenh.dll → SUCCESS
• RegCreateKey write HKCU\Software\Policies\Microsoft\SystemCertificates\CA → ACCESS DENIED (Read/Write, Delete)
• RegCreateKey write HKLM\SOFTWARE\Microsoft\SystemCertificates\CA → ACCESS DENIED
• RegCreateKey write HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT → ACCESS DENIED
• All SystemCertificates registry writes denied → 8009001d

Full .PML (583 MB) and CSV (264 MB) retained. Available via private read-only link if a maintainer requests it. Not uploading publicly to avoid leaking username/path/environment variables.

Conclusions

1. PowerShell 5.1 fails in Codex's write-restricted token because SystemCertificates registry writes are denied → 8009001d.
2. PowerShell 7 launches but is constrained by ConstrainedLanguage mode.
3. System Node directly in the sandbox also crashes CSPRNG (ncrypto::CSPRNG(nullptr, 0), exit 134) — proving the issue is not limited to PowerShell 5.1; Codex's restricted context also has a Node/CNG compatibility problem.
4. Codex desktop agent tooling still hardcodes PowerShell 5.1, even when PowerShell 7 is installed.
5. UI Full Access mode does not bypass the failure path.

Requests

1. Prioritize support for auto-selecting pwsh.exe or configurable agent shell (ref #16579).
2. Investigate write-restricted token denying SystemCertificates writes causing PowerShell 5.1 Crypto initialization failure.
3. Investigate Node.js ncrypto::CSPRNG assertion failure under restricted context.
4. Evaluate whether Full Access mode truly bypasses the restricted token path.

Reproduction steps

1. Windows 11, install Codex Desktop (Microsoft Store MSIX)
2. config.toml: [windows].sandbox = "unelevated"
3. codex sandbox "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -Command 'echo ok' → exit -65536
4. codex sandbox "C:\Program Files\nodejs\node.exe" -e "console.log(require('crypto').randomBytes(16).toString('hex'))" → exit 134 (CSPRNG)
5. codex sandbox "C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -Command 'echo ok' → exit 0 ✅

Related issues

• #16579 (shell_path configuration feature request)
• #19629 (integrated terminal selection does not affect agent shell)