Windows: copilot plugin update fails with os error 5 while any CLI session is running #5194

Describe the bug

On Windows, copilot plugin update <name> (and copilot plugin uninstall) fails with Access is denied. (os error 5) whenever any Copilot CLI session is running, including when the command is run from a shell inside a session. The plugin stays on the old version. Users who keep several sessions open have to exit all of them to update a single plugin.

Sysinternals handle64 shows the running copilot.exe holding directory handles on each installed plugin's root folder and on its manifest folders (.claude-plugin, .github, .github\plugin), for both marketplace and direct installs. Renaming the plugin root folder is denied, while renaming its other subfolders succeeds, so the update's folder-replace step cannot complete.

This appears related to in-session plugin reload (1.0.35, 1.0.69, 1.0.93), which keeps plugin folders open. A plugin that updates itself in place with git pull is unaffected because it never renames its folder.

Affected version

GitHub Copilot CLI 1.0.95

Steps to reproduce the behavior

1. Install a marketplace plugin: copilot plugin install <plugin>@<marketplace>.
2. Start a Copilot CLI session and leave it running.
3. In a separate terminal, after the marketplace publishes a newer version, run copilot plugin update <plugin>.
4. Output: Access is denied. (os error 5). copilot plugin list still shows the old version.
5. Optional: handle64 -nobanner installed-plugins lists copilot.exe handles on %USERPROFILE%\.copilot\installed-plugins\<marketplace>\<plugin> and its .claude-plugin / .github subfolders.
6. Exit every session and rerun the command from a plain terminal. The update succeeds.

Expected behavior

Updating a plugin should not require closing every running session. Possible approaches:

• Running sessions release or reopen plugin folder handles so the update can replace the folder.
• The update installs to a new versioned folder and running sessions switch to it on /restart or plugin reload.

At minimum, the error should name the cause (for example, "a running Copilot session is using this plugin; exit sessions and retry") instead of a bare os error 5.

Additional context

• OS: Windows 11 x64
• Terminal: Windows Terminal
• Shell: PowerShell 7
• 0.0.402 noted plugin update "handles Windows file locks"; this looks like a regression since live plugin reload.
• 1.0.81 made path-sourced plugins in local marketplaces load live from their real directory, which avoids the problem for local plugins but not for remote marketplace or direct installs.
• Workaround: exit all sessions, update from a plain terminal, relaunch.