Deploy with Enterprise Admin Console - Claude.ai Documentation

The Enterprise Admin Console for Desktop 3P is generally available.

To use the Enterprise Admin Console, contact your Anthropic representative to have an organization provisioned.

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 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, as they do with MDM or a bootstrap server. Anthropic holds your user list and the settings you save. If you turn on usage analytics, Anthropic also holds token and session counts from your users’ apps. Anthropic never holds provider credentials such as API keys or your users’ tokens. For the full list of what Anthropic stores, see 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. 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, for most settings, 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. If you turn on usage analytics, Anthropic also stores the token and session counts that users’ apps report. As with MDM or bootstrap delivery, prompts and model responses go to your inference provider and conversations stay on the device.

Data	Does Anthropic store it?
Prompts, model responses, and tool inputs and outputs	No. They go to your inference provider, and tool calls go to the connectors you configure. Data handling at the provider depends on the provider, as described under Data handling by provider.
Conversation history, projects, memory, and uploaded files	No. They stay on the device. To take them to another device, see Move a user to a new device.
Provider credentials, API keys, bearer tokens, and MCP secrets	No, except the client secret of a Google Desktop-app OAuth client, which Google doesn’t treat as confidential. You can enter one for Google sign-in to your provider or for a managed MCP server that signs in with Google. Everything else stays on the device, and the console refuses to save it.
Plugin and skill content	No. It stays in your own repositories or on devices. The console stores marketplace locations and installation settings, not content.
OpenTelemetry export, if you configure a collector	No. It goes to your collector only.
User accounts (name and work email), group membership, and administrator roles	Yes.
Single sign-on and SCIM connection settings, if you use them	Yes.
The configuration your administrators save, organization-wide and per group	Yes. Anthropic delivers it to users’ apps. It contains no credentials other than a Google Desktop-app OAuth client secret, if you enter one.
Essential telemetry (crash and error reports) and non-essential telemetry (product analytics)	Yes, unless you turn them off on the Telemetry & updates page. Neither contains prompt or response content. Telemetry and egress describes what each category contains.
Usage analytics: session, token, and estimated-cost counts per user, conversation, and model	Yes, if you turn on the Report desktop usage to this organization switch on the Telemetry & updates page. The switch is off by default. Users’ apps report new counts only while the switch is on, and turning the switch off doesn’t delete counts that Anthropic has already received. The counts contain no prompt, response, or file content. Usage analytics lists exactly what each report contains.

The app contacts api.anthropic.com at every launch to check the user’s sign-in and download the configuration. While the app runs, it contacts api.anthropic.com again every 10 minutes by default to check for configuration changes. The app contacts claude.ai when the user signs in, and the claude.ai sign-in and approval pages run a browser check from hcaptcha.com and *.hcaptcha.com. If those two hosts are blocked, signing in can fail with a message that the browser couldn’t be verified, whichever sign-in method your organization uses. api.anthropic.com, claude.ai, hcaptcha.com, and *.hcaptcha.com are in addition to the hosts listed on Telemetry and egress. While usage analytics is on, the app also sends its token and session counts to api.anthropic.com every few minutes during use and when it quits, so usage analytics needs no additional firewall entry.

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. You can ask for more than one organization, for example a test organization alongside your production one. To share single sign-on and verified domains across them, verify the Primary Owner’s email domain in the first organization before you ask for the next, and name the same Primary Owner. Organizations with separate sign-in settings can’t verify the same domain.

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

Save the Connection page, where you choose your inference provider, before the other pages. The console doesn’t accept Save changes on any other page until a connection is saved. A user who signs in to Claude Desktop and clicks Restart before a connection is saved stays in standard Claude Desktop instead of switching to your configuration. After you save the connection, ask those users to quit and reopen Claude Desktop, then restart when prompted.

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 the file or paste its text. The console reads JSON, .reg files, .mobileconfig profiles, and XML .plist files. Get the file from the place where your configuration is today:

Configuration built in Claude Desktop: on the macOS or Windows workstation where you built it, go to Developer → Configure Third-Party Inference… → Export → JSON config
Organization-managed device: on a device where an MDM profile or registry policy sets the Claude Desktop configuration, open the in-app configuration window, then go to Export → JSON config (redacted). This option requires Claude Desktop 4.23118.0 or later. If you don’t see it, follow the Windows registry policy or macOS profile item instead. The file masks the values of API key, token, and header settings. Before you upload or share the file, check its URLs, arguments, and text fields for other secrets.
Windows registry policy: choose the .reg file that you deploy. If you set the policy with Group Policy or Intune, use a device that has the policy. Open Command Prompt in a folder that doesn’t sync to a cloud drive, then run this command:
Command Prompt
reg export HKLM\SOFTWARE\Policies\Claude claude-policy.reg /y
The command writes claude-policy.reg to that folder. Choose that file. If the command doesn’t write a file, or the console doesn’t read any settings from the file, replace HKLM with HKCU in the command to read user policy. claude-policy.reg holds every value in plain text, including any credential that the policy sets, so delete it after the upload.
macOS profile: choose the .mobileconfig profile or XML .plist file that your MDM deploys. If the profile is signed or the .plist file is in binary format, the console shows the command that converts it.
Bootstrap server: use the JSON that your server returns
Linux device: use the /etc/claude-desktop/managed-settings.json file
Another source: write the JSON yourself. Put the keys at the top level, with names exactly as in the configuration reference.

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. If the configuration was built in Claude Desktop, check the Automatically import earlier third-party sessions switch on the Capabilities page after the upload. A configuration built there can mark this switch as off even if nobody turned it off, and the console keeps the value from the file. To move the devices and users of an existing fleet to this configuration, see Migrate an existing fleet to the admin console.

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:

