Repository navigation
fix(agent): find Store pwsh and fix PowerShell arguments - #2175
Benoît Cortier (CBenoit) merged 3 commits into
Conversation
The package broker only reported PowerShell 7 as available when the MSI installation existed under Program Files, so machines with the Microsoft Store installation could not broker PowerShell 7 operations. The broker now falls back to the user's pwsh.exe app execution alias, validated against the Microsoft.PowerShell package family like the winget.exe alias, and launches the verified WindowsApps target. Several generated PowerShell commands passed parameters the cmdlets do not accept, so those operations always failed: -Repository on Uninstall-PSResource, Uninstall-Module and Update-Module, and -SkipPublisherCheck on Update-Module. Update-Module updates from the repository a module was installed from, so the Windows PowerShell update first checks that this repository is the policy-matched source and fails otherwise. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Lines changed:
Validation:
|
Let maintainers know that an action is required on their side
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
🟡 Changes recommended
The review found an issue that should be addressed before approval.
3 open issues
Policy matching still usesrequest.source.name(evaluator/matching.rs:31), but uninstall now… · New The new repository preflight omits-AllowPrerelease, although the subsequentUpdate-Module… · New The Store fallback drops the verified executable guard and returns the user-writable alias path. If… · New
What changed in this PR
This PR adds Microsoft Store PowerShell 7 discovery to the package broker and corrects unsupported PowerShell cmdlet arguments.
Changes:
- Fall back to the target user’s
pwsh.exealias when the MSI installation is absent. - Extend alias validation to the Microsoft PowerShell package family.
- Remove unsupported parameters and check the installed repository before Windows PowerShell updates.
| File | Description |
|---|---|
crates/now-package-broker/src/policy_security.rs |
Adds PowerShell alias identity validation and tests. |
crates/now-package-broker/src/executor/windows/mod.rs |
Adds Store PowerShell discovery for availability checks and command preparation. |
crates/now-package-broker/src/command_builder/powershell.rs |
Corrects cmdlet arguments and adds update repository checks and regression tests. |
Review effort: Balanced
Check the installed repository before Uninstall-Module and Uninstall-PSResource, which take no -Repository, and list prerelease versions in the Windows PowerShell check. Launch the Store pwsh from the alias target pinned when the alias was validated, so replacing the alias afterwards cannot redirect the launch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The package broker only reported PowerShell 7 as available when the MSI installation existed under Program Files, so machines with the Microsoft Store installation could not broker PowerShell 7 operations. The broker now falls back to the user's
pwsh.exeapp execution alias, validated against theMicrosoft.PowerShellpackage family like thewinget.exealias, and launches theWindowsAppstarget it pinned during that validation.Several generated PowerShell commands passed parameters the cmdlets do not accept, so those operations always failed:
-RepositoryonUninstall-PSResource,Uninstall-ModuleandUpdate-Module, and-SkipPublisherCheckonUpdate-Module. Those commands act on installed modules, andUpdate-Moduleupdates from the repository a module was installed from, so they now first check that every installed version, prereleases included, came from the policy-matched source and fail otherwise.🤖 Generated with Claude Code