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

TierUse it nowhow much it should matter to you
Useful3my rating, 1 to 5
Signal2worth watching, 1 to 5
AreaManaged Settingswhat it touches
KindNew Featuresin v2.1.265,
Group of 7 Use it now Notable

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.

Read from
Names in the bundleonFailureretries
Since it was published

The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.

Added since A small documentation edit on Claude Code gateway compatibility guide touched a line naming retries after this was published. * When the upstream rejects a [thinking signature](https://platform.claude.com/docs/en/build-with-claude/extended-thinking), including with a `400` whose message says the block is `bound to a different conversation`, Claude Code removes ea… llm-gateway-protocol see the edit
Confirmed since Anthropic's documentation has since written up retries, on List Events. The model is currently overloaded. Emitted after automatic retries are exhausted. api/beta/sessions/events/list see the edit
How sure we are
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agreesAnthropic's documentation has since written up retries, on List Events.

See this entry in the whole of v2.1.265 →

Feedback