Page	What you configure there
Connection	The inference provider (gateway, Amazon Bedrock, Bedrock Mantle, Google Cloud’s Agent Platform, or Microsoft Foundry), its endpoint, region, or project, how users authenticate to it, custom request headers, and, under Models, the model list, default model, model discovery, and cost-estimate rates. Desktop sign-in on this page holds the Require this organization in Claude Desktop switch described under Users in more than one Claude organization.
Capabilities	Whether Chat, Cowork, and Code are each available, Unified Claude, the folders and network hosts the app may use, permission modes and built-in tool policy, the built-in browser and its site permissions, whether users may add their own skills and plugins, skill scanning, organization instructions, and Claude.ai data import
Connectors	Managed MCP servers, including the built-in connectors, whether users may add their own MCP servers, and desktop extension policy
Telemetry & updates	Which telemetry categories go to Anthropic, whether users’ apps report usage analytics to your organization, OpenTelemetry export to your collector, update policy, the configuration relaunch window, the configuration re-check interval, and how much of the configuration devices keep on disk
Limits	A per-user token limit and its window
Appearance	Banner text and colors, end-user attribution, and whether the app shows feature announcements and configuration deprecation warnings
Plugins	The plugin marketplaces that users’ apps fetch, and how each one installs

The console refuses API keys, tokens, and secrets anywhere in the configuration, including in request headers and MCP server settings. The one exception is the client secret of a Google Desktop-app OAuth client, for Google sign-in to your inference provider or a managed MCP server that signs in with Google, which Google doesn’t treat as confidential. Users authenticate to your provider on the device, as described under Choose how users authenticate to your provider. A setting takes effect only on Claude Desktop releases that support it, so a device on an earlier release gets a new restriction only after it updates. The configuration changelog lists the release that added each key. 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.

Choose how users authenticate to your provider

Choose an interactive sign-in wherever your provider offers one. It is the recommended credential kind for a deployment managed from the console. Users sign in inside the app with their own accounts, and there is no shared credential to distribute to devices or rotate.

The console never holds a provider credential. The Credential kind field on the Connection page tells Claude Desktop how each user’s device obtains one, and offers the kinds your provider supports: Interactive sign-in in the app, Identity provider sign-in (OIDC) (for example, for Amazon Bedrock behind an authenticating proxy), Workforce Identity (Google Cloud’s Agent Platform only), Cloud vendor profile (an AWS profile or Google Cloud credentials file already on the device), or Helper script (a credential helper on the device). Static API keys and bearer tokens aren’t offered, because the console refuses to store them. The same Connection settings go to every user, so a credential kind that depends on something present on each device works only if your device management puts it there.

Provider	Recommended credential kind	Credential fields on the Connection page	What users do at first launch
LLM gateway	Interactive sign-in with your identity provider	Gateway SSO IdP (OIDC) with your identity provider’s issuer URL and the client ID of the application you registered for Claude Desktop	The app shows a Sign in with your organization button that opens your identity provider’s sign-in page in the browser. After sign-in, the app sends that user’s token to your gateway on every request, and your gateway validates it.
Amazon Bedrock	Interactive sign-in through IAM Identity Center	AWS SSO start URL, AWS SSO region, AWS SSO account ID, and AWS SSO role name	The app shows a Sign in with AWS page and the user approves in the browser. No AWS CLI is needed.
Google Cloud’s Agent Platform, users with Google accounts	Interactive sign-in with Google	Vertex OAuth client ID and Vertex OAuth client secret from a Desktop-app OAuth client in your own Google Cloud project. Google doesn’t treat a Desktop-app client secret as confidential, so the console accepts it.	The app shows a Sign in with Google Cloud page and the user approves Google’s consent screen in the browser
Google Cloud’s Agent Platform, users who sign in with another identity provider	Workforce Identity	Workforce Identity audience and Workforce Identity IdP (OIDC) with your identity provider’s issuer URL and client ID	The app shows a Sign in with Google Cloud page and the user signs in to your identity provider in the browser. No Google identity is needed.
Microsoft Foundry	Interactive sign-in with Microsoft Entra ID	Entra ID tenant ID and Entra ID client ID, and optionally Entra ID sign-in flow	The app shows a Sign in with Microsoft page and the user signs in with a device code, in the browser, or through the operating system’s account picker
Bedrock Mantle	Helper script, because Mantle has no interactive sign-in	Helper script with the absolute path of a script that prints the bearer token	The app shows no sign-in page and runs the script whenever it needs a token

Tokens from these sign-ins are stored only on the user’s device. The linked provider pages cover setup at the provider, network egress, and session lifetime for each option.

When a helper script is the right choice

Choose Helper script for Bedrock Mantle, or when the credential for your gateway or provider can only come from tooling that runs on the device, such as an internal secret broker. The console stores the script’s path, not the script. Install the script at that absolute path on every device through your software distribution, in a location that users can’t modify, for example /usr/local/bin/corp-cred-helper on a macOS fleet or C:\Program Files\Corp\cred-helper.cmd on a Windows fleet. For a fleet of macOS and Windows devices, put the Windows path in Helper script (Windows). Windows devices run that script in place of the one in Helper script. Claude Desktop runs the script under the user’s operating-system account, so anything that differs per user, such as reading that user’s home folder or keychain, belongs inside the script.

Managed MCP servers that need authentication

A managed MCP server that supports OAuth needs nothing on the device. Set OAuth on the server’s entry on the Connectors page to Auto-register (dynamic client registration) or Bring your own client, and Claude Desktop signs each user in through the browser, as described under OAuth sign-in. For a server that needs a secret, enter the absolute path of a helper script on the device that prints it, in the field for that kind of secret:

A confidential OAuth client secret: the Client secret helper script field
A request header that carries a token: the Headers helper script field
Environment variables for a local server: the Environment helper script field

The managedMcpServers schema describes each script’s output format. Install each script at the same absolute path on every device, as with the inference helper script. Set up sign-in for managed MCP servers explains how to tell whether a server needs a client ID or also a client secret.

Localhost base URLs

The Gateway base URL, Bedrock base URL, and Vertex AI base URL fields on the Connection page take an https:// URL. They also accept an address on the device itself (localhost, 127.0.0.1, or [::1]) over https:// or http://, for example http://localhost:4000. Use a localhost address only when your organization runs a proxy or tunnel to your provider on every device in the deployment, because Claude Desktop sends model requests to whatever program answers at that address on each device. A localhost address in these fields requires Claude Desktop 1.52386.0 or later on every device, so update your devices before you save a localhost address. With a localhost address saved, a user on an earlier release who signs in for the first time stays in standard Claude Desktop instead of switching to your configuration. A device on an earlier release that already runs your configuration loses its connection to your provider the next time the app starts, until the device updates or you remove the localhost address.

Per-group permission policies

