Claude Code Enterprise: Best Team Setup Guide

Enterprise rollouts of Claude Code live or die on identity, policy, and observability. This guide walks the full team-deployment path: choosing a seat model, wiring SSO and SCIM, distributing managed settings, locking down MCP and hooks, and exporting telemetry. By the end you can ship Claude Code to thousands of engineers without losing control of cost, compliance, or code.

Enterprise: What You’ll Learn

This guide is the single source of truth for any enterprise admin standing up Claude Code at scale. You will learn how plan tiers map to access, how to choose between seat-based and usage-based billing, and how SSO plus SCIM keep joiners, movers, and leavers in sync. Each section ends with a concrete artifact: a config file, a CLI command, or a documented sequence you can copy into a runbook.

The goal is a deployment that passes a security review on the first try. We cover managed settings, the controls that ship with the enterprise plan, and the monitoring hooks that turn seat sprawl into a measurable signal. Skip nothing if your auditor is reading along.

Plan Tiers and Enterprise Eligibility

Claude Code is not gated behind one plan. It ships on Pro and Max for individuals, on Team for self-service groups, and on two distinct enterprise offers for organizations that need identity federation and policy controls. Console sits beside all of them for API-key-first usage.

Pro and Max are simple: one human, one subscription, higher rate limits on Max. They lack admin tooling and have no concept of seats or centrally managed settings. Choose them only for solo developers who will never touch a shared codebase policy. They also lack any SSO path, which means an engineer on a Pro plan cannot be federated into your tenant even if you wanted to sponsor them.

Team is the first tier where Claude Code is included on every seat. It adds an admin console, centralized billing, and the Just-in-Time (JIT) provisioning model. It does not include SCIM directory sync — that is reserved for enterprise and Console plans. Many teams hit this ceiling at around 50 engineers and upgrade.

Console is the API-first tier. It bills pay-as-you-go against API keys rather than seats, and it supports SCIM alongside the same organization role model used elsewhere: Primary Owner, Owner, and Member, with Custom roles available on Enterprise plans for finer-grained access. Console is the right answer for organizations that already think in API consumption — for example, a platform team that wants to issue short-lived keys to CI runners and never expose the console to end users.

The split between the two enterprise SKUs matters for procurement. Seat-based plans charge per person and cap usage per seat; they are predictable but rigid. Usage-based plans charge at API rates for whatever is consumed and work well for spiky workloads where most users touch Claude Code lightly and a few power users push hard.

There is no penalty for running both in parallel. A common enterprise pattern is seat-based billing for the 80% of engineers who use Code daily, plus a usage-based pool for the 20% who spike on large refactors or batch migrations. The two populations are differentiated by group membership in the IdP, and finance reconciles them on a single invoice.

When procurement asks for a five-year total cost projection, the honest answer is that nobody knows adoption curves in advance. Budget for the upper bound on a seat-based plan, instrument the actual usage, and renegotiate at the 18-month mark when real data exists. Vendors expect this renegotiation; pricing flexibility is wider than list suggests.

Choosing Your Enterprise Seat Model

Seat types differ across plan families, and the matrix below is the one most teams get wrong on first reading. The rule of thumb: on usage-based enterprise plans, only the Chat + Claude Code seat (or the single Enterprise seat on the unified variant) actually grants Code access.

The practical advice is to model seats against real usage before signing. A 500-seat legacy deployment that only buys 100 Premium seats will produce 400 support tickets the day Code rolls out. A usage-based deployment that hands Chat seats to power users will produce the same tickets in reverse. Run a two-week pilot, measure per-seat token volume, then pick.

For headless CI workloads — the kind covered in our Claude Code Headless Mode Guide — usage-based plans are usually the better fit because pipeline runs are bursty and unpredictable. Seat-based plans shine for interactive daily-driver use where per-seat caps align with the way engineers actually work.

SSO Setup: SAML 2.0 and OIDC

Single sign-on is the backbone of any enterprise deployment. Claude Code supports both SAML 2.0 and OpenID Connect (OIDC), with SAML 2.0 recommended for environments where your identity provider already speaks it fluently. Both are available on Team and enterprise plans.

Prerequisites

Before you touch SSO, verify the email domain your engineers will log in from. Domain verification is mandatory — Anthropic will not federate authentication for a domain you cannot prove you own. Add the supplied TXT record to DNS, wait for propagation, and confirm the green check in the admin console.

