Follow Discord
Sweep 22 Sep 2026 · 17:19Z Build v2.1.280 501 read Stable v2.1.267 Latest v2.1.280 Next v2.1.280 Feeds RSS JSON llms.txt Unofficial
Claude Code v2.1.265 ·

policyHelpers gets retries, remote sourcing, and clearer validation

Organization-managed policyHelpers now retry on failure, can come from remote managed settings, and warn on misconfiguration

TierUnder the hoodhow much it should matter to you
Useful1my rating, 1 to 5
Signal0worth watching, 1 to 5
AreaManaged Settingswhat it touches
KindInternal Changesin v2.1.265,
Group of 7 Under the hood

Organization-managed policyHelpers now retry on failure, can come from remote managed settings, and warn on misconfiguration

What

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Why

Together 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.

See this entry in the whole of v2.1.265 →

Feedback