Windows: plugin update fails with "Access is denied (os error 5)" while VS Code is running (Copilot extension holds watcher handles on installed-plugins)
- Langage dominant
- Shell
- Étoiles
- 11.2k
- Forks
- 1.9k
- Merge moyen
- 14 h 16 min
- PR mergées (30 j)
- 6
Description
### Describe the bug
`copilot plugin update` (and the same flow triggered from the GitHub Copilot desktop app) fails on Windows with:
```
Failed to update plugin: Error: Failed to install plugin: Error: Access is denied. (os error 5)
```
The git fetch/checkout of the marketplace clone succeeds every time (the clone under `%LOCALAPPDATA%\copilot\marketplaces\...` ends up at the target commit, working tree clean). The failure happens in the final step that replaces `~\.copilot\installed-plugins\\`.
Root cause (verified with a system-wide handle enumeration via `NtQuerySystemInformation(SystemExtendedHandleInformation)`): **VS Code's Copilot extension holds directory watcher handles** (access mask `0x100081`, i.e. `ReadDirectoryChangesW`-style) on the installed plugin folder itself and its `hooks`, `agents`, and `skills` subdirectories:
```
pid=15064 handle=0x424 access=0x100081 path=\?\C:\Users\\.copilot\installed-plugins\\al-agentic-dev
pid=15064 handle=0x65c access=0x100081 path=...\al-agentic-dev\hooks
pid=15064 handle=0x678 access=0x100081 path=...\al-agentic-dev\agents
pid=15064 handle=0x67c access=0x100081 path=...\al-agentic-dev\skills
```
(pid 15064 = `Code.exe --type=utility --utility-sub-type=node.mojom.NodeService` — the VS Code file-watcher host.)
On Windows, a directory that has an open watcher handle cannot be renamed/replaced, so the installer's folder swap fails with `ERROR_ACCESS_DENIED (5)`. Closing VS Code releases the handles and the identical update command then succeeds immediately (v2.5.0 → v3.0.0 in my case).
This is very confusing for users: restarting the Copilot desktop app doesn't help, and even a reboot doesn't help if VS Code relaunches before the update is retried. The error message gives no hint that another application is holding the folder.
### Affected version
GitHub Copilot CLI 1.0.70 (also reproduced through GitHub Copilot desktop app 1.0.21, which calls the same installer via `plugins.update`)
### Steps to reproduce the behavior
1. On Windows, install a plugin from a marketplace, with the VS Code GitHub Copilot extension active (so it watches `~\.copilot\installed-plugins\...`).
2. With VS Code still running, run `copilot plugin update @` (or click Update in the desktop app's plugin settings).
3. Error: `Failed to install plugin: Error: Access is denied. (os error 5)`. The installed plugin stays at the old version.
4. Close VS Code, run the same command → update succeeds.
### Expected behavior
The update should succeed while VS Code is running — e.g. by copying the new version into place file-by-file instead of renaming/removing the directory root, by retrying with backoff, or by staging to a sibling dir and swapping with `FILE_RENAME_FLAG_POSIX_SEMANTICS`. Failing that, the error message should name the process holding the directory (the Restart Manager API can identify it) so users don't reach for a reboot.
### Additional context
- Operating system: Windows 11 Pro 10.0.26200, x86_64
- Diagnosis details: per-file probes all pass (no file locks, no read-only attributes, ACLs fine — Restart Manager reports nothing because it doesn't surface directory watcher handles); only the rename of the plugin folder root fails. Bisected by rename-probing every subdirectory: only the root and the three watched subdirs are held.
- The plugin in question ships `hooks/`, `agents/`, `skills/` and an `extensions/` canvas extension, but the bug is independent of plugin content — any plugin folder watched by VS Code's Copilot extension will hit it.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Commencez au point d’entrée `copilot plugin update` et suivez l’étape de l’installeur Windows qui remplace le répertoire du plugin installé. Reproduisez l’échec avec VS Code en cours d’exécution et son extension Copilot active ; le travail est terminé lorsque la mise à jour réussit sans fermer VS Code ou que l’erreur identifie le processus qui maintient le répertoire ouvert.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- vscode
- Domaine
- cli, operating-systems
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Calme
- Clarté
- Plutôt claire
- Accessibilité débutants
- 52/100