Configuring SAML 2.0

SAML 2.0 is the most common path. The admin console gives you an ACS URL and an entity ID; you paste those into your IdP application, then upload the IdP metadata back into Claude. Vendor guides exist for the three IdPs most teams use:

• Okta — use the prebuilt SAML app template and map Email to NameID.
• Microsoft Entra ID — create an enterprise application from the non-gallery template, set identifier URI to the entity ID.
• Google Workspace — add a custom SAML app and upload the SP metadata XML.

OIDC as an alternative

OIDC is supported when your organization standardized on it for other SaaS apps. Configure the client ID, client secret, and the well-known discovery URL. Token refresh is handled by the CLI transparently; engineers see a browser prompt on first login and silent refresh thereafter.

Hardening SSO

Two controls layer on top of SSO and are worth turning on for any regulated enterprise. IP allowlisting restricts logins to known egress ranges. Tenant restrictions go further, preventing users from authenticating into a different tenant with the same identity. Pair both with SSO and you have a deployment that satisfies most financial-sector identity frameworks out of the box.

Claim mapping deserves more attention than it usually gets. The SAML assertion or OIDC token carries claims — email, name, group membership — that Claude uses to route users. A mismatch between the claim name Claude expects and the name your IdP emits produces a silent failure: login succeeds, but the user lands with no seat and no group. Walk through the claim mapping in the admin console against a real test user before declaring SSO done.

Signing certificate rotation is the second silent failure mode. IdPs rotate their signing certificates annually or on demand, and when they do, Claude’s stored copy goes stale. Logins fail for every user until you re-upload metadata. Subscribe to your IdP’s rotation notifications and treat the re-upload as a planned change, not an incident.

Always test SSO in a staging tenant before flipping production. A misconfigured claim mapping will lock every engineer out at once, and the recovery path is a breakglass admin account you must have created in advance. Document that account in a sealed envelope or secrets manager, never in a wiki.

Domain Verification and Domain Capture

Domain verification proves ownership. Domain capture turns that proof into automation. When capture is enabled, any user who signs up with an email on your verified domain is automatically routed into your workspace instead of landing in a personal account.

For a greenfield enterprise rollout, domain capture is the difference between 5 support tickets and 500. Without it, engineers will create personal accounts during onboarding, link their work email, and you will spend the first month reconciling those accounts back into the managed tenant. With it, onboarding is silent: the user logs in via SSO and lands in the right seat, in the right group, on the first try.

Domain capture only works for domains you have verified. Subdomains need separate verification unless you verify the organizational domain with a wildcard. Read the IdP-side guidance for wildcard handling — Entra and Okta treat it differently, and the wrong choice silently drops subdomain users into a personal account.

Capture interacts with onboarding in ways that surprise first-time admins. When an engineer signs up with their work email before capture is enabled, they create a personal account that the capture feature then needs to migrate. The migration is automatic but produces a one-time email to the user that looks like phishing. Warn your workforce in advance, or expect a spike in security-team tickets the day capture goes live.

Multiple verified domains are supported when your organization uses several email domains after an acquisition or a brand split. Map each domain to the same tenant, and capture routes users from all of them into the correct workspace. Cross-domain routing is one of the few enterprise features that has zero configuration overhead once the domains are verified.

SCIM Directory Sync and JIT Provisioning

Provisioning is where most enterprise deployments differentiate themselves. Claude Code supports three models, and the choice determines how much manual user management you will do.

The single most common mistake in enterprise planning is assuming SCIM ships on Team. It does not. Team plans max out at JIT, which creates users on first login from attributes in the SAML assertion or OIDC token. JIT is fine for sub-100-engineer orgs with stable membership; it falls over the moment you need offboarding to be immediate or seat types to follow IdP group changes.

SCIM requirements

SCIM directory sync keeps Claude in lockstep with your IdP. When a user is disabled in Okta or Entra, the SCIM bridge calls the Claude API and deactivates that user within minutes. For Microsoft Entra-based SCIM, you need Entra ID P1 or P2 licensing — the free tier does not support provisioning to non-gallery SCIM applications.

Group mappings

