fix(install): version pinning defeated on PS 5.1, and TEMP cleanup leaks on spaced profiles

[unlimitedmediagroup]

Two independent bugs in install.ps1, both of which fail silently on Windows. Found while installing on Windows 11 / Windows PowerShell 5.1 with a user profile containing a space (C:\Users\Win 1).

1. Version pinning is defeated on Windows PowerShell 5.1

Resolve-Version calls Invoke-WebRequest without -UseBasicParsing. On PS 5.1 that routes the response through the Internet Explorer engine for DOM parsing, which requires IE first-run setup and can prompt. The call throws, Resolve-Version returns $null, and the script prints:

Could not resolve latest version; falling back to 'latest' path.

That fallback is the mutable /releases/latest/download/ path — precisely the stale-binary case the comment above Resolve-Version warns about:

right after a release it can serve the PREVIOUS binary together with a self-consistent stale SHA256SUMS — which passes checksum and installs an old version despite printing success

So on PS 5.1 the immutable-versioned-URL protection never engaged. This is the more consequential of the two bugs: the install still reports success, and the checksum still verifies, because the stale manifest matches the stale binary.

Worth noting the two -OutFile downloads were unaffected — -OutFile skips HTML parsing entirely. That asymmetry is why only this one step failed while everything else looked healthy, and why the failure is easy to miss. I added -UseBasicParsing to those two calls as well; it changes nothing today but removes the same latent IE dependency.

2. Cleanup leaks files when the profile path contains a space

Windows reports TEMP in 8.3 short form for such profiles (C:\Users\WIN1~1\AppData\Local\Temp). PowerShell's filesystem provider cannot resolve the ~ segment, so every cleanup call fails:

Remove-Item : An object at the specified path C:\Users\WIN1~1 does not exist.
At line:108 char:9
At line:158 char:1

The downloaded binary (~33 MB) and SHA256SUMS are left in TEMP on every run, including every future upgrade. -LiteralPath does not fix this — I tested it; the short path itself has to be expanded via GetLongPathName. The added block is a no-op when TEMP is already long.

Verification

Same machine, same shell, before and after.

Before:

Could not resolve latest version; falling back to 'latest' path.
Downloading OfficeCLI...
  (via mirror)
Checksum verified.
Remove-Item : An object at the specified path C:\Users\WIN1~1 does not exist.
Remove-Item : An object at the specified path C:\Users\WIN1~1 does not exist.
OfficeCLI installed successfully!

→ 2 errors, 2 leaked files in TEMP, downloaded from the mutable path.

After:

Latest version: v1.0.146
Downloading OfficeCLI...
  (via mirror)
Checksum verified.
Download verified.
OfficeCLI installed successfully!

→ exit 0, no errors, 0 leftovers, downloaded from the pinned immutable path.

Also confirmed the resulting install is healthy (officecli --version → 1.0.146) and that Resolve-Version now returns v1.0.146 from both the mirror and the GitHub fallback.

Scope

Both changes are confined to install.ps1. No behavior change on systems already unaffected: -UseBasicParsing is the recommended form on 5.1 and is the default and a no-op on PowerShell 7+, and the TEMP block only runs when TEMP actually contains a ~.

🤖 Generated with Claude Code