Windows: uninstall only half-removes the standalone install (browser4-cli-win32-x64.exe + user PATH entry left behind)

[platonai]

Summary

On Windows, uninstall removes only part of the standalone (installer-created) footprint, leaving the install in a half-removed state: the aliases go, the real binary stays, and the user PATH entry written by the installer is never removed.

Observed

State after browser4-cli uninstall -y on a machine where the CLI had been installed by the official installer (aliases in ~/.local/bin, plus the %LOCALAPPDATA%\Programs copy):

Path	Before	After uninstall -y
%USERPROFILE%\.local\bin\b4.exe	present	removed
%USERPROFILE%\.local\bin\browser4-cli.exe	present	removed
%USERPROFILE%\.local\bin\browser4-cli-win32-x64.exe	present	left behind
%LOCALAPPDATA%\Programs\browser4-cli\*.exe (3 files)	present	left behind
user PATH entry %LOCALAPPDATA%\Programs\browser4-cli	present	left behind

The uninstaller reported: Binary and companion links scheduled for removal after exit. — the deferred pass did remove two of the three files in ~/.local/bin.

Why browser4-cli-win32-x64.exe is missed

COMPANION_NAMES in cli/browser4-cli/src/main.rs (~L16976), used by attempt_self_removal:

#[cfg(windows)]
const COMPANION_NAMES: &[&str] = &[
    "b4.exe",
    "b4.cmd",
    "browser4-cli.exe",
    "browser4-cli.cmd",
];

It covers the aliases the installer creates, but not the binary the installer actually downloads. cli/scripts/install-browser4-cli.ps1 derives that name from the platform key:

# L230
return "win32-$arch"
# L256
return "browser4-cli-$PlatformKey" + $(if ($PlatformKey.StartsWith("win32")) { ".exe" } else { "" })

which yields browser4-cli-win32-x64.exe (same naming convention as scripts/build-all-platforms.ps1:19) — precisely the file that survives uninstall.

The user PATH entry

install-browser4-cli.ps1 appends its install directory to the persistent user PATH (L657-683, via [System.Environment]::SetEnvironmentVariable("Path", $newPath, "User")).

Nothing on the uninstall side ever touches PATH. grep -n "PATH" cli/browser4-cli/src/*.rs only finds unrelated lookups (Java, browser discovery, 7-Zip) plus the install/upgrade npm resolution — handle_uninstall (…/src/main.rs ~L17094) has no PATH handling at all. So after uninstall the user is left with a PATH entry pointing at a directory that the uninstaller does not remove.

Question / proposed resolution

54fd3b432e44975c45a2d22ef0c2e0e5b59b988f (fix(test): pre-clean accepts standalone binary as out of uninstall scope) states the standalone binary is deliberately out of scope:

uninstall only manages package-manager installs (npm/pnpm/yarn/cargo); the standalone binary is refreshed by re-running install-browser4-cli.sh/.ps1, so a leftover there is expected, not a broken uninstall.

If that is still the intent, the current behaviour is inconsistent — the same directory is partially cleaned (b4.exe / browser4-cli.exe removed, browser4-cli-win32-x64.exe kept). Either:

• (a) out of scope — remove nothing from ~/.local/bin / %LOCALAPPDATA%\Programs\browser4-cli, and say so in the uninstall summary, or
• (b) in scope — add the platform-named binary (browser4-cli-win32-x64.exe and equivalents) to COMPANION_NAMES, and remove the installer-written user PATH entry.

Option (b) is what the command's own help implies: "Remove all globally installed browser4-cli (npm, cargo) and its runtime data".

Environment

Same as #595 — browser4-cli 4.13.19 on Windows / PowerShell.