›_ Codex Issues
Codex Issues / #19550

Code tool calls fail with Powershell 7 installations from Windows Store or Winget

Open 💬 3 comments Opened Apr 25, 2026 by SlippyDong
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

26.5304.20706

What subscription do you have?

plus

Which IDE are you using?

vs code

What platform is your computer?

Windows 11 Pro

What issue are you seeing?

When powershell 7 is installed through windows store or winget, the default path for the installlocation is:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.1.0_x64__8wekyb3d8bbwe\pwsh.exe

When Codex tries to invoke tool calls using powershell the agent's terminal exits early and eventually runs a Get-Location which then gives a success response, after which the agent continues its tasks. The agent will then request elevated permissions to run some standard queries which fail in the sandbox but after seeing this in several fresh prompts I wondered what caused these failures and narrowed it down the how Powershell is installed on the system. When Powershell is installed with the MSI, the default installation path is in the Program Files folder and this resolved the tool call problems the agent had.

What steps can reproduce the bug?

  1. Install Powershell 7 through Windows Store or Winget
  2. Open VS CODE and provide a random task to the code agent on a random code base
  3. Watch the reasoning output and tool calls for exit codes that error - the agent will note that they fail and will try to fall back on MCP first and then run a Get-Location that succeeds.

What is the expected behavior?

  1. Check the current installlocation of Powrshell 7: Get-AppxPackage Microsoft.PowerShell
  2. If it returns empty, you're not using the Windows Store or Winget version, but if it returns something like:
Microsoft.PowerShell_7.6.1.0_x64__8wekyb3d8bbwe
InstallLocation : C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.1.0_x64__8wekyb3d8bbwe
IsFramework : False
PackageFamilyName : Microsoft.PowerShell_8wekyb3d8bbwe

This means Powershell is installed as a WindowsApp instead of a normal program and Codex may have trouble using it in tool calls.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19549

Powered by Codex Action

SplitMilky · 2 months ago

Confirmed here in Codex desktop as well, not just the VS Code extension.

On this machine, pwsh works interactively for the user, but resolves to a WindowsApps install:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.2.0_x64__8wekyb3d8bbwe\pwsh.exe

From Codex's sandboxed exec environment:

  • default shell launches failed before command execution
  • observed error: CreateProcessAsUserW failed: 5
  • cmd.exe worked reliably
  • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe worked reliably
  • pwsh.exe was not visible/usable via normal lookup paths from the sandboxed process

This looks like a sandbox / shell-resolution issue specific to Store-installed PowerShell 7 under C:\Program Files\WindowsApps\..., rather than a general PowerShell failure.

badwordsno · 1 month ago

Confirmed on Codex Desktop with a current version and a controlled before/after test.

Environment:

  • Windows 11 10.0.26200 x64
  • Codex Desktop package 26.721.3996.0
  • Bundled CLI 0.146.0-alpha.3.1
  • PowerShell 7.6.4

Before:

  • pwsh resolved to C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe / the Store MSIX package path.
  • Both the default elevated sandbox and a one-off unelevated test failed 20/20 before the command started with CreateProcessAsUserW failed: 5.
  • Codex Repair and a full app restart did not change the result.

Change:

  • Installed the official PowerShell 7.6.4 x64 MSI/WiX package while leaving the existing Store package installed.
  • Fully restarted Codex Desktop so it inherited the updated PATH.

After:

  • pwsh resolves to C:\Program Files\PowerShell\7\pwsh.exe.
  • The default elevated workspace-write sandbox passed 20/20 read-only process-launch probes.
  • No Codex configuration change was required for this fix.

Additional data point: the Store package did not need to be removed on this machine; installing the same-version MSI side by side and ensuring the MSI path won after a full Codex restart was sufficient.