Admins can set managedSourcesBehavior to merge managed settings sources instead of only the top one.
What's wrong with this entry?
A new enterprise settings key, managedSourcesBehavior, accepts "first-wins" (the default, and exactly today's behaviour) or "merge". Under first-wins the highest-priority managed source present is the whole managed tier. Under merge, all present managed sources are deep-merged with fixed precedence and arrays unioned, so a lower source can contribute keys instead of being discarded. Any admin who sets the key gets it on this build; everyone else sees no change.
- Managed source precedence is server-managed, then MDM / OS policy, then
managed-settings.json. - Some keys never merge and are owned whole by the highest source present:
fallbackModel, the restriction allowlists (allowedMcpServers,availableModels,strictKnownMarketplaces,allowedChannelPlugins) and the login pins (forceLoginOrgUUID,forceLoginMethod,forceLoginGatewayUrl). - The key is only honored when set in the highest-priority source, so a lower source cannot opt itself into merging.
- Windows HKCU settings and
--managed-settingsnever take part in the merge. - The key is stripped from the settings object before composition, so it never leaks into effective settings. It does not exist in 2.1.241.
managedSourcesBehavior
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.248
Two new settings keys named: WSL settings inheritance and managed-source behaviour
Both mention managed source behavior