Skip to main content
Server-managed settings let organization Owners centrally configure Claude Code from Admin Settings > Claude Code > Managed settings in the claude.ai console. Claude Code clients fetch these settings automatically when users authenticate with an eligible credential on a platform where server-managed delivery is supported. See Platform availability for the credentials and platforms that qualify.
Server-managed settings are available for Claude for Teams and Claude for Enterprise customers.

Requirements

To use server-managed settings, you need:
  • Claude for Teams or Claude for Enterprise plan
  • The Owner or Primary Owner role in your Claude organization, to view and edit the configuration
  • Network access to api.anthropic.com

Choose between server-managed and endpoint-managed settings

Claude Code supports two approaches for centralized configuration. Server-managed settings deliver configuration from Anthropic’s servers. Endpoint-managed settings are deployed directly to devices through native OS policies (macOS managed preferences, Windows registry) or managed settings files. If your devices are enrolled in an MDM or endpoint management solution, endpoint-managed settings provide stronger security guarantees because the settings file can be protected from user modification at the OS level. Endpoint-managed settings don’t reach cloud sessions in Anthropic-hosted environments, so organizations using Claude Code on the web should configure server-managed settings as well. Sessions in a self-hosted environment also read the managed settings file in the runner image. The settings precedence below says when that file applies.

Configure server-managed settings

1

Open the admin console

In the claude.ai console, go to Admin Settings > Claude Code > Managed settings.If the link redirects you to a different Admin Settings page instead of the Claude Code page, your account doesn’t have the required role. Admin and other non-Owner roles can’t view or edit managed settings, so ask an Owner or Primary Owner in your organization to make the change. See Access control.
2

Define your settings

Add your configuration as JSON. All settings available in settings.json are supported except those restricted to OS-level policy delivery; see Current limitations for that short list. This includes hooks, environment variables, and managed-only settings like allowManagedPermissionRulesOnly.This example enforces a permission deny list, prevents users from bypassing permissions, and restricts permission rules to those defined in managed settings. The Bash(curl *) rule matches curl as Claude writes it, not /usr/bin/curl or sh -c 'curl …'; for network enforcement that doesn’t depend on the command text, add a sandbox block with allowManagedDomainsOnly.
Hooks use the same format as in settings.json.This example runs an audit script after every file edit across the organization:
Because hooks execute shell commands, users in interactive sessions see a security approval dialog before Claude Code applies them.To configure the auto mode classifier so it knows which repos, buckets, and domains your organization trusts, deliver an autoMode block the same way; see Configure auto mode for how the autoMode entries affect what the classifier blocks and important warnings about the environment, allow, soft_deny, and hard_deny fields.
3

Save and deploy

Save your changes. Claude Code clients receive the updated settings on their next startup or hourly polling cycle.

Verify settings delivery

To confirm that settings are being applied, ask a user to restart Claude Code. If the configuration includes settings that trigger the security approval dialog, the user sees a prompt describing the managed settings the next time Claude Code fetches them: at the next start, or within an hour in a running interactive session. You can also verify that managed permission rules are active by having a user run /permissions to view their effective permission rules. To check the fetch outcome on a specific machine, have the user run claude doctor and read the Managed settings (remote) line. Requires Claude Code v2.1.248 or later. The line reports one of four outcomes:
  • The delivered settings loaded
  • Your organization has no server-managed settings configured
  • The fetch failed, with the cause and whether a cached policy still applies
  • Claude Code skipped the fetch, with the reason. See Platform availability for the providers and configurations that skip it
While the fetch is still in progress, the line reports that instead. In a running session, /status shows the same line after a failed fetch, and for some skipped-fetch causes, such as a third-party provider variable or a custom ANTHROPIC_BASE_URL exported in the user’s shell.

Access control

The following roles can manage server-managed settings:
  • Primary Owner
  • Owner
Restrict access to trusted personnel, as settings changes apply to all users in the organization.

Managed-only settings

Most settings keys work in any scope. A handful of keys are only read from managed settings and have no effect when placed in user or project settings files. See managed-only settings for the permission and plugin controls, or read the Scope column of the All settings index for the full set.

