{"version":"2.1.265","anchor":"policyhelpers-per-source-shadowing-warning-gated-behind-man","canonical_anchor":"new-retryable-policy-helper-execution-engine-with-backoff-a","heading":"policyHelpers gets retries, remote sourcing, and clearer validation","tier":"use","area":"Managed Settings","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/policyhelpers-per-source-shadowing-warning-gated-behind-man","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### policyHelpers gets retries, remote sourcing, and clearer validation\n\nOrganization-managed policyHelpers now retry on failure, can come from remote managed settings, and warn on misconfiguration\n\n**What**\n\n- A full retry-and-backoff engine for organization-managed `policyHelpers` (per-OS helper scripts or static settings payloads) was added, covering arming, execution, retrying, and telemetry, including remote (managed-settings-dialog) arming\/consent flows and mid-session re-arming. Helper failures are classified as transient (non-zero exit, timeout, missing file, interpreter unavailable) and retried with bounded exponential backoff, or permanent (bad path, oversized, parse failure, invalid envelope, schema rejected) and not retried.\n\n- `policyHelpers` can now be honored from remote managed settings, not just admin-controlled policy sources, for plain policy payloads; a helper or any payload touching something the managed-settings approval dialog lists still requires the settings to be verified and approved first that session. The singular `policyHelper` key itself is still never honored from remote.\n\n- New validation messages explain that `onFailure` and `retries` are ignored when set on the singular `policyHelper` key, and are honored only on the per-OS `policyHelpers.<os>` entries; a missing helper combined with `onFailure: refuse` and no static fallback is now startup-fatal when delivered from an OS-admin policy source.\n\n- A new warning fires when more than one managed-settings source defines helper configuration and `managedSourcesBehavior` is `\"merge\"`, since only the highest-priority source's helper configuration actually takes effect.\n\n- A warning (status-only, or startup-fatal via MDM\/managed settings) now flags cases where `onFailure: \"require\"` has no usable default fallback, since a failing helper with no `defaultSettings` would otherwise silently produce nothing.\n\n- When no per-OS entry matches and Claude Code falls back to a static default settings payload, it no longer logs an info message or fires a telemetry event about the fallback; this now happens silently.\n\n**Why**\n\nTogether these changes make organization-managed policy helpers more robust and predictable: failures retry sensibly, misconfigurations are caught early instead of silently doing nothing, and administrators get clearer signals about which settings actually take effect when multiple sources conflict.\n\n- Area: Managed Settings\n- Names: `managedSourcesBehavior`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 3\/5"}