Claude Code enterprise: managed settings, policies and admin setup

Rolling out Claude Code in an enterprise comes down to four decisions: which API provider your developers authenticate to, how managed settings reach their machines, what those settings enforce, and how you track usage. Managed settings take precedence over every developer's local configuration, so they are where company policy lives.

This guide walks through those decisions in order, following Anthropic's administrator setup page and managed settings reference, read on 24 October 2026. SSO, SCIM and seat assignment happen at the Claude account level and are covered in Anthropic's Claude Enterprise Administrator Guide.

Which deployment option should an enterprise choose?

The provider decides billing, sign-in, compliance posture and which features developers get.

According to the enterprise deployment overview, Teams includes SSO, admin tools and server-managed settings, while Enterprise adds domain capture, role-based permissions and Compliance API access.

Some features need a claude.ai account: cloud sessions, cloud scheduled tasks, Code Review, Remote Control and the Chrome extension do not work with Console keys or cloud credentials alone. If you go the cloud route, read the Bedrock, Agent Platform and Foundry guide before you decide.

What are managed settings in Claude Code?

Managed settings are a settings.json-shaped policy that an administrator delivers and developers cannot override. Claude Code checks four sources, highest priority first:

By default, Claude Code uses the highest source that delivers at least one policy key and ignores the rest, without merging them, apart from a few keys it reads from every admin source. Setting managedSourcesBehavior to "merge" in the top source combines them instead.

The plist and HKLM locations need admin rights to write, so they resist tampering. HKCU is writable without elevation, so the docs describe it as a convenience default rather than an enforcement channel.

Managed values win over user and project settings, with a few security exceptions. Lists such as permissions.allow and permissions.deny merge across all sources, so developers can add to managed lists but not remove entries. See the Claude Code settings guide for the normal precedence rules.

How do you deploy a managed settings file?

The fastest route is a file placed by whatever tooling already manages your fleet:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true
}

This example blocks two file reads, turns off bypass mode and makes managed settings the only source of permission rules. Save it at:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux and WSL: /etc/claude-code/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

If several teams own parts of the policy, give each part its own file in managed-settings.d/ next to the main file. Claude Code merges managed-settings.json first, then each *.json file in that folder in alphabetical order, so names like 10-telemetry.json and 20-security.json control the order.

Confirm on one machine before rolling out: run /status, and the Setting sources line should show Enterprise managed settings (file).

How do server-managed settings work?

Server-managed settings deliver the same policy from Anthropic's servers, so you need no MDM. An Owner or Primary Owner writes JSON under Organization settings > Claude Code > Managed settings at claude.ai. Claude Code fetches it at startup and refreshes it hourly during a session.

Requirements from the server-managed settings page:

• A Claude for Teams or Claude for Enterprise plan
• The Owner or Primary Owner role
• Network access to api.anthropic.com

Hooks, which run shell commands, and some environment variables trigger a security approval dialog for the developer in interactive sessions. To check delivery on a machine, run claude doctor and read the Managed settings (remote) line, which reports whether the settings loaded, none exist, the fetch failed, or it was skipped.

The docs note that endpoint-managed settings give stronger guarantees on MDM-enrolled devices, because the OS protects the file. Endpoint settings don't reach cloud sessions, though, so organizations whose developers run cloud sessions should also configure server-managed settings. A mixed-provider company can combine server-managed settings for claude.ai users with a file or OS policy for everyone else.

What can administrators enforce?

Permission rules and the sandbox cover different layers. The docs point out that denying WebFetch blocks Claude's fetch tool, but if Bash is allowed, curl can still reach any URL; the sandbox's network allowlist closes that gap at the OS level. The permissions guide and sandbox guide cover the syntax, and the Claude Code security guide explains the threat model.

You can also deploy an organization-wide CLAUDE.md at the managed policy path. That is guidance for Claude, not an enforced rule.

On Enterprise plans that sign in through claude.ai or the Anthropic API, admins can restrict models, set a default model and cap effort from organization settings without deploying anything. Those controls don't reach Bedrock, Agent Platform, Foundry or Claude Platform on AWS, where you use availableModels, model and maxEffortLevel in managed settings instead.

How do you track Claude Code usage and spend?

On Teams and Enterprise, per-user usage and spend come from the spend report in analytics settings, not the dashboard. To push telemetry into your own observability stack, follow the Claude Code OpenTelemetry guide. Turning off Anthropic telemetry with DISABLE_TELEMETRY also stops the data that feeds your analytics dashboard.

How does Claude Code handle enterprise data?

The admin docs state that on Team, Enterprise, Claude API and cloud provider plans, Anthropic doesn't train models on your code or prompts, and your API provider determines retention. Zero Data Retention is available to qualified Claude for Enterprise accounts, and there is a HIPAA configuration for Enterprise organizations that have HIPAA enabled. For request-level audit logs, the docs recommend a gateway between developers and your provider, such as a self-hosted Claude apps gateway.

How do you roll Claude Code out to developers?

Anthropic's best practices for organizations:

1. Make install one step. A "one click" install in your dev environment drives adoption.
2. Invest in CLAUDE.md files at the org and repo level so Claude understands your codebase.
3. Start with guided usage: codebase questions, small bug fixes, and asking Claude to plan before it edits.
4. Pin model versions on cloud providers so upgrades happen when you decide.
5. Share MCP servers through a checked-in .mcp.json configured by one central team.

When developers hit login problems, the usual fixes are /logout then /login, claude update if the enterprise sign-in option is missing, and restarting the terminal.

Teams that standardize on shared skills often keep them in one repo. Kipt keeps prompts and Agent Skills as Markdown in a private GitHub repo you own and installs every skill with npx skills add https://github.com/<you>/<repo>.git --all -g. If your policy sets strictPluginOnlyCustomization, skills from user and project sources are blocked, so check that setting before you hand out an install command.