A managed key blocks command-sourced plugins, falling back to your existing hook restriction.
What's wrong with this entry?
A new managed settings key, disableCommandPluginSources, stops plugins that come from a command source from being installed, updated or re-resolved. If it is unset it follows allowManagedHooksOnly, so an organization that already restricts hooks gets this too. Either key blocking produces a dedicated message naming both keys. Both fall back to blocking when the configured value fails validation. Only read from managed settings, so absent those, command sources stay allowed.
- Gates:
policySettings.disableCommandPluginSourcesandpolicySettings.allowManagedHooksOnly. - When blocked, the plugin is not installed or updated and its command is not run.
Command-sourced plugins are disabled by your organization's managed settings (disableCommandPluginSources / allowManagedHooksOnly). The plugin was not installed or updated and its command was not run.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.238
Managed settings can refuse plugin sources and marketplace updates
Both mention disable command source allow managed hook only
-
v2.1.238
Plugin marketplaces and archives can mint HTTP headers from a command
Both mention disable command source allow managed hook only
-
v2.1.242
Administrators and --bare can block plugin hooks from loading
Both mention disable allow managed hook only