> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/jackdog668/claude-code/llms.txt
> Use this file to discover all available pages before exploring further.

# Enterprise Features

> MDM managed settings, policy limits, remote config, team memory sync, proxy support, and other features for enterprise deployments.

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:

| Key                                 | Priority            | Notes                                      |
| ----------------------------------- | ------------------- | ------------------------------------------ |
| `HKLM\SOFTWARE\Policies\ClaudeCode` | High (admin-only)   | Requires administrator privileges to write |
| `HKCU\SOFTWARE\Policies\ClaudeCode` | Low (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.

<Note>
  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.
</Note>

### 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:

```json theme={null}
{
  "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

```json theme={null}
{
  "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

<Warning>
  Secret scanning is applied before uploads. Team memory entries that contain secrets are blocked from syncing.
</Warning>

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:

```json theme={null}
{
  "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`.