SCIM carries group membership from the IdP into Claude, where you map groups to roles and seat types. The built-in roles are Primary Owner, Owner, and Member; Enterprise plans can also define Custom roles for finer-grained access. Every user must be assigned to a role-based group — unassigned users fall back to a default role that usually lacks Claude Code access entirely.

A simple, robust pattern is one group per role per seat type: claude-admins, claude-developers-premium, claude-developers-standard, claude-readonly. Map each to the corresponding role and seat type in the admin console. Engineers move seats by changing group membership in the IdP, which is already a governed, audited workflow in most enterprise directories.

Sync cadence matters more than admins expect. Most IdPs push SCIM updates within minutes of a directory change, but some configurations poll on a schedule that can stretch to an hour. For offboarding SLAs measured in minutes — common in regulated industries — confirm the push model is active and that deactivation triggers immediately on the disable event, not on the next scheduled sync.

The deactivation-then-reactivation flow is worth rehearsing. When a user goes on extended leave, disabling them in the IdP should free their seat; re-enabling should restore access without losing their session history. Test both directions against a real account before relying on the flow in production, because IdP edge cases around reactivation are common and rarely documented.

Custom roles are the escape hatch when Primary Owner, Owner, and Member do not fit. Define a custom role that grants, say, read-only analytics access without code execution, and map a group to it. Custom roles are how large enterprise deployments model nuanced access patterns like “auditor who can view usage but cannot run Code.”

Managed Settings Delivery Mechanisms

Managed settings let admins push configuration to every Claude Code client without touching engineer machines one at a time. There are four delivery mechanisms, checked in priority order — Claude Code applies the first one that returns a non-empty configuration.

The Windows user registry key is the fallback of last resort. Unlike the plist and HKLM registry locations, it does not require admin privileges to write, so treat it as a convenience default for a single user rather than an enforcement channel.

Server-managed settings

Server-managed settings are the recommended path for any enterprise with more than a handful of engineers. The admin console on claude.ai holds the canonical policy; clients fetch it on startup and refresh hourly during active sessions. A change pushed at 9 AM is live on every connected workstation by 10 AM with no deploy pipeline and no MDM coordination.

For air-gapped or sovereign-cloud deployments, an equivalent self-hosted gateway serves the same JSON. This is the route most regulated industries take because the policy server stays inside their network perimeter and the only outbound traffic is model inference.

plist and registry policy

On managed laptops, plist (macOS) and registry policy (Windows) integrate with the MDM tools you already run. Jamf, Intune, and similar platforms push the policy as part of the standard configuration profile flow, which means Claude Code settings ride along with disk encryption, screen lock, and every other enterprise baseline control.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>allowManagedMcpServersOnly</key> <true/>
  <key>allowManagedHooksOnly</key> <true/>
  <key>forceLoginOrgUUID</key> <string>9f3c-...</string>
</dict>
</plist>

File-based settings and drop-in directories

File-based settings are the lowest-tech delivery but still useful for Linux CI runners and bare-metal hosts that are not under MDM. The base path differs per OS, but all platforms support a sibling drop-in directory named managed-settings.d/. Files inside are merged alphabetically, so 10-base.json is overridden by 90-overrides.json when keys collide.

{
  "permissions": {
    "allowManagedPermissionRulesOnly": true
  },
  "allowManagedMcpServersOnly": true,
  "allowManagedHooksOnly": true,
  "forceLoginOrgUUID": "9f3c-2e1a-7d44-91b8-aa3344bb99cc"
}

One important limit: managed MCP server paths defined in managed-mcp.json cannot be pushed through the server-managed settings API. Those are file- or MDM-only. Plan for MDM coverage on any host that needs the managed-MCP guarantee.

Conflict resolution between mechanisms follows the priority order in the table above. When the same key is set by both server-managed and file-based config, the server value wins. This is by design — it lets the admin push an emergency change that overrides whatever a stale MDM profile is still shipping. But it also means file-based config alone is not a sufficient control; an attacker who can influence server-managed settings overrides every local policy.

For this reason, treat the admin console credentials as tier-zero secrets. The same access controls you apply to domain admin accounts in Active Directory should apply to the Claude admin console. Strong MFA, privileged access workstations, and breakglass auditing all apply.

Drop-in directory merging is order-dependent and worth documenting in your runbook. Naming files with a two-digit prefix — 10-base.json, 20-mcp.json, 90-overrides.json — gives operators a predictable mental model and makes emergency overrides easy to slot in without editing existing files.

