Skip to main content
Claude Code includes features designed for enterprise and team environments: centrally managed configuration via MDM or managed settings files, organization-level policy restrictions, cloud-synced team memory, proxy and certificate support, and more.

​
MDM managed settings

On macOS and Windows, IT administrators can push Claude Code configuration using Mobile Device Management (MDM) profiles. Settings are read from OS-level policy stores and override user settings.

​
macOS

Settings are read from the com.anthropic.claudecode preference domain. Plist files are loaded in priority order (highest first):
  1. /Library/Managed Preferences/<username>/com.anthropic.claudecode.plist — per-user managed preferences
  2. /Library/Managed Preferences/com.anthropic.claudecode.plist — device-level managed preferences
Only /Library/Managed Preferences/ is used (requires root/MDM push). The user-writable ~/Library/Preferences/ path is not used for policy enforcement.

​
Windows

Settings are read from the Windows registry:
KeyPriorityNotes
HKLM\SOFTWARE\Policies\ClaudeCodeHigh (admin-only)Requires administrator privileges to write
HKCU\SOFTWARE\Policies\ClaudeCodeLow (user-writable)Only used when no admin source exists
The registry value name is Settings and must contain a JSON blob matching the Claude Code settings schema.
Registry keys live under SOFTWARE\Policies (on the WOW64 shared key list), so both 32-bit and 64-bit processes read the same values without redirection.

​
Linux

Linux has no MDM equivalent. Use the managed settings file instead:
  • /etc/claude-code/managed-settings.json — primary managed settings file
  • /etc/claude-code/managed-settings.d/*.json — drop-in directory; all .json files are merged

​
Priority order

Settings sources are applied with first-source-wins semantics (highest priority first): 
Remote managed settings → HKLM / macOS plist → managed-settings.json → HKCU

​
Remote managed settings

Organizations using Anthropic’s console can push settings remotely. Claude Code polls for changes every hour. The response contains a uuid, checksum, and a full settings blob that is validated against the settings schema. Fetch failures are non-blocking (fail open): if the remote endpoint is unreachable, the last cached response is used. The cache file is stored at ~/.claude/remote-managed-settings.json.

​
Policy limits

Console administrators can configure organization-level policy restrictions. Claude Code fetches these restrictions in the background and caches them at ~/.claude/policy-limits.json. Policies are a map of restriction keys to { allowed: boolean }. If a key is absent, the feature is allowed. The service polls every hour and retries on transient failures (max 5 retries). Auth failures disable retries for that session. Eligibility:
  • Console users (API key): all eligible
  • OAuth users (Claude.ai): Team and Enterprise/C4E subscribers only
The fetch fails open — if the endpoint returns an error, Claude Code continues without restrictions.

​
allowManagedHooksOnly

When set to true in managed settings, only hooks from managed settings run. User, project, and local hooks are silently ignored. This prevents untrusted external hook scripts from executing.

​
Available models

The availableModels settings key restricts which models users can select: 
{
  "availableModels": ["opus", "sonnet"]
}
Accepts family aliases ("opus" matches any Opus version), version prefixes, and full model IDs. An empty array allows only the default model. When undefined, all models are available.

​
MCP server allowlist and denylist

{
  "allowedMcpServers": [
    { "serverName": "approved-server" },
    { "serverUrl": "https://tools.example.com/*" }
  ],
  "deniedMcpServers": [
    { "serverCommand": ["npx", "dangerous-package"] }
  ]
}
The denylist takes precedence: a server on both lists is blocked.

​
Team memory sync

Team memory syncs shared Markdown memory files across all authenticated members of an organization, scoped per repository (identified by git remote hash). API operations:
  • GET /api/claude_code/team_memory?repo=<owner/repo> — pull server content
  • PUT /api/claude_code/team_memory?repo=<owner/repo> — push changed entries
Sync semantics:
  • Pull overwrites local files with server content (server wins per-key)
  • Push uploads only keys whose content hash differs from the server (delta upload)
  • File deletions do not propagate: deleting a local file will not remove it from the server
Secret scanning is applied before uploads. Team memory entries that contain secrets are blocked from syncing.
Team memory is available for OAuth users (Claude.ai) and syncs at session start.

​
Proxy support

​
HTTPS_PROXY

Claude Code respects the standard HTTPS_PROXY (and NO_PROXY) environment variables for outbound HTTP requests.

​
Upstream proxy (CCR)

When running inside a CCR (Claude Code Remote) session container with an upstream proxy configured, Claude Code automatically:
  1. Reads a session token from /run/ccr/session_token
  2. Downloads the upstream proxy CA certificate and merges it with the system bundle
  3. Starts a local CONNECT→WebSocket relay
  4. Sets HTTPS_PROXY and SSL_CERT_FILE environment variables for all agent subprocesses
Every step fails open — a broken proxy setup will not break an otherwise-working session. The following hosts are excluded from proxy interception via NO_PROXY:
  • localhost, 127.0.0.1, ::1
  • RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
  • 169.254.0.0/16 (IMDS)
  • anthropic.com and subdomains
  • github.com, api.github.com, and subdomains
  • Common package registries (registry.npmjs.org, pypi.org, files.pythonhosted.org, index.crates.io, proxy.golang.org)

​
Client certificates (CLAUDE_CODE_CLIENT_CERT)

To authenticate with a proxy or internal service using a client certificate, set CLAUDE_CODE_CLIENT_CERT to the path of a PEM-encoded certificate file.

​
System CA certificates

Claude Code uses the system CA bundle (/etc/ssl/certs/ca-certificates.crt on Linux). In CCR sessions, the upstream proxy CA is concatenated with the system bundle so subprocesses (curl, gh, Python) trust the MITM proxy.

​
Disabling auto-updates

Set DISABLE_AUTOUPDATER=1 to prevent Claude Code from checking for or applying automatic updates.

​
strictPluginOnlyCustomization

Enterprise administrators can lock down which customization surfaces (skills, agents, hooks, MCP) users can modify. The strictPluginOnlyCustomization setting accepts an array of surface names: 
{
  "strictPluginOnlyCustomization": ["hooks", "agents"]
}
When a surface is listed, only plugin-provided configurations for that surface are accepted; user/project/local customizations are ignored.

​
Audit logging and diagnostics

Claude Code writes diagnostic logs at ~/.claude/debug/. The most recent log is always available at ~/.claude/debug/latest (symlink on supported platforms). Errors are logged to ~/.claude/errors/ (internal builds only). All sessions write transcripts to ~/.claude/projects/ by default; set cleanupPeriodDays to control retention (0 disables persistence entirely). For structured diagnostics, Claude Code instruments key startup phases and hook execution timing. These timings are accessible in debug output when running with --debug.

Build docs developers (and LLMs) love

Get started for freeTalk to us