Deploy with Enterprise Admin Console

With the Enterprise Admin Console, Anthropic hosts your organization’s Claude Desktop 3P configuration, and your administrators manage it centrally instead of pushing files to each device. You sign in to the console in a browser and choose your inference provider, the app’s settings, and which groups of users get which settings, rather than authoring an MDM profile or running a bootstrap server. Your users sign in to Claude Desktop once with their work account, through your single sign-on if you connect it. The app then downloads the settings that apply to them and sends every model request to your provider. Prompts, responses, and files go to your inference provider, exactly as they do with MDM or a bootstrap server. Anthropic holds your user list and the settings you save, and never holds provider credentials. See exactly what data Anthropic stores under Where your data goes.

​

How it works

Anthropic creates a Claude Enterprise organization for your deployment and invites a Primary Owner. Your administrators sign in to that organization at claude.ai and open Organization settings. There they add users and groups, connect single sign-on, assign administrator roles, and edit the Claude Desktop configuration for the whole organization and for individual groups. On each device, the user signs in to Claude Desktop once. The app recognizes that the account belongs to a third-party deployment, downloads the configuration that applies to that user, and asks the user to restart. After the restart, the app runs in third-party mode. It sends model requests to your inference provider, as it does with MDM or bootstrap delivery. While the app runs, it re-checks the configuration on a timer. When you save a change, the app downloads it at the next check and asks the user to relaunch, as described under Configuration updates. You don’t push an MDM profile or run a bootstrap server. Users are provisioned a Claude account only to sign in to Claude Desktop and receive their settings. They sign in with their work email address, through your single sign-on if you connect it.

​

Where your data goes

Anthropic stores your organization’s user accounts and the configuration you save, and delivers that configuration to users’ apps. Prompts and model responses go to your inference provider, and conversations stay on the device, as they do with MDM or bootstrap delivery. The app contacts api.anthropic.com at every launch to check the user’s sign-in and download the configuration, and claude.ai when the user signs in, in addition to the hosts listed on Telemetry and egress.

​

Get set up

Contact your Anthropic representative to have an organization provisioned for your deployment. The Primary Owner receives an email invitation, signs in at claude.ai, and finds an empty organization to configure. If your company already has a Claude organization that has verified your email domain, usually a Claude Enterprise organization, name that organization’s Primary Owner as the Primary Owner of the new one too. The new organization then appears as an additional organization alongside your existing one and uses the existing organization’s single sign-on connection, SCIM directory, and verified domains. Your existing organization is not changed. If no existing organization has verified the email domain of the person you name, the new organization starts with its own sign-in settings.

​

Connect your identity provider

Set up single sign-on before inviting users, as described in Set up single sign-on. Users then sign in to Claude Desktop through your identity provider, and you can provision them with SCIM. Single sign-on is recommended rather than required. Without it, invited users sign in with their work email address through the standard Claude sign-in, such as a sign-in link emailed to them. A new organization starts set to Invite only, so only people you invite can join. For a pilot, keep that setting and invite the people you want. For a wider rollout, let people join automatically the first time they sign in through your identity provider (just-in-time provisioning), or sync them from your identity provider’s directory with SCIM, as described in Set up JIT or SCIM provisioning. When the new organization shares your existing organization’s single sign-on connection, as described under Get set up, you still choose, separately for each organization, how people join it and which groups from your identity provider it uses. Groups synced from your identity provider through SCIM appear among the organization’s groups and can carry their own settings, as described under Per-group permission policies. The Claude sign-in is separate from the sign-in to your inference provider or gateway, and the app never sends Claude account credentials or tokens to your provider. Users sign in to Claude once to receive their settings. They then authenticate to your provider the same way they do with MDM or bootstrap delivery.

​

Configure Claude Desktop

Sign in at claude.ai, switch to the organization, and open Organization settings. The Desktop 3P section in the left navigation has one page per settings area, listed under What you can configure. Each field sets one of the documented configuration keys, and the console checks values as you type and again when you click Save changes.

​

Start from an existing configuration file

If you already deploy Claude Desktop with an MDM profile, a bootstrap server, or a configuration built in the app, upload that configuration instead of entering each setting again. On the Connection page, click Import configuration…, then choose a .json file or paste the JSON. The console reads JSON in any of these forms:

