Admins can ship managed settings directly in policy, including per-OS defaults, without running a helper program.
What's wrong with this entry?
policyHelpers, the top-level setting where an IT admin points Claude Code at a program that supplies managed settings, now also accepts a plain default settings payload and a per-OS defaultSettings payload used when no helper runs or the helper cannot be reached.
defaultsits at the top of thepolicyHelpersmap;defaultSettingssits inside each per-OS entry next to that OS's helper executable.- The parse-failure message for
policyHelperswas rewritten to describe the new shape. - When the setting comes from an OS-admin policy source and does not parse, startup fails rather than falling back.
plus an optional "default" settings payload
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.228
Managed settings accept per-OS
policyHelpersBoth mention policy helper managed
-
v2.1.228
New
policyHelpersmanaged-settings key for per-OS policy helper executablesBoth mention policy helper managed
-
v2.1.235
Policy helpers can be delivered by remote managed settings, after explicit approval
Both mention policy helper managed