The Permission policies page, under People in the left navigation, applies different settings to users in specific groups. You can add policies after you save the organization-wide settings on the Connection page, and each group can have one policy. 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, the banner, and Claude.ai data import. 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. For the OpenTelemetry settings, the token limit, the banner, and the Claude.ai data import settings, only one policy applies to each: the highest-ranked policy that sets any part of it. That policy supplies the parts it sets, and every other part keeps the organization-wide value, even when a lower-ranked policy sets that part. 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. A group’s policy can also turn on Unified Claude for that group, as described under Turn on Unified Claude. From November 10, 2026, Unified Claude is on by default even for a group whose policy turns Cowork off.

Turn on Unified Claude

Unified Claude combines Chat and Cowork into one experience. These switches under Allowed surfaces on the Capabilities page control Unified Claude for your organization:

Opt into the new Chat and Cowork unified view turns on Unified Claude. From November 10, 2026, Unified Claude is on by default while this switch is off. Cowork is then on even where the Cowork switch is off.
Chat and Cowork unified view takes the place of the separate Chat and Cowork switches when you turn on the Opt into the new Chat and Cowork unified view switch. Turn on the Chat and Cowork unified view switch to give users the unified view. Turn it off to turn Chat and Cowork off entirely. Code is not affected.

A group’s policy has the same two switches in its Capabilities section. Unified Claude is in beta. In an organization with no saved configuration, the console starts with Unified Claude on and stores it when you first click Save changes on the Connection page. Where the saved configuration leaves the Opt into the new Chat and Cowork unified view switch off, Unified Claude stays off until you turn it on or until November 10, 2026. While Unified Claude is on, whether you turned it on or it is on by default, it overrides the Chat, Advanced file analysis, and Cowork switches, including where you turned one of them off.

When you turn on Unified Claude for your organization, it is on for every group. That includes a group whose policy turns Chat or Cowork off. From November 10, 2026, the default does the same, so a group whose policy turns Cowork off gets Cowork.For a member of several groups, Unified Claude comes from the highest-ranked of their policies that sets it, even when a higher-ranked policy turns Chat or Cowork off.

To turn on Unified Claude for your whole organization, open Organization settings and go to the Capabilities page under Desktop 3P. Under Allowed surfaces, turn on the Opt into the new Chat and Cowork unified view switch. If the Chat and Cowork unified view switch under it is off, turn it on. Click Save changes. Until November 10, 2026, you can turn on Unified Claude for some groups only:

Make sure Unified Claude is off for your organization

Open Organization settings and go to the Capabilities page under Desktop 3P. If the Opt into the new Chat and Cowork unified view switch under Allowed surfaces is off, continue with the next step. If the switch is on, turn it off, set the Chat and Cowork switches that reappear, and click Save changes.

Open the group's policy

Go to the Permission policies page under People. Open the group’s policy, or click Add permission policy and pick the group, as described under Per-group permission policies.

Turn on Unified Claude for the group

In the policy’s Capabilities section, turn on the Opt into the new Chat and Cowork unified view switch. If the Chat and Cowork unified view switch under it is off, turn it on.

Save the policy

Click Save changes.

Until November 10, 2026, you can turn Unified Claude off again for your organization or for a group. From that date, the same changes leave Unified Claude on by default, whatever the Chat and Cowork switches say.

For your whole organization: open Organization settings and go to the Capabilities page under Desktop 3P. Under Allowed surfaces, turn off the Opt into the new Chat and Cowork unified view switch. The Chat and Cowork switches reappear in the positions they had. Switches that nobody set are at their defaults. Cowork is on, and Chat and advanced file analysis are off. Set the switches as you want, then click Save changes.
For a group: while Unified Claude is off for your organization, open Organization settings, go to the Permission policies page under People, and open the group’s policy. If the policy has other settings, click Reset to default in the Opt into the new Chat and Cowork unified view row, then click Save changes. If the policy has no other settings, remove the policy with Remove policy on the Permission policies page. Until November 10, 2026, the Chat and Cowork switches then apply to the group again.

Turning on the Opt into the new Chat and Cowork unified view switch sets the desktopHome key, and turning it off removes the key. The Chat and Cowork unified view switch saves the value standard when it is on and off when it is off. With the value off, the Opt into the new Chat and Cowork unified view switch stays on, and Chat and Cowork are off entirely. Users’ apps pick up the change as described under Configuration updates.

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 menu also offers Anthropic’s public plugin marketplaces under Curated by Anthropic, and Salesforce’s under From partners, which Connect to Salesforce walks through. The app does not add these 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. The Keep only your organization ID and restrictions on disk switch on the same page also stops crash reports, as described under Configuration kept on devices. The app attributes crash reports and product analytics to your organization automatically, and also attributes product analytics to the signed-in user’s Claude account. An OpenTelemetry collector that you configure on the same page must use an https:// endpoint.

Configuration kept on devices

From Claude Desktop 2.7032.0, each device keeps a copy of part of the last configuration it downloaded from the admin console, and applies it at the next launch, before the app has downloaded the current configuration. The copy holds your organization’s ID and name, the Block essential telemetry and Block nonessential telemetry switches, the Microsoft 365 native sign-in broker and Default Quick Entry shortcut settings, and restrictions, such as Block nonessential services turned on or Allow local MCP servers turned off. It doesn’t hold lists, such as the folders and network hosts the app may use, or whether Chat, Cowork, and Code are available. Signing out of Claude Desktop deletes the copy. To keep less on devices, open Organization settings, go to the Telemetry & updates page under Desktop 3P, and turn on the Keep only your organization ID and restrictions on disk switch. The copy then holds only your organization ID and restrictions. Releases before 2.7032.0 keep the whole configuration except secrets, and ignore the switch. When you turn on the switch, a running app trims its copy at its next configuration check (every 10 minutes by default), without a relaunch. An app that isn’t running trims its copy at the next launch that downloads the configuration. Turning on the switch has two effects for users:

From the first launch after a device trims its copy, the app sends no crash reports to Anthropic, even while the Block essential telemetry switch is off. Error stack traces and performance timings still leave the device while the Block essential telemetry switch is off. An app that is already running keeps sending crash reports until it relaunches. For support, you then collect logs from affected devices yourself, as described under Essential telemetry.
The sign-in screen can’t show your organization’s name until the app has downloaded the configuration.

Usage analytics

