{"version":"2.1.232","anchor":"policy-helper-settings-are-now-per-os-with-a-static-fallback","canonical_anchor":"policy-helper-settings-are-now-per-os-with-a-static-fallback","heading":"Policy helper settings are now per-OS with a static fallback","tier":"use","area":"Managed Settings","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232\/e\/policy-helper-settings-are-now-per-os-with-a-static-fallback","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232","markdown":"### Policy helper settings are now per-OS with a static fallback\n\nPolicy helpers now take per-OS entries plus a static settings payload used when they fail.\n\n**What**\n\nThe 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.\n\n**Details**\n\n- Helper paths must be absolute, normalized and at most 1024 characters, with no control or invisible characters and no `.` or `..` segments.\n- On Windows, UNC and drive-relative forms are rejected and the path must end in `.exe`; on POSIX, `\/proc` and `\/net` magic roots are rejected.\n- Only honored from admin-controlled policy sources, not from user or project settings.\n\n**Evidence**\n\n`path must end in .exe on Windows`\n\n- Area: Managed Settings\n- Names: `policyHelpers`, `default`\n- Tier: Use it now\n- Useful: 3\/5\n- Signal: 3\/5"}