Shared Configuration Controls

Once settings are flowing, the next question is what to centrally control. The enterprise admin toolkit targets four shared surfaces: plugins, managed MCP servers, managed hooks, and managed permission rules.

Plugins

Plugins are the distribution vehicle for team config — slash commands, subagents, hooks, MCP servers, and skills can all be packaged as a plugin and published to an internal marketplace. The deep dive on plugin packaging lives in our Claude Code Extensibility Guide; for enterprise purposes the key controls are blockedMarketplaces, which blacklists untrusted marketplaces, and the requirement that installed plugins come from your vetted internal registry.

A mature enterprise plugin strategy treats the internal marketplace like any other artifact repository. Plugins are signed, versioned, scanned for secrets on push, and reviewed by a security owner before promotion to the stable channel. Engineers install from the stable channel by default; the experimental channel is gated behind an opt-in flag that auditors can list.

Managed MCP servers

Setting allowManagedMcpServersOnly: true restricts the client to MCP servers defined in the admin-managed config. Engineers cannot add a server pointing at an unvetted external API. This is the single most important enterprise control for preventing data exfiltration through rogue tool calls.

Managed hooks

Setting allowManagedHooksOnly: true blocks user, project, and plugin hooks from running. Only admin-defined hooks execute. Use this when your security posture requires that every side effect of a Claude Code session — commit messages, lint runs, audit log writes — is centrally owned.

Managed permission rules

Setting allowManagedPermissionRulesOnly: true locks the permission rules engine to admin-supplied rules. Engineers cannot widen the allowlist to grant Claude new dangerous capabilities like running shell commands without confirmation. The sibling post on Claude Code Permissions Guide covers how to author rules that match your blast-radius tolerance.

Permission rules are the layer where policy meets friction. Too permissive and you lose your security posture; too restrictive and engineers disable Code entirely and fall back to copy-paste workflows that bypass every control. Start from a deny-by-default baseline, add narrowly-scoped allow rules per repository, and review the rules quarterly as codebases evolve.

Organization Model Controls

The enterprise plan adds a layer of model controls. Two of the three are always enforced server-side; the third is a default engineers can override unless your organization turns on enforcement. Three controls matter for procurement and policy:

• Org model restrictions — allowlist which models engineers may select (for example, block a more expensive model during a budget freeze). Always server-side.
• Org default model — set the model that loads on first launch so engineers do not have to choose. This is a starting point, not a lock: engineers can change it locally unless your organization has enabled enforcement (available to a limited set of organizations — ask your Anthropic account team).
• Org effort limits — cap the reasoning effort or token budget per request to keep runaway sessions in check. Always server-side.

Model restrictions and effort limits are server-side on purpose. A user who edits local settings, deletes config files, or installs an old CLI still hits the org policy on the next API call. That is the right failure mode for regulated enterprise environments where local config is untrusted by definition. The org default model does not carry the same guarantee — treat it as a cost-conscious default, and pair it with org model restrictions if you need a hard lock rather than a suggestion.

The default model choice deserves a moment of thought. Setting it to the cheapest model that meets your quality bar keeps the long tail of trivial queries — “what does this function do” — from hitting premium models. Engineers can still upgrade explicitly for harder work, but the default nudges cost in the right direction without policy theater.

Pair org model controls with usage-based billing when cost predictability is the priority, and with seat-based billing when per-seat caps already bound cost. The two patterns solve different problems and most large deployments use both at once for different populations.

Monitoring and Observability with OpenTelemetry

You cannot manage what you cannot see. Claude Code exports OpenTelemetry signals that flow into any OTLP-compatible collector — Grafana Alloy, Datadog Agent, Honeycomb, Jaeger, or a self-hosted OpenTelemetry Collector. Three signal types ship: metrics, logs and events, and distributed traces (currently in beta).

Enabling telemetry

Turn telemetry on with environment variables. The minimal config is four lines:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4317

Ship these variables to every developer shell via MDM, your dotfile management tool, or the CI runner image. For enterprise consistency, bake them into the base image engineers pull — that way no one forgets to set them after a laptop refresh.

What the signals mean

Metrics cover token usage (input, output, cached) and tool activity (which tools fire, how often, how long they take). Logs capture discrete events like session start and permission prompts. Traces link a single user request across CLI, model call, and tool execution, which makes performance triage possible for the first time on a per-session basis.