Usage analytics lets your administrators see how much each user uses Chat, Cowork, and Code in Claude Desktop. Usage analytics is off by default. A member with the Owner or Primary Owner role can turn it on: open Organization settings, go to the Telemetry & updates page under Desktop 3P, and turn on the Report desktop usage to this organization switch. Claude Desktop 1.46388.1 and later report usage. While the switch is on, each user’s app counts its Chat, Cowork, and Code activity. The app sends the counts to Anthropic every few minutes during use and when it quits. A running app starts or stops reporting at its next configuration check (every 10 minutes by default), without a relaunch. Anthropic stores the counts for your organization and ties each report to the user’s Claude account. The counts appear on the Desktop usage page. To open the page, click Analytics in the user menu on claude.ai, or Desktop usage under Desktop 3P in Organization settings. The page includes the following:

Sessions and tokens for Chat, Cowork, and Code (the page labels Code Claude Code). Token totals leave out cached tokens, which your provider also bills. The counts are approximate. For example, an app that stops unexpectedly can lose its last few minutes of counts.
A daily chart. Days and months on the page are in UTC.
A chart of tokens by model.
A Team table with one row for each member who reported usage that month. Each row shows the member’s name and email from your member list, their sessions, their tokens, and their last active day.

Click a member’s row in the Team table to show only that member’s sessions and tokens. When the month’s reports include cost estimates, switch the control at the top of the page from Tokens to Cost to show estimated cost in US dollars instead of tokens. In the Cost view, the Team table shows each member’s estimated cost. While a single member is selected, the page doesn’t show estimated cost or the chart of tokens by model. To download a CSV file, click the Export button above the Team table. The file has one row for each member who matches the table’s search, including the member’s input, output, cache read, and cache write tokens and, when the month has estimates, their estimated cost. Members with the Primary Owner, Owner, or Admin role can open the Desktop usage page. Members whose role from the Admin roles page includes the Analytics permission can also open the page. Each report contains only the following:

Data	Example
A session count: one for each Chat, Cowork, or Code conversation	`1`
Token counts for each conversation and model: input, output, cache read, and cache write	`1300` input tokens
An estimated cost in US dollars for each conversation and model. The app calculates the estimate on the device, at Anthropic list prices or at the rates you set under Models on the Connection page, and labels which it used (`list` or `managed`). A model ID that the app can’t match to a Claude model (such as a gateway alias) has no estimate unless you set a rate for that exact ID	`0.0133`, `list`
The tab the activity happened in	`cowork`
The model identifier, exactly as your provider or configuration identifies the model. For Amazon Bedrock, the identifier can be an inference profile ARN, which includes your AWS region and account ID. Claude Desktop 1.52386.0 and later mask the account ID before sending. For Google Cloud, the identifier can be a resource path that includes your project ID	`claude-sonnet-4-5`
The date and time of the counted activity	`2026-08-27T21:00:01Z`
A random identifier for the conversation	`local_c34fa9b2-…`
A random identifier for the app installation. Crash reports and product analytics carry the same identifier	`49819623-…`
The app version, the operating system type and version, the processor architecture, and a fixed product label	`1.49585.0`, `darwin`, `24.6.0`, `arm64`, `claude-desktop`

The reports never contain prompts, responses, file names or contents, tool names, tool inputs or outputs, folder or project names, connector names, or host names. When you turn off the Report desktop usage to this organization switch on the Telemetry & updates page under Desktop 3P in Organization settings, users’ apps stop reporting at their next configuration check and discard any counts they haven’t sent. Turning the switch off doesn’t delete counts that Anthropic has already received. While the switch is off, the Desktop usage page shows a notice instead of the counts. If you remove a user from the organization, your totals still include the user’s counts, shown without a name or email.

Audit administrator changes

The Compliance API’s Activity Feed keeps an audit record of administrator activity, such as a member’s role change and saves of the Claude Desktop configuration and permission policies. The Compliance API switch starts recording in every organization under the same parent organization, so first check what it captures in your other organizations. As the Primary Owner, switch to your deployment’s organization, go to Organization settings > API, and turn on the Compliance API switch. Create a key with the read:compliance_activities scope.

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 other than the app-behavior keys and forceLoginOrgUUID. For a device that keeps a managed profile or registry policy with any other key, see Devices with a managed profile.
Devices can reach api.anthropic.com at every launch and while the app runs, and claude.ai, hcaptcha.com, and *.hcaptcha.com when users sign in, in addition to the hosts on Telemetry and egress
You have added the device, network, and provider controls that you want, as described under Limit Claude Desktop to your organization

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.

Open Claude Desktop and sign in on the standard sign-in screen with your work email address, through your organization’s single sign-on if you use it.

Restart when prompted

The app shows a dialog titled with your organization’s name that reads “Your organization’s Claude settings have changed. Restart to apply them.” You can’t dismiss the dialog. Click Restart, and the app relaunches in third-party mode with your configuration. An account that also belongs to another Claude organization sees a Switch and restart prompt instead, as described under Users in more than one Claude organization.

If your connection uses an interactive sign-in, sign in to your inference provider or gateway next, as with MDM or bootstrap delivery.

Check the result

The account menu at the bottom of the sidebar shows your organization’s name and an Inference configuration item marked Managed by your organization, and Settings → Privacy names your inference provider. On a device whose managed profile sets any key other than the app-behavior keys, the account menu shows your organization’s name without the Inference configuration item.

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. Give each user their own computer login. Claude Desktop keeps conversation history for each computer login and organization, not for each Claude account, and Sign out doesn’t delete it. Members of your organization who share a computer login see each other’s conversations. If people must share a login, ask each person to choose Sign out from the account menu when they finish, so that the next person signs in with their own Claude account.

Limit Claude Desktop to your organization

The admin console alone doesn’t keep a device on your organization’s settings. The console delivers your settings to members who sign in to Claude Desktop. The app applies the settings on the device and stores the sign-in in the user’s own application data directory. A user can stop using your settings, for example by signing out, deleting the app data, or setting up their own inference provider in the app. These controls still apply when a user stops using your settings:

Device management: deploy forceLoginOrgUUID with your Claude organization’s ID in a machine-level managed profile, as described under Keep a device on its managed profile. The app then ignores an inference provider that a user sets up in the app and limits standard Claude Desktop sign-in to your organization. You continue to manage settings in the console.
Network: at your firewall or secure web gateway, block inference endpoints other than your provider’s. The app needs api.anthropic.com and claude.ai, so limit those hosts to your Claude organizations, including your admin console organization, with tenant restrictions.
Inference provider: in your provider’s access policies, set who can send model requests to your provider from any app or configuration.

