plugin install fails with Access is denied (os error 5) on Windows for all sources

Bug Description

copilot plugin install fails 100% of the time on Windows 11 with:

Failed to install plugin: Error: Failed to install plugin: Access is denied. (os error 5)

It fails for a marketplace source (azure@azure-skills), a direct GitHub repo, and a local directory source — so it is not specific to one plugin or fetch method.

Version

• GitHub Copilot CLI: 1.0.71 (also seen on 1.0.70)
• OS: Windows 11 Enterprise 10.0.26200, x64
• git: 2.50.1.windows.1

Steps to reproduce

1. copilot plugin marketplace add microsoft/azure-skills
2. copilot plugin install azure@azure-skills
3. Fails with Access is denied. (os error 5)

Expected behavior

Plugin installs successfully.

Actual behavior

Install aborts. It creates an empty target folder under ~/.copilot/installed-plugins/ (e.g. azure-skills and _direct) then fails on its first file operation, before any file is written.

Investigation / ruled out

• Not permissions/sandbox: fails identically when run directly as the real user with Full Control over the entire ~/.copilot tree.
• Not Controlled Folder Access: Get-MpPreference shows EnableControlledFolderAccess = 0.
• Not git: git clone --depth 1 https://github.com/microsoft/azure-skills.git succeeds (1552 files).
• Not a lock: the leftover target folder can be freely renamed/deleted.
• Plain create/write/delete under installed-plugins and %TEMP% all succeed as the same user.
• Fails for both remote and local sources, immediately after the target dir is created.
• No detail is written to ~/.copilot/logs; the message is stderr-only and double-wrapped, hiding the offending path.

Suspected cause

A native filesystem op in the install/cache pipeline (likely remove_dir_all/rename/copy) returning Windows ERROR_ACCESS_DENIED — a common Rust-on-Windows failure against read-only files (e.g. git pack objects). Surfacing the actual path in the error would greatly help.

Workaround

copilot --plugin-dir <local-plugin-dir> loads the plugin fine, confirming only the install/copy path is broken.

Reproduce the failure with the marketplace, direct repository, and local-directory install commands, then trace the install/cache pipeline immediately after the target directory is created. Identify the first filesystem operation returning ERROR_ACCESS_DENIED and surface its path; done means plugin installation succeeds on Windows for each source and the error identifies the offending path when it fails.