• The file that Claude Desktop saves from Developer → Configure Third-Party Inference… → Export → JSON config, on macOS or Windows. Export it on the workstation where you built the configuration. On a device whose MDM profile or registry policy sets the Claude Desktop configuration, that window is read-only and doesn’t offer this export.
• The JSON that your bootstrap server returns.
• A macOS .mobileconfig profile converted to JSON with plutil -convert json -o config.json YourProfile.mobileconfig.
• A Linux /etc/claude-desktop/managed-settings.json file.

For a Windows fleet, use the JSON config export, because the console doesn’t read .reg files or registry policy. The console fills in the matching settings and lists anything in the file that it can’t store, such as credentials, bootstrap keys, and values that are set automatically from your organization, like the display name. It then shows every change against the saved configuration, and replaces the configuration when you click Replace configuration. If the connection in the file can’t be stored, for example because it relies on an API key or token in the file, the console keeps your saved connection instead. Before the users of an existing fleet sign in, prepare their devices:

• MDM or bootstrap fleets: remove the Claude Desktop configuration profile or registry policy, including a profile or policy that carries only bootstrap keys. A device that keeps one uses that configuration and ignores the admin console. A profile that sets only the app-behavior keys can stay.
• Machines configured in the app: a device set up from the in-app configuration window with Apply locally stays in its local third-party configuration. Return it to standard Claude Desktop first. To do that, sign out in the app and choose the Anthropic sign-in option on the sign-in screen, as described under Single-machine setup.

Users then sign in as described under Onboard users. Conversations from the earlier configuration stay on the device. To let users bring those conversations into the app’s history, turn on Claude.ai data import on the Connectors page, which sets the claudeAiImport key. Users then open Settings → Import & export in the app, and the earlier sessions appear in the Cowork & Code step of the import wizard.

​

What you can configure

From the console you can set the same configuration keys that MDM and bootstrap delivery support, apart from the items listed under Limitations. The Desktop 3P section of the left navigation has these pages: The console stores no API keys, tokens, or secrets, and refuses them anywhere in the configuration, including in request headers and MCP server settings. Users authenticate to your provider with an interactive sign-in, a cloud credential profile, or a credential helper on the device, and a managed MCP server that needs a secret takes the path of a helper script that exists at the same path on every device. Most of these settings can also differ per group of users, on the Permission policies page under People, as described under Per-group permission policies.

​

Per-group permission policies

The Permission policies page, under People in the left navigation, applies different settings to users in specific groups. Click Add permission policy, pick a group, and set only the settings that should differ. Every other setting comes from the organization-wide settings. A policy can, for example, turn Chat, Cowork, and Code on or off, narrow the model list and the managed MCP servers to a subset by name, and change built-in tool settings, network allowlists, telemetry, token limits, and the banner. The inference connection (the provider, its endpoint, and how users authenticate to it) is organization-wide, and a policy can’t add models or managed MCP servers that the organization-wide settings don’t define. Policies are ranked in the order shown on the page, and you drag them to change the ranking. When a user belongs to several listed groups, most settings, including the model list, come from the highest-ranked of their policies that sets them, and lower-ranked policies fill in only what the higher ones leave unset. Managed MCP servers combine instead, so the user keeps every server that any of their policies selects. The OpenTelemetry settings and the token limit each come from one policy only, the highest-ranked policy that sets any part of them. Lower-ranked policies’ values for them are ignored, and any part that policy leaves unset keeps the organization-wide value. For example, if the Traders policy (ranked first) turns Code off and selects the wiki server, and the Analysts policy (ranked second) sets a token limit and selects the tickets server, a user in both groups has Code off, the Analysts token limit, and both servers. Everything these policies leave unset comes from the organization-wide settings, and a user in no listed group gets the organization-wide settings unchanged. Groups are managed on the Groups page under People, including groups synced from your identity provider.

​

Plugin marketplaces

On the Plugins page under Desktop 3P, list the plugin marketplaces that users’ apps should fetch. The marketplaces you add are git repositories, or a marketplace.json file and plugin archives on an HTTPS origin you control. The Add marketplace menu also offers Anthropic’s public plugin marketplaces under Curated by Anthropic. The app does not add the Anthropic marketplaces on its own in third-party mode.

​

Telemetry defaults

