fix(agent-core-v2): detect PowerShell 7 via PATH and fix Windows installer probes - #2719
fix(agent-core-v2): detect PowerShell 7 via PATH and fix Windows installer probes#2719MaxwellGengYF wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 0bc0054 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0bc005400e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| path.win32.join(localAppData, 'Microsoft', 'WindowsApps', 'pwsh.exe'), | ||
| ); | ||
| } | ||
| return candidates.slice(0, MAX_WINDOWS_POWERSHELL_CANDIDATES - 2); |
There was a problem hiding this comment.
When where.exe returns four or more unique pwsh paths before the WindowsApps execution alias, this slice drops the explicit %LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe candidate that was just appended. In the standard-locations-fail scenario this change is meant to fix, stale PATH shims can consume all four additional slots and the MSIX-only alias is never probed, so installation still fails even though PowerShell 7 is available; reserve a slot for the explicit alias or prioritize it ahead of PATH results.
Useful? React with 👍 / 👎.
| // MSIX installs have no C:\Program Files\PowerShell\7\pwsh.exe; the | ||
| // working binary is the WindowsApps execution alias on PATH. | ||
| const alias = 'C:\\Users\\probe\\AppData\\Local\\Microsoft\\WindowsApps\\pwsh.exe'; |
There was a problem hiding this comment.
This adds explanatory comments inside the test body, but the scoped package guide requires comments to live only in the top-of-file /** */ header and not beside statements. Please fold this rationale into the scenario header or the test name so the file stays consistent with the package convention.
AGENTS.md reference: packages/agent-core-v2/AGENTS.md:L36-L40
Useful? React with 👍 / 👎.
1 participant
Related Issue
#2715
Problem
Installing the Kimi Computer Use plugin on Windows fails even when both Windows
PowerShell 5.1 and PowerShell 7 are installed:
winget install Microsoft.PowerShell(MSIX) has noC:\Program Files\PowerShell\7\pwsh.exe— the binary lives in WindowsApps with anexecution alias on PATH. The installer only probed the hardcoded MSI path, so spawn
failed with ENOENT.
C:\Program Files\PowerShell\7\Modulesto themachine PSModulePath. Under Windows PowerShell 5.1 this shadows the system modules
(Microsoft.PowerShell.Utility/.Archive/.Security), so the probe falsely reported
Get-FileHash,Expand-Archive, andGet-AuthenticodeSignatureas missing.kimi-cu.exe doctorcan exceed it ("command timed out after 3000ms").What changed
pwshviawhere.exe pwshand the%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exeMSIX alias (deduped, probed until one passes), keeping the standard locations first.
$env:PSModulePathto$PSHOMEfirst inside both the installer probe and theofficial setup-script invocation, so a PowerShell 7 install can no longer shadow the
cmdlets Windows PowerShell 5.1 needs.
installerProbeTimeoutMscopy-paste that readctx.detectProbeTimeoutMs.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.