[BUG] Windows: PowerShell 7 installed via WinGet is not detected by shell discovery #41321

Description

PowerShell 7.6.4 installed through the standard WinGet flow is not detected by OpenCode on Windows, even though Windows itself can launch pwsh through the standard App Execution Alias.

For PowerShell 7.6.x, WinGet installs the MSIX package by default. The package exposes pwsh.exe through the standard per-user WindowsApps PATH entry, which is a Windows App Execution Alias:

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

This is the normal supported installation path, not a custom or version-specific PATH setup. Pressing Win+R and entering pwsh launches PowerShell 7 without any custom PATH changes. The same command also works from Windows Terminal, and Get-Command pwsh resolves it to the standard WindowsApps alias path.

The Desktop shell picker may not list pwsh, but the same behavior can be reproduced in both Desktop and CLI by setting "shell": "pwsh" directly in opencode.json.

Microsoft documents this installation behavior here:

https://learn.microsoft.com/en-us/powershell/scripting/install/install-powershell-on-windows#install-powershell-using-winget

This is related to #17372 and #30615, but this issue adds the MSIX-specific detail: the alias is executable by Windows but appears to be rejected by OpenCode's regular-file validation. Adding the version-specific WindowsApps package directory to PATH makes PowerShell 7 detectable, which points to shell discovery or validation rather than PATH configuration.

Plugins

None required to reproduce.

OpenCode version

OpenCode Desktop/CLI v1.18.13

Steps to reproduce

1. Install Microsoft.PowerShell through the standard WinGet flow.

2. Leave the standard WindowsApps PATH entry unchanged.

3. Press Win+R, enter pwsh, and verify that PowerShell 7 launches.

4. Add the following to opencode.json:

   {
     "$schema": "https://opencode.ai/config.json",
     "shell": "pwsh"
   }

5. Start OpenCode Desktop or the OpenCode CLI.

6. Run a shell command through OpenCode.

Actual behavior

The WindowsApps pwsh.exe App Execution Alias is not detected or is treated as unavailable. OpenCode falls back to powershell.exe instead of using PowerShell 7.

Adding the version-specific directory below to PATH makes OpenCode detect PowerShell 7:

C:\Program Files\WindowsApps\Microsoft.PowerShell_<version>_x64__8wekyb3d8bbwe

However, this workaround has an additional problem in the Desktop app: the shell settings window displays the full version-specific path instead of the short shell name. The long path consumes excessive horizontal space and can break the layout.

This is therefore not a satisfactory workaround and should not be required for a standard WinGet installation.

Expected behavior

OpenCode should recognize and use the standard Windows App Execution Alias when pwsh is available through PATH.

The following configuration should work without adding a version-specific WindowsApps directory:

{
  "shell": "pwsh"
}

Technical context

The current Windows shell discovery appears to resolve pwsh with which("pwsh") and then require the resolved path to pass stat(...).isFile().

An MSIX App Execution Alias is not a conventional executable file, so this validation may reject it even though Windows can execute it normally.

The local verification was:

$PSVersionTable.PSVersion.ToString()
# 7.6.4

$PSVersionTable.PSEdition
# Core

(Get-Command pwsh).Source
# C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

Related issues

• OpenCode uses Windows PowerShell 5.1 instead of the PowerShell 7 it was launched from #17372
• "shell": "pwsh" config not respected, still uses PowerShell 5.1 on Windows #30615
• 无法使用shell #20603

Screenshot and/or share link

No screenshot or share link.

Operating System

Windows 11 Pro Insider Preview 25H2
Build 26100.ge_release.240331-1435

Terminal

Windows Terminal for verification; OpenCode Desktop/CLI