# Claude Code v2.1.175 > Claude Code v2.1.175, released 12 Jun 2026 (2026-06-12). 9 entries read out of the shipped bundle. Unofficial, and not affiliated with Anthropic. Web version: https://changelogs.core-directive.com/v/2.1.175 This release introduces a comprehensive model allowlist enforcement system for organizations, allowing admins to restrict which Claude models users and agents can access. Users affected by these policies now see clear warning indicators in the status line and informational messages explaining why a model switch was blocked or redirected. ## New Features ### Organization-Enforced Model Allowlist (`enforceAvailableModels`) **What** Administrators can now configure an `availableModels` allowlist in policy settings to restrict which Claude models users and agents are permitted to use. When `enforceAvailableModels` is set to true alongside a non-empty `availableModels` list, any attempt to use a model outside the list is silently redirected to the next allowed model, and a warning is displayed. **Details** - Controlled via the `enforceAvailableModels` and `availableModels` keys in organization policy settings - If the user's preferred model (from CLI flag, SDK request, or `/model` switch) is not in the allowlist, Claude Code falls back to the nearest allowed model - Model overrides (`modelOverrides`) allow admins to map model aliases or families to specific allowed variants - The system applies a "cascade trust" model: if an admin policy source exists but fails to load, enforcement is suspended and a warning is logged rather than silently defaulting to less-restricted behavior - Plan mode also respects the allowlist — if the Opus or Haiku upgrade model used during planning is not in the allowlist, planning falls back to the resting model with a logged warning - Agent and skill model requests are checked against the allowlist; blocked models trigger a notification rather than silently using an unauthorized model **Evidence** New policy enforcement engine (search for `"enforceAvailableModels: a policy source exists but failed to load"`) ### Model Restriction Warning in Status Line **What** When an organization policy forces a different model than you requested, a warning indicator now appears in the status line showing what you asked for and what is actually being used. **Details** - New `model-restricted` warning entry in the status line, displayed at the `warning` tier (higher prominence than informational indicators) - The warning shows both the requested model name and the effective model being used - Replaces the `model-source` info indicator when a restriction is active — the two do not display simultaneously - The session also emits an inline warning message at startup when a startup-time restriction is detected **Evidence** New status line entry (search for `"model-restricted"`) ### "Set by your organization" Model Indicator **What** When your active model has been selected or constrained by an organization policy, a `· Set by your organization` suffix now appears in model information displays. **Evidence** New indicator function (search for `"· Set by your organization"`) ### `CLAUDE_CODE_REMOTE_MEMORY_DIR` Environment Variable **What** A new environment variable lets you specify a custom directory for remote memory storage, overriding the default location. **Usage** `CLAUDE_CODE_REMOTE_MEMORY_DIR=/path/to/memory claude` **Details** - If set, remote memory reads and writes use the specified directory instead of the default path - Useful in containerized or shared environments where memory files should reside at a specific location **Evidence** New env variable handler (search for `"CLAUDE_CODE_REMOTE_MEMORY_DIR"`) ## Improvements ### Sharper Model Restriction Notifications for Agents When an agent or skill requests a model that is blocked by the `availableModels` allowlist, a medium-priority warning notification is now shown to the user identifying which agent type made the request and what restriction was applied. Previously, blocked model requests could fail silently. **Evidence** New `onModelRestricted` callback in agent invocation (search for `"agent-model-restricted-"`) ### Safer Model Change Handling in SDK/Remote Sessions The `set_model` and session-initialization code paths now verify model names against the allowlist before applying them. If a model is not allowed, the change is rejected and the user sees an actionable warning message instead of the session silently using an unexpected model. **Evidence** Updated `onSetModel` handler (search for `"model-restricted-bridge-"`) ### `availableModels` Propagated from Policy Tier The policy settings merge now correctly propagates `availableModels` from the first (highest-priority) policy tier into the merged view used by the allowlist checker. In the previous version this field was not forwarded through the merge, so the new enforcement system could not see it. **Evidence** Policy merge update (search for `"availableModels: w[0]?.availableModels"`) ### Improved Safety Message Wording The message shown when a model declines a request due to safety measures now reads "has safety measures that flagged something in this session" (previously "has measures that flagged something in this session"). The wording more clearly attributes the behavior to safety systems rather than the model generically. **Evidence** Wording change (search for `"has safety measures that flagged something in this session"`) ## Bug Fixes - Fixed plan-mode model selection not checking the allowlist when upgrading from Haiku or Opus plan model — the upgrade model is now validated and falls back gracefully with a warning rather than attempting to use an unauthorized model. (search for `"Plan mode: the haiku plan upgrade model is not in the availableModels allowlist"`) - Fixed a regression where model name matching used an incomplete word-boundary check that could incorrectly match substring model names in the allowlist. The new matcher (`ekK`) requires non-alphanumeric boundaries on both sides of the match. (search for `"ekK"` — the new boundary-aware substring matcher)