Windows: active MCP workers lock plugin directories and block plugin updates

Start at the app's plugin update action and the bundled CLI's copilot plugin update --all, then trace how active MCP workers and their launcher processes are managed on Windows. Done means plugin updates coordinate with affected workers or defer safely with an actionable retry path, while unrelated sessions remain running and affected tools reconnect afterward.

Short summary

On Windows, active plugin MCP workers hold installation-directory handles that prevent plugin replacement. Updating plugins while sessions are running can fail with a sharing violation rather than safely coordinating the update with those workers.

Affected version or release

• GitHub Copilot app: 1.1.22
• Bundled Copilot CLI: 1.0.84-5
• Windows ARM64, version 25H2, build 10.0.26200.9457
• Observed September 20-21, 2026. Not independently reproduced on another machine or a newer build.

Installation context

Windows desktop installation with multiple active Copilot sessions and installed plugins contributing MCP servers. This affects local plugin installation directories, not a particular GitHub repository.

What happened?

The app's plugin update action reported "Some plugins couldn't be updated" and "8 of 10 plugins failed to update." The visible failures included "Access is denied. (os error 5)" and "The process cannot access the file because it is being used by another process."

A targeted local investigation confirmed sharing violations on two installed-plugin root directories, including the Azure plugin. Running plugin MCP workers and their launcher processes held handles to those directories.

After stopping only the identified plugin workers, the directory sharing violations disappeared. Running the bundled CLI's copilot plugin update --all then completed successfully for all 10 installed plugins, with exit code 0. The app and Copilot session processes remained running.

Active sessions subsequently started new plugin workers, and directory locks returned. This confirms that the workaround does not remove the underlying live-update limitation; a second update failure after worker restart was not tested.

Steps to reproduce

Observed workflow; exact timing and reproducibility on a clean installation are not yet established:

1. On Windows, install a plugin that contributes an MCP server, such as the Azure plugin.
2. Start Copilot app sessions that launch the plugin's MCP workers.
3. Leave those sessions running and use the app's plugin update action.
4. Observe update failures when a worker holds the installation directory open.

Diagnostic isolation used in this instance:

1. Identify processes holding handles to the affected plugin directories.
2. Stop only those identified workers after saving work and accounting for interruption of their MCP tools.
3. Retry the update using the bundled CLI.
4. Observe successful updates; active sessions may later recreate the workers and locks.

Expected behavior

• Coordinate replacement of plugin directories with affected MCP workers, or safely defer the update until they are no longer in use.
• If coordination is not possible, explain that a running plugin is blocking the update and provide an actionable retry/restart path.
• Keep unrelated sessions running and reconnect affected tools after a successful update.

Additional context

Evidence from non-mutating Windows filesystem probes and handle inspection:

• Opening the affected plugin root directories with CreateFileW, requesting DELETE access with read/write/delete sharing and OPEN_EXISTING, returned Win32 error 32. The probes did not delete or rename files.
• Process-handle inspection identified plugin MCP workers/launchers holding directory handles.
• The same access probes succeeded immediately after the identified workers were stopped.
• The subsequent all-plugin update reported 10 successful updates and exit code 0; the installed-plugin inventory still listed all 10 plugins.

Scope and uncertainty:

• Directory locking was directly confirmed for two plugins. This report does not attribute all eight initial failures to that cause.
• No read-only files or restrictive ACLs were found in the two installations checked for permissions. A separate access-denied failure succeeded on a standalone CLI retry before worker cleanup, so its cause remains unconfirmed.
• This is filesystem/process evidence, not a source-level diagnosis of a particular updater implementation.
• Raw logs, screenshots, personal paths, process inventories, and private marketplace details are intentionally omitted. The diagnostic results above are a sanitized summary.

Related open reports:

• #3922 reports plugin update failures with os error 5, but does not establish the same directory-lock cause.
• #3838 reports insufficient file/path details in plugin upgrade and uninstallation errors.

This issue focuses specifically on coordinating Windows plugin replacement with active MCP workers.