Repository navigation
Windows: plugin update fails with "Access is denied (os error 5)" while VS Code is running (Copilot extension holds watcher handles on installed-plugins) #4095
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\<marketplace>\<plugin>.
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\<user>\.copilot\installed-plugins\<marketplace>\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
- On Windows, install a plugin from a marketplace, with the VS Code GitHub Copilot extension active (so it watches
~\.copilot\installed-plugins\...). - With VS Code still running, run
copilot plugin update <plugin>@<marketplace>(or click Update in the desktop app's plugin settings). - Error:
Failed to install plugin: Error: Access is denied. (os error 5). The installed plugin stays at the old version. - 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 anextensions/canvas extension, but the bug is independent of plugin content — any plugin folder watched by VS Code's Copilot extension will hit it.
Activity
reinrl commentedon Aug 10, 2026
Hoping to get some additional attention on this - this leads to bad DX, as a developer can manually copy files with no problem, but attempting to use the CLI commands to update a plugin will fail unless all active windows (CLI, VS Code, etc.) are closed first.
Tak2121 commentedon Aug 11, 2026
dileep-chagam commentedon Sep 17, 2026
Corroborating on CLI 1.0.85 (current latest) — the newest version reported in this thread so far, after 1.0.70 and 1.0.79 above. Still failing.
Environment: Windows 11, GitHub Copilot extension active in VS Code.
copilot plugin update <plugin>fails withAccess is denied. (os error 5). Confirmed on 1.0.85 by one user; a second user on Windows reports the identical symptom independently.Two additional data points:
plugin uninstallfails the same way, so uninstall-then-reinstall is not available as a fallback. This matches the 1.0.79 corroboration above, and it means an affected user has no CLI-side recovery path at all.hooks/andskills/— two of the three watched subdirectories identified in the root-cause analysis — and noagents/. Consistent with your finding that the trigger is the watcher handles rather than plugin content. Worth noting because it can easily read as plugin-specific: elsewhere this has been reported as "installs fail for plugins containing ahooks/directory", which looks like the same bug seen from the outside.One consequence worth flagging for prioritisation, from a plugin author's side: we currently have a fix ready for a separate Copilot-specific bug in our own plugin, and the Windows users who need that fix are exactly the users who cannot run
plugin updateorplugin uninstallto receive it. While this is open, there is no delivery path from a plugin author to an affected Windows user.Happy to run any diagnostic that would help narrow it further.
Flujo de instalacion unica del plugin y workaround real de os error 5