Under the hood
The policy helper subprocess now has a hard timeout cap and reports a distinct timed_out error.
policyHelper subprocess execution now clamps its configured timeout to an internal maximum, and when that limit is hit, returns a distinct timed_out error code with a "timed out after Xms" message instead of falling through to the generic exit-code handling.
Names in the bundlepolicyHelper
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 Configure server-managed settings touched a line naming policyHelper after this was published.
When a [`policyHelper`](/docs/en/settings-reference#policyhelper) supplies managed settings, its output is the only source these checks read, apart from [`forceRemoteSettingsRefresh`](/docs/en/settings-reference#forceremotesettingsrefresh)…server-managed-settings see the edit
Confirmed since
Anthropic's documentation has since written up policyHelper, on All settings.
| Read from the highest-priority source only | Reads the key only from the highest-priority source that carries a policy key, so a lower source's value is ignored even when the highest source sets none | [`apiKeyHelper`](#apikeyhelper), [`…settings-reference see the edit
Two sources agreeTwo things we can check say the same as this entry.
Anthropic's documentation agrees
Anthropic's documentation has since written up policyHelper, on All settings.
Anthropic's release notes agree
Fixed policyHelper timeoutMs and refreshIntervalMs values above the timer maximum (2147483647) causing failures or re-runs every…