You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Windows: /upgrade on a winget install replaces the WinGet\Links alias and leaves winget/Add-Remove Programs on the old version #5096
On Windows, when Copilot CLI is installed with winget (GitHub.Copilot) and then updated with the built-in updater (/upgrade), the update bypasses winget. The new binary is written over winget's command alias instead of the winget package, so the install record is never updated:
winget list and Add/Remove Programs keep reporting the old version, and winget offers an "upgrade" to the version that is already running.
Software inventory tooling that relies on install records (Uninstall registry keys / winget) reports the wrong version.
The winget package folder and the binary that actually runs are out of sync.
Affected version
GitHub Copilot CLI 1.0.91 (updated from 1.0.89 via /upgrade)
Steps to reproduce the behavior
Install with winget: winget install --id GitHub.Copilot -e (here this installed 1.0.89).
Run copilot and use /upgrade.
copilot --version reports 1.0.91.
winget list --id GitHub.Copilot still shows the old version, with the running version offered as an update:
Name Id Version Available Source
Copilot CLI GitHub.Copilot v1.0.89 v1.0.91 winget
The Uninstall entry HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\GitHub.Copilot_Microsoft.Winget.Source_8wekyb3d8bbwe still has DisplayVersion = v1.0.89.
Compare the two binaries:
$links="$env:LOCALAPPDATA\Microsoft\WinGet\Links\copilot.exe"$pkg="$env:LOCALAPPDATA\Microsoft\WinGet\Packages\GitHub.Copilot_Microsoft.Winget.Source_8wekyb3d8bbwe\copilot.exe"
(Get-Item$links).LinkType # empty: no longer a symlink
(Get-Item$links).VersionInfo.ProductVersion # 1.0.91
(Get-Item$pkg).VersionInfo.ProductVersion # 1.0.89 (unchanged)
The other winget portable packages in WinGet\Links are still symbolic links into WinGet\Packages; for Copilot CLI the link has been replaced by a regular file containing the new version.
Expected behavior
Either of:
The updater detects a winget-managed install and defers to the package manager (for example: "Copilot CLI was installed with winget; run winget upgrade GitHub.Copilot"), or
The update is applied in a way that keeps the winget install consistent (package folder, WinGet\Links alias and install record reflect the running version).
The same question likely applies to other package-manager installs (Homebrew, npm) where a self-update can diverge from what the package manager reports.
Additional context
OS: Windows 11, x64
Shell: PowerShell 7
Install method: winget (portable package, user scope)
The old 1.0.89 binary remains in the winget package folder; only the WinGet\Links\copilot.exe alias was replaced.
Activity