Claude Code Server-Managed Settings: The Admin Console Push That Replaces Your MDM Pipeline

Last week I argued that if you have more than a handful of engineers on Claude Code, repo-level .claude/settings.json is not enough — you need managed-settings.json deployed through MDM. That is still true. What changed in 2026 is that you no longer need an MDM team to roll it out.

Claude Code now supports server-managed settings: a remote configuration tier pushed from the Claude.ai admin console, with no file on disk and no MDM involvement. If you are on the Team plan running Claude Code 2.1.38+ or the Enterprise plan running 2.1.30+, this is available to you today, and most platform teams I talk to are still treating MDM-deployed managed-settings.json as the only option.

It is not. And the precedence rules matter.

The New Top of the Settings Hierarchy

Claude Code’s settings stack already had a clear order — repo > user > project > local — with managed settings sitting on top of all of them as the unoverridable tier. Server-managed settings now sit at the same top tier alongside MDM and the on-disk managed-settings.json file. Within that managed tier, the documented precedence is:

1. Server-managed settings (admin console push)
2. MDM / OS-level policies (Jamf, Kandji, Group Policy, Intune)
3. managed-settings.json on disk (the file we deployed last week)
4. HKCU registry (Windows)

Server-managed wins. If you push a policy from the admin console that conflicts with a fleet managed-settings.json deployed by MDM, the server policy applies. That is the entire point.

What This Actually Replaces

For organizations without a mature endpoint management pipeline — which is most companies smaller than a couple hundred engineers — the old path looked like this: get IT to package a JSON file, push it through Jamf or Group Policy, verify on a pilot machine, then deploy fleet-wide. Two-week ticket minimum.

Server-managed settings collapse that to: log into the admin console, write the policy in the UI, save. Claude Code clients fetch the new policy at startup and re-poll hourly during active sessions. No reboot. No reinstall. No ticket.

This is a real change in posture. The friction that kept smaller teams from deploying any managed policy at all just dropped to near zero.

The Approval Gate Most Teams Will Hit

Server-managed settings have one behavior MDM-deployed settings do not: certain categories require explicit user approval before they apply on a given machine. The current list per the docs:

• Shell command settings (custom commands surfaced to the model)
• Custom environment variables (anything injected into the model’s process env)
• Hook configurations (pre/post-tool-use hooks)

These three need the user to click through an approval prompt the first time the new policy hits their client. Deny rules in permissions.deny, the audit log path, telemetry settings, default model — those apply silently.

The reasoning here is sound: a malicious admin (or a compromised admin account) could otherwise inject a hook that exfiltrates every prompt or a shell command that pipes diffs to an external endpoint. Approval gating those three categories means a developer at least sees the change before it takes effect. It also means your “push the new hook policy fleet-wide” plan has a manual confirmation step you cannot skip.

If you need silent enforcement of hooks or shell commands, MDM-deployed managed-settings.json still does that without the prompt. Use the right tool for the right setting.

What Belongs on the Server, What Belongs in MDM

After running both for two weeks across a small fleet, the split that has held up:

Push from the admin console:

• permissions.deny rules that should be hot-updatable when a new exfil vector is discovered
• Default model pinning (when you want to change it without re-deploying)
• Telemetry and audit log endpoints
• Anything you want to A/B across user groups (more on this in a second)

Keep in MDM managed-settings.json:

• Hook configurations you need to enforce silently
• Shell command allowlists that must apply before first launch
• Anything that needs to survive the user being signed out of their org account

The reason for the second list is that server-managed settings only apply once the user authenticates with org credentials. A fresh laptop with a developer running claude before signing in gets no server policy. MDM-deployed settings apply from the first invocation.

Group-Targeted Policies Are the Sleeper Feature

Anthropic added user groups to the admin console earlier in 2026. Groups can be created manually or synced from an IdP via SCIM, and each group can be assigned a custom role plus its own spend limit. The piece most teams have not connected yet: server-managed settings respect group membership.

This means you can push one permissions.deny policy to the “Security” group and a different one to the “Platform” group without writing two separate managed-settings.json files and pushing them through MDM with different scoping. Write two policies in the console, assign to groups, done. Group membership changes via SCIM propagate within the hour-long polling window.

For a 200-engineer org that previously needed Jamf smart groups + MDM JSON variants to do the same thing, this is significant.

Verification Workflow

The same verification workflow from the MDM-deployed setup still applies, with one addition:

1. Push the policy in the admin console
2. On a test machine, run claude config list — server-managed settings should appear flagged as such
3. Attempt a denied action, confirm immediate block
4. If hooks or shell commands are in the policy, walk through the approval prompt
5. Sign the test user out, sign back in, confirm policy reapplies

The sign-out test matters because that is where server-managed differs most from on-disk managed settings — the policy is bound to the org-authenticated session, not the machine.

Model Versions for Org-Wide Pinning

If you pin a default model via server-managed settings, the current strings are: claude-opus-4-7 (flagship), claude-sonnet-4-6 (workhorse), and claude-haiku-4-5-20251001 (fast). Verify against the live model list at docs.anthropic.com/en/docs/about-claude/models before deploying — model strings change frequently and pinning to a deprecated one will silently break agent runs.

Where Server-Managed Settings Lose

Three real limitations:

1. No silent hook/shell-command enforcement. User approval is mandatory for those three categories.
2. No effect before org auth. Pre-auth sessions ignore server policy entirely.
3. No fine-grained rollback. Console changes apply globally within the hour. There is no canary group, no staged rollout percentage, no “apply to 10% of fleet for 24 hours” toggle. If you push a bad deny rule, every active session picks it up at next poll.

Mitigate the third one by maintaining a single non-production test group that you deploy to first, wait 90 minutes, then promote the policy to broader groups. It is a manual canary, but it is the canary you have.

The 20-Minute Rollout for a Team Already on Team Plan v2.1.38+

1. Open the admin console at claude.ai → Settings → Claude Code policies
2. Write a minimum-viable policy: deny curl, wget, rm -rf /, .env reads, credential files
3. Assign to a single test group (one user)
4. On that user’s machine, run claude config list — confirm the server policy appears
5. Try three denied actions, confirm all blocked
6. Expand assignment to one team
7. Wait 24 hours, watch for tickets
8. Roll org-wide

The whole sequence takes longer than it runs because of the wait windows, not because of the work. The actual work is twenty minutes.

Why This Article Exists

The MDM-deployed managed-settings.json approach from last week is still the right answer for orgs that need silent, pre-auth policy enforcement. For everyone else — which is most teams adopting Claude Code in 2026 — server-managed settings are the easier path and most platform teams I talk to do not know they exist yet. Admin console push, no on-disk file, no MDM dependency, group-scoped via SCIM. If you are on a recent Team or Enterprise plan, this is the deployment posture you actually want.

Sources

• docs.anthropic.com/en/docs/about-claude/models (model version strings)
• code.claude.com/docs/en/server-managed-settings (server-managed settings docs)
• code.claude.com/docs/en/admin-setup (admin setup reference)
• support.claude.com/en/articles/11845131-use-claude-code-with-your-team-or-enterprise-plan (Team/Enterprise Claude Code usage)
• support.claude.com/en/articles/13799932-manage-groups-and-group-spend-limits-on-enterprise-plans (group management + spend limits)
• support.claude.com/en/articles/13133195-set-up-jit-or-scim-provisioning (SCIM provisioning)
• claude.com/product/claude-code/enterprise (Enterprise plan overview)
• anthropic.com/news/claude-code-on-team-and-enterprise (admin controls launch)