What probably matters to youSection of the release
What
A managed-settings policy helper, the per-OS script an administrator points Claude Code at to generate settings, now takes an outputBehavior field that says whether the settings payload it produces replaces that source's settings or merges over them. The field is only read on the per-OS policyHelpers entries; on the singular policyHelper key it is ignored and the helper's output replaces the policy tier regardless. An unrecognised value on a per-OS entry is not tolerated: the whole entry is dropped and no policy helper runs on that operating system.
Details
"merge" is the one value checked explicitly at the points where the generated payload is applied; anything else on a valid entry means replace.
The field is new in this build and did not exist in 2.1.241, so existing helper configurations keep replacing until they opt into merging.
Setting outputBehavior on the singular policyHelper produces a status-only warning during managed-settings loading and validation, saying it is ignored; nothing about the helper's behaviour changes.
An unrecognised value is reported as leaving it unknown whether the payload replaces or merges over that source's settings, and the entry is discarded rather than guessed at.
Helper fingerprinting now also records the byte size of each inline helper script under its policyHelpers.* key, and the helper store keeps a set of retired helper paths.
Evidence
"outputBehavior" is unrecognized, so whether the payload replaces or merges over this source's settings is unknown., on the singular policyHelper is ignored, "outputBehavior" on the singular policyHelper is ignored
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
