avoid redownload if the previous update fails

[asgs]

Describe the feature or problem you'd like to solve

when copilot is requested to update itself, it downloads a package and then installs it. if the installation fails for whatever reason, the next update request downloads the package once again without trying to reuse the previously downloaded update

Proposed solution

Here is a shell snippet indicating the fact that Copilot tries to redownload the update package when the previous attempt to update failed

Caching binaries in the local filesystem can avoid this and isn't a bad idea until the next update arrives

~/git-repos$ copilot update
Checking for updates...
Checking GitHub for the latest release...
Update available: v1.0.84-3 (current: 1.0.84-1).
Downloading update package...
Download complete. Installing...
Error during update: Failed to download package: Error: EPERM: operation not permitted, rename 'C:\Users\myself\.copilot\pkg\tmp\1.0.84-3-13492-1789030021787' -> 'C:\Users\myself\.copilot\pkg\win32-x64\1.0.84-3'

~/git-repos$ copilot update
Checking for updates...
Checking GitHub for the latest release...
Update available: v1.0.84-3 (current: 1.0.84-1).
Downloading update package...
Download complete. Installing...
Copilot CLI version 1.0.84-3 installed.

### Example prompts or workflows

_No response_

### Additional context

_No response_

[asgs]

This is what Claude Opus 5 has to say

The ask:

copilot update downloads the package, install fails (Windows rename permission error — the running binary is locked), and the retry re-downloads the whole thing instead of reusing what's already on disk.

My take:

The request is reasonable but treats a symptom. The real bug is the Windows self-replace: on Windows you can't rename over a running executable's target the way you can on POSIX. The standard fix is the rename-self trick — move the live copilot.exe to copilot.exe.old, move the new binary into place, delete the stale one on next launch. That's what Go tools (minio/selfupdate), rustup, and gh itself do. Fix that and the retry loop mostly disappears — which is why caching alone would be a bit of a band-aid.

That said, caching is still worth doing, and cheap:

• Download to %LOCALAPPDATA%...\cache\copilot--.zip, verify checksum, then install. On retry, if the file exists and the checksum matches, skip the fetch.
• The checksum gate is the important part — a resumed-or-truncated cached blob that gets trusted is a worse failure than a redundant download. Same reason it should be content-addressed by version+digest, not just version.
• Evict on success and on version change so the cache doesn't grow unbounded.

Priorities if I were triaging: (1) make the Windows replace atomic/retry-safe, (2) surface a real error message telling the user the binary is in use rather than a raw rename error, (3) add the checksum-verified cache. Bandwidth is the least of the three problems here — a user hitting this is more annoyed by the failed install than by the ~tens of MB.

One thing the issue doesn't say and would matter for the maintainers: whether the failure is reproducible or was a one-off from another copilot process (or an editor extension) holding the file open. If it's the latter, a short retry-with-backoff plus a "close other Copilot processes" hint fixes more real cases than caching would.

By the way, this issue happened because I had a copilot cli session running in another tab