Claude Code can now block new model releases by policy

Claude Code 2.1.283 shipped two managed settings that let an admin block specific models and refuse new model releases outright. That is a small changelog line with a real consequence: your coding agent's model fleet stops changing without your say-so. If you have ever discovered that a vendor enabled something new by default and your team had been using it for a week, this is the control you wanted.

What actually happened

Per the Claude Code changelog, version 2.1.283 added:

• deniedModels, a managed setting to block specific models.
• availableModelsMatch, a managed setting whose "exact" option blocks new model releases.

Both are managed settings, meaning they are set by whoever administers the install, not by the developer at the keyboard. The same release also added MCP tool, WebFetch, and WebSearch outputs to tool.output OpenTelemetry span events, and /doctor prompt-audit to audit CLAUDE.md files for outdated model patterns.

The version before it, 2.1.282, is the one worth reading if you already rely on managed settings. It fixed managed permissions, autoMode, worktree, and attribution settings being partially ignored, and fixed managed settings ignoring mistyped boolean lock keys. 2.1.283 fixed the same class of bug for managed sandbox settings, where one invalid nested value voided the block.

Why model pinning matters for your business

Pin the version, then verify the pin. Those are two separate jobs and most teams only do the first.

The case for availableModelsMatch: "exact" is straightforward once you have been burned. A new model lands, it is better on average, and it is also different — different token consumption, different tool-calling behavior, different failure modes on the one prompt in your pipeline that was tuned around the old model's quirks. For an interactive session that is a minor annoyance. For a scheduled agent that opens pull requests unattended, it is a silent change to production behavior with no deploy and no diff. Regulated work makes it worse: if you told a client which model processes their data, a default-on upgrade makes that statement false without anyone lying.

The deniedModels case is narrower and more common than people admit. Cost, data residency, a model your legal review has not cleared — all reasons to keep a specific model off the menu rather than trusting everyone to remember.

Now the verify part. The 2.1.282 and 2.1.283 fixes describe managed settings that were silently dropped because one nested value was invalid or one boolean lock key was mistyped. That is the worst failure mode a policy system has: the config is present, the admin believes it is enforced, and nothing enforces it. Whatever policy layer you run — Claude Code, your CI, your cloud IAM — the control is only real if you have tested that it blocks something. Write a check that tries a denied model and expects a failure, and run it on the schedule you run everything else.

Sources: Claude Code changelog.