Claude Code

Anthropic Console (Enterprise) walkthrough

Text-only walkthrough; UI labels match the Anthropic Console at the time of writing.

1. Sign in to the Anthropic Console as an org admin.
2. Settings → API Keys → Admin keys → Create new key. Name: arrakis-admin-readonly. Scope: read. Store it in your secret manager and paste into Arrakis platform Settings → Integrations → Anthropic.
3. Settings → Authentication → enable SSO/SCIM (SAML or OIDC).
4. Settings → Organization → enforce Claude Code login via the managed-settings keys forceLoginMethod: "claudeai" and forceLoginOrgUUID: "<your-org-uuid>" so that developer machines cannot sign in to a personal account.
5. Settings → Announcements → optional companyAnnouncements for rollout messaging shown at startup.

Live admin pages: docs.anthropic.com  and code.claude.com/docs .

Anthropic over Bedrock variant

Customers running Claude Code against Amazon Bedrock have a different control plane: AWS IAM + CloudTrail + Bedrock Model Invocation Logging.

Even on Bedrock, keep Claude Code OTel enabled — Bedrock invocation logs do not contain client-side prompt, tool, or session telemetry (no Bash command arguments, no MCP tool names, no hook events, no session resource attributes). The OTel exporter is the only source for those.

Deep-link: AWS Bedrock model invocation logging .

Managed settings file

Managed settings are JSON files read by Claude Code at startup. Per-OS paths:

Precedence

Settings precedence, high to low:

1. Managed (MDM-delivered)
2. CLI flags
3. Local (~/.claude/settings.local.json)
4. Project (.claude/settings.json)
5. User (~/.claude/settings.json)

permissions.allow and permissions.deny arrays merge across scopes — a managed deny cannot be removed by a project- or user-level setting.

Enforceable keys

Sample managed-settings.json shape

A managed-settings file typically contains an env block (with the OTel exporter variables CLAUDE_CODE_ENABLE_TELEMETRY, OTEL_METRICS_EXPORTER, OTEL_LOGS_EXPORTER, OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_HEADERS, and OTEL_RESOURCE_ATTRIBUTES), a permissions block (with allow/deny arrays), and the policy-pin keys (forceLoginMethod, forceLoginOrgUUID, forceRemoteSettingsRefresh, minimumVersion).

The exact JSON body — including the tenant OTLP endpoint hostname, bearer token, recommended permissions.deny patterns, and forceLoginOrgUUID — is provisioned per-tenant in the Arrakis platform under Settings → Integrations → Deployment, or available from Arrakis support. Download the latest sample from the platform rather than hand-authoring it.

Drop-in directory

The managed-settings.d/ directory lets multiple owners ship config without overwriting each other. Files are read in alphabetical order and merged into the single-file managed-settings.json:

• Objects are deep-merged (later wins on key collision).
• Arrays are concatenated and de-duplicated (so permissions.deny accumulates).
• Hidden files (leading dot) are ignored.

Arrakis ships its OTel configuration as a sortable-prefixed drop-in fragment with a tenant-specific name, so customer base policies stay untouched and Arrakis updates can be re-applied independently. The exact fragment file name is provisioned per-tenant; download the latest fragment from the Arrakis platform under Settings → Integrations → Deployment.

MDM payloads

Three delivery channels are commonly in use:

Jamf Pro (macOS)

Use a Custom Configuration Profile targeting the Anthropic preference domain com.anthropic.claudecode. The profile carries an env dictionary with the OTel exporter variables and the policy-pin keys (forceLoginMethod, forceLoginOrgUUID).

For tighter file-based control, deploy the JSON managed-settings file via a Files & Processes payload to the managed-settings.d/ directory (see Managed settings file) instead of (or in addition to) the preferences-domain plist.

The exact plist body, the tenant OTLP endpoint, the bearer token value, and the drop-in fragment file name are provisioned per-tenant in the Arrakis platform under Settings → Integrations → Deployment, or available from Arrakis support.

Microsoft Intune (Windows)

Use a Settings catalog policy (or a script payload) to write a REG_SZ JSON value under HKLM\SOFTWARE\Policies\ClaudeCode. The JSON value contains the same env block and policy-pin keys as the macOS plist.

For macOS endpoints managed by Intune, deploy a Custom Configuration Profile (.mobileconfig) carrying the equivalent plist payload.

For WSL endpoints under the same Intune-managed Windows host, set wslInheritsWindowsSettings: true so Linux-side Claude Code reads the Windows registry policy instead of requiring a separate /etc/claude-code/ file.

The exact registry value contents (including the OTLP endpoint, bearer token, and forceLoginOrgUUID) and the matching .mobileconfig body are provisioned per-tenant in the Arrakis platform under Settings → Integrations → Deployment, or available from Arrakis support.

Iru (macOS)

Use a Custom Profile library item carrying the same payload as the Jamf plist. Mark the profile Continuously Enforced so a missing or modified file is re-applied on each Iru (formerly Kandji) check-in. For Windows endpoints managed via Iru EDR-style flows, use a Custom Script library item to set the registry value.

Generic mobileconfig (macOS) and JSON-registry (Windows)

For MDMs not listed above (Workspace ONE, Mosyle, Hexnode, etc.), use vendor-agnostic delivery:

• macOS — a .mobileconfig whose payload type is the Anthropic com.anthropic.claudecode preference domain.
• Windows — a script payload (PowerShell or equivalent) that writes the JSON value under HKLM\SOFTWARE\Policies\ClaudeCode.

The complete .mobileconfig body and the PowerShell registry-write script (including the tenant OTLP endpoint, bearer token, and forceLoginOrgUUID) are provisioned per-tenant in the Arrakis platform under Settings → Integrations → Deployment, or available from Arrakis support.

Egress verification

Cross-link to OTel Collector & Arrakis Endpoint → Verifying connectivity for the TCP/TLS, synthetic OTLP, and failure-mode probes shared across tools.

Claude-Code-specific debug commands:

Content-control flags (privacy vs. fidelity)

Four content-control gates determine how much of the prompt, tool, and API surface is captured. All default to off.

Recommended Arrakis defaults: OTEL_LOG_USER_PROMPTS=1, OTEL_LOG_TOOL_DETAILS=1, OTEL_LOG_TOOL_CONTENT=0, OTEL_LOG_RAW_API_BODIES=0. Override per-org as governance and DLP review allow.

Distributed tracing (beta)

Set both:

CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1
OTEL_TRACES_EXPORTER=otlp

Span hierarchy emitted:

claude_code.interaction
  ├── claude_code.llm_request
  ├── claude_code.tool
  └── claude_code.hook

Traces reuse the same OTLP endpoint as logs and metrics — see OTel Collector & Arrakis Endpoint for endpoint configuration.

Resource attributes for multi-team

Use OTEL_RESOURCE_ATTRIBUTES to tag every emitted log, metric, and span with team, department, and cost-center metadata so the Arrakis platform can scope dashboards and alerts. Example shape:

OTEL_RESOURCE_ATTRIBUTES="department=<dept>,team.id=<team>,cost_center=<cc>"

Format constraints:

• No spaces, no quotes, no commas inside values.
• Encode special characters as percent escapes (%20 for space) or substitute underscores.
• The string is parsed as comma-separated key=value pairs by the OTel SDK.