Policy-driven enabledPlugins installs the plugin but persists "enabled": false, so it never activates (1.0.83) — reproduces via device/MDM and repo-level settings

Comece reproduzindo o fluxo de políticas com managed-settings.json e .github/copilot/settings.json; em seguida, inspecione o caminho de inicialização interativa e o ~/.copilot/config.json resultante. Compare as entradas orientadas por políticas com as entradas das configurações do usuário e use copilot plugins list e copilot plugins update --all para verificar o comportamento. Considera-se concluído quando uma entrada de enabledPlugins é instalada com enabled: true e seus skills estão ativos em uma inicialização interativa subsequente.

Describe the bug

A policy/configuration-driven enabledPlugins entry installs the named plugin to disk, but records it in ~/.copilot/config.json as "enabled": false. The plugin's skills never activate, and the state does not self-correct on subsequent interactive starts. There is no error or warning.

This reproduces via two independent delivery channels, which suggests the defect is in the shared policy-install path rather than in any one channel:

1. Device/MDM — %ProgramFiles%\GitHubCopilot\managed-settings.json (source=mdm)
2. Repository/folder-level — .github/copilot/settings.json in a trusted folder, with no managed policy present at all (effective policy resolved: source=none)

In both cases the plugin is fetched and written to disk correctly and then left inert.

This is the same symptom as #4283 (closed as completed on 2026-09-03, no fix version stated), which was reported against the server-managed channel. It is distinct from #4039: there the plugin was marked installed/enabled but never synced to disk — here the sync to disk succeeds and the enablement flag is the thing that is wrong.

Affected version

GitHub Copilot CLI 1.0.83 (Windows, x86_64). Latest published at time of writing (npm view @github/copilot version → 1.0.83).

Steps to reproduce the behavior

1. Create %ProgramFiles%\GitHubCopilot\managed-settings.json, owned by BUILTIN\Administrators:

   {
     "extraKnownMarketplaces": {
       "example-marketplace": {
         "source": { "source": "github", "repo": "org-name/marketplace-repo" },
         "autoUpdate": true
       }
     },
     "enabledPlugins": {
       "example-plugin@example-marketplace": true
     }
   }
   

   org-name/marketplace-repo is a private repository the signed-in user has access to. example-plugin is not installed and does not appear in ~/.copilot/settings.json.

2. Start an interactive session from a folder listed in trustedFolders in ~/.copilot/config.json (auto-install does not fire in -p mode, cf. #4507):

   copilot --log-level debug --log-dir <dir>
   

3. Confirm from the log that the policy loaded:

   [managedSettings] device MDM policy loaded: bypassDisabled=false, keys=[enabledPlugins,extraKnownMarketplaces]
   [managedSettings] effective policy resolved: source=mdm, bypassDisabled=false, serverFetchFailed=false, ...
   

4. Exit the session, then inspect the install directory and ~/.copilot/config.json.

5. Start a second interactive session in the same folder and re-inspect.

Expected behavior

example-plugin@example-marketplace is installed and enabled, and the skills it contributes are available.

Actual behavior

The plugin is installed, with its skills present on disk:

~/.copilot/installed-plugins/example-marketplace/example-plugin/
  ├── .claude-plugin/plugin.json
  └── skills/<skill-name>

But ~/.copilot/config.json records it as disabled:

{
  "name": "example-plugin",
  "marketplace": "example-marketplace",
  "installed_at": "...",
  "cache_path": "...",
  "source_sha": "...",
  "enabled": false
}

Consequences observed:

• The skill it contributes does not appear in copilot plugins list and is not active in-session.
• A second interactive start leaves enabled: false unchanged.
• Plugins that appear in the user's own settings.json show "enabled": true in the same config.json, so only the policy-driven entry is affected.
• copilot plugins update --all reports Processed 8 installed plugins and does not consider the policy-named plugin.

Additional context

• The same policy file's model key is enforced — the session switched to the model named in policy — so the device channel is being honoured and parsed correctly (keys=[enabledPlugins,extraKnownMarketplaces,model]). The defect is specific to the enablement flag for policy-installed plugins.
• Practical impact for an enterprise rollout: a policy can place a plugin on every machine and leave it inert. Plugins whose value is in the hooks they contribute silently never run, so presence on disk is not a usable success signal — the enabled flag in config.json has to be checked instead. That makes the failure easy to mistake for a successful deployment.
• The documented semantics for the key are "Defines plugins that are automatically installed or blocked for all enterprise users", which reads as covering enablement as well as installation.