Sampling strategy matters once volume grows. A 1,200-engineer deployment generating traces on every session floods a collector within hours. Configure head-based sampling at the client for traces (one in ten sessions, say) and rely on metrics for full coverage. Reserve 100% trace sampling for incidents, where you temporarily raise the rate to capture a specific failure mode in flight.

Correlation IDs are the bridge between Claude Code telemetry and your existing traces. Each session emits a trace ID that you can join against GitHub commit hashes, CI build IDs, or ticket numbers when the gateway is configured to propagate them. That join is what makes the difference between “Claude was slow on Tuesday” and “Claude was slow on PR 4821 because of an oversized file.”

The analytics dashboard

Team and enterprise plans also unlock a hosted analytics dashboard at claude.ai/analytics/claude-code. It is the fastest way to answer “who used Code this week” without standing up your own collector. For deeper analysis — correlating token spend with PR merge rate, for example — pipe the OTLP stream into your existing observability stack and join the data there.

Build alerts on token-volume anomalies early. A single runaway agent loop can burn through an enterprise monthly token budget in an afternoon, and the dashboard shows the spike only after the fact. Alerting on the live OTLP stream catches it inside the first minute.

Cloud Provider Billing and Usage Attribution

For usage-based enterprise deployments and self-hosted gateway deployments, the bill arrives through your cloud provider. Attribution is critical because Claude Code spend looks like an opaque line item on the AWS, GCP, or Azure invoice until you break it down.

• AWS — use Cost Explorer with tags applied at the gateway deployment level. Group by the user tag the self-hosted gateway emits.
• GCP — Billing exports to BigQuery give per-label spend. Map the gateway’s per-user label to a cost center.
• Azure — Cost Management breaks down by resource tag. Apply the same tagging discipline as the rest of your estate.

The self-hosted Claude apps gateway adds two capabilities cloud-provider billing alone does not offer: per-user usage attribution and per-user spend limits. Set a soft limit that pings the user and a hard limit that suspends access, and review the limit curve monthly as adoption grows.

Treat the gateway as the system of record for cost allocation. Cloud-provider invoices are authoritative for total spend but coarse for who-did-what; the gateway knows the engineer, the repository, and the session that produced each token. That granularity is what makes enterprise chargeback defensible to finance.

Chargeback models fall into three families, and the choice depends on organizational culture. Direct chargeback bills each team for its actual usage — precise but politically sensitive when a small team’s bill spikes after a successful pilot. Allocation divides total cost by headcount or revenue — fair but removes the incentive to optimize. Hybrid models floor-allocate a base budget and charge back only the overage, which is the pattern most enterprise finance teams settle on after one cycle of direct chargeback friction.

Whatever model you pick, publish the methodology before publishing the numbers. Teams accept a chargeback they understand and argue about a chargeback that arrives as a surprise. The gateway’s per-user attribution is the evidence trail that turns a contested bill into a reviewed line item.

A Worked Example

Imagine a 1,200-engineer fintech rolling out Claude Code under a usage-based enterprise plan with Microsoft Entra ID as the IdP and an OpenTelemetry Collector feeding Datadog. Here is how the rollout unfolds across a four-week phased deployment, written as a runbook you can adapt.

Week one — identity foundation. The admin verifies the corporate email domain in the Claude console, enables domain capture, and configures SAML 2.0 against Entra. A breakglass admin account is created, stored in the privileged secrets manager, and added to the sealed-envelope process the security team already runs for root credentials.

Week two — provisioning. SCIM directory sync is configured between Entra and Claude. Because the company has Entra ID P2 on every seat, provisioning is supported without additional licensing. Four groups are created in Entra — claude-admins, claude-developers-premium, claude-developers-standard, claude-readonly — and mapped to roles and seat types in the console. A dry-run sync validates the user payload before going live.

Week three — policy. Server-managed settings are pushed with allowManagedMcpServersOnly: true, allowManagedHooksOnly: true, and allowManagedPermissionRulesOnly: true. The plist equivalent is packaged for the macOS fleet via Jamf, and the registry policy for Windows via Intune, so that laptops offline during the server push still pick up the policy locally.

Week four — observability and rollout. Telemetry environment variables are baked into the base developer image. A Datadog dashboard goes live with three panels: token volume by user, tool invocation count by repository, and session duration distribution. The rollout proceeds to a 50-engineer pilot, then 250, then the full 1,200 over five business days.