The telemetry categories, keys, and egress hosts on Telemetry and egress apply unchanged. Essential and non-essential telemetry are on until you turn them off on the Telemetry & updates page. Crash reports are attributed to your organization automatically. An OpenTelemetry collector that you configure on the same page must use an https:// endpoint.

​

Onboard users

Before the first user signs in, confirm the following:

• You hold the Owner or Primary Owner role in the new organization
• You have saved a configuration that includes the inference provider, as described under Configure Claude Desktop
• Single sign-on is connected, if you use it, and the users you want on this deployment are invited or provisioned, as described under Connect your identity provider
• Devices run the latest Claude Desktop release, installed as described in Installation and setup
• Devices carry no MDM-delivered Claude Desktop configuration. If a managed profile or registry policy sets any key other than the app-behavior keys (the update, configuration re-check, relaunch window, and network proxy keys), the app uses that configuration and ignores the configuration from the admin console.
• Devices can reach api.anthropic.com at every launch and claude.ai when users sign in, in addition to the hosts on Telemetry and egress

A device picks up the configuration from the admin console the first time the user signs in to Claude in the app. Walk through it on a test device first. If something looks wrong, Help → Troubleshooting → Generate Diagnostic Report produces a report that shows where the app read its configuration from. You can share it with your Anthropic representative.

​

Users in more than one Claude organization

A user’s Claude account can belong to your deployment’s organization and to other Claude organizations, and the user can move between them in Claude Desktop. When such a user signs in, the app opens in their other organization and asks whether to switch to yours, with Switch and restart and Not now buttons. A user who chooses Not now isn’t asked again on that device and can switch later by choosing your organization from the account menu. Each move into or out of your organization restarts the app, because third-party mode runs as a separate app configuration. To go back, the user chooses Sign out and signs in to Claude again after the restart. To remove the choice, turn on Require this organization in Claude Desktop under Desktop sign-in on the Connection page. Members who also belong to another organization are then switched to yours whenever they sign in to Claude Desktop and can’t choose to stay. Browsers are not affected.

​

Configuration updates

From Claude Desktop 1.46388.0, a running app checks for a changed configuration about every 10 minutes, and after the device wakes. When it finds a change, it shows a Relaunch Claude Desktop card in the sidebar and gives the user 24 hours to relaunch. When the window ends, the app requires a restart and restarts itself after 2 minutes of inactivity. Earlier releases check about every 30 minutes and allow 1 hour. To change the window, set Configuration relaunch window on the Telemetry & updates page. The window can be 0 to 336 hours, and 0 requires the restart as soon as the app sees the change. The setting applies to Claude Desktop 1.46388.0 and later. Earlier releases always allow 1 hour. An app that isn’t running picks up the change at its next launch. Connection and credential settings never change in a running session. If a setting is changed that affects where users’ apps connect or sign in, or what can run on their devices (including when permission policies are added, removed, or reordered), Owners receive an email alert with the identity of the administrator who made the change.

​

Remove users or return to MDM

A user returns a device to standard Claude Desktop by choosing Sign out from the account menu. The app relaunches signed out. When you remove a user from the organization, Anthropic revokes their Claude Desktop sign-in to that organization. A running app isn’t interrupted. At its next launch the app can no longer download the organization’s configuration. It shows either the sign-in screen, where Or sign in with Claude.ai returns the device to standard Claude Desktop, or a Restart required prompt whose Restart button does the same. To return a whole fleet to MDM or bootstrap delivery, deploy the configuration profile or registry policy again. The device-managed configuration takes precedence over the configuration from the admin console from the app’s next launch. Conversations created under the admin console’s configuration stay on the device but no longer appear in the app’s history after the switch. Users can bring them into the app’s history from Settings → Import & export in the app, as described at the end of Start from an existing configuration file, after you set the claudeAiImport key with enabled set to true in the profile or policy you deploy.

​

Limitations

• The Claude API is not available as the inference provider with the admin console.
• If a device can’t reach api.anthropic.com at launch, the app opens with a Configuration sync issue warning and can’t connect to your inference provider until it downloads the configuration. It keeps retrying in the background and loads the configuration when a retry succeeds, without a relaunch. Quitting and reopening the app retries immediately. An app that is already running keeps working if the connection to Anthropic drops.
• Bootstrap keys and settings that only make sense on the device, such as disabling claude.ai sign-in, are not available in the console.