Managed Settings: Enterprise Policy

The Organizational Safety Floor

User and project settings let individuals and teams customize Claude Code for their context. Managed settings define the floor below which no customization can go. They are deployed by administrators through MDM, configuration management tools, or Anthropic's server-managed settings system, and they take precedence over every other settings source — including command-line arguments.

If you need a guarantee that every developer in your organization uses the sandbox, cannot enter bypassPermissions mode, and can only install the MCP servers you have vetted, managed settings are the mechanism. Individual developers can still configure Claude Code within the bounds you set, but they cannot override the floor.

Delivery Mechanisms

Managed settings reach developer machines through several paths depending on your platform and infrastructure:

• macOS: A plist file deployed via MDM (Jamf, Kandji, etc.) under the Claude Code preference domain, or a JSON file at the system-level managed settings path.
• Linux: A JSON file at /etc/claude-code/managed-settings.json.
• Windows: Registry keys under the HKLM hive, or a JSON file at C:Program FilesClaudeCodemanaged-settings.json.
• Server-managed settings: Configured in Claude.ai admin settings and delivered to Claude Code at startup. Requires an internet connection to fetch. Set forceRemoteSettingsRefresh: true to make Claude Code refuse to start if it cannot fetch fresh settings — fail-closed enforcement for environments that require a live policy check at startup.
• SDK managedSettings option: Pass inline JSON per invocation when embedding Claude Code in automation. Values can tighten organizational policy but cannot loosen it.

The Settings Precedence Chain

Understanding where managed settings sit in the precedence chain is essential for predicting how conflicts resolve:

A deny rule set in managed settings cannot be removed at any lower level. A disabledMode setting in managed settings cannot be re-enabled by user settings. The chain is strictly additive in the restrictive direction.

The Managed-Only Keys

Some settings keys are only read from managed settings. Placing them in user or project settings has no effect. These are the most important organizational controls:

• allowManagedPermissionRulesOnly: When true, only allow, ask, and deny rules from managed settings apply. User, project, and local settings cannot add their own permission rules. Use this when you need the organizational rule set to be authoritative.
• allowManagedMcpServersOnly: When true, only MCP servers in the managed allowlist are loaded. Developers cannot add their own servers. Use this to limit Claude Code to vetted integrations.
• allowManagedHooksOnly: When true, only hooks from managed settings and force-enabled plugins are loaded. Project and user hooks are blocked. Use this to prevent project hooks from circumventing organizational security gates.
• strictPluginOnlyCustomization: Blocks skills, agents, hooks, and MCP servers from user and project sources entirely, limiting them to plugins and managed settings. Can be set to true (lock all) or an array of specific surfaces like ["hooks", "skills"].
• forceRemoteSettingsRefresh: Blocks Claude Code from starting until managed settings are freshly fetched, and exits if the fetch fails. Ensures policy is always current.
• sandbox.filesystem.allowManagedReadPathsOnly: Only sandbox read-allow paths from managed settings are honored — developers cannot widen read access beyond the managed list.
• sandbox.network.allowManagedDomainsOnly: Only managed domain allowlist entries apply. Non-allowed domains are blocked automatically rather than prompting.
• disableSideloadFlags: Rejects --plugin-dir, --plugin-url, --agents, and --mcp-config CLI flags at startup, preventing bypass of managed restrictions via one-time flags.

A Practical Managed Configuration

A reasonable baseline for an engineering organization that uses internal infrastructure:

{ "permissions": { "disableBypassPermissionsMode": "disable", "disableAutoMode": false }, "sandbox": { "enabled": true, "failIfUnavailable": true, "allowUnsandboxedCommands": false, "credentials": { "files": [ { "path": "~/.aws", "mode": "deny" }, { "path": "~/.ssh", "mode": "deny" } ] } }, "allowManagedMcpServersOnly": true, "autoMode": { "environment": [ "$defaults", "Organization: Acme Corp. Primary use: software development.", "Source control: github.com/acme-corp and all repos under it", "Trusted internal domains: *.acme.internal, api.acme.com", "Key internal services: Jenkins at ci.acme.com, Artifactory at artifacts.acme.com" ] } }

This configuration: disables bypassPermissions for all developers, requires the sandbox (and fails if unavailable), locks down credential reads for AWS and SSH, restricts MCP servers to the managed list, and gives the classifier the infrastructure context it needs for routine internal operations to succeed without repeated denials.

Anthropic publishes SOC 2 Type 2 and ISO 27001 certifications through the Anthropic Trust Center for organizations that need compliance documentation for their Claude Code deployment.