Follow Discord
Sweep 22 Oct 2026 · 21:04Z Build v2.1.309 528 read Stable v2.1.308 Latest v2.1.308 Next v2.1.309 Feeds RSS JSON llms.txt llms-full.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

Group of 7 Use it now Notable No documentation found Improvements
JSON All of v2.1.265
Use it nowTier: how much it should matter to you
4Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
Managed SettingsArea: what it touches
ImprovementsKind: in v2.1.265,
What probably matters to youSection of the release

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.

Read from
Names in the bundlepolicyHelpers

See this entry in the whole of v2.1.265 →

Feedback