Codespaces ships Copilot CLI 1.0.3 and `copilot update` only installs with `sudo`

Describe the bug

A newly opened GitHub Codespace starts with GitHub Copilot CLI 1.0.3 installed at /usr/local/bin/copilot.

Running copilot update reports that version 1.0.80 was downloaded, but the installed binary is not replaced and copilot --version continues to report 1.0.3, even after opening a new terminal or restarting the Codespace.

Running sudo copilot update does successfully install the update. This indicates that the normal updater cannot replace the root-owned binary in /usr/local/bin, but still prints a success message.

Affected version

• Preinstalled version in the Codespace: 1.0.3
• Version reported as downloaded by the updater: 1.0.80

Steps to reproduce the behavior

1. Open a GitHub Codespace.
2. Run copilot --version and confirm that it reports GitHub Copilot CLI 1.0.3.
3. Run copilot update.
4. Observe the message: Copilot CLI version 1.0.80 downloaded.
5. Run copilot --version again.
6. Open a new terminal or restart the Codespace and run copilot --version again.
7. Run sudo copilot update and observe that the update succeeds.

Actual output

$ copilot --version
GitHub Copilot CLI 1.0.3.
Run 'copilot update' to check for updates.

$ copilot update
Checking for updates...
Copilot CLI version 1.0.80 downloaded.

$ copilot --version
GitHub Copilot CLI 1.0.3.
Run 'copilot update' to check for updates.

The version remains 1.0.3 after opening a new terminal and after restarting the Codespace. The update succeeds only when run as sudo copilot update.

Investigation

• which -a copilot returns a single path: /usr/local/bin/copilot.
• ls -la /usr/local/bin/copilot shows that the file is still dated March 9 after the non-sudo update, so the installed binary was not overwritten.
• The normal updater appears unable to write to the root-owned /usr/local/bin/copilot binary.
• Despite not replacing the binary, it prints a successful download message instead of reporting the installation failure.
• Running sudo copilot update successfully performs the update.

Expected behavior

1. New GitHub Codespaces should start with the current supported stable Copilot CLI version (1.0.80 at the time of this report, or the latest stable version), rather than the outdated 1.0.3 binary.
2. copilot update should actually replace the installed binary.
3. If the updater cannot write to /usr/local/bin/copilot, it should exit with a non-zero status and clearly explain that elevated permissions are required, for example by suggesting sudo copilot update.
4. It should not display a success message unless the installed binary has been replaced and the new version can be verified.

Workaround

$ sudo copilot update

Environment

• GitHub Codespaces (devcontainer)
• Linux Codespace
• Initial Copilot CLI version: 1.0.3
• Update version reported by the CLI: 1.0.80
• Installed binary: /usr/local/bin/copilot
• Exact uname -a output was not captured

Related issue

• #4405 — the stale preinstalled binary and failed non-sudo update prevented verification with the newer CLI version suggested there.

Start by reproducing copilot update in a GitHub Codespace and inspect the copilot update entry point together with installation at /usr/local/bin/copilot. Compare normal and sudo runs, including their exit status and version output. Done means the supported version is available in new Codespaces, failed replacement is reported clearly, and success is only shown after the installed version changes.