Without device management, you can block other accounts in Claude Desktop with a switch in the console. The person at the device can remove the block, so the switch doesn’t enforce sign-in.

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. From Claude Desktop 1.49585.0, they can instead pick their other organization from the account menu, which also restarts the app and asks them to sign in. To remove Not now, turn on Require this organization in Claude Desktop under Desktop sign-in on the Connection page. Members who also belong to another organization then get the prompt the next time Claude Desktop starts or they sign in, and they can’t dismiss it. While they are in your organization, the account menu lists another of their organizations only if that organization has the same setting on. Browsers are not affected. On a device whose managed profile sets an inference provider or bootstrap keys, no prompt appears while the app is open on the profile’s configuration. If the profile is complete, this setting doesn’t remove the profile from the prompt, as described under Devices with a managed profile.

Another Claude Enterprise organization can block other accounts in Claude Desktop, even if it doesn’t use the admin console. If it has the block on and yours doesn’t, a user who uses Claude Desktop signed in to that organization can’t then switch to your organization on the same computer login. The block applies from the app’s next start at the latest. Devices already on your configuration stay on it until their user signs out or switches away.To keep your organization available, ask that organization’s administrators to add your organization’s ID to their Allowed organizations list. Copy the ID from Value under Desktop sign-in on the Connection page.

Block other accounts in Claude Desktop

To keep personal accounts and other organizations’ accounts out of Claude Desktop without device management, turn on the Block other accounts after a member signs in switch. After a user uses Claude Desktop signed in to your organization, the app blocks other accounts for that computer login from its next start. The block also applies on personal devices. A blocked person sees a page that reads “This account is not approved by your enterprise admin” and can only log out.

The person at the device can remove the block, so the switch doesn’t enforce sign-in. To enforce sign-in to your organization, deploy forceLoginOrgUUID through device management. On a device that has the key, the key’s value applies instead of the switch and the Allowed organizations list. On a device whose managed profile restricts the deployment mode, the switch and the list don’t apply, so set forceLoginOrgUUID in that profile.

Check what the block covers:

Accounts that stay allowed: accounts in your organization and in the organizations on your Allowed organizations list. An account in your organization can also be in another organization that has this switch on. Where that account uses Claude Desktop, that organization and the organizations on its list stay allowed too.
In-app inference providers: from standard Claude Desktop or your configuration, people can’t switch to an inference provider set up in the app or to the Claude API account sign-in. Your members can’t switch either. An app that already uses either one continues to use it. Configurations from a managed profile or a bootstrap server stay available. Before Claude Desktop 4.23118.0, this limit doesn’t apply.
Outside the block: sign-ins outside Claude Desktop, such as claude.ai in a browser and the mobile apps, and other computer logins on the same device. For device, network, and provider controls, see Limit Claude Desktop to your organization.

To turn on the block:

Check that devices run Claude Desktop 4.29.0 or later. Devices on the staggered release channel get releases later.
- Releases 3.6556.1 and 3.6556.2: the app applies the block but ignores the list, so it also blocks the organizations on it. After an update to 4.29.0 or later, the device allows those organizations from the first app start after a user next uses Claude Desktop there signed in to your organization.
- Releases before 3.6556.1: the app ignores the block’s switch.
In the admin console, go to Desktop sign-in on the Connection page. Turn on the Require this organization in Claude Desktop switch. Without that switch, the block’s switch is unavailable.
If people at your company use other Claude organizations, save the list before you turn on the block. Otherwise, a device can block those organizations until it gets the list and restarts. Click Edit list in the Allowed organizations row. Add each organization’s ID on its own line, below your own organization’s ID. Click Copy list. Then click Save.
Turn on the Block other accounts after a member signs in switch. Then click Block other accounts.
Set up the block in each Claude Enterprise organization on the list too. Without this step, on devices where only that organization’s users use Claude Desktop, the block ends about 30 days after your users last used Claude Desktop there.
- With a Connection page: follow the same steps and paste the same list.
- Without a Connection page: go to Organization settings > Organization and access. Under Security, click Edit list in the Allowed organizations row, paste the same list, and click Save. Then turn on the switch above that row and confirm.

Unblock other accounts in Claude Desktop

Remove the block from every device or from one:

Every device: turn off the Block other accounts after a member signs in switch under Desktop sign-in on the Connection page of the admin console. Each device gets the change when a user next uses Claude Desktop there signed in to your organization. The device removes the block at the start after that, so the change can take two restarts. A removed user’s device can’t get the change, so remove users after their devices get it.
One device: ask the person at the device to sign out of your organization, quit Claude Desktop, and delete the saved-org-lock.json file from the application data directory. The block returns if a user signs in to your organization there while the switch is on.

The block also ends by itself at the first app start about 30 days after a user last used Claude Desktop on the device signed in to your organization.

Configuration updates

From Claude Desktop 1.46388.1, a running app checks for a changed configuration about every 10 minutes, and after the device wakes. Some settings, such as the token limit and the banner, apply to the running app without a relaunch. For any other change, a card in the sidebar counts down to a required restart, and the user has 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.1 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. About once a month, a user’s sign-in to Claude on a device expires.

App not running: the app asks the user to sign in again at its next launch.
App running: the app keeps its current settings, and conversations continue. Until the user signs in again, the app doesn’t download configuration changes or report usage analytics. From Claude Desktop 2.42304.0, the app shows a Your session has expired banner with a Sign in again button. The banner appears in places such as the home screen and Code. Earlier releases show no message, and the user quits and reopens the app to sign in again.

Migrate an existing fleet to the admin console

If your fleet gets its Claude Desktop configuration from MDM, a bootstrap server, or the in-app configuration window, you can move it to the admin console and keep your inference provider, unless that provider is the Claude API. Users’ earlier work stays on each device. The app copies that work on the same device so it appears under your organization. Try these steps on a test device first.

Import your configuration

Upload your current configuration, as described under Start from an existing configuration file. Put settings that differ between groups of users in per-group permission policies.

Finish the configuration before users sign in

