How do I push Claude Code policy to my whole org when we do not have an MDM?

If your org has MDM, use endpoint-managed settings: ship a managed-settings.json via MDM so the file is protected at the OS level and cannot be tampered with between policy fetches. Server-managed settings are for everyone else. They deliver config from Anthropic’s servers at session start, no device enrollment required.

Step 1: Open the admin console

Navigate to Claude.ai > Admin Settings > Claude Code > Managed settings. You need the Primary Owner or Owner role. The full JSON you enter here is delivered to every developer’s Claude Code session on startup and hourly polling.

Step 2: Write the policy JSON

All settings.json keys work here. Common starting policy:

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

allowManagedPermissionRulesOnly: true is a managed-only key: it locks out project and user permission rules so developers cannot open exceptions themselves. Without it, your deny rules are suggestions.

To configure the auto-mode classifier so it knows your org’s trusted repos and domains:

{
  "autoMode": {
    "environment": [
      "Source control: github.yourcompany.com and all repos under it",
      "Trusted cloud buckets: s3://your-build-artifacts",
      "Internal domains: *.corp.yourcompany.com"
    ]
  }
}

To run an audit script after every file edit across the org:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "/usr/local/bin/audit-edit.sh" }
        ]
      }
    ]
  }
}

Step 3: Enforce fail-closed startup

By default, if the remote settings fetch fails at startup, the CLI continues without managed settings. There is a brief unenforced window. For environments where any unmanaged window is unacceptable:

{
  "forceRemoteSettingsRefresh": true
}

With this setting active, the CLI blocks at startup until settings are freshly fetched. If api.anthropic.com is unreachable, the CLI exits rather than proceeding. The setting is also cached locally after first delivery, so subsequent startups enforce fail-closed even before a fresh fetch succeeds.

Before enabling: verify that your network policies allow connectivity to api.anthropic.com. If that endpoint is firewalled, all developers are locked out.

How delivery works

Settings are fetched at startup and polled hourly. On first launch with no cache, the fetch runs asynchronously, which means there is a brief window before restrictions apply. On subsequent launches, cached settings apply immediately while a fresh fetch happens in the background. Cached settings survive network failures until the next successful fetch.

Within the managed tier, server-managed settings take complete precedence over endpoint-managed settings. If you deploy a managed-settings.json via MDM and also have server-managed settings active, the endpoint-managed file is ignored as long as the server delivers any keys at all. If you clear the server-managed config to fall back to MDM, the cached settings persist until the next successful fetch.

Footguns

Hooks trigger a security approval dialog on first apply. Any hook definition, custom environment variable, or shell command setting causes developers to see a dialog describing what is being configured. They must approve to proceed. If a developer rejects, Claude Code exits. This is by design for hooks but surprises orgs that include hooks in their initial rollout. In non-interactive (-p) mode, dialogs are skipped and settings apply automatically.

Third-party providers bypass server-managed settings entirely. If a developer sets CLAUDE_CODE_USE_BEDROCK=1, CLAUDE_CODE_USE_VERTEX=1, or a custom ANTHROPIC_BASE_URL, server-managed settings are not delivered. The setting requires a direct connection to api.anthropic.com. There is no in-band way to prevent this from the managed settings themselves. Use endpoint-managed settings via MDM if you need hard enforcement.

Clearing server-managed settings does not immediately fall back to MDM. Cached settings persist on client machines until the next successful fetch. If you clear the admin console to roll back policy while developers are actively working, they will continue to see the old policy until the next hourly poll or restart. Use forceRemoteSettingsRefresh: true before clearing to ensure the CLI exits instead of running with stale policy.

allowManagedPermissionRulesOnly cannot be removed silently. Once deployed, this key locks developers out of adding their own permission rules. When you need to relax it, the new settings take effect on the next poll, but developers will not know to restart. Send a team message.

Per-group configurations are not yet supported. Server-managed settings apply uniformly to all developers in the org. You cannot send different policy to contractors vs. employees or to different teams. If you need per-group policy, use endpoint-managed settings via MDM.

When NOT to use server-managed settings

• Your org has MDM. Endpoint-managed settings with a protected managed-settings.json offer stronger guarantees because the file cannot be modified between policy fetches.
• You need to restrict MCP server configurations org-wide. MCP server configuration cannot be distributed through server-managed settings.
• Your team uses Bedrock, Vertex, Foundry, or a custom API endpoint. Server-managed settings will not reach those sessions.
• You need policyHelper or wslInheritsWindowsSettings. Those keys only work in OS-level policy delivery, not server-managed settings.