{"version":"2.1.323","anchor":"policy-managed-helper-commands-can-be-wrapped-by-a-new-check","canonical_anchor":"policy-managed-helper-commands-can-be-wrapped-by-a-new-check","heading":"Helper commands not matching policy may now run through a wrapper","tier":"notice","area":"Managed Settings","scope":"org","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/policy-managed-helper-commands-can-be-wrapped-by-a-new-check","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### Helper commands not matching policy may now run through a wrapper\n\nA helper command that does not match the organization's policy setting may now be started through a wrapper instead of directly\n\n**Unclear.** It is not clear what the extra check looks at or what the wrapper changes about how the command runs.\n\n**What**\n\nSettings can name helper commands that Claude Code runs for you, such as `apiKeyHelper`, which fetches an API key. An organization's policy settings can name these commands too. When the configured helper command does not match the one in policy settings, Claude Code now runs an extra check. If that check passes, Claude Code starts the command through a wrapper instead of running it directly.\n\n**Why**\n\nThis may change how helper commands such as `apiKeyHelper` are launched.\n\n- Area: Managed Settings\n- Names: `apiKeyHelper`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5\n- Scope: org\n- Heads-up: yes"}