Org policy helpers can now arrive via remote settings, but only run after an admin approves the exact payload.
What's wrong with this entry?
policyHelpers, an org-configured program Claude Code runs to resolve policy, was previously accepted only from MDM or local managed settings. It can now be armed from remote settings, but it refuses to run until an admin approves the exact payload in the managed-settings dialog. Without approval it logs "not yet approved in the managed-settings dialog" and runs nothing. Approval is stored separately, is revoked whenever the payload changes, and the helper then runs in a stripped-down environment.
- The consent record is kept as
remote-settings-helper-consentand was added to the data purge list. Changing the remote payload revokes it; revocation part-way through a run discards the helper's output. - Declined or missing consent emits
settings_policy_helpers_per_oswithremote_consent_missing. - A remote-armed helper runs with known secret variables deleted (
ANTHROPIC_API_KEY,AWS_SESSION_TOKEN,GOOGLE_APPLICATION_CREDENTIALSand similar) and loader-style prefixes removed (LD_,DYLD_,NODE_OPTIONS,GIT_), withPYTHONNOUSERSITE=1,GIT_CONFIG_NOSYSTEM=1, and PATH/HOME-like variables pinned under/var/empty/claude-code-policy-helper(orC:\Windows\claude-code-policy-helper). - No feature flag is involved: this only affects orgs whose remote settings carry a per-OS
policyHelpersentry and who approve it.
not yet approved in the managed-settings dialog
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.232
Warnings when policy helper settings are nested in the wrong place
Both mention policy helper managed