Set every setting you rely on in the console, because the console’s configuration replaces the profile’s. Add your plugin marketplaces on the Plugins page. To migrate users’ work, check that the Automatically import earlier third-party sessions switch under Claude.ai data import on the Capabilities page is on (the default). To skip the migration, turn it off. Devices that already migrated keep their items.

The app migrates users’ work once on each device, the next time it starts after the user signs in to your organization. It skips uploaded plugins, saved skills, and scheduled tasks if the console has turned that feature off, and optional plugins that your organization doesn’t offer yet. Changing those settings later doesn’t migrate the skipped items.

Update Claude Desktop

Update devices to Claude Desktop 2.42304.0 or later. Earlier releases migrate fewer items.

Remove the managed profile

Remove the Claude Desktop configuration profile or registry policy, including one that carries only bootstrap keys. You can keep a profile that sets only the app-behavior keys and forceLoginOrgUUID.

Devices that keep a profile with any other key: see Devices with a managed profile
Devices configured in the app: the user signs out and chooses the Anthropic sign-in option, as described under Single-machine setup

Have users sign in

Have users sign in to Claude with their work email address and restart the app when asked, as described under Onboard users.

What is migrated

The app migrates these items in the background. The originals stay in place, so migrated sessions use disk space a second time.

Chat, Cowork, and Code sessions
Cowork projects
Artifacts
Memory, unless the user paused it
Users’ global instructions and Instructions for Claude, unless they already set them in your organization
Scheduled tasks from Cowork and Code, except one-time tasks whose time has passed
Plugins that users uploaded, unless userPluginUploadsEnabled is false
Skills that users saved, unless skillCreationEnabled is false
Optional organization plugins that users turned on, if you offer them from your plugins directory or from a marketplace that your inference gateway serves
Optional organization plugins that users turned on from other marketplaces, such as a git repository, if you offer the marketplace from the same repository or URL as your earlier configuration. Devices that migrated under an earlier release get these plugins the first time they start 2.42304.0 or later, if the Automatically import earlier third-party sessions switch is still on.

Automatic import of earlier third-party sessions describes the migration for users, including how to remove migrated sessions and projects.

What is not migrated

Users set up these items again:

Optional organization plugins that the migration skipped: install them again from Customize → Plugins → Discover → Organization
Plugins from marketplaces the user added: add the marketplace and install the plugins again
One-time scheduled tasks that the migration skipped: create them again
App preferences: set the model, per-tool permissions, and notifications again
Connected folders in Cowork sessions: connect the folders again
“Always allow” choices in Cowork sessions and scheduled tasks: approve again when a session or task asks
Connector sign-ins: sign in again to any connector that asks

To let users import their claude.ai conversations, and any local sessions that the migration left out, with the import wizard, turn on the Enable import switch (off by default) under Claude.ai data import on the Capabilities page.

Devices with a managed profile

A managed profile is a macOS configuration profile, a Windows registry policy, or the Linux /etc/claude-desktop/managed-settings.json file, from MDM or bootstrap delivery. A device whose profile sets any key other than the app-behavior keys uses the profile’s configuration until its user moves the device to the admin console’s configuration. Where you can, remove every such key other than forceLoginOrgUUID before users sign in, as described under Migrate an existing fleet to the admin console. To prevent the move, or to allow it only for your organization, see Keep a device on its managed profile. Before Claude Desktop 2.37337.0, the device uses the profile and ignores the admin console. To move a device to the admin console’s configuration:

If the profile sets an inference provider or bootstrap keys and the app is open on the profile’s configuration, choose Sign out from the account menu.
If the profile sets an inference provider or bootstrap keys, choose Or sign in with Claude.ai on the sign-in screen.
Sign in to your organization.
If the app asks Which organization do you want to work in?, choose your organization. Otherwise, restart the app when it asks, as described under Onboard users.

The app asks that question only if the profile is complete. It offers the profile and your organization. A profile is complete if it sets a bootstrapUrl that bootstrapEnabled hasn’t turned off, or an inference provider with every setting that provider requires. Require this organization in Claude Desktop doesn’t remove the profile from the prompt. To stop the app from offering the profile, remove the profile from the device. After the removal, a device opens the admin console’s configuration if its user moved it there and hasn’t signed out or switched away since. After the move, the device stays on the admin console’s configuration at later launches. Deploying the profile again doesn’t move it back, except as described under Remove users or return to MDM. If the profile sets an inference provider or bootstrap keys, the account menu also lists the profile’s configuration.

Which settings apply on a device with a managed profile

On a device whose profile sets only app-behavior keys, the profile’s values apply instead of the console’s for all of those keys. Any of those keys that the profile leaves out runs its default, as described under Update keys and managed precedence. While a device whose profile sets any other key, such as forceLoginOrgUUID, is on the admin console’s configuration, the app still takes these from the profile:

The network proxy keys.
isLocalDevMcpEnabled set to false, for local (stdio) servers in the console’s managed MCP servers only. The app starts such a server only if the profile’s own managedMcpServers lists a local (stdio) server of the same name, and it uses the profile’s command, arguments, and environment. The profile’s value doesn’t block local MCP servers that users add. To keep blocking them, turn off Allow local MCP servers on the console’s Connectors page.
disableWslSessions.
The keys described under Keep a device on its managed profile.

Other settings come from the console, including the inference provider, restrictions, telemetry, and the update, relaunch window, and re-check keys. The profile’s values, and its bootstrap server’s, don’t apply even where the console leaves a setting unset. Before the app downloads the console’s configuration at a launch, it applies what it kept of the last download, not the profile’s values. That copy doesn’t hold disableAutoUpdates, so until a download succeeds, neither the console’s nor the profile’s value blocks updates. The app doesn’t fall back to the profile’s provider or server when it can’t reach api.anthropic.com. See Limitations. Before users sign in, set every setting you rely on in the console, as described under What you can configure.

Keep a device on its managed profile

On Claude Desktop 2.37337.0 or later, a user who belongs to any organization that uses the admin console can move a device to that organization’s configuration by signing in. The organization doesn’t have to be yours. To prevent the move, or to allow it only for your organization, set one of these keys in the device’s managed profile:

