[lewishampson]

• I have read the contributing guidelines, and I agree with the Code of Conduct.
• Have you checked that there aren't other open pull requests for the same changes?
• Have you tested that the committed code can be executed without errors?
• Have you confirmed that this issue is caused by UniGetUI itself, and not by the package manager or the package involved?

---

The existing code for parsing -Confirm:$false only worked under PowerShell 5.x (powershell.exe), which splits the pair and passes the value on as the literal text $false. PowerShell 7 (pwsh.exe) splits it too, but evaluates the value first and passes a real boolean, which the launcher did not recognise. The pair fell through to the array splat and the cmdlet rejected it with "a positional parameter cannot be found that accepts argument 'False'".

This fix adds parsing for the PowerShell 7 shape in the same style as the existing parsing without affecting the PowerShell 5.x path.

Closes #5388

[Gabriel Dufresne (GabrielDuf)]

Looks good, Thanks for looking into this and fixing it!

[Jordan Humberto de Souza (SHJordan)]

Confirming this also affects v2026.3.0, which was published on 2026-09-15 — two days before this PR merged — so no release currently includes the fix.

Repro on v2026.3.0 (pwsh 7.5.x, PSResourceGet 1.2.0): updating Microsoft.WinGet.Client via the PowerShell7 manager fails with

Update-PSResource : a positional parameter cannot be found that accepts argument 'False'

because pwsh hands the launcher an already-evaluated bool for -Confirm:$false, while the launcher at that release only matched the literal text '$false' (the pre-#5391 shape).

Could you confirm which release will carry this fix (v2026.3.1?), so users know when the local workaround — patching unigetui_ps_operation.ps1 — is no longer needed? Thanks!

[lewishampson]

Jordan Humberto de Souza (@SHJordan) I don't know the release cycle. I was affected by the bug and wrote a fix as a volunteer contributor to an open source project.
You (or at least, whichever LLM you're using) apparently have a working fix:

the local workaround — patching unigetui_ps_operation.ps1

so you could continue using that, or you could just pull and build the main branch yourself from the repo.

What do you gain from chasing people over release dates?

Also, please at least proof-read your LLM output before posting it. Some real humans still read and write code, and a comment like

Confirming this also affects v2026.3.0, which was published on 2026-09-15 — two days before this PR merged — so no release currently includes the fix.

on a completed PR, linked to a raised bug for the issue you're asking about doesn't make much sense; the PR was both raised and merged after the release, so of course it affects said release. It's just wasting people's time.

I have a real project manager at work for wasting my time, I don't need one for volunteer work, too.