Windows: Codex launches Store pwsh directly from WindowsApps, causing CIM native DLL access denied

What happened?

On Windows, Codex appears to choose the Store/MSIX PowerShell Preview executable from the package install directory as the default shell:

C:\Program Files\WindowsApps\Microsoft.PowerShellPreview_7.7.2.0_x64__8wekyb3d8bbwe\pwsh.exe

When that executable is launched directly from C:\Program Files\WindowsApps\..., the process does not have an MSIX package identity. Some PowerShell cmdlets that need native DLLs from the package directory then fail with E_ACCESSDENIED.

Example failure observed from a Codex shell tool call:

Get-CimInstance Win32_Processor

Actual result:

Get-CimInstance: The type initializer for 'Microsoft.Management.Infrastructure.Native.ApplicationMethods' threw an exception.

Expanded exception:

System.TypeInitializationException: The type initializer for 'Microsoft.Management.Infrastructure.Native.ApplicationMethods' threw an exception.
 ---> System.DllNotFoundException: Unable to load DLL 'Microsoft.Management.Infrastructure.Native.Unmanaged.DLL' or one of its dependencies: Access is denied. (0x80070005 (E_ACCESSDENIED))

The failing DLL is located under the PowerShell Preview MSIX install directory:

C:\Program Files\WindowsApps\Microsoft.PowerShellPreview_7.7.2.0_x64__8wekyb3d8bbwe\Microsoft.Management.Infrastructure.Native.Unmanaged.DLL

Why I think this is a Codex launch/environment issue

The same machine can run the command successfully outside the Codex-launched shell.

These variants work:

powershell.exe -NoProfile -Command "Get-CimInstance Win32_Processor"

and launching PowerShell Preview through the App Execution Alias:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh-preview.exe

When launched via the alias, the process has the expected package identity:

Microsoft.PowerShellPreview_7.7.2.0_x64__8wekyb3d8bbwe

When launched directly from the package directory, GetCurrentPackageFullName returns APPMODEL_ERROR_NO_PACKAGE (15700), so the process has no package identity. In that state, directly loading the native DLL from C:\Program Files\WindowsApps\... fails with access denied.

A useful diagnostic detail: copying the same Microsoft.Management.Infrastructure.Native.Unmanaged.DLL to %TEMP% and preloading it allows Get-CimInstance to succeed in the same Codex shell process, which suggests the DLL itself and its dependencies are not corrupt; the access denial is tied to loading it from the MSIX package location without package identity.

Expected behavior

Codex should avoid directly launching MSIX-packaged executables from C:\Program Files\WindowsApps\... as the default shell, or should resolve/use the App Execution Alias instead, so the process gets the correct package identity.

Alternatively, Codex could prefer Windows PowerShell (powershell.exe) or a non-Store/MSI pwsh.exe on Windows when the resolved pwsh.exe points inside C:\Program Files\WindowsApps.

Environment

OS: Microsoft Windows 10.0.29617
Codex: codex-cli 99.0.0
Default shell observed in Codex tool call: PowerShell 7.7.0-preview.2 Core
PowerShell package: Microsoft.PowerShellPreview_7.7.2.0_x64__8wekyb3d8bbwe

Reproduction sketch

1. Install PowerShell Preview from the Microsoft Store / MSIX package.
2. Ensure the package install directory appears before normal shell locations in the environment used by Codex, so pwsh.exe resolves to something like:

``text
C:\Program Files\WindowsApps\Microsoft.PowerShellPreview_...\pwsh.exe
``

1. Start Codex on Windows.
2. Ask Codex to run:

``powershell
Get-CimInstance Win32_Processor
``

1. Observe Microsoft.Management.Infrastructure.Native.Unmanaged.DLL load failure with E_ACCESSDENIED.