Current limitations

Server-managed settings have the following limitations:
  • Settings apply uniformly to all users in the organization. Per-group configurations are not yet supported.
  • You can’t distribute a managed-mcp.json file through server-managed settings. Deliver the allowedMcpServers and deniedMcpServers policy keys there instead. On Claude Code v2.1.259 or later, you can also provide remote servers with managedMcpServers, which accepts http and sse servers only and doesn’t take exclusive control the way the file does. Claude Code reads a managed-mcp.json deployed at its system path separately from the managed settings tier, so the file still applies when server-managed settings are in effect.
  • Settings restricted to OS-level policy sources, such as policyHelper and wslInheritsWindowsSettings, aren’t honored. Deploy them through MDM or a system managed-settings.json file instead. A policyHelper deployed that way runs only when its source is the one selected under precedence within the managed tier.

Settings delivery

Settings precedence

Server-managed settings and endpoint-managed settings both occupy the highest tier in the Claude Code settings hierarchy. No other settings level can override them, including command line arguments, apart from the exceptions to managed settings precedence. Within the managed tier, Claude Code by default uses the first source that delivers at least one policy key, checking server-managed settings first and then endpoint-managed settings, apart from the exception keys covered next. How Claude Code combines managed sources has the full ranking, the carve-out for the control keys, and the opt-in that applies every source. If the selected source is an MDM policy or managed settings file whose policyHelper supplies managed settings, the helper’s output replaces that source as the only managed configuration for the run. Claude Code doesn’t consult a policyHelper configured in MDM or file-based settings while server-managed settings deliver a policy key. If a later fetch finds the server-managed settings removed, Claude Code runs that helper right away instead of at the next launch. The policyHelper entry covers what happens when that run fails. If you clear your server-managed configuration in the admin console with the intent of falling back to an endpoint-managed plist or registry policy, be aware that cached settings persist on client machines until the next successful fetch, and the keys that apply only at the next launch, such as model, stay in effect until each client relaunches. Run /status to see which managed source is active.

Per-key exceptions across managed sources

Three kinds of keys are exceptions to the no-merge rule:
  • Cross-source lock keys: a small set of keys, such as the sandbox allowlist locks, listed on the managed settings page. Claude Code honors them when any admin-controlled managed source sets them; the user-writable HKCU registry tier is excluded. When a policyHelper supplies managed settings, its output is the only source these checks read, apart from forceRemoteSettingsRefresh, which Claude Code reads from the admin sources directly at startup.
  • The env block: apart from the telemetry unit and routing variables paired with a credential key, both covered below, it merges per key across the admin-controlled sources. For each environment variable, the highest-priority source defining it wins, and lower admin sources fill in variables the higher sources leave unset. An endpoint-managed env entry therefore applies whenever the server-managed configuration leaves that variable unset, or while a cached server value for it is withheld pending server confirmation. Requires Claude Code v2.1.223 or later. Before v2.1.223, Claude Code applies the selected source’s whole env block only.
    • Telemetry unit: the OTEL_EXPORTER_OTLP_* exporter keys, the OTEL_LOG_* content-capture toggles, OTEL_LOGS_EXPORTER, and the beta tracing variables ENABLE_BETA_TRACING_DETAILED and BETA_TRACING_ENDPOINT follow the highest source that sets any of them as a unit. A source that delivers the otelHeadersHelper credential key claims the unit too, but lands these variables only when it is the selected source: a source that isn’t selected but delivers the key contributes none of them and still blocks lower sources from filling them in. Either way, an exporter endpoint from one source can never pair with credentials from another.
    • Credential-paired routing: a source that pairs routing variables with a selected-source-only credential key, such as apiKeyHelper or otelHeadersHelper, contributes those routing variables only when it wins the slot.
  • Gateway sign-in keys: Claude Code never reads forceLoginGatewayUrl or the "gateway" value of forceLoginMethod from server-managed settings, so selecting server-managed settings neither supplies a gateway sign-in nor hides one set in an MDM policy or managed settings file. The managedSourcesBehavior entry says which admin source on the machine supplies them.