{"version":"2.1.273","anchor":"api-key-helper-now-routed-through-model-catalog-policy-check","canonical_anchor":"auth-type-detection-now-reports-whether-the-api-key-came-fro","heading":"API keys sourced from apiKeyHelper now go through model-catalog policy checks","tier":"internal","area":"Models","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273\/e\/api-key-helper-now-routed-through-model-catalog-policy-check","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273","markdown":"### API keys sourced from apiKeyHelper now go through model-catalog policy checks\n\nAuth detection now recognizes keys from apiKeyHelper and routes them through the same model-catalog policy check as other auth methods\n\n**What**\n\n- The function that determines the active authentication type now returns both the auth type and whether the API key came from an `apiKeyHelper`, and treats a key sourced this way as present even if its actual value is empty or falsy.\n\n- A new `api_key_helper` case was added to the logic that decides model-catalog access policy, so it now goes through the same `allow_model_catalog` policy check that was previously only applied to `not_claude_ai_auth`. The no-auth-method case also gained API-key-specific served-catalog handling.\n\n**Why**\n\nThis ensures that when an organization supplies API keys via an `apiKeyHelper` script rather than a static key, Claude Code correctly recognizes that an API key is in use and applies the same model-catalog access policy as it does for other authentication methods.\n\n- Area: Models\n- Names: `api_key_helper`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}