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

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.

Start by reproducing the policy flow with managed-settings.json and .github/copilot/settings.json, then inspect the interactive startup path and the resulting ~/.copilot/config.json. Compare policy-driven entries with user settings entries and use copilot plugins list and copilot plugins update --all to verify behavior. Done means an enabledPlugins entry is installed with enabled: true and its skills are active on a subsequent interactive start.