[BUG] PowerShell tool launches powershell.exe (5.1) instead of pwsh.exe (7) when PS7 is installed via Microsoft Store (MSIX)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code's PowerShell tool launches powershell.exe (Windows PowerShell 5.1, Desktop edition) even when PowerShell 7 is installed and on PATH — specifically when PS7 was installed via the Microsoft Store (MSIX), where pwsh.exe on PATH is the WindowsApps execution alias rather than a normal .exe.

This appears related to but not covered by the fix for #54335.

What Should Happen?

The PowerShell tool should launch pwsh.exe (PowerShell 7) when it is available on PATH, regardless of whether the install is MSI/winget or MSIX/Store.

Steps to Reproduce

1. On Windows 11, install PowerShell 7 from the Microsoft Store (this is the MSIX install). Confirm pwsh.exe resolves on PATH:

``
> where pwsh.exe
C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe
> pwsh -NoProfile -Command "$PSVersionTable.PSVersion.ToString()"
7.6.1
`
The WindowsApps\pwsh.exe entry is an MSIX execution alias that resolves to C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.1.0_x64__8wekyb3d8bbwe\pwsh.exe`.

1. Open Claude Code in any directory.
2. Ask Claude to run $PSVersionTable via the PowerShell tool.
3. Observe that the output reports PowerShell 5.1 / Desktop, not 7.x / Core.

Error Messages/Logs

Output of $PSVersionTable from the PowerShell tool:

Name                           Value
----                           -----
PSVersion                      5.1.26100.8115
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.26100.8115
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Claude Code Version

2.1.123 (Claude Code)

Operating System

Windows 11 Pro 10.0.26200

Terminal/Shell

Windows Terminal (bug is not terminal-dependent — the PowerShell tool spawns its own interpreter subprocess)

Is this a regression?

I don't know — the previous fix (#54335) targeted the VSCode extension; I have not verified whether the bare CLI ever resolved pwsh.exe correctly on a Microsoft Store install.

Additional Information

Why this looks distinct from #54335:

• #54335 was titled "Claude Code for VSCode uses powershell.exe instead of pwsh.exe" and was closed as completed on 2026-04-28.
• This repro is the standalone CLI (claude 2.1.123) in a regular terminal — not the VSCode extension — and the version was released after that close.
• The install pattern is the MSIX / Microsoft Store variant. On PATH, pwsh.exe is an execution alias under %LOCALAPPDATA%\Microsoft\WindowsApps, not a normal .exe. A resolver that uses a normal Get-Command-style PATH lookup picks it up; one that filters out WindowsApps aliases or stat-checks the underlying file would miss it. So the MSIX install case appears not to be covered by whatever fix landed for #54335, hence filing fresh rather than asking for a reopen.

Workaround: none known from the user side — the PowerShell tool's interpreter selection isn't user-configurable as far as I can tell. Falling back to the Bash tool when PS7-specific syntax is needed.