Malformed admin fallback settings payloads are caught at startup instead of silently doing nothing.
What's wrong with this entry?
The default and per-OS defaultSettings payloads inside policyHelpers are now parsed as managed-settings objects, so a malformed admin payload is caught at startup instead of silently doing nothing.
- Any nested
policyHelper/policyHelpersinside a payload is stripped before the rest is validated. - Delivered from an OS-admin policy source, a payload that does not validate stops Claude Code from starting.
not a valid static settings payload — Claude Code refuses to start on it when delivered from an OS-admin policy source
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