Week five — feedback and iteration. The pilot cohort surfaces two predictable pain points: permission prompts that block common workflows, and a small number of power users who hit the org effort limit. The permission baseline gets three narrowly-scoped additions, and the effort limit is raised for the group mapped to premium seats. No global policy changes — every adjustment is group-scoped.

The result is a deployment where every login is federated, every seat assignment is governed by IdP group membership, every client is policy-bound, and every session is observable. The enterprise can answer an auditor’s question — “who ran Claude Code against the payments repo last Tuesday, and what did it cost?” — in under five minutes, without a single manual log search.

The official reference for these steps lives in Anthropic’s admin setup documentation at code.claude.com/docs/en/admin-setup. Use it as the canonical source when vendor behavior shifts between this guide’s publication and your rollout date.

Enterprise: Common Mistakes to Avoid

Even experienced platform teams make the same four mistakes on their first enterprise Claude Code rollout. Each one is preventable with a small amount of planning, and each one is expensive to unwind once it has baked into a live deployment.

• Assuming SCIM ships on Team. It does not. SCIM directory sync is an enterprise and Console feature. A Team rollout that banked on SCIM for offboarding will leave departed-user accounts active for days. Plan an upgrade path or accept JIT’s limitations in writing.
• Mixing up seat types on usage-based plans. Only the Chat + Claude Code seat (or the unified Enterprise seat) grants Code access. Handing a Chat-only seat to a developer produces a “no access” error that looks like a bug but is really a procurement misclick.
• Pushing managed-MCP rules via server settings. The server-managed API cannot deliver managed-mcp.json. Those paths are file- or MDM-only. A rollout that depends on the server channel for MCP lockdown will silently leave engineers free to add rogue servers.
• Forgetting the breakglass admin account. A misconfigured SAML claim locks every engineer out at once, including the admins who could fix it. A pre-provisioned breakglass account, stored offline and tested quarterly, is the only fast recovery path.

Enterprise: Best Practices

• Model seats against real usage before signing. A two-week pilot with per-seat token telemetry beats any procurement spreadsheet at predicting the right plan mix.
• Use one IdP group per role per seat type. claude-developers-premium is clearer than a generic claude-users and survives reorganizations without re-mapping.
• Layer server-managed settings over MDM policy. Server-managed gives you hour-scale changes; MDM gives you offline coverage. Most regulated enterprise estates need both.
• Turn on telemetry before the pilot. Baseline metrics collected during the pilot become the comparison point for every future cost and performance conversation.
• Alert on token anomalies early. A runaway agent loop can consume a monthly enterprise token budget in an afternoon; OTLP-stream alerting catches it inside the first minute.

Enterprise: Frequently Asked Questions

Is SCIM available on the Team plan?

No. SCIM directory sync is available on enterprise and Console plans only. Team plans support Just-in-Time provisioning, which creates users on first login but does not sync group or status changes back from the IdP.

Which seat type grants Claude Code access on a usage-based enterprise plan?

On the two-seat variant, only the Chat + Claude Code seat grants Code access; a Chat-only seat does not. On the single-seat variant, the unified Enterprise seat grants Code access. On the legacy seat-based plan, only Premium seats grant access.

Can managed MCP servers be pushed through server-managed settings?

No. The server-managed settings API cannot deliver managed-mcp.json paths. Managed MCP server configuration is delivered file-based or via MDM (plist on macOS, registry policy on Windows, the managed-settings file on Linux).

Which identity providers are documented for SSO?

SAML 2.0 and OIDC are both supported, with SAML 2.0 recommended. Anthropic publishes setup guides for Okta, Microsoft Entra ID, and Google Workspace. Other SAML 2.0-compliant IdPs work but require manual metadata exchange.

How often do server-managed settings refresh during an active session?

Server-managed settings refresh hourly during active sessions. A change pushed to the admin console at 9 AM is live on every connected workstation by 10 AM without a deploy pipeline or MDM coordination.

Enterprise Claude Code deployments succeed or fail on four pillars: the right seat model, federated identity with SCIM, centrally managed settings enforced through multiple channels, and telemetry that makes usage measurable. Get those four right and the rest — policy, observability, cost attribution — follows naturally.