Claude Code managed settings: how a company enforces policy

Claude Code managed settings are the settings an organization deploys to every developer's machine, and Anthropic's documentation says Claude Code applies them above every other level: nothing in a developer's own settings files, or the --settings flag, overrides a managed key. A company can deliver them from the Claude admin console, through MDM or the Windows registry, or as a managed-settings.json file, and use them to lock permission rules, block bypass mode, pin logins to the company's organization and control which MCP servers and plugins are allowed. This guide covers how they are delivered, how they rank, the keys most teams start with, and what they cannot enforce. It was checked on November 9, 2026 against Anthropic's settings, permissions and server-managed settings documentation.

Why this matters now

Coding agents moved from individual experiments to company rollouts this year, and the questions that follow are about control: who can turn off the permission prompts, which models and MCP servers are allowed, and whether a developer can log in with a personal account on a work machine. On November 9, 2026 a report that a large bank was restricting Claude Code for some staff was one of the most discussed stories on Hacker News. We could not confirm that report with a primary source, so this post does not rely on it. Google autocomplete does show people searching "claude code enterprise policy" and "claude code enterprise rules", and Anthropic's documentation answers most of those questions directly.

The four ways to deliver managed settings

• Server-managed settings. Set in the Claude admin console under Organization settings, Claude Code, Managed settings. The documentation says Claude Code fetches them at startup and polls hourly. They need a Claude for Teams or Claude for Enterprise plan, the Owner or Primary Owner role, and network access to api.anthropic.com.
• macOS MDM. A configuration profile for the managed preferences domain com.anthropic.claudecode.
• Windows policy. The registry value Settings under HKLM\SOFTWARE\Policies\ClaudeCode. The user-writable HKCU equivalent is documented as the lowest-ranked managed source.
• A file on disk. managed-settings.json at /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux and WSL, and C:\Program Files\ClaudeCode\ on Windows. The documentation says the legacy C:\ProgramData\ClaudeCode\ path is not read. An optional managed-settings.d/ directory beside it holds drop-in *.json files, merged after the main file in alphabetical order, which is handy when different teams own different parts of the policy.

MCP servers that every developer should get can be described in a managed-mcp.json file in the same system directory. The server-managed documentation says that file cannot be distributed through the admin console, and that the allowedMcpServers and deniedMcpServers keys should be delivered there instead.

One limit on reach: the documentation says endpoint-managed files and MDM settings do not reach cloud sessions run by Anthropic. If developers also use those, set the policy in the admin console too.

How managed settings rank

The documented order, highest first, is managed settings, command line, project local (.claude/settings.local.json), shared project (.claude/settings.json), then user settings. Three details change how you write a policy:

• Lists merge. For list settings such as permission rules, the documentation says Claude Code combines the lists from every scope instead of picking one. A managed deny list adds to whatever developers have; it does not replace their allow rules unless you also use allowManagedPermissionRulesOnly (below).
• Deny wins everywhere. Rules are evaluated deny, then ask, then allow, and the documentation says that if a tool is denied at any level, no other level can allow it. An allow rule cannot carve an exception out of a deny rule.
• Not every key is a lock. The documentation says a managed model is a starting default, not a lock. To restrict models, it points to availableModels and deniedModels.

Keys most teams start with

These are the settings we would look at first for a company rollout. Each description follows Anthropic's settings reference; the choice of which to use is ours.

• permissions.disableBypassPermissionsMode set to "disable": prevents anyone from entering bypassPermissions mode and rejects --dangerously-skip-permissions. permissions.disableAutoMode does the same for auto mode.
• allowManagedPermissionRulesOnly (managed only): makes managed settings the only source of permission rules, ignoring allow, ask and deny rules in user, project, local and --settings files, and the --allowedTools flag. Strict, so test it with a pilot group first.
• permissions.deny for secret paths, for example Read(./.env), Read(./.env.*) and Read(./secrets/**). The permissions documentation says a Read deny rule also blocks Edit and Write on the same path, and that a .claudeignore file has no effect.
• forceLoginMethod and forceLoginOrgUUID: restrict how developers log in and pin claude.ai logins to your organization. The authentication documentation says a claude.ai login to any other organization then produces an error and Claude Code exits at startup.
• allowedMcpServers and deniedMcpServers: allowlist which MCP servers users can add, and block specific ones by URL, command or name. Pair these with the review steps in our MCP security checklist.
• strictKnownMarketplaces (managed only): controls which plugin marketplace sources users can add and install plugins from.
• sandbox: isolates Bash commands from the filesystem and network on macOS, Linux and WSL2. See how to sandbox an AI agent for what a sandbox does and does not cover.
• forceRemoteSettingsRefresh (managed only): blocks startup until server-managed settings are freshly fetched and exits if the fetch fails. Useful when a stale policy is worse than no session.
• cleanupPeriodDays and companyAnnouncements: how long transcripts are kept before deletion, and a message shown at startup, for example a link to your internal AI use policy.

A minimal starting file could look like this (ours, built only from keys and rule formats in the documentation):

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

With allowManagedPermissionRulesOnly on, developers' own allow rules stop working, so you will also need managed allow rules for the commands your teams run every day. Without it, drop that line and the deny list still applies on top of everyone's own rules.

What managed settings cannot enforce

• Path rules are not a full file boundary. The permissions documentation says Read and Edit deny rules do not apply to a command that reads files without naming them, such as grep -r pattern ., and points to the sandbox for OS-level enforcement.
• Bash rules are not a security boundary. The same page notes that a rule like Bash(curl *) does not stop /usr/bin/curl or sh -c '...'. Use network controls and the sandbox for anything that must hold.
• Local admins can change the source. The documentation notes that local admin rights let a developer edit the managed source itself. Server-managed settings and MDM are harder to change than a file, but device management is still what makes the policy stick.
• Some settings ask the user. The server-managed documentation says hooks, apiKeyHelper, a custom status line and some sandbox settings delivered from the console need the user's approval in an interactive session, and that Claude Code exits if the user rejects them.

Managed settings also say nothing about what data developers may paste into a prompt, which repositories are in scope or how output is reviewed. Those belong in a written AI use policy that the settings then back up; our AI governance and security audit covers both.

How we approach this

This is our approach, not a rule. For a client rollout we start with a pilot group on server-managed settings: bypass mode disabled, the login pinned to the company organization, deny rules for secret paths, and an MCP allowlist limited to servers someone has reviewed. Project teams keep a committed .claude/settings.json for their own allow rules, and personal approvals stay in an ignored settings.local.json (see our guide to that file). We turn on allowManagedPermissionRulesOnly only after the pilot shows which commands people actually need, because switching it on first tends to send developers looking for workarounds.

Sources: Claude Code, settings, Claude Code, permissions, Claude Code, server-managed settings, Claude Code, managed settings, Claude Code, authentication. All read November 9, 2026. These pages change often and show no last-updated date, so check them before deploying a policy.