What this read moved
1–9 of 9cowork/changelog Changed · +37 / -0 lines
from line 2
22
33> Release notes for Claude Desktop
44
5<Update label="v1.49585.0" description="2026-09-08">
6 **General**
7
8 * Changed an invalid "Required organization" device-policy value to block sign-in with a configuration error, shown in the diagnostic report, instead of being ignored.
9 * Updated the app runtime to Electron 44 (Chromium 152); macOS 13 Ventura or later is now required.
10 * Fixed chats started from the menu bar or Quick Entry panel opening as an empty page for up to a minute before the reply appeared, and ignoring your instructions from Settings > Instructions for Claude.
11 * Fixed macOS sometimes showing repeated "bash would like to access data from other apps" prompts after quitting the app with sessions open.
12 * Fixed scheduled tasks around Mac sleep: a task that ran while the Mac was asleep was sometimes stopped as unresponsive when it woke, tasks missed during sleep sometimes started during a brief background wake and failed (they now start once the Mac is fully awake), and a one-time task occasionally started many sessions at once after wake.
13
14 **Code**
15
16 * Improved terminal tabs: they now show when a command is still running and ask before closing one that is, and a tab whose shell crashed or was killed stays open with a Restart option instead of closing silently with its output.
17 * Removed the Git requirement for local sessions that don't use a worktree; on Windows, Git for Windows (Git Bash) is no longer needed to start a session.
18 * Fixed the Files pane discarding unsaved edits without asking when you closed the pane, expanded another pane, or opened it in a new window; fixed the editor joining lines in files that mix Windows and Unix line endings; and a failed save now says the file couldn't be saved and offers Try again instead of claiming the file changed on disk.
19 * Fixed the selected model reverting or being refused when you switched models while a session was starting, restarting, or still answering; the session now uses the model you chose, and model changes in SSH and WSL sessions no longer fail with "plugin hooks could not be loaded".
20 * Added automatic sending for messages held after you hit your 5-hour limit: they now send when the limit resets, and you can still edit, cancel, or send them early.
21
22 **Cowork**
23
24 * Fixed a conversation started from an artifact, or from an artifact comment's Send to Claude, not using your selected model.
25 * Fixed a task disappearing from the app while its files stayed on disk when one of them was in use during delete; the task is now kept so the delete can be retried.
26 * Fixed an issue where the app could quit at launch with a very large number of Cowork tasks.
27 * Fixed the "Can't reach the Claude API" warning staying on screen until the app was restarted even after the connection had recovered; it now clears on its own.
28
29 **3P**
30
31 * Added `continuousAccessEvaluation` to the Microsoft 365 entry in `managedMcpServers`: the bundled connector's sign-ins, through the OS sign-in broker as well as the browser, request Continuous Access Evaluation tokens from Microsoft, which can live up to about 28 hours but are revoked within minutes when an administrator revokes sessions or a tenant network policy no longer allows them; set it to `disabled` to keep standard one-hour tokens on every sign-in path. Defaults to `enabled`.
32 * Added each model's description from the gateway to the model picker for deployments that discover models from the gateway.
33 * Changed `microsoftAuthBroker`: a new `required` option makes Microsoft 365 sign-in fail when the OS sign-in broker is unavailable instead of falling back to the browser, so the refresh token always stays held by the broker, and removes the token cache an earlier browser sign-in left on disk. Earlier versions treat `required` as `disabled` (browser sign-in only), so set it once every device is on this version or later.
34 * Changed Claude API, Google Vertex AI, Amazon Bedrock, and Bedrock Mantle deployments that set no custom base URL to no longer suppress Claude Code's experimental features, so tool search is on by default there (on Vertex AI with Claude 4.5 and newer models) and `toolSearchEnabled` is no longer needed to turn it on; gateway and Foundry deployments, and those providers behind a custom base URL, are unchanged.
35 * Fixed Amazon Bedrock sessions that use IAM Identity Center sign-in showing an internal error or a bare "operation was aborted" message when AWS sign-in could not be reached at session start; the app now says whether IAM Identity Center was unreachable, temporarily unavailable, refused the account or role, or returned an unreadable response, and what to do next.
36 * Fixed find in page (⌘F) missing matches in messages scrolled out of view.
37 * Fixed Google Cloud (Vertex AI) sessions sometimes running under the computer's own Google login instead of the credential your organization configured, and the app not asking you to sign in again after your Google session expired.
38 * Fixed the app refreshing the sign-in token about once a second when an inference gateway answers 403 to the model list request.
39 * Fixed the built-in Microsoft 365 connector showing Connected before anyone had signed in; its first request in a conversation now offers the sign-in, and a cancelled sign-in no longer hides its tools; the bundled connector also gains a tool that reads Teams channel messages.
40</Update>
41
542<Update label="v1.46388.4" description="2026-09-05">
643 **General**
744
third-party/claude-desktop/admin-console New page · 178 lines, new page
# Deploy with Enterprise Admin Console ## 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 ### Per-group permission policies ### Plugin marketplaces ### Telemetry defaults ## Onboard users ### Users in more than one Claude organization ### Configuration updates ## Remove users or return to MDM ## Limitations
A whole new page. There's nothing to diff it against, so here is what it says.
# Deploy with Enterprise Admin Console
> Manage your organization's Claude Desktop 3P configuration centrally with the Enterprise Admin Console, hosted by Anthropic
<Note>
The Enterprise Admin Console for Desktop 3P is in beta. Contact your Anthropic representative to have an organization provisioned.
</Note>
With the Enterprise Admin Console, Anthropic hosts your organization's [Claude Desktop 3P](/docs/third-party/claude-desktop/overview) 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](/docs/third-party/claude-desktop/mdm) profile or running a [bootstrap server](/docs/third-party/claude-desktop/bootstrap). 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](#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](https://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](#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.
| 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](/docs/third-party/claude-desktop/overview#data-handling-by-provider). |
| Conversation history, projects, memory, and uploaded files | **No.** They stay on the device. |
| Provider credentials, API keys, bearer tokens, and MCP secrets | **No.** They stay on the device, and the console refuses to save them. |
| 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. |
| 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](/docs/third-party/claude-desktop/telemetry) describes what each category contains. |
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](/docs/third-party/claude-desktop/telemetry).
## 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](https://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](https://support.claude.com/en/articles/13132885-set-up-single-sign-on-sso). 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](https://support.claude.com/en/articles/13133195-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](#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](#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](https://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](#what-you-can-configure). Each field sets one of the documented [configuration keys](/docs/third-party/claude-desktop/configuration), 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](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence) can stay.
* **Machines configured in the app:** a device set up from the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration) 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](/docs/third-party/claude-desktop/installation#single-machine-setup).
Users then sign in as described under [Onboard users](#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`](/docs/third-party/claude-desktop/configuration#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](/docs/third-party/claude-desktop/import#step-2-local-cowork-and-code-sessions).
### What you can configure
From the console you can set the same [configuration keys](/docs/third-party/claude-desktop/configuration) that MDM and bootstrap delivery support, apart from the items listed under [Limitations](#limitations). The **Desktop 3P** section of the left navigation has these pages:
| Page | What you configure there |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Connection** | The inference provider ([gateway](/docs/third-party/claude-desktop/gateway), [Amazon Bedrock](/docs/third-party/claude-desktop/bedrock), [Bedrock Mantle](/docs/third-party/claude-desktop/mantle), [Google Cloud's Agent Platform](/docs/third-party/claude-desktop/vertex), or [Microsoft Foundry](/docs/third-party/claude-desktop/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](#users-in-more-than-one-claude-organization). |
| **Workspace** | Whether Chat, Cowork, and Code are each available, the folders and network hosts the app may use, permission modes and built-in tool policy, whether users may add their own skills and plugins, and organization instructions |
| **Connectors** | Managed MCP servers, including the [built-in connectors](/docs/third-party/claude-desktop/built-in-connectors), whether users may add their own MCP servers, desktop extension policy, and [**Claude.ai data import**](/docs/third-party/claude-desktop/import) |
| **Telemetry & updates** | Which telemetry categories go to Anthropic, OpenTelemetry export to your collector, update policy, the [configuration relaunch window](#configuration-updates), and the configuration re-check interval |
| **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](#plugin-marketplaces) that users' apps fetch, and how each one installs |
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](/docs/third-party/claude-desktop/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).
### 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](/docs/third-party/claude-desktop/extensions#plugin-marketplaces-admin) 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](/docs/third-party/claude-desktop/telemetry) 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](#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](#connect-your-identity-provider)
* Devices run the latest Claude Desktop release, installed as described in [Installation and setup](/docs/third-party/claude-desktop/installation)
* Devices carry no MDM-delivered Claude Desktop configuration. If a managed profile or registry policy sets any key other than the [app-behavior keys](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence) (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](/docs/third-party/claude-desktop/telemetry)
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.
<Steps>
<Step title="Sign in to Claude">
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.
</Step>
<Step title="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](#users-in-more-than-one-claude-organization).
</Step>
<Step title="Sign in to the inference provider">
If your connection uses an interactive sign-in, sign in to your inference provider or gateway next, as with MDM or bootstrap delivery.
</Step>
<Step title="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.
</Step>
</Steps>
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](/docs/third-party/claude-desktop/mdm) or [bootstrap](/docs/third-party/claude-desktop/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](#start-from-an-existing-configuration-file), after you set the [`claudeAiImport`](/docs/third-party/claude-desktop/configuration#claudeaiimport) key with `enabled` set to `true` in the profile or policy you deploy.
## Limitations
* The [Claude API](/docs/third-party/claude-desktop/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.
third-party/claude-desktop/configuration Changed · +66 / -54 lines
from line 4
44
55<Tip>Most settings on this page are easier to configure in the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration). Use this reference when you're scripting an MDM policy or bootstrap response by hand.</Tip>
66
7Claude Desktop on third-party (3P) is configured entirely through OS-native managed preferences: a `.mobileconfig` profile on macOS, registry policy on Windows, or a root-owned JSON file on Linux. This page documents every supported key. For the desktop release each key first appeared in, see the [configuration changelog](/docs/third-party/claude-desktop/configuration-changelog).
7Claude Desktop on third-party (3P) is configured through OS-native managed preferences: a `.mobileconfig` profile on macOS, registry policy on Windows, or a root-owned JSON file on Linux (organizations in the admin console beta can instead deliver these settings from **Organization settings** on claude.ai). This page documents every supported key. For the desktop release each key first appeared in, see the [configuration changelog](/docs/third-party/claude-desktop/configuration-changelog).
88
99The easiest way to author a configuration is the in-app configuration window (**Developer → Configure Third-Party Inference…**), which validates values, shows per-provider requirements, and exports directly to `.mobileconfig` or `.reg`. Use this reference when you need to author policy by hand, audit an existing profile, or understand exactly what a key does.
1010
from line 258
258258
259259 **Extended context** (`supports1m`) is a capability assertion you make about your deployment; only set it for models you've confirmed support the 1M-token window:
260260
261 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}
261 ```json theme={null}
262262 [{"name": "claude-sonnet-5", "supports1m": true}, "claude-opus-4-8"]
263263 ```
264264
from line 266
266266
267267 **Display label** (`labelOverride`) is for IDs the picker can't derive a friendly name from (Bedrock ARNs, gateway routing aliases). Display-only; `name` is still what the app sends:
268268
269 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}
269 ```json theme={null}
270270 [{"name": "arn:aws:bedrock:us-east-1:123:application-inference-profile/abc", "labelOverride": "Claude Opus (Prod)"}]
271271 ```
272272
273273 **Tier mapping** (`anthropicFamilyTier`) tells the app which Claude tier (`haiku`/`sonnet`/`opus`/`fable`/`mythos`) an entry stands in for, so bare tier aliases (e.g. in Code sessions) resolve to your model. `isFamilyDefault: true` picks the winner when several entries share a tier:
274274
275 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}
275 ```json theme={null}
276276 [{"name": "us.anthropic.claude-opus-4-8", "anthropicFamilyTier": "opus"}]
277277 ```
278278
from line 297
297297 <Accordion title="inferenceModelPricing details">
298298 Each row replaces Anthropic list price for one model in the Usage page's estimate, in USD per million tokens (`inputPerMtok`, `outputPerMtok`, `cacheReadPerMtok`, `cacheWritePerMtok`, all four required; `cacheWritePerMtok` prices both 5-minute and 1-hour cache writes); rows apply only while `inferenceModelPricingEnabled` is `true` and do not turn the estimate on by themselves. Mirrors Claude Code's managed `modelPricing.overrides`, and `name` is matched the same way: a built-in Claude model ID (e.g. `claude-sonnet-4-6`, or its Bedrock, Vertex, or Foundry ID) covers every dated and provider spelling of that model; any other value (a gateway alias, an inference-profile ARN) matches that exact ID only (case-insensitive) and wins over a built-in row. An ID Claude Code cannot map to a Claude model at all gets no estimate until a row here prices it. `inferenceModelPricingMultiplier` still applies on top of a row.
299299
300 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}
300 ```json theme={null}
301301 {"inferenceModelPricingEnabled": true, "inferenceModelPricingMultiplier": 0.9, "inferenceModelPricing": [{"name": "claude-sonnet-4-6", "inputPerMtok": 2.4, "outputPerMtok": 12, "cacheReadPerMtok": 0.24, "cacheWritePerMtok": 3}]}
302302 ```
303303
from line 476
476476 </Accordion>
477477
478478 <Accordion title="toolSearchEnabled details">
479 When enabled, Cowork, Code, and Chat sessions place only tool names in context up front, and Claude fetches a tool's full schema the first time it needs it. Use this when many MCP tools are configured and their inlined schemas crowd out the context window (sessions that compact every turn or two). Enable it only if your endpoint forwards and accepts the request shape it will receive; when it does not, requests fail with HTTP 400. Leave unset to keep the conservative default.
479 When enabled, Cowork, Code, and Chat sessions place only tool names in context up front, and Claude fetches a tool's full schema the first time it needs it. Use this when many MCP tools are configured and their inlined schemas crowd out the context window. If your endpoint does not accept the request shape it then receives, requests fail with HTTP 400.
480480
481 * **Gateway provider, app versions bundling Claude Code 2.1.247 or later**: requests add only the tool-search shape (the `tool-search-tool-2025-10-19` `anthropic-beta` value, deferred tool loading, `tool_reference` content blocks); every other experimental Claude Code beta stays suppressed. OS-level Claude Code managed settings that keep that suppression or turn `ENABLE_TOOL_SEARCH` off still win; set `ENABLE_TOOL_SEARCH` to `force` there instead (with `parentSettingsBehavior: "merge"`). Environments that put Claude Code in its own gateway mode (`CLAUDE_CODE_USE_GATEWAY`) get tool search with Claude Code's gateway-safe shape regardless.
482 * **Other providers, and earlier app versions**: the experimental-beta suppression is lifted for the session, so requests carry the tool-search shape together with Claude Code's other experimental betas for that provider (for example `context_management` fields). On Vertex with app versions bundling Claude Code older than 2.1.221, leave this unset while any model older than Claude 4.5 is in use; those engines send the header regardless of model and Vertex's pre-4.5 stacks reject it.
481 * **Claude API, Vertex AI, Bedrock, or Bedrock Mantle with no custom base URL**: not needed. The app leaves Claude Code's experimental betas on there, as terminal Claude Code does, so tool search is on by default (on Vertex AI, for Claude 4.5 and newer models). To turn it off in Code, Cowork, and Chat, set `ENABLE_TOOL_SEARCH` to `false` in the `env` block of OS-level Claude Code managed settings (with `parentSettingsBehavior: "merge"`). Earlier app versions treat these like the last case.
482 * **Gateway provider, app versions bundling Claude Code 2.1.247 or later**: requests add only the tool-search shape (the `tool-search-tool-2025-10-19` `anthropic-beta` value, deferred tool loading, `tool_reference` content blocks); every other experimental Claude Code beta stays suppressed. OS-level Claude Code managed settings that keep that suppression or turn `ENABLE_TOOL_SEARCH` off still win; set `ENABLE_TOOL_SEARCH` to `force` there instead (with `parentSettingsBehavior: "merge"`). Sessions in Claude Code's own gateway mode (`CLAUDE_CODE_USE_GATEWAY`) get its gateway-safe tool-search shape regardless.
483 * **Foundry, a custom base URL, and earlier app versions**: the app suppresses Claude Code's experimental betas for the session and the key lifts that, so requests carry the tool-search shape together with Claude Code's other experimental betas for that provider. On Vertex with app versions bundling Claude Code older than 2.1.221, leave this unset while any model older than Claude 4.5 is in use; those engines send the header regardless of model and Vertex's pre-4.5 stacks reject it.
483484 </Accordion>
484485
485486 <Accordion title="skipWebFetchPreflight details">
from line 547
546547
547548### Authentication
548549
549| Setting | Type | Availability | Default | Description |
550| ----------------------------------------------------------------------------------------------- | ------ | --------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
551| <span id="microsoftauthbroker" />Microsoft 365 native sign-in broker<br />`microsoftAuthBroker` | `enum` | MDM + Bootstrap | `auto` | Set to “disabled” to force browser-based Microsoft 365 sign-in instead of the native Company Portal / Windows account broker. One of: `auto`, `disabled`. Defaults to `auto`. |
550| Setting | Type | Availability | Default | Description |
551| ----------------------------------------------------------------------------------------------- | ------ | --------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
552| <span id="microsoftauthbroker" />Microsoft 365 native sign-in broker<br />`microsoftAuthBroker` | `enum` | MDM + Bootstrap | `auto` | “disabled” forces browser-based Microsoft 365 sign-in; “required” fails sign-in when the OS broker is unavailable, so the refresh token stays broker-held. One of: `auto`, `disabled`, `required`. Defaults to `auto`. |
552553
554<AccordionGroup>
555 <Accordion title="microsoftAuthBroker details">
556 `auto` (default): use the OS sign-in broker where available (WAM on Windows, the Company Portal SSO extension on macOS) and fall back to a browser sign-in otherwise. `disabled`: always use the browser sign-in. `required`: fail sign-in when the broker is unavailable rather than falling back to the browser, so the refresh token stays broker-held. Linux has no broker, so `required` is not supported there. Desktop builds older than the version that introduced `required` treat it as `disabled` (browser-only sign-in) — the opposite posture — so gate rollout on client version.
557 </Accordion>
558</AccordionGroup>
559
553560### Extensions
554561
555562| Setting | Type | Availability | Default | Description |
from line 589
582589
583590 For the bundled Microsoft 365 connector, the send tools (`outlook_send_mail`, `outlook_send_draft`, `outlook_forward_mail`, `outlook_create_event`, `outlook_update_event`, `teams_send_chat_message`, `teams_send_channel_message`, `teams_reply_channel_message`) cannot be loosened below `ask`; an `allow` setting resolves to `ask`.
584591
585 | Field | Type | Default | Description |
586 | --------------------------------------- | ---------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
587 | `name` | `string` | — | Unique name for this server. Shown to users and used to key tool policy and sign-in state. |
588 | `server` | `string` | — | Which bundled connector this entry turns on. Set instead of a transport; each built-in server has its own fields. One of: `microsoft365`, `websearch`, `github`. |
589 | `tenantId` | `string` | — | Your organization’s Microsoft Entra directory (tenant) ID. |
590 | `clientId` | `string` | — | OAuth app client ID for this built-in server. |
591 | `azureCloud` | `enum` | — | Microsoft cloud for sign-in and Graph. Leave as global for commercial Microsoft 365; US Government clouds require your own app registration (Client ID). One of: `global`, `us-gov-high`, `us-gov-dod`. |
592 | `scope` | `string` | — | What the server may request at sign-in. If blank, Desktop’s default read set is used. |
593 | `toolPolicy` | `object` | — | Lock the approval state for specific tools. Unlisted tools stay user-controlled. |
594 | `headers` | `object` | — | Static headers sent on every request — routing and tenant headers only. No credentials here; use the headers helper script for tokens and rotating values. |
595 | `headersHelper` | `string` | — | Script that prints the auth header as a JSON object to stdout. Runs before each request (cached for the TTL below). |
596 | `headersHelperTtlSec` | `integer` | — | How long the helper’s headers are reused before it runs again, in seconds. Defaults to 300. |
597 | `headersHelperRefreshBufferSec` | `integer` | — | Seconds before the TTL expires at which the helper re-runs mid-session. Defaults to 60. Keep it larger than the helper’s typical runtime. |
598 | `provider` | `enum` | — | Runs search from the desktop, for inference providers without native web search. Supply the provider’s API key through the headers helper script below. One of: `brave`, `tavily`, `exa`, `custom`. |
599 | `customUrl` | `string` | — | POST endpoint accepting \{q} JSON and returning a results\[] array. Only used when provider is Custom. |
600 | `host` | `string` | — | Leave blank for github.com. For GitHub Enterprise Server, your instance’s base URL. |
601 | `toolsets` | `string` | — | Comma-separated github-mcp-server toolsets to enable. If blank, the bundled server’s default toolsets are used. |
602 | `readOnly` | `boolean` | — | Offer only read tools — the server registers no write tools at all. |
603 | `transport` | `enum` | — | How the app connects: Streamable HTTP or legacy SSE for remote servers, or a local command over stdio. One of: `http`, `sse`, `stdio`. |
604 | `url` | `string` | — | HTTPS endpoint of the remote MCP server. |
605 | `oauth` | `object` | — | OAuth for a remote server: true to auto-register a client, a pre-registered client ID with tenant and scope, or mode “hosted” for an Anthropic-signed identity. |
606 | `oauth.clientId` | `string` | — | OAuth client ID from your IdP app registration. Leave unset to auto-register (dynamic client registration) and only narrow scopes. |
607 | `oauth.clientSecret` | `string` | — | Only for IdPs whose token endpoint requires a client secret (e.g. Box). Leave blank for PKCE-only public clients. |
608 | `oauth.clientSecretHelper` | `string` | — | Executable that prints the client secret on stdout. Overrides the inline value. |
609 | `oauth.authorizationServer` | `string[]` | — | Issuer URLs the OAuth sign-in may use, as a JSON array. Pre-filled by presets; ask your IdP admin if unsure. |
610 | `oauth.authorizationUrl` | `string` | — | Only for IdPs that don’t serve a .well-known discovery document. Set together with Token URL; requires Client ID. |
611 | `oauth.tokenUrl` | `string` | — | Only for IdPs that don’t serve a .well-known discovery document. Set together with Authorization URL; requires Client ID. |
612 | `oauth.tenantId` | `string` | — | Required for single-tenant Entra apps. Leave blank for multi-tenant or non-Microsoft IdPs. |
613 | `oauth.authFlow` | `enum` | — | How Entra sign-in runs for this server: the system browser (default) or the OS identity broker. One of: `browser`, `broker`. |
614 | `oauth.scope` | `string` | — | Space-separated scopes sent on the authorize request. Leave unset to use the scopes the server advertises. Required when Tenant ID is set. |
615 | `oauth.appendOfflineAccess` | `boolean` | — | Adds offline\_access to the authorize request so the IdP returns a refresh token for silent renewal. |
616 | `oauth.callbackHost` | `enum` | — | Use localhost only if your IdP’s registered redirect URI specifies it. One of: `127.0.0.1`, `localhost`. |
617 | `oauth.callbackPort` | `integer` | — | Only set if your IdP requires an exact-match redirect port. Entra accepts any. |
618 | `oauth.additionalRedirectReferrerHosts` | `string` | — | Space-separated hostnames also accepted as the referrer of the sign-in callback. Only needed when the IdP completes sign-in from a different host. |
619 | `command` | `string` | — | Absolute path to the server executable, run on the user’s machine. |
620 | `args` | `string[]` | — | Arguments passed to the command, one per entry. |
621 | `env` | `object` | — | Environment variables set for the command. |
622 | `envHelper` | `string` | — | Script that prints environment variables as a JSON object to stdout. Runs when the local server starts (cached for the TTL below). |
623 | `envHelperTtlSec` | `integer` | `300` | Maximum age of a cached helper result, in seconds (default 300). Applies when the server starts or restarts. |
624 | `startupTimeoutSec` | `integer` | `120` | Maximum wait in seconds for the server to start and list its tools. |
592 | Field | Type | Default | Description |
593 | --------------------------------------- | ---------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
594 | `name` | `string` | — | Unique name for this server. Shown to users and used to key tool policy and sign-in state. |
595 | `server` | `string` | — | Which bundled connector this entry turns on. Set instead of a transport; each built-in server has its own fields. One of: `microsoft365`, `websearch`, `github`. |
596 | `tenantId` | `string` | — | Your organization’s Microsoft Entra directory (tenant) ID. |
597 | `clientId` | `string` | — | OAuth app client ID for this built-in server. |
598 | `azureCloud` | `enum` | — | Microsoft cloud for sign-in and Graph. Leave as global for commercial Microsoft 365; US Government clouds require your own app registration (Client ID). One of: `global`, `us-gov-high`, `us-gov-dod`. |
599 | `continuousAccessEvaluation` | `enum` | `enabled` | Request CAE-capable Microsoft Graph tokens: long-lived (up to about 28 hours) but revocable within minutes. Set “disabled” to keep standard one-hour tokens. One of: `enabled`, `disabled`. |
600 | `scope` | `string` | — | What the server may request at sign-in. If blank, Desktop’s default read set is used. |
601 | `toolPolicy` | `object` | — | Lock the approval state for specific tools. Unlisted tools stay user-controlled. |
602 | `headers` | `object` | — | Static headers sent on every request — routing and tenant headers only. No credentials here; use the headers helper script for tokens and rotating values. |
603 | `headersHelper` | `string` | — | Script that prints the auth header as a JSON object to stdout. Runs before each request (cached for the TTL below). |
604 | `headersHelperTtlSec` | `integer` | — | How long the helper’s headers are reused before it runs again, in seconds. Defaults to 300. |
605 | `headersHelperRefreshBufferSec` | `integer` | — | Seconds before the TTL expires at which the helper re-runs mid-session. Defaults to 60. Keep it larger than the helper’s typical runtime. |
606 | `provider` | `enum` | — | Runs search from the desktop, for inference providers without native web search. Supply the provider’s API key through the headers helper script below. One of: `brave`, `tavily`, `exa`, `custom`. |
607 | `customUrl` | `string` | — | POST endpoint accepting \{q} JSON and returning a results\[] array. Only used when provider is Custom. |
608 | `host` | `string` | — | Leave blank for github.com. For GitHub Enterprise Server, your instance’s base URL. |
609 | `toolsets` | `string` | — | Comma-separated github-mcp-server toolsets to enable. If blank, the bundled server’s default toolsets are used. |
610 | `readOnly` | `boolean` | — | Offer only read tools — the server registers no write tools at all. |
611 | `transport` | `enum` | — | How the app connects: Streamable HTTP or legacy SSE for remote servers, or a local command over stdio. One of: `http`, `sse`, `stdio`. |
612 | `url` | `string` | — | HTTPS endpoint of the remote MCP server. |
613 | `oauth` | `object` | — | OAuth for a remote server: true to auto-register a client, a pre-registered client ID with tenant and scope, or mode “hosted” for an Anthropic-signed identity. |
614 | `oauth.clientId` | `string` | — | OAuth client ID from your IdP app registration. Leave unset to auto-register (dynamic client registration) and only narrow scopes. |
615 | `oauth.clientSecret` | `string` | — | Only for IdPs whose token endpoint requires a client secret (e.g. Box). Leave blank for PKCE-only public clients. |
616 | `oauth.clientSecretHelper` | `string` | — | Executable that prints the client secret on stdout. Overrides the inline value. |
617 | `oauth.authorizationServer` | `string[]` | — | Issuer URLs the OAuth sign-in may use, as a JSON array. Pre-filled by presets; ask your IdP admin if unsure. |
618 | `oauth.authorizationUrl` | `string` | — | Only for IdPs that don’t serve a .well-known discovery document. Set together with Token URL; requires Client ID. |
619 | `oauth.tokenUrl` | `string` | — | Only for IdPs that don’t serve a .well-known discovery document. Set together with Authorization URL; requires Client ID. |
620 | `oauth.tenantId` | `string` | — | Required for single-tenant Entra apps. Leave blank for multi-tenant or non-Microsoft IdPs. |
621 | `oauth.authFlow` | `enum` | — | How Entra sign-in runs for this server: the system browser (default) or the OS identity broker. One of: `browser`, `broker`. |
622 | `oauth.scope` | `string` | — | Space-separated scopes sent on the authorize request. Leave unset to use the scopes the server advertises. Required when Tenant ID is set. |
623 | `oauth.appendOfflineAccess` | `boolean` | — | Adds offline\_access to the authorize request so the IdP returns a refresh token for silent renewal. |
624 | `oauth.callbackHost` | `enum` | — | Use localhost only if your IdP’s registered redirect URI specifies it. One of: `127.0.0.1`, `localhost`. |
625 | `oauth.callbackPort` | `integer` | — | Only set if your IdP requires an exact-match redirect port. Entra accepts any. |
626 | `oauth.additionalRedirectReferrerHosts` | `string` | — | Space-separated hostnames also accepted as the referrer of the sign-in callback. Only needed when the IdP completes sign-in from a different host. |
627 | `command` | `string` | — | Absolute path to the server executable, run on the user’s machine. |
628 | `args` | `string[]` | — | Arguments passed to the command, one per entry. |
629 | `env` | `object` | — | Environment variables set for the command. |
630 | `envHelper` | `string` | — | Script that prints environment variables as a JSON object to stdout. Runs when the local server starts (cached for the TTL below). |
631 | `envHelperTtlSec` | `integer` | `300` | Maximum age of a cached helper result, in seconds (default 300). Applies when the server starts or restarts. |
632 | `startupTimeoutSec` | `integer` | `120` | Maximum wait in seconds for the server to start and list its tools. |
625633 </Accordion>
626634
627635 <Accordion title="mcpPersistentAlwaysAllowEnabled details">
from line 734
726734| Setting | Type | Availability | Default | Description |
727735| --------------------------------------------------------------------------------------------------- | --------- | --------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
728736| <span id="otlpendpoint" />OpenTelemetry collector endpoint<br />`otlpEndpoint` | `string` | MDM + Bootstrap | — | Where OpenTelemetry logs and metrics are sent. Leave blank to disable. |
729| <span id="otlpprotocol" />OpenTelemetry exporter protocol<br />`otlpProtocol` | `enum` | MDM + Bootstrap | `http/protobuf` | grpc or http/protobuf. One of: `http/protobuf`, `http/json`, `grpc`. Defaults to `http/protobuf`. |
737| <span id="otlpprotocol" />OpenTelemetry exporter protocol<br />`otlpProtocol` | `enum` | MDM + Bootstrap | `http/protobuf` | Transport protocol for the OpenTelemetry exporters. One of: `http/protobuf`, `http/json`, `grpc`. Defaults to `http/protobuf`. |
730738| <span id="otlpheaders" />OpenTelemetry exporter headers<br />`otlpHeaders` | `object` | MDM + Bootstrap | — | Static collector headers — routing and tenant headers only. No credentials here; use Collector authentication or the headers helper script for tokens. Deprecated: `otlpHeaders as a "Name=value,…" string or a ["Name: value", …] list` (accepted until October 7, 2026); use a JSON object such as \{"Name": "value"}. If it is still present after that, a string or list value will be rejected as malformed and no exporter headers will be sent. |
731739| <span id="otlpauthmode" />Collector authentication<br />`otlpAuthMode` | `enum` | MDM + Bootstrap | — | inference-credential sends the user’s inference bearer token to the collector as Authorization: Bearer. One of: `none`, `inference-credential`. |
732740| <span id="otlpheadershelper" />OpenTelemetry headers helper script<br />`otlpHeadersHelper` | `string` | MDM + Bootstrap | — | Absolute path to an executable that prints a JSON object of collector headers. Merged over the static headers and Collector authentication; the helper wins. |
from line 744
736744| <span id="otlptracesenabled" />Export traces<br />`otlpTracesEnabled` | `boolean` | MDM + Bootstrap | — | Also export OpenTelemetry traces from Cowork tasks and Code sessions. Uses Claude Code’s session tracing. |
737745
738746<AccordionGroup>
747 <Accordion title="otlpProtocol details">
748 Code sessions export over the protocol set here. Chats and Cowork tasks export over `http/protobuf` instead of `grpc` on Windows, and on other platforms whenever the Claude Code engine is given an HTTP proxy (the operating system's proxy, `egressProxyUrl` or `egressProxyPacUrl`, or `HTTPS_PROXY` / `HTTP_PROXY` in a Claude Code settings file); the application log notes the substitution. The desktop application's own events always go over `http/json` to `<endpoint>/v1/logs`. None of this changes the endpoint, so choose `grpc` only for a collector that also serves OTLP/HTTP at the same address; otherwise keep `http/protobuf` and point `otlpEndpoint` at the collector's OTLP/HTTP receiver (conventionally port 4318).
749 </Accordion>
750
739751 <Accordion title="otlpAuthMode details">
740752 `inference-credential` adds `Authorization: Bearer <token>` to every export, using the token the app currently holds for the inference provider, with no helper script to deploy. The collector must accept that token as issued: a gateway OIDC token carries the gateway’s audience, Microsoft Entra on Foundry issues the Foundry resource’s token, and Vertex workforce identity forwards a Google Cloud access token; static gateway and Bedrock keys are forwarded as-is. Because the token can also call inference as the user, use this only for a collector you operate; for anything else, use the headers helper script with an ingest-scoped credential. Kinds that never produce a bearer (AWS SigV4 kinds on Bedrock, Google ADC / OAuth files on Vertex, API-key kinds) export without it — use the helper script instead. Cowork tasks pick up the current token each time they start; a Code session keeps the token it started with for as long as it stays open; the desktop’s own event exporter uses the current token on every flush. Before sign-in, exports go out unauthenticated. An `Authorization` header printed by the headers helper script wins over this.
741753 </Accordion>
from line 861
849861 <Accordion title="orgPluginSettings details">
850862 Locks per-tool permissions on MCP servers that arrive via the org-plugins directory — one entry per server name:
851863
852 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}
864 ```json theme={null}
853865 [{"serverName": "internal-search", "tools": [{"toolName": "delete_document", "permission": "blocked"}]}]
854866 ```
855867
third-party/claude-desktop/configuration-changelog Changed · +7 / -0 lines
from line 4
44
55Configuration keys by Claude Desktop release. Each section lists keys added in that release, with the MDM key name (for plist/registry deployment) and the equivalent JSON shape (for local-file or bootstrap remote configuration).
66
7<Update label="v1.49585.0" description="2026-09-08">
8 **Changed:**
9
10 * `managedMcpServers`: the built-in Microsoft 365 server entry (`"server": "microsoft365"`) accepts a new `continuousAccessEvaluation` value, `enabled` (the default) or `disabled`. When enabled, the bundled connector requests Continuous Access Evaluation-capable Microsoft Graph tokens, which live up to about 28 hours but are cut off within minutes when an administrator revokes sessions or disables the account, or, where the tenant enforces a location or compliant-network Conditional Access policy, when the token is used from outside that network; `disabled` keeps standard one-hour tokens. A change applies to tokens issued after the connector next starts.
11 * `microsoftAuthBroker` accepts a new `required` value: Microsoft 365 sign-in fails when the OS sign-in broker (WAM on Windows, the Company Portal SSO extension on macOS) is unavailable instead of falling back to the browser, so the refresh token stays broker-held, and the connector removes the token cache an earlier browser sign-in left on disk. Linux has no broker, so `required` is not supported there. Earlier releases treat `required` as `disabled` (browser-only sign-in), so deploy it once every device is on this release or later.
12</Update>
13
714<Update label="v1.46388.4" description="2026-09-05">
815 No configuration changes in this release.
916</Update>
third-party/claude-desktop/in-app-configuration Changed · +8 / -8 lines
from line 20
2020
2121Use the **Export** menu to generate deployment artifacts for a fleet:
2222
23| Export option | Use with |
24| --------------------------- | --------------------------------------------------------------------------------------------------- |
25| `.mobileconfig` profile | Jamf or any macOS MDM |
26| `.reg` policy file | Intune, Group Policy, or any Windows MDM |
27| ADMX template (`.zip`) | Intune or Group Policy; a schema-only template, you enter values in the management console |
28| Profile Manifest (`.plist`) | Jamf, ProfileCreator, or similar macOS tools; a schema-only template, you enter values in your tool |
29| Bootstrap JSON | The response body for a [bootstrap server](/docs/third-party/claude-desktop/bootstrap) |
30| Egress allowlist | Your firewall or network team |
23| Export option | Use with |
24| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
25| `.mobileconfig` profile | Jamf or any macOS MDM |
26| `.reg` policy file | Intune, Group Policy, or any Windows MDM |
27| ADMX template (`.zip`) | Intune or Group Policy; a schema-only template, you enter values in the management console |
28| Profile Manifest (`.plist`) | Jamf, ProfileCreator, or similar macOS tools; a schema-only template, you enter values in your tool |
29| JSON config | The response body for a [bootstrap server](/docs/third-party/claude-desktop/bootstrap), or a configuration file for a device without MDM |
30| Egress allowlist | Your firewall or network team |
3131
3232See [Deploy with MDM](/docs/third-party/claude-desktop/mdm) or [Deploy with a bootstrap server](/docs/third-party/claude-desktop/bootstrap) to distribute what you exported.
3333
third-party/claude-desktop/installation Changed · +15 / -12 lines
from line 1
11# Installation and setup
22
3> Install Claude Desktop on 3P, check device readiness, and choose how configuration reaches your devices: an MDM profile or a bootstrap server
3> Install Claude Desktop on 3P, check device readiness, and choose whether configuration reaches your devices through the Enterprise Admin Console, an MDM profile, or a bootstrap server
44
55Claude Desktop on third-party (3P) is the standard Claude Desktop application plus a managed configuration that activates third-party inference mode. Setup is two pieces: install the regular Claude Desktop app, and deliver the configuration to it.
66
from line 39
3939| macOS | `.dmg` | Drag **Claude.app** to Applications |
4040| Windows | `.msix` | Supports per-machine provisioning for enterprise deployment |
4141
42For fleet rollouts, distribute the installer through your standard software-distribution mechanism after the configuration reaches devices; [Choose a configuration delivery model](#choose-a-configuration-delivery-model) covers how the configuration gets there.
42For fleet rollouts, distribute the installer through your standard software-distribution mechanism. On the MDM and bootstrap paths, distribute it after the configuration reaches devices; [Choose a configuration delivery model](#choose-a-configuration-delivery-model) covers how the configuration gets there.
4343
4444## Choose a configuration delivery model
4545
46Configuration reaches devices in one of two ways. Both typically use your MDM tooling to push a profile; the difference is what the profile contains.
46Configuration reaches devices in one of three ways. With the Enterprise Admin Console, Anthropic hosts the configuration and users receive it by signing in to the app. With MDM or a bootstrap server, you typically push a profile to devices with your MDM tooling, and the two differ in what the profile contains.
4747
48| | MDM profile | Bootstrap server |
49| -------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
50| What you deploy to devices | The full configuration, exported as a `.mobileconfig` or `.reg` profile | A minimal profile containing only the bootstrap keys (`bootstrapUrl`, optionally `bootstrapOidc` or request headers) |
51| Where settings live | In the profile, identical for every device the profile targets | On an HTTPS endpoint you operate, which returns each user's configuration at sign-in |
52| Per-user values | Separate profiles per device group | The server keys its response to the signed-in user |
53| Changing settings | Export and push an updated profile | Change your server's response; devices pick it up at the next fetch, with no profile push |
48| | Enterprise Admin Console | MDM profile | Bootstrap server |
49| -------------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
50| What you deploy to devices | Only the app, which downloads each user's configuration when they sign in with their work account | The full configuration, exported as a `.mobileconfig` or `.reg` profile | A minimal profile containing only the bootstrap keys (`bootstrapUrl`, optionally `bootstrapOidc` or request headers) |
51| Where settings live | In the Enterprise Admin Console, which Anthropic hosts and your administrators edit in a browser | In the profile, identical for every device the profile targets | On an HTTPS endpoint you operate, which returns each user's configuration at sign-in |
52| Per-user values | Permission policies per group of users | Separate profiles per device group | The server keys its response to the signed-in user |
53| Changing settings | Save the change in the console. Running apps pick it up at their next check and ask the user to relaunch | Export and push an updated profile | Change your server's response; devices pick it up at the next fetch, with no profile push |
5454
55Choose an MDM profile when one configuration, or a few group-scoped profiles, covers your fleet. Most MDMs support role-based distribution, so per-group configuration doesn't require a bootstrap server.
55Choose the Enterprise Admin Console when you want to manage the configuration centrally without operating MDM profiles or a server, and your users can sign in to Claude Desktop with a Claude account tied to their work email. Anthropic stores your user list and the settings you save. Prompts still go only to your inference provider, and conversations stay on the device. Contact your Anthropic representative to have an organization provisioned.
5656
57Choose an MDM profile when one configuration, or a few group-scoped profiles, covers your fleet and no device should depend on a sign-in to Anthropic. Most MDMs support role-based distribution, so per-group configuration doesn't require a bootstrap server.
58
5759Building the configuration in the app is optional. The [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration) can also export schema-only templates (an ADMX template for Windows, a Profile Manifest `.plist` for macOS) from its **Export** menu, so you can enter values directly in your management console instead. See [Export the profile](/docs/third-party/claude-desktop/mdm#2-export-the-profile) for all formats.
5860
5961Choose a bootstrap server when your organization doesn't use MDM, or when per-user credentials or frequently changing settings would make per-group profiles unwieldy. The tradeoff is that you operate the endpoint.
6062
61The two models don't combine: when a bootstrap response is in effect, it replaces MDM-delivered values wholesale, and a few device-level keys are only available via MDM (see the Availability column in the [configuration reference](/docs/third-party/claude-desktop/configuration)).
63The models don't combine. A device whose MDM profile or registry policy sets any key other than the [app-behavior keys](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence) uses that configuration and ignores the Enterprise Admin Console. When a bootstrap response is in effect, it replaces MDM-delivered values wholesale, and a few device-level keys are only available via MDM (see the Availability column in the [configuration reference](/docs/third-party/claude-desktop/configuration)).
6264
6365Pick your path:
6466
67* [Deploy with Enterprise Admin Console](/docs/third-party/claude-desktop/admin-console) covers provisioning, configuring the app in the console, and onboarding users.
6568* [Deploy with MDM](/docs/third-party/claude-desktop/mdm) covers authoring the configuration in the app, exporting the profile, and deploying it to your fleet.
6669* [Deploy with a bootstrap server](/docs/third-party/claude-desktop/bootstrap) covers getting the bootstrap keys onto devices and running the server.
6770
68On either path, deploy the configuration before the app so users open Claude for the first time and land directly in the third-party deployment.
71On the MDM and bootstrap paths, deploy the configuration before the app so users open Claude for the first time and land directly in the third-party deployment. With the Enterprise Admin Console, save a configuration in the console first, and users then install the app and sign in.
6972
7073## Single-machine setup
7174
third-party/claude-desktop/legal Changed · +4 / -0 lines
### Enterprise Admin Console for Desktop 3P
from line 12
1212
1313Claude Desktop on 3P routes model inference through the provider you configure (Google Cloud's Agent Platform, Amazon Bedrock, Microsoft Foundry, a compatible gateway, or the Anthropic API directly). Inference usage is billed by, and subject to your agreement with, that provider. When you configure the Anthropic API as your provider, inference billing and data terms fall under your Anthropic agreement. Your existing commercial agreement with Anthropic continues to apply to your use of the Claude Desktop application, unless we've mutually agreed otherwise.
1414
15### Enterprise Admin Console for Desktop 3P
16
17If your organization manages Claude Desktop on 3P from the Enterprise Admin Console for Desktop 3P (**Organization settings** on claude.ai), rather than authoring the configuration in MDM or hosting your own bootstrap server, Anthropic hosts that console. Your use of the Enterprise Admin Console for Desktop 3P is subject to Anthropic's [Commercial Terms of Service](https://www.anthropic.com/legal/commercial-terms). When you access Claude through a third-party provider (Google Cloud's Agent Platform, Amazon Bedrock, Microsoft Foundry, or a compatible gateway), the Commercial Terms apply only to your use of the Enterprise Admin Console, unless we've mutually agreed otherwise.
18
1519## Compliance
1620
1721When using Google Cloud's Agent Platform or Amazon Bedrock, the app sends conversation content only to your configured inference endpoint and stores it on the local device. Data handling at the endpoint is governed by [Google Cloud](https://cloud.google.com/vertex-ai/generative-ai/docs/data-governance) and [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html) respectively, and the compliance posture of your deployment is determined by your inference provider and the device environment you control.
third-party/claude-desktop/feature-matrix Changed · +1 / -1 lines
from line 6
66
77## Key differences
88
9**Configuration.** Claude Enterprise uses a web-based admin console. Claude Desktop on 3P is configured entirely via [MDM](/docs/third-party/claude-desktop/mdm) (Jamf, Intune, Group Policy) or a [bootstrap server](/docs/third-party/claude-desktop/bootstrap), with no Anthropic-hosted admin interface.
9**Configuration.** Claude Enterprise uses a web-based admin console. Claude Desktop on 3P is configured via [MDM](/docs/third-party/claude-desktop/mdm) (Jamf, Intune, Group Policy) or a [bootstrap server](/docs/third-party/claude-desktop/bootstrap); organizations in the admin console beta can instead manage it from **Organization settings** on claude.ai.
1010
1111**Telemetry.** Claude Desktop on 3P sends usage and debugging metrics only, and these can be fully disabled via managed configuration. Claude Enterprise does not offer telemetry toggles. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry).
1212
third-party/claude-desktop/overview Changed · +2 / -2 lines
from line 25
2525| ---------------------- | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
2626| Model inference | Anthropic API | Your configured provider endpoint (Google Cloud's Agent Platform, Amazon Bedrock, Microsoft Foundry, or gateway), or the Anthropic API |
2727| Web application | Loaded from claude.ai | Bundled inside the desktop app |
28| User identity | Anthropic account | Local device identity only |
28| User identity | Anthropic account | Local device identity only (Anthropic account when managed from the claude.ai admin console, in beta) |
2929| Conversation storage | Anthropic backend | Local disk on the user's machine |
3030| Code execution sandbox | Local VM | Local VM (identical) |
31| Configuration | Admin console at claude.ai | OS-native configuration (MDM-managed or per-user) |
31| Configuration | Admin console at claude.ai | OS-native configuration (MDM-managed or per-user), or the claude.ai admin console (beta) |
3232
3333The desktop app detects 3P mode at launch from the configured inference provider. When a provider and its credentials are present, the sign-in screen offers the option to skip Anthropic authentication and start the app using your inference-provider configuration instead.
3434