Policy helpers now take per-OS entries plus a static settings payload used when they fail.
What's wrong with this entry?
The managed-settings policy helper, an admin-controlled hook that supplies settings at startup, now takes separate entries for macos, linux, windows and wsl plus an optional default entry that is a plain settings payload rather than a program to run. A helper that fails at startup or refresh falls back to that static payload without spawning anything.
- Helper paths must be absolute, normalized and at most 1024 characters, with no control or invisible characters and no
.or..segments. - On Windows, UNC and drive-relative forms are rejected and the path must end in
.exe; on POSIX,/procand/netmagic roots are rejected. - Only honored from admin-controlled policy sources, not from user or project settings.
path must end in .exe on Windows
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