{"version":"2.1.223","anchor":"managed-settings-tier-merge-no-longer-falls-through-for-two-","canonical_anchor":"managed-settings-tier-merge-no-longer-falls-through-for-two-","heading":"Managed-settings tier merge no longer falls through for two keys","tier":"notice","area":"Managed Settings","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223\/e\/managed-settings-tier-merge-no-longer-falls-through-for-two-","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223","markdown":"### Managed-settings tier merge no longer falls through for two keys\n\nTwo admin-managed settings now come only from the top policy tier, so lower tiers can't sneak values in.\n\n**What**\n\nTwo admin-controlled keys are now read only from the highest-precedence tier, so a lower tier can no longer supply them when the top tier omits them.\n\n**Details**\n\n- `forceLoginOrgUUID` and `allowedMcpServers` now follow the rule `availableModels` already used, reading from tier index 0 only\n- previously each was taken from the first tier that happened to define it\n- the merge result gained a `present` field with `remote`, `mdm` and `file` booleans reporting which tiers were found\n\n**Evidence**\n\n`forceLoginOrgUUID: u[0]?.forceLoginOrgUUID`\n\n- Area: Managed Settings\n- Names: `forceLoginOrgUUID`, `allowedMcpServers`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 0\/5"}