{"version":"2.1.251","anchor":"blocked-commands-can-now-say-which-org-policy-blocked-them","canonical_anchor":"blocked-commands-can-now-say-which-org-policy-blocked-them","heading":"Blocked commands can now say which org policy blocked them","tier":"internal","area":"Policy","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251\/e\/blocked-commands-can-now-say-which-org-policy-blocked-them","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251","markdown":"### Blocked commands can now say which org policy blocked them\n\nOrg-disabled built-in commands now carry a policy name and label for explaining why they're gone.\n\n**What**\n\nBuilt-in commands that an organization can switch off, including heap dumps, team onboarding, and the design consent and revoke commands, now carry the policy name and a readable label such as \"Heap dumps\" next to their existing enabled check. This is the plumbing for telling you why a command is unavailable rather than just hiding it.\n\n**Details**\n\n- Each entry pairs a policy key like `allow_heap_dump` or `allow_team_onboarding` with a display label and a verb, so a message can be assembled grammatically.\n- The generic builder used for locally defined commands carries the same fields.\n- Whether a command runs is still decided by the existing policy checks; this only adds the wording.\n\n**Evidence**\n\n`featureLabel: \"Heap dumps\"`\n\n- Area: Policy\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}