Prevent the move: set deploymentMode to 3p in a profile that says what the app connects to, or to 1p in a profile that leaves the device on standard Claude Desktop. The app ignores the admin console, and a device that already moved leaves the console’s configuration at its next launch. Devices on versions before 4.16336.0 also need disableDeploymentModeChooser, as described under Restrict a device to one deployment mode.
Allow only your organization: set forceLoginOrgUUID to your Claude organization’s ID. This ID isn’t deploymentOrganizationUuid, which is a UUID you generate. Devices already on your organization’s admin console configuration stay on it. The app ignores the admin console configuration of any other organization and limits standard Claude Desktop sign-in on the device to your organization.

You can use forceLoginOrgUUID to help prevent shadow IT, which here means people using personal Claude accounts or other organizations’ accounts in Claude Desktop on work computers. A user who signs in to standard Claude Desktop with an account that isn’t in your organization sees a page that reads “This account is not approved by your enterprise admin” and can only log out. Claude Desktop 4.16336.0 or later checks Sign in with Claude Console against the forceLoginOrgUUID in the device’s managed profile. Users see that sign-in where the profile selects the Claude API with no static key or credential helper. If the key leaves out the Claude Console organization that a user selects, the app records a warning in main.log and still uses the sign-in. A later release stops using a sign-in that the key leaves out. Where forceLoginOrgUUID is set, that release also stops using an API key that a version before 3.1623.0 created at sign-in, whatever IDs it lists, until the device’s next sign-in. A user whose organization the key leaves out also sees a notice that reads “Your Claude Console sign-in will stop working after a future update”. The notice gives the ID of that Claude Console organization, and the user can dismiss it. A user whose device still uses an API key from before 3.1623.0 sees the same notice, whatever IDs forceLoginOrgUUID lists. For that user it gives no ID and says to sign out and sign in again. The notice requires Claude Desktop 4.23118.0 or later.

Add the organization: a Claude Console organization has its own ID. In Claude Console, go to Settings > Organization and copy the Organization ID. Add the ID of each Claude Console organization that you allow to forceLoginOrgUUID, in a JSON array with your Claude organization’s ID.
Check a device: search main.log, and any numbered copies beside it such as main1.log, in the logs directory on the user’s device for coming release. If a warning names the ID of a Claude Console organization that you allow, add that ID. Otherwise, have the user sign out and sign in again with a Claude Console organization that the key lists.
Before a user signs in again: unless deploymentOrganizationUuid is set, the app stores sessions and other local data under the organization of the sign-in. After a sign-in to another organization, earlier data can stop appearing in the app. Setting that key now has the same effect. Neither deletes the earlier sessions.

To deploy forceLoginOrgUUID:

Update devices to Claude Desktop 2.37337.0 or later. Earlier versions ignore the admin console when this key is set.
In the admin console, copy the Key and the Value from the Allow only this organization with device management (MDM) row, under Desktop sign-in on the Connection page.
Add the key and value to the device’s managed profile, in one of the locations the app reads. Enter a single ID without braces or quotation marks. In the Windows registry, make it a String value (REG_SZ). For more than one organization, enter a JSON array of IDs as one string value, such as ["ID-1","ID-2"].
Restart Claude Desktop after the profile reaches the device.

If the value lists only other IDs, or the app can’t read it, the app uses only the profile and the console’s settings stop applying. Correct the value and restart Claude Desktop. If the device doesn’t return to the console’s configuration, its user signs in to your organization again, as described under Devices with a managed profile. For the macOS and Windows locations where the app reads a managed profile’s keys, see Deploy the configuration.

On a device that uses the admin console, adding one of these keys to a profile that sets only app-behavior keys changes which settings apply. See Which settings apply on a device with a managed profile. With deploymentMode set to 3p or 1p, or disableDeploymentModeChooser set to true, the profile becomes the device’s whole configuration, and the device stops using the admin console. To require members who also belong to another organization to switch to yours, leave such a profile as it is and turn on Require this organization in Claude Desktop.

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. On a device whose managed profile sets an inference provider or bootstrap keys, the sign-in screen also offers Or sign in with your organization (or with the provider’s name), which restarts the app on the profile’s configuration. 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 your organization’s sign-in screen, where Return to Claude.ai sign-in returns the device to standard Claude Desktop, or a Restart required prompt whose Restart button does the same. A removed user’s device that blocks other accounts keeps the block. The block ends about 30 days after the user’s last use, or when the person at the device removes it.

Removing a user doesn’t end their access to your inference provider. To stop model requests from an app that is still running, also end their access at your provider or identity provider.

To return a whole fleet to MDM or bootstrap delivery, deploy the profile again with disableDeploymentModeChooser set to true. The device returns to the profile’s configuration at the app’s next launch. From Claude Desktop 1.46388.1, a running app also notices the profile or policy at its next configuration re-check and asks the user to relaunch. To move a fleet to standard Claude Desktop instead, deploy a profile of standard Claude Desktop keys that sets forceLoginOrgUUID to another organization’s ID, the one your users move to.

Keep a key that restricts the deployment mode (or, for standard Claude Desktop, forceLoginOrgUUID) in the profile. On Claude Desktop 2.37337.0 or later, without the key the device goes back to the admin console’s configuration at its next launch, without asking the user. If the user’s sign-in to your organization has expired or you removed the user, the app shows your organization’s sign-in screen or a Restart required prompt instead.A device that left the admin console’s configuration on an earlier release goes back too, so add disableDeploymentModeChooser to the profile before devices update. A key that you add later takes effect at the device’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 device returns to the profile. Users can bring them into the app’s history from Settings → Import & export in the app, as described under Open the import wizard, after you set the claudeAiImport key with enabled set to true in the profile or policy you deploy.

Manage the configuration with the Admin API

The configuration that the admin console edits is also available as one JSON document through the Admin API. You can keep it in version control and apply it from a pipeline. Requests authenticate with an Admin API key that the organization’s Primary Owner creates. Sign in at claude.ai, switch to your Claude Desktop deployment’s organization, and open Organization settings → API. Click Create key, name the key, and select the read:desktop_config scope to read the configuration and write:desktop_config to replace it. Only that organization’s Create key dialog lists these two scopes. A key that reads and writes needs both scopes. Copy the key when it’s shown, because you can’t view it again. Pass the key in the x-api-key header. The key determines the organization, so there is no organization ID in the path. The examples read the key from the ANTHROPIC_ADMIN_KEY environment variable.

Read the configuration

curl -sS --fail-with-body https://api.anthropic.com/v1/organizations/desktop_config \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -o desktop-config.json.tmp \
  && mv desktop-config.json.tmp desktop-config.json

