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 Hooks use the same format as in 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
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.settings.json.This example runs an audit script after every file edit across the organization: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
/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
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.jsonfile through server-managed settings. Deliver theallowedMcpServersanddeniedMcpServerspolicy keys there instead. On Claude Code v2.1.259 or later, you can also provide remote servers withmanagedMcpServers, which acceptshttpandsseservers only and doesn’t take exclusive control the way the file does. Claude Code reads amanaged-mcp.jsondeployed 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
policyHelperandwslInheritsWindowsSettings, aren’t honored. Deploy them through MDM or a systemmanaged-settings.jsonfile instead. ApolicyHelperdeployed 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 whosepolicyHelper 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
policyHelpersupplies managed settings, its output is the only source these checks read, apart fromforceRemoteSettingsRefresh, which Claude Code reads from the admin sources directly at startup. - The
envblock: 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-managedenventry 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 wholeenvblock only.- Telemetry unit: the
OTEL_EXPORTER_OTLP_*exporter keys, theOTEL_LOG_*content-capture toggles,OTEL_LOGS_EXPORTER, and the beta tracing variablesENABLE_BETA_TRACING_DETAILEDandBETA_TRACING_ENDPOINTfollow the highest source that sets any of them as a unit. A source that delivers theotelHeadersHelpercredential 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
apiKeyHelperorotelHeadersHelper, contributes those routing variables only when it wins the slot.
- Telemetry unit: the
- Gateway sign-in keys: Claude Code never reads
forceLoginGatewayUrlor the"gateway"value offorceLoginMethodfrom 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. ThemanagedSourcesBehaviorentry says which admin source on the machine supplies them.