On an error status, curl exits non-zero before the mv, so your saved copy is kept and the error message is in desktop-config.json.tmp. --fail-with-body needs curl 7.76 or later. With an older curl, use --fail, which discards the error message. A read returns 404 until a configuration has been saved, on the Connection page of the console or by a first write through this API. The response has these fields:

Field	Contents
`config`	The organization-wide configuration as nested JSON, in the v2 format described under Response schema for bootstrap servers. Stored header values appear as a placeholder, as described under Replace the configuration.
`status`	`active` or `disabled`. A `disabled` configuration isn’t served to users’ apps, as the warning under Replace the configuration describes.
`group_settings`	An object whose `entries` list holds the per-group permission policies in rank order, highest first, each with a `group_id` and its `config`. A `group_id` that matches no group is accepted and applies to nobody until a group with that ID exists.
`version`	An integer that increases with every change.
`checksum`	A digest of `config` and `group_settings` as returned. It leaves out `status`, so compare `version` to detect changes.
`updated_at`	The time of the last change.

Replace the configuration

A write replaces the whole document and accepts only config, status, group_settings, and expected_version. Send config, status, and group_settings together, even the parts you are not changing. Sending version, checksum, or updated_at returns 400. The jq line below keeps only the accepted fields, sets expected_version, and fails if desktop-config.json has no version. Set expected_version to the version you read, or to 0 for a first write when nothing has been saved. The write is then refused with 409 if anyone changed the configuration after you read it. Without expected_version, the last writer wins. Sending update.json unedited returns 200 without creating a new version.

jq -e 'select(.version != null) | {config, status, group_settings, expected_version: .version}' \
  desktop-config.json > update.json
# Edit update.json, then:
curl -sS --fail-with-body -X POST https://api.anthropic.com/v1/organizations/desktop_config \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d @update.json

On an error status, curl prints the error body and exits non-zero (curl 7.76 or later, as under Read the configuration). The response to a successful write is the stored document in the same shape as a read. Header values you save are never returned. In every headers or customHeaders map, including the request headers for your provider, OpenTelemetry export, and managed MCP servers, each stored value reads as the placeholder [stored on server - enter a new value to replace]. Sending the placeholder back keeps the stored value. A write that sends the placeholder is refused with 400 in two cases: nothing is stored under that header name yet (a first write, or a renamed header or server), or the same write changes where those headers are sent, for example with a new baseUrl. Send the actual header values in those cases. A write goes through the same server checks as a save in the admin console, but the console checks more before it saves, for example that the connection to your inference provider is complete. A write can therefore store a connection that users’ apps can’t use. Put every setting your provider requires in config, including how users authenticate, so that users’ apps can pick up the change as described under Configuration updates. Owners receive the email alert described there when a write changes where users’ apps connect or sign in, what can run on their devices, or the status. In place of an administrator, the alert names the key by its ID (apikey_…).

Setting status to disabled stops serving the configuration to users’ apps, as if none had been saved. A running app isn’t interrupted. At its next launch it shows a Restart required prompt whose Restart button returns the device to standard Claude Desktop, signed out. New sign-ins also stay in standard Claude Desktop. To serve the configuration again, set status back to active with another API write, or open Organization settings, go to the Connection page under Desktop 3P, and click Turn on in the banner at the top of the page. After that, users who clicked Restart sign in again as described under Onboard users.

Admin API errors

Status	Meaning
`400`	The server refused the document. The message names the field and the rule, for example `config.inference.baseUrl: must not embed credentials in the URL`. Nothing is stored.
`401`	The key in `x-api-key` is unknown, deleted, disabled, or expired.
`403`	The key lacks the scope the request needs, or isn’t an organization-level key. For a missing scope, the message lists the scopes the key has and the one required.
`404`	The key was created in an organization other than your Claude Desktop deployment’s, the `x-api-key` header is missing or its key is malformed, or (on a read) no configuration has been saved yet.
`409`	`expected_version` is not the current version. Read the configuration again and reapply your change.
`429`	Admin API requests share a per-organization limit of 100 requests per minute, as described under Rate limits. Retry after the number of seconds in the `retry-after` header.

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.
The console can’t hold modelCatalogEnabled, modelCatalogUrl, or deploymentDisplaySubtitle. An app managed from the console never fetches the model catalog, so it doesn’t need the two catalog keys.

​How it works

​Where your data goes

​Get set up

​Connect your identity provider

​Configure Claude Desktop

​Start from an existing configuration file

​What you can configure

​Choose how users authenticate to your provider

​When a helper script is the right choice

​Managed MCP servers that need authentication

​Localhost base URLs

​Per-group permission policies

​Turn on Unified Claude

​Plugin marketplaces

​Telemetry defaults

​Configuration kept on devices

​Usage analytics

​Audit administrator changes

​Onboard users

​Limit Claude Desktop to your organization

​Users in more than one Claude organization

​Block other accounts in Claude Desktop

​Unblock other accounts in Claude Desktop

​Configuration updates

​When the Claude sign-in expires

​Migrate an existing fleet to the admin console

​What is migrated

​What is not migrated

​Devices with a managed profile

​Which settings apply on a device with a managed profile

​Keep a device on its managed profile

​Remove users or return to MDM

​Manage the configuration with the Admin API

​Read the configuration

​Replace the configuration

​Admin API errors

​Limitations

How it works

Where your data goes

Get set up

Connect your identity provider

Configure Claude Desktop

Start from an existing configuration file

What you can configure

Choose how users authenticate to your provider

When a helper script is the right choice

Managed MCP servers that need authentication

Localhost base URLs

Per-group permission policies

Turn on Unified Claude

Plugin marketplaces

Telemetry defaults

Configuration kept on devices

Usage analytics

Audit administrator changes

Onboard users

Limit Claude Desktop to your organization

Users in more than one Claude organization

Block other accounts in Claude Desktop

Unblock other accounts in Claude Desktop

Configuration updates

When the Claude sign-in expires

Migrate an existing fleet to the admin console

What is migrated

What is not migrated

Devices with a managed profile

Which settings apply on a device with a managed profile

Keep a device on its managed profile

Remove users or return to MDM

Manage the configuration with the Admin API

Read the configuration

Replace the configuration

Admin API errors

Limitations