Home Docs Claude Documentation

One capture · claude-docs

One read of Claude Documentationclaude-docs-20260925T173705Z

15 pages moved out of 243 read.

Pages moved 15 significant first

Pages read 243 in this capture

Captured 25 Sep 2026 17:37 UTC

Corpus hash b77b27d8da78 corpus-hash

What this read moved

1-15 of 15

third-party/claude-desktop/admin-console Changed · +5 / -3 lines

from line 16

1616

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

1818

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

19While 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](#configuration-updates). You don't push an MDM profile or run a bootstrap server.

2020

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

2222

from line 165

165165

166166### Usage analytics

167167

168Usage 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. If your organization needs HIPAA compliance, don't turn on the switch.

169169

170As a beta feature, usage analytics hasn't yet been reviewed for HIPAA compliance. Anthropic will provide guidance on HIPAA compliance at general availability. For now, if your organization needs HIPAA compliance, don't turn on the switch.

171

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

171173

172174The 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:

from line 243

241243

242244### Configuration updates

243245

244From Claude Desktop 1.46388.1, 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.

246From 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, the app 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.

245247

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

247249

third-party/claude-desktop/bedrock Changed · +5 / -5 lines

from line 48

4848 }

4949 ```

5050

51 Set the permission set's **Session duration** to between 8 and 12 hours. This value controls how long a user can run Claude Desktop before needing to sign in to AWS again.

51 Set the permission set's **Session duration** to between 8 and 12 hours. This value sets how long each set of temporary AWS credentials lasts before the app requests a new set from IAM Identity Center. It does not control how often users sign in. Sign-in frequency follows the access portal session duration, described under [What users experience](#what-users-experience).

5252 </Step>

5353

5454 <Step title="Federate Identity Center to your IdP (optional)">

from line 87

8787

8888On success, the app stores the IAM Identity Center access token and refresh token encrypted with the operating system's secure storage (Keychain on macOS, DPAPI on Windows), dismisses the sign-in page, and shows Cowork.

8989

90At the start of each Cowork session, the app exchanges the stored token with IAM Identity Center for short-lived AWS credentials scoped to the configured account and permission set, and passes them into the session sandbox as `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN`. This is the same credential shape that `aws sso login` produces, obtained without the AWS CLI.

90At the start of each Cowork or Code session, the app exchanges the stored token with IAM Identity Center for short-lived AWS credentials scoped to the configured account and permission set, and writes them to the session's AWS credentials files, described under [Transient credential files](/docs/third-party/claude-desktop/data-storage#transient-credential-files). The session reads them through `AWS_SHARED_CREDENTIALS_FILE` and `AWS_PROFILE`, so the secret values are never passed as environment variables. This is the same credential shape that `aws sso login` produces, obtained without the AWS CLI.

9191

9292If the stored token expires or is revoked, the app shows a **Sign in again** prompt; clicking it reopens the AWS access portal in the browser. If you deploy a different `inferenceBedrockSsoStartUrl`, the app finds no stored token for the new URL and shows the sign-in page on next launch.

9393

from line 102

102102

103103#### Notes and limitations

104104

105* **All four keys required.** If only some of the `inferenceBedrockSso*` keys are set, the app logs a warning and ignores the partial configuration.

105* **All four keys required.** A partial set does not enable in-app sign-in. If `inferenceCredentialKind` is set to `interactive`, the app treats the configuration as invalid, logs an error that names the missing keys, and does not connect until they are supplied. If `inferenceCredentialKind` is not set, the app uses whichever other credential the configuration provides, or reports that no credential is configured.

106106* **One account and role per deployment.** Every user in a given managed configuration signs in to the same AWS account and assumes the same permission set. To give different groups different Amazon Bedrock permissions, deploy distinct configuration profiles with different `inferenceBedrockSsoRoleName` values.

107* **Mid-session credential refresh.** The app checks the AWS credentials' expiry before each turn and silently mints new ones from the stored IAM Identity Center token when they are close to expiring. If the Identity Center token itself has expired or been revoked, the app shows a **Sign in again** prompt; click it to re-authenticate with AWS in your browser. The permission set's session duration controls how long the Identity Center token remains valid, so set it long enough to cover a working day.

108* **Connection probe.** The in-app **Test connection** button reports that the connection cannot be verified in this mode, because the app cannot sign Amazon Bedrock requests outside the sandbox. This matches the behavior of named-profile mode and does not indicate a problem.

107* **Mid-session credential refresh.** The app checks the AWS credentials' expiry before each turn and silently mints new ones from the stored IAM Identity Center token when they are close to expiring. If the Identity Center token itself has expired or been revoked, the app shows a **Sign in again** prompt; click it to re-authenticate with AWS in your browser. The access portal session duration in IAM Identity Center sets how long the Identity Center sign-in itself lasts, as described under [What users experience](#what-users-experience).

108* **Connection probe.** The in-app **Test connection** button completes the AWS sign-in if needed, then sends a short test request to a model from your **Models** list through the app's Claude Code runtime. Add at least one model first, because this credential type cannot discover models automatically. If the app has not yet finished downloading its Claude Code runtime, the test reports that it cannot run; wait a moment and try again. Named-profile mode behaves the same way.

109109* **Configuration rotation.** If you change `inferenceBedrockSsoStartUrl` in the managed profile, existing users are automatically signed out and prompted to sign in again on next launch.

110110

111111### Named profile

third-party/claude-desktop/bootstrap Changed · +3 / -3 lines

from line 39

3939

4040Run the endpoint across multiple replicas or regions behind a load balancer. Do not rely on response caching for availability: responses are per-user and carry credentials (see the `Cache-Control: no-store` guidance under [Server responsibilities](#server-responsibilities)). If your configuration data lives in a database, a read replica of that store improves availability without caching responses.

4141

42A refetch that returns different values does **not** change the running session. The app keeps the configuration it launched with (inference credentials, egress allowlist, MCP servers, and renderer state such as the model picker all stay on the boot-time values), prompts the user to restart, and applies the new response when it relaunches.

42When a refetch returns different values, a few settings apply to the running app without a restart, such as the banner, the display name, and the token limit, as do the two lifecycle keys described below. Every other setting, including inference credentials, the egress allowlist, MCP servers, and the model list, stays on the values the app launched with. For those, the app prompts the user to restart and applies the new response when it relaunches.

4343

44Claude Desktop 1.40609.0 and later enforce that restart. Once a background re-check returns a changed response, the user can keep working for [`relaunchEnforcementHours`](/docs/third-party/claude-desktop/configuration#relaunchenforcementhours) (24 hours by default, at most 336 hours, or `0` to require the restart at once; releases before 1.46388.1 default to 1 hour). After that window the app blocks further use until it restarts, and it relaunches on its own once it has been idle for two minutes (no Claude task running and no keyboard or pointer input).

44Claude Desktop 1.40609.0 and later enforce that restart. Once a background re-check returns a changed response that needs a restart, the user can keep working for [`relaunchEnforcementHours`](/docs/third-party/claude-desktop/configuration#relaunchenforcementhours) (24 hours by default, at most 336 hours, or `0` to require the restart at once; releases before 1.46388.1 default to 1 hour). After that window the app blocks further use until it restarts, and it relaunches on its own once it has been idle for two minutes (no Claude task running and no keyboard or pointer input).

4545

4646Return `relaunchEnforcementHours` in the bootstrap response to change the window, and `configRecheckIntervalMinutes` to change how often running apps check for a new response. The app reads both keys from the newest response, so changing them does not itself require a restart. In the nested response format ([`bootstrap-config-v2`](#response-schema)) both keys sit under `lifecycle`, as `lifecycle.relaunchEnforcementHours` and `lifecycle.configRecheckIntervalMinutes`. Releases before 1.46388.1 read the window from `bootstrap.relaunchEnforcementHours` and do not read the `lifecycle` path, so move the value when your fleet updates (the flat-format key name is unchanged). On a device where `bootstrapUrl` came from an imported file rather than MDM, a device-management profile that sets only [app-behavior keys](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence), such as the update keys, supplies these two keys as well, so set them in that profile or the defaults apply there.

4747

third-party/claude-desktop/configuration Changed · +29 / -6 lines

### Tool approvals on scheduled tasks

This page is larger than the 256 KiB this site keeps, so one side of the diff below stops where the stored text does.

from line 18

1818

1919The local location is a directory: `_meta.json` records which saved configuration is applied, and each configuration is a `<id>.json` file alongside it. The in-app configuration window writes here.

2020

21When a managed source is present, it wins and locally written values are ignored. The exception is a managed source that sets only [app-behavior keys](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence) (the update keys `disableAutoUpdates`, `autoUpdaterEnforcementHours`, and `updateViaUpdatesHost`, the lifecycle keys `relaunchEnforcementHours` and `configRecheckIntervalMinutes`, or the [network proxy keys](/docs/third-party/claude-desktop/network-proxy#pin-a-proxy-from-managed-configuration)): those keys are enforced from the managed source, but the rest of the configuration stays local and user-editable. Configuration takes effect **at launch**, so fully quit and reopen the app after any change. From version 1.46388.1 a running app also notices a changed managed configuration at its next re-check ([`configRecheckIntervalMinutes`](#configrecheckintervalminutes), 10 minutes by default), prompts the user to restart, and requires the restart after [`relaunchEnforcementHours`](#relaunchenforcementhours) (24 hours by default). On Windows, the two policy hives are not merged: when machine policy is present under `HKLM\SOFTWARE\Policies\Claude`, the app ignores `HKCU\SOFTWARE\Policies\Claude` entirely; [Deploy the configuration](/docs/third-party/claude-desktop/mdm#4-deploy-the-configuration) has the exact rule. See [Deploy with MDM](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence) for the full precedence rules.

21When a managed source is present, it wins and locally written values are ignored. The exception is a managed source that sets only [app-behavior keys](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence) (the update keys `disableAutoUpdates`, `autoUpdaterEnforcementHours`, and `updateViaUpdatesHost`, the lifecycle keys `relaunchEnforcementHours` and `configRecheckIntervalMinutes`, or the [network proxy keys](/docs/third-party/claude-desktop/network-proxy#pin-a-proxy-from-managed-configuration)): those keys are enforced from the managed source, but the rest of the configuration stays local and user-editable. Configuration takes effect **at launch**, so fully quit and reopen the app after any change. From version 1.46388.1 a running app also notices a changed managed configuration at its next re-check ([`configRecheckIntervalMinutes`](#configrecheckintervalminutes), 10 minutes by default) and, for most settings, prompts the user to restart and requires the restart after [`relaunchEnforcementHours`](#relaunchenforcementhours) (24 hours by default). On Windows, the two policy hives are not merged: when machine policy is present under `HKLM\SOFTWARE\Policies\Claude`, the app ignores `HKCU\SOFTWARE\Policies\Claude` entirely; [Deploy the configuration](/docs/third-party/claude-desktop/mdm#4-deploy-the-configuration) has the exact rule. See [Deploy with MDM](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence) for the full precedence rules.

2222

2323<Note>

2424 Claude Desktop on 3P reads the same managed-configuration sources as standard Claude Desktop but ignores keys scoped to standard deployments. Keys such as `forceLoginOrgUUID` have no effect in a 3P deployment.

from line 326

326326

327327 **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:

328328

329 ```json theme={null}

329 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}

330330 [{"name": "claude-sonnet-5", "supports1m": true}, "claude-opus-4-8"]

331331 ```

332332

from line 334

334334

335335 **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:

336336

337 ```json theme={null}

337 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}

338338 [{"name": "arn:aws:bedrock:us-east-1:123:application-inference-profile/abc", "labelOverride": "Claude Opus (Prod)"}]

339339 ```

340340

341341 **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:

342342

343 ```json theme={null}

343 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}

344344 [{"name": "us.anthropic.claude-opus-4-8", "anthropicFamilyTier": "opus"}]

345345 ```

346346

from line 374

374374 <Accordion title="inferenceModelPricing details">

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

376376

377 ```json theme={null}

377 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}

378378 {"inferenceModelPricingEnabled": true, "inferenceModelPricingMultiplier": 0.9, "inferenceModelPricing": [{"name": "claude-sonnet-4-6", "inputPerMtok": 2.4, "outputPerMtok": 12, "cacheReadPerMtok": 0.24, "cacheWritePerMtok": 3}]}

379379 ```

380380

from line 1079

10791079 <Accordion title="orgPluginSettings details">

10801080 Locks per-tool permissions on MCP servers provided by any installed plugin — from the org-plugins directory or a plugin marketplace, remote or run locally — one entry per server name (compared case-insensitively):

10811081

1082 ```json theme={null}

1082 ```json theme={null} theme={null} theme={null} theme={null} theme={null} theme={null} theme={null}

10831083 [{"serverName": "internal-search", "tools": [{"toolName": "delete_document", "permission": "blocked"}]}]

10841084 ```

10851085

from line 1089

10891089

10901090 For a plugin server that Claude Code launches or connects to itself (a marketplace plugin's), the permissions travel on Claude Code's managed-settings channel: another Claude Code [managed-settings source](https://claude.com/docs/third-party/claude-desktop/code#interaction-with-claude-code%E2%80%99s-own-managed-settings) on the device replaces them unless that source sets `parentSettingsBehavior` to `"merge"`. `blocked` on a server the app connects to itself holds either way.

10911091

1093 | ------------------ | ---------- | ------- | --------------------------------------------------------------------------------------------------------------------------- |

1094 | `serverName` | `string` | — | Name of the plugin-delivered MCP server thi

1092 | Field | Type

third-party/claude-desktop/credential-helper Changed · +4 / -0 lines

## Use a different helper path on Windows

from line 44

4444

4545Keep secrets out of the arguments. The arguments appear in the diagnostic report and are visible to other processes on the device, so have the helper fetch any secret itself.

4646

47## Use a different helper path on Windows

49When one configuration serves both Windows devices and macOS or Linux devices, set `inferenceCredentialHelper` to the macOS and Linux path and [`inferenceCredentialHelperWindows`](/docs/third-party/claude-desktop/configuration#inferencecredentialhelperwindows) to the Windows path, for example `C:\Program Files\Corp\cred-helper.exe`. Windows devices run that executable with the same arguments, timeout, cache time, and environment variables as the main helper, and macOS and Linux devices ignore the key. A [bootstrap server](/docs/third-party/claude-desktop/bootstrap) can deliver it under the same [user-consent rule](/docs/third-party/claude-desktop/bootstrap#keys-that-require-user-consent) as the helper path; in the nested response format, set `commandWindows` next to `command` in `inference.credential`.

4751## When the helper runs

4852

4953Claude Desktop sets the `CLAUDE_HELPER_CONTEXT` environment variable on every invocation so the script can decide whether interactive authentication (opening a browser, prompting for a device code) is appropriate.

third-party/claude-desktop/extensions Changed · +17 / -17 lines

from line 271

271271

272272Claude Desktop fetches marketplaces on the host operating system, outside the Cowork VM. The credential is used only for this fetch and is never passed into the VM or exposed to the model.

273273

274| `credentialKind` | How it authenticates |

275| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

276| `"anonymous"` | No credential is sent. Use for public repositories or unauthenticated file hosts. |

277| `"userGit"` | Uses the git credential helpers already configured for the signed-in OS user (for example, `git-credential-manager`, macOS Keychain, or a GitHub CLI credential helper). Use when each user already has read access through their own account. For `url` sources, the same credential is sent as HTTP Basic on the manifest and archive requests. |

279| `"inferenceCredential"` | `url` sources only. Sends the credentials Claude Desktop already sends to your inference gateway or to your [bootstrap server](/docs/third-party/claude-desktop/bootstrap), so a marketplace hosted on either is private to signed-in members without a separate credential. On the gateway's origin it sends the same `Authorization` bearer as inference and works for [gateway single sign-on](/docs/third-party/claude-desktop/gateway#single-sign-on-with-your-identity-provider), a [credential helper](/docs/third-party/claude-desktop/credential-helper), and bearer-scheme API keys. On the bootstrap server's origin (Claude Desktop 1.37937.0 or later) it sends the bootstrap sign-in token or your `bootstrapHeaders` and `bootstrapHeadersHelper` headers. Claude Desktop sends a credential only when the marketplace URL is on one of those two origins. When there is nothing to send yet (no sign-in held and no bootstrap headers configured, or a gateway API key sent as `x-api-key` rather than a bearer), no request is made and the entry reports why in the diagnostic report. |

274| `credentialKind` | How it authenticates |

276| `"anonymous"` | No credential is sent. Use for public repositories or unauthenticated file hosts. |

278| `"credentialHelper"` | Runs the executable at `credentialHelper`. If it prints a bare token, the token is used as the git password for username `x-access-token` (accepted by GitHub, GitLab, and Azure DevOps) and, for `url` sources, sent as `Authorization: Bearer <token>` on the manifest and archive requests. For hosts that need a particular username, print git-credential lines `username=<user>` and `password=<token>` instead (for example `x-token-auth` for Bitbucket Data Center access tokens, or `gitlab+deploy-token-N` for a GitLab deploy token); `url` sources then use HTTP Basic. Print `authtype=Bearer` and `credential=<token>` to force a bearer header. For `url` sources, the helper can instead print a flat JSON object of HTTP headers, such as `{"Authorization": "Bearer …", "X-Tenant": "acme"}` (the form a managed MCP server's `headersHelper` prints, not an inference credential helper's `{"token": …}` object), and Claude Desktop sends every header in it on each request to that marketplace. `github` and `git` sources refuse this form. Output that opens with `{` must be a valid header object, or the fetch is refused. Username forms require Claude Desktop 1.37937.0 or later. Otherwise follows the execution model of an [inference credential helper](/docs/third-party/claude-desktop/credential-helper). |

280280

281281Because the fetch happens on the host, the marketplace host does not need to be on the [`coworkEgressAllowedHosts`](/docs/third-party/claude-desktop/configuration#coworkegressallowedhosts) allowlist. It does need to be reachable from end-user devices.

282282

from line 323

323323

324324| File | Purpose |

325325| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

326| `.claude-plugin/plugin.json` | **Required.** Plugin manifest (name, description, version). Directories without this file are ignored. |

326| `.claude-plugin/plugin.json` | Plugin manifest (name, description, version). Required unless a top-level `SKILL.md` serves as the manifest; see the note below this table. A directory with neither is ignored. |

327327| `version.json` | `{"version": "1.2.3"}`. When this string changes, Claude Desktop re-syncs the plugin on next launch. Any string change triggers re-sync (there's no semver ordering, so a downgrade is just another version string). If absent, the directory's modification time is used instead. |

328328| `.mcp.json` | MCP servers bundled with this plugin. A JSON object keyed by server name: `{"mcpServers": {"<name>": {"type": "http", "url": "...", "oauth": true}}}`. A remote entry uses `type` (`http` or `sse`), not `transport`, and supports `url`, `headers`, and `oauth` only. `toolPolicy`, `headersHelper`, and `headersHelperTtlSec` are not read from this file. A local entry gives a `command` with optional `args` and `env` (`type` is `"stdio"` or omitted). Give `command` as a program name on `PATH` or an absolute path, using `${CLAUDE_PLUGIN_ROOT}` for the plugin's directory under `org-plugins/`. Claude Desktop starts these local servers itself, including when [`isLocalDevMcpEnabled`](/docs/third-party/claude-desktop/configuration#islocaldevmcpenabled) is `false`. Local entries require Claude Desktop 1.49585.0 or later. A local entry that references `${user_config.<key>}` is skipped, because per-user plugin settings are not available to organization plugins. The diagnostic report's **MCP servers** section lists each server, with the reason for any it skipped. |

329329| `agents/` | Sub-agent definitions. |

from line 332

332332| `hooks/` | Hook definitions that run on agent lifecycle events. See [Plugin hooks](#plugin-hooks) for where they run. |

333333

334334<Note>

335 Each entry in `org-plugins/` must carry a valid manifest: a `.claude-plugin/plugin.json`, or a top-level `SKILL.md` for an entry that distributes a single skill. A directory with neither is not loaded and never appears in the user's plugin browser; the diagnostic report's plugin section shows the rejected entry and why. To distribute an MCP connector, declare it in a plugin's `.mcp.json` or use [`managedMcpServers`](#managed-mcp-servers-admin).

335 Each entry in `org-plugins/` must carry a valid manifest: a `.claude-plugin/plugin.json`, or a top-level `SKILL.md` whose frontmatter declares `agents` or `mcpServers` (a skill folder that also acts as a plugin). A plain skill folder does not qualify on its own. To distribute a single skill, place it under `skills/<name>/SKILL.md` in a plugin that has a `plugin.json`. A directory with no valid manifest is not loaded and never appears in the user's plugin browser. The diagnostic report's plugin section shows the rejected entry and why. To distribute an MCP connector, declare it in a plugin's `.mcp.json` or use [`managedMcpServers`](#managed-mcp-servers-admin).

336336</Note>

337337

338338See the [plugins reference](https://code.claude.com/docs/en/plugins) for the full file format of each component, including the hooks schema.

from line 342

342342</Note>

343343

344344<Note>

345 MCP servers declared in a plugin's `.mcp.json` don't carry a `toolPolicy` field in the plugin file itself. To lock tools on a plugin-delivered server, set [`orgPluginSettings`](/docs/third-party/claude-desktop/configuration#orgpluginsettings) in managed configuration, keyed on the server's `name`, or add a [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers) entry with `"transport": "policy-only"`, the server's `name`, and a `toolPolicy`. A `policy-only` entry connects to nothing. It only applies the permissions, and it takes precedence over `orgPluginSettings` for that server. A regular `managedMcpServers` entry that matches a plugin's server by URL or name governs that server the same way.

346346</Note>

347347

348348### Auto-installing organization plugins

from line 358

358358}

359359```

360360

361| Value | Behavior |

362| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |

363| `"required"` | Installs automatically when the user signs in. The Uninstall action is hidden. If the plugin is removed from disk, it reinstalls on the next sign-in. |

364| `"auto_install"` | Installs automatically when the user signs in. Users can uninstall it, and it stays uninstalled for that user. |

365| `"available"` (or omitted) | Default. Users install manually from the plugin browser. |

361| Value | Behavior |

362| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

363| `"required"` | Installs automatically the next time the app syncs organization plugins (at launch or when a session starts). The Uninstall action is hidden. If a user's installed copy is removed, it reinstalls on the next sync. |

364| `"auto_install"` | Installs automatically on the next sync. Users can uninstall it, and it stays uninstalled for that user. |

365| `"available"` (or omitted) | Default. Users install manually from the plugin browser. |

366366

367This mirrors the installation preference behavior of remote-managed plugins on claude.ai. Changing a plugin's `installationPreference` takes effect the next time each user signs in.

367This mirrors the installation preference behavior of remote-managed plugins on claude.ai. Changing a plugin's `installationPreference` takes effect at each user's next sync.

368368

369369### Updating organization plugins

370370

from line 411

411411| `userPluginMarketplacesEnabled` | `true` | Users cannot add plugin marketplaces of their own; the add-marketplace options are hidden. Marketplaces you provision with `allowedPluginMarketplaces` are unaffected. Requires Claude Desktop 1.37937.0 or later. |

412412| `userPluginUploadsEnabled` | `true` | Users cannot upload plugin files or create plugins with Claude; every in-app option for adding a plugin of their own is hidden. Plugins from your marketplaces and the organization plugins directory are unaffected. Requires Claude Desktop 1.37937.0 or later. |

413413

414Setting `isLocalDevMcpEnabled` to `false` and leaving `isDesktopExtensionEnabled` at `false` restricts MCP servers and connectors to those delivered through `managedMcpServers` and `org-plugins/`. Setting [`skillCreationEnabled`](/docs/third-party/claude-desktop/configuration#skillcreationenabled) to `false` turns off skill creation and upload in the app. Skills already on the device keep working, as do skills from [organization plugins](#organization-plugins-admin). Users can still install plugins from the marketplaces you provision regardless of these settings. Setting `userPluginMarketplacesEnabled` and `userPluginUploadsEnabled` to `false` removes only the options for adding marketplaces and plugins of their own, and anything a user added earlier stays in place. See the [Locked down profile](/docs/third-party/claude-desktop/configuration#recommended-security-profiles) for a complete example.

414Setting `isLocalDevMcpEnabled` to `false` and leaving `isDesktopExtensionEnabled` at `false` restricts MCP servers and connectors to those delivered through `managedMcpServers` and `org-plugins/`, plus any that installed plugins bundle, whether from your marketplaces or added by users. To limit plugin-bundled servers to ones you name, or to none, set [`allowedPluginMcpServers`](/docs/third-party/claude-desktop/configuration#allowedpluginmcpservers) to a list of URL patterns. An empty list admits no plugin-bundled server. Setting [`skillCreationEnabled`](/docs/third-party/claude-desktop/configuration#skillcreationenabled) to `false` turns off skill creation and upload in the app. Skills already on the device keep working, as do skills from [organization plugins](#organization-plugins-admin). Users can still install plugins from the marketplaces you provision regardless of these settings. Setting `userPluginMarketplacesEnabled` and `userPluginUploadsEnabled` to `false` removes only the options for adding marketplaces and plugins of their own, and anything a user added earlier stays in place. See the [Locked down profile](/docs/third-party/claude-desktop/configuration#recommended-security-profiles) for a complete example.

415415

416416## Related topics

417417

third-party/claude-desktop/feature-matrix Changed · +14 / -14 lines

from line 63

6363

6464## Admin features

6565

66| Feature | Claude Enterprise | Claude Desktop on 3P |

67| --------------------------------------------------------------------------------------------- | :---------------: | :------------------: |

68| Endpoint / gateway configuration | — | ✓ |

69| Skills, hooks, and plugins distribution | ✓ | ✓ |

70| MCP server allowlist | ✓ | ✓ |

71| Feature toggles (web search, local MCP, etc.) | ✓ | ✓ |

72| Auto-updates | ✓ | ✓ |

73| Per-user usage caps | ✓ | ✓ |

74| [Data retention policies](/docs/third-party/claude-desktop/configuration#chatsessionretentiondays) | ✓ | ✓ |

75| Compliance API | ✓ | — ‡ |

76| Analytics API | ✓ | — ‡ |

77| OpenTelemetry export | ✓ | ✓ |

78| User management via UI | ✓ | ✓ ◊ |

79| RBAC | ✓ | ✓ ◊ |

66| Feature | Claude Enterprise | Claude Desktop on 3P |

67| ------------------------------------------------------------------------------------------------------- | :---------------: | :------------------: |

68| Endpoint / gateway configuration | — | ✓ |

69| Skills, hooks, and plugins distribution | ✓ | ✓ |

70| MCP server allowlist | ✓ | ✓ |

71| Feature toggles (web search, local MCP, etc.) | ✓ | ✓ |

72| Auto-updates | ✓ | ✓ |

73| Per-user usage caps | ✓ | ✓ |

74| [Data retention policies](/docs/third-party/claude-desktop/data-storage#automatic-deletion-of-idle-sessions) | ✓ | ✓ |

75| Compliance API | ✓ | — ‡ |

76| Analytics API | ✓ | — ‡ |

77| OpenTelemetry export | ✓ | ✓ |

78| User management via UI | ✓ | ✓ ◊ |

79| RBAC | ✓ | ✓ ◊ |

8080

8181‡ Many of these capabilities can be achieved via OpenTelemetry export to your own collector. See [Monitoring](/docs/cowork/monitoring).

8282

third-party/claude-desktop/gateway Changed · +13 / -13 lines

from line 263

263263

264264The `inferenceGatewayOidc` value is one JSON object with these fields:

265265

266| Field | Required | Description |

267| --------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

268| `clientId` | Yes | Application (client) ID registered with the identity provider. |

269| `issuer` | Yes\* | OIDC issuer URL — the base URL only, **without** `/.well-known/openid-configuration`. The app appends that path itself to discover the authorization and token endpoints. |

270| `authorizationUrl` | No\* | Explicit OIDC authorization endpoint. Use together with `tokenUrl` instead of `issuer` when the identity provider does not serve `/.well-known/openid-configuration`. Ignored when `issuer` is set. |

271| `tokenUrl` | No\* | Explicit OIDC token endpoint. Must be set together with `authorizationUrl`. Ignored when `issuer` is set. |

272| `scopes` | No | Space-separated OIDC scopes. Defaults to `openid profile email offline_access`. Required when `bearerTokenType` is `access_token`. See [Refresh tokens and session lifetime](#refresh-tokens-and-session-lifetime) for how this field interacts with silent refresh. |

273| `redirectPort` | No | Fixed local port for the loopback redirect. Leave unset to let the app choose an ephemeral port (Entra). Set when the provider requires an exact port match (Okta). |

274| `redirectHost` | No | Host in the loopback redirect URI, `127.0.0.1` (the default) or `localhost`. Set to `localhost` when the identity provider accepts only `localhost` in a registered redirect URI, and register the `localhost` form of the URI instead (`http://localhost/callback`, or `http://localhost:<port>/callback` with `redirectPort`). |

275| `bearerTokenType` | No | Which token the app sends to the gateway as the `Authorization: Bearer` value. `id_token` (the default) sends the OIDC ID token — the gateway validates it offline against the provider's JWKS with `aud` equal to the client ID. `access_token` sends the OAuth access token instead — use this for gateways that validate as an OAuth resource server rather than validating the ID token directly. When set to `access_token`, `scopes` is required. |

276| `appendOfflineAccess` | No | Whether to automatically append `offline_access` to `scopes` in `access_token` mode. Defaults to `true`. Set to `false` only if your authorization server rejects `offline_access` as an unrecognized scope. See [Refresh tokens and session lifetime](#refresh-tokens-and-session-lifetime). |

277| `resource` | No | RFC 8707 resource indicator: an absolute `https://` URL identifying the gateway as the access-token audience. When set, the app sends `resource=<value>` on the authorization, token, and refresh requests. Use only with `bearerTokenType: "access_token"` and an identity provider that implements RFC 8707 (for example AD FS); leave unset for Microsoft Entra ID, which rejects the parameter; request the gateway's API scope in `scopes` instead. Changing it signs users in again. Ignored by the OS-broker sign-in flow (`inferenceGatewayOidcAuthFlow: broker`). |

278| `additionalRedirectReferrerHosts` | No | Space-separated hostnames also accepted as the referrer of the sign-in callback, for identity providers that complete sign-in from a different host than the authorization URL's (for example a portal or step-up page on a sibling host). When a callback is rejected for a referrer mismatch, the app log names the host to add. |

266| Field | Required | Description |

268| `clientId` | Yes | Application (client) ID registered with the identity provider. |

269| `issuer` | Yes\* | OIDC issuer URL — the base URL only, **without** `/.well-known/openid-configuration`. The app appends that path itself to discover the authorization and token endpoints. |

271| `tokenUrl` | No\* | Explicit OIDC token endpoint. Must be set together with `authorizationUrl`. Ignored when `issuer` is set. |

273| `redirectPort` | No | Fixed local port for the loopback redirect. Leave unset to let the app choose an ephemeral port (Entra). Set when the provider requires an exact port match (Okta). |

277| `resource` | No | RFC 8707 resource indicator naming the gateway as the access-token audience: an `https://` URL, or, for AD FS, one of the relying-party trust's identifiers that has a scheme, such as `https://…` or `urn:…`, spelled as it is registered. A value with no scheme is sent as `https://<value>`; an identifier with a scheme of its own is sent exactly as written. When set, the app sends `resource=<value>` on the authorization, token, and refresh requests. Use only with `bearerTokenType: "access_token"` and an identity provider that implements RFC 8707 (for example AD FS); leave unset for Microsoft Entra ID, which rejects the parameter; request the gateway's API scope in `scopes` instead. Changing it signs users in again. Ignored by the OS-broker sign-in flow (`inferenceGatewayOidcAuthFlow: broker`). |

279279

280280\* Either `issuer`, or both `authorizationUrl` and `tokenUrl`, is required.

281281

third-party/claude-desktop/installation Changed · +6 / -6 lines

from line 45

4545

4646Configuration 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

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 |

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 |

49| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |

53| Changing settings | Save the change in the console. Running apps pick it up at their next check and, for most settings, 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

5555Choose 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

third-party/claude-desktop/ssh-remote-sessions Changed · +9 / -8 lines

from line 10

1010

1111## How a remote session works

1212

131. **Connect.** The user picks an SSH host from the environment picker in Code, or adds one by entering its address, port, and an identity file. Claude Desktop connects with its built-in SSH client, applies the host's entry from the device's `~/.ssh/config` (see [SSH configuration on the device](#ssh-configuration-on-the-device)), and prompts in the app if the host asks for a password or a one-time code.

131. **Connect.** The user picks an SSH host from the environment picker in Code, or adds one by entering its address, port, and an identity file. Claude Desktop connects through the device's OpenSSH client on macOS and Linux, or its built-in SSH client on Windows (see [Host requirements](#host-requirements) to change either default), applies the host's entry from the device's `~/.ssh/config` (see [SSH configuration on the device](#ssh-configuration-on-the-device)), and prompts in the app if the host asks for a password or a one-time code.

14142. **Deploy.** Claude Desktop places a remote server and the Claude Code engine under `~/.claude/remote/` in the SSH user's home directory on the host ([Host requirements](#host-requirements) lists every path) and reuses them on later connections.

15153. **Run.** The remote server starts the engine on the host with the inference credential and policy from your managed configuration. Every file read, edit, shell command, and git operation runs on the host, in the working directory the user chose there. Claude Desktop connects to [managed MCP servers](/docs/third-party/claude-desktop/extensions#managed-mcp-servers-admin) from the device and exposes them to the engine as tools.

16164. **Stream.** Claude's responses and tool output stream back to Claude Desktop. Permission prompts appear in Claude Desktop, and the engine waits on the host until the user answers.

from line 113

113113

114114The Claude Code engine is a standalone executable with no runtime dependencies. The device needs the OpenSSH client (`ssh` and `ssh-keygen`). Claude Desktop runs the first `ssh` on the user's `PATH`; to pin a specific OpenSSH installation instead, set [`sshClientPath`](/docs/third-party/claude-desktop/configuration#sshclientpath) (beta, Claude Desktop 1.46388.1 or later) to the program's absolute path, and `ssh-keygen` is then taken from the same directory when present. If the pinned program is missing or cannot be run, SSH connections fail with an error that shows the configured path, rather than falling back to another `ssh`.

115115

116By default, Claude Desktop makes the SSH connection with its built-in client and runs the device's OpenSSH tools only to evaluate the user's SSH configuration, look up host keys, and run the session's terminal. To have the device's OpenSSH client carry the connection itself, set [`sshTransport`](/docs/third-party/claude-desktop/configuration#sshtransport) to `system-openssh` (beta, Claude Desktop 1.52386.0 or later). Your own OpenSSH build's Kerberos (GSSAPI), certificate, and `ssh_config` support then handles authentication. The program is the one `sshClientPath` names, or else the first `ssh` on the user's `PATH`, and it must be OpenSSH 7.6 or newer (on Windows, Win32-OpenSSH 9.4 or newer). On a Windows device with no usable OpenSSH client and no `sshClientPath`, the built-in client is used instead. `builtin` selects the built-in client explicitly. A change applies to new connections, and sessions that are already connected keep their client.

116On macOS and Linux, Claude Desktop makes the SSH connection by running the device's OpenSSH client, so your own OpenSSH build's Kerberos (GSSAPI), certificate, and `ssh_config` support handles authentication. The program is the one `sshClientPath` names, or else the first `ssh` on the user's `PATH`, and it must be OpenSSH 7.6 or newer. On Windows, the app's built-in SSH client makes the connection by default, and the app runs the device's OpenSSH tools to evaluate the user's SSH configuration, look up host keys, and run the session's terminal. To have the device's OpenSSH client carry the connection on Windows too, set [`sshTransport`](/docs/third-party/claude-desktop/configuration#sshtransport) (beta) to `system-openssh`; the client must be Win32-OpenSSH 9.4 or newer. On a Windows device with no usable OpenSSH client and no `sshClientPath`, the built-in client is used regardless. Set `sshTransport` to `builtin` to use the built-in client on every platform. A change applies to new connections, and sessions that are already connected keep their client.

117117

118118Claude Desktop writes the following into the SSH user's home directory on the host. Each user who connects gets their own copy.

119119

from line 133

133133

134134### SSH configuration on the device

135135

136Claude Desktop applies the host's entry in the user's `~/.ssh/config`: hostname, port, user, identity file, SSH agent, and `ProxyCommand`.

136Claude Desktop applies the host's entry in the user's `~/.ssh/config`. With the device's OpenSSH client (the default on macOS and Linux), the whole entry applies as it would in a terminal, including `ProxyJump`, certificate host keys, and GSSAPI, and the app still connects only to the resolved hostname that passed `sshHostAllowlist`. The built-in client (the default on Windows) applies the hostname, port, user, identity file, SSH agent, and `ProxyCommand`.

137137

138* For hosts behind a bastion, configure a `ProxyCommand`. `ProxyJump` is not supported.

139* The host's key must already be in the device's `~/.ssh/known_hosts` as a plain entry; the app does not prompt to accept a new key and does not evaluate `@cert-authority` entries. Have users connect once from a terminal before adding the host in the app.

140* An identity file protected by a passphrase is skipped, not prompted for. Load it into the SSH agent, or use an unencrypted key.

141* For a host reached through a `ProxyCommand`, the app skips host key verification and relies on the command to authenticate the host.

138* For hosts behind a bastion, configure a `ProxyJump` or `ProxyCommand`. `ProxyJump` works only when the device's OpenSSH client carries the connection (the default on macOS and Linux); the built-in client refuses it with a message suggesting `ProxyCommand`.

139* With the device's OpenSSH client, OpenSSH's own host key checking applies. For a host that is not yet in `~/.ssh/known_hosts`, the app shows the key's fingerprint, asks the user whether to trust it, and records a trusted key in the user's `known_hosts` file, unless the user's own SSH configuration accepts new keys without asking. `@cert-authority` entries are honored, and a changed host key is always refused.

140* With the built-in client, the host's key must already be in the device's `~/.ssh/known_hosts` as a plain entry. The app does not prompt to accept a new key and does not evaluate `@cert-authority` entries, so have users connect once from a terminal before adding the host in the app.

141* With the built-in client, an identity file protected by a passphrase is skipped, not prompted for. Load it into the SSH agent, or use an unencrypted key. With the device's OpenSSH client, the app asks for the passphrase once the host's key is verified, and skips the key if the user cancels.

142* With the built-in client, a host reached through a `ProxyCommand` skips host key verification and relies on the command to authenticate the host.

142143* The connection times out after 30 seconds. A larger `ConnectTimeout` in the host entry extends it.

143144

144145## Troubleshoot

from line 158

157158

158159### SSH host key verification failed

159160

160The host's key is not in the device's `~/.ssh/known_hosts`, or it has changed. Connect to the host from a terminal on the device to record the current key, then retry.

161The host's key has changed, or it is not in the device's `~/.ssh/known_hosts` and was not trusted in the app (the built-in client never asks). Connect to the host from a terminal on the device to check and record the current key, then retry.

161162

162163## Related

163164

third-party/claude-desktop/code Changed · +2 / -0 lines

from line 19

1919| `inferenceProvider` and all provider credential keys (`inferenceGateway*`, `inferenceAnthropicApiKey`, `inferenceVertex*`, `inferenceBedrock*`, `inferenceFoundry*`, `inferenceCredentialHelper*`) | Selects the inference backend and supplies credentials. Code sessions use the same provider, endpoint, and credentials as Cowork sessions. |

2020| `inferenceModels` | Populates the model picker. The first entry is the default for new Code sessions. |

2121| `autoModeEnabled` | Controls **Auto mode**. When the key is not set, Code sessions offer Auto mode and new sessions start in it unless the user has already chosen another mode or a Claude Code `permissions.defaultMode` applies. Set it to `false` to remove Auto mode from Code and Cowork. Set it to `true` to also offer **Automatically approve** in Cowork. A separately deployed Claude Code managed-settings file that sets `disableAutoMode` to `"disable"` overrides this key and keeps Auto mode hidden; see below. |

22| `scheduledTasksEnabled` | When `false`, the routines list in Code is hidden and Code sessions start without Claude Code's in-session scheduling tools, so the `/loop` command cannot schedule recurring work. Cowork's scheduled tasks are turned off by the same key. |

2223| `disabledBuiltinTools` | Removes the listed tools from Code sessions. Tools your provider does not support, such as WebSearch on Amazon Bedrock, are removed automatically in addition to your list. |

2324| `builtinToolPolicy` | Tools set to `"ask"` require approval on each call in Code sessions, enforced via a PreToolUse hook and Claude Code `permissions.ask` rules. |

2425| `disableBypassPermissionsMode` | Removes bypass permissions mode. The app stops offering the mode and starts a session that requests it in a stricter permission mode instead, independent of Claude Code managed-settings precedence. The key requires Claude Desktop 1.46388.1 or later. A separately deployed Claude Code managed-settings file that sets `permissions.disableBypassPermissionsMode` to `"disable"` removes the mode as well. |

from line 42

4142| `allowedWorkspaceFolders` | A filesystem sandbox for shell commands, which can then create or change files only inside your allowed roots and the session's temporary locations. The sandbox does not restrict which files those commands read unless you also set `blockReadsOutsideWorkingDirectories`. The roots are also passed as `additionalDirectories` at launch, which is always applied independent of managed-settings precedence, and the app keeps Claude's file tools inside the roots. The app also refuses to start a Code session outside an allowed root. |

4243| `blockReadsOutsideWorkingDirectories` | Claude Code's `permissions.blockReadsOutsideWorkingDirectories` for Code sessions. Claude's file tools refuse to read outside the working directories (the session's folder plus your allowed roots, if any) in every permission mode. Where the sandbox from `allowedWorkspaceFolders` or `coworkEgressAllowedHosts` is running, it also hides the user's home directory and similar locations, such as other users' home folders and mounted volumes, from shell commands, so a sandboxed command that reads there fails without a prompt. Without a running sandbox, a shell command that reads outside the working directories, or that Claude Code cannot analyze, asks the user for approval first, even in bypass permissions mode. The key requires Claude Desktop 1.46388.1 or later. The block takes effect only in sessions that run Claude Code v2.1.257 or later; if the app cannot install its current Claude Code engine and a session runs one older than v2.1.257 that is still on the device, that session runs without the block and the app logs a warning. |

4344| `managedMcpServers` | `strictPluginOnlyCustomization` set to `["mcp"]`, so the Code session does not load MCP servers that users define on Claude Code's side (`~/.claude.json`, a project's `.mcp.json`, or `claude mcp add`); your managed servers, which the app connects and supplies to the session itself, and MCP servers bundled in plugins still load. When [`isLocalDevMcpEnabled`](/docs/third-party/claude-desktop/configuration#islocaldevmcpenabled) is `false`, the app also sets an `allowedMcpServers` list that admits only remote servers, with `allowManagedMcpServersOnly`, so local (stdio) servers bundled in plugins from marketplaces or that users install themselves are refused, while those plugins' remote servers still connect. Per-tool `toolPolicy` values on each server are emitted as `permissions.deny` (for `blocked`) or `permissions.ask` (for `ask`) rules against the corresponding `mcp__<server>__<tool>` names. |

45| `allowedPluginMcpServers` | `strictPluginOnlyCustomization` set to `["mcp"]` together with an `allowedMcpServers` list holding your entries and `allowManagedMcpServersOnly`, whether or not `managedMcpServers` is set. MCP servers bundled in plugins from marketplaces, or in plugins users install themselves, connect only when their URL matches an entry; no such plugin's local (stdio) server is admitted, and an empty list admits none. Your managed servers and the servers from the organization plugins directory still load. |

4446

4547The network and filesystem sandboxes apply on macOS, and on Linux devices and [SSH hosts](/docs/third-party/claude-desktop/ssh-remote-sessions#managed-configuration-on-the-remote-host) with Claude Code's [sandbox dependencies](https://code.claude.com/docs/en/sandboxing) installed. Claude Code does not sandbox shell commands on Windows devices, and on a Linux device or SSH host without the dependencies commands run unsandboxed with a warning in the session. In those cases, and when neither sandbox key is set, `blockReadsOutsideWorkingDirectories` still confines Claude's file tools but can only ask the user to approve shell commands that read outside the working directories or that Claude Code cannot verify.

4648

third-party/claude-desktop/connectors-m365 Changed · +1 / -0 lines

from line 257

257257| `outlook_email_search` | Search Outlook mail |

258258| `outlook_calendar_search` | Search calendar events |

259259| `find_meeting_availability` | Find free meeting times |

260| `outlook_find_available_time` | Find open time slots for a meeting between the user and specific participants |

260261| `chat_message_search` | Search Teams chat (1:1 and group; channel messages need `ChannelMessage.Read.All`) |

261262| `sharepoint_search`, `sharepoint_folder_search` | Search SharePoint and OneDrive |

262263| `read_resource` | Fetch a specific item, such as a message, event, or file |

third-party/claude-desktop/data-storage Changed · +1 / -1 lines

from line 41

4141| `cowork_plugins/` | User-installed and [org-provisioned](/docs/third-party/claude-desktop/extensions#organization-plugins-admin) plugins. Created on first plugin install. |

4242| `IndexedDB/`, `Local Storage/`, `Session Storage/` | Renderer-side UI state (window layout, recent folders, preferences). |

4343

44Files in this directory are written with owner-only permissions so other OS accounts on the same machine cannot read them.

44Files in this directory are written with owner-only permissions so other OS accounts on the same machine cannot read them. The app encrypts stored sign-in tokens and similar secrets with the operating system's secure storage (see [Credentials](#credentials)), but not conversations, settings, or locally applied configuration, including an API key saved from the in-app configuration window. Protection at rest for those files depends on the device's full-disk encryption, such as FileVault or BitLocker.

4545

4646The logs directory contains `main.log` (application and configuration-validation events), `cowork_vm_node.log` (sandbox VM activity), `claude.ai-web.log` (renderer events), and `mcp.log` / `mcp-server-<name>.log` (MCP connection events).

4747

third-party/claude-desktop/foundry Changed · +1 / -1 lines

from line 74

7474

7575If the app can no longer renew the credential silently, it shows a **Sign in again** prompt; clicking it reopens the configured sign-in flow. For the device-code and browser flows this happens when the stored refresh token expires or is revoked. For the broker flow it happens when the broker can no longer renew the token silently.

7676

77`inferenceFoundryTenantId`, `inferenceFoundryClientId`, and `inferenceFoundryAuthFlow` can be set through an MDM profile or a [bootstrap server](/docs/third-party/claude-desktop/bootstrap). When a bootstrap server delivers `inferenceFoundryTenantId` or `inferenceFoundryClientId`, the values are among the [keys that require user consent](/docs/third-party/claude-desktop/bootstrap#keys-that-require-user-consent), so users may see a one-time approval dialog depending on how `bootstrapUrl` reached the device.

77`inferenceFoundryTenantId`, `inferenceFoundryClientId`, and `inferenceFoundryAuthFlow` can be set through an MDM profile or a [bootstrap server](/docs/third-party/claude-desktop/bootstrap). When a bootstrap server delivers `inferenceFoundryResource`, `inferenceFoundryTenantId`, or `inferenceFoundryClientId`, the values are among the [keys that require user consent](/docs/third-party/claude-desktop/bootstrap#keys-that-require-user-consent), so users may see a one-time approval dialog depending on how `bootstrapUrl` reached the device.

7878

7979<Note>

8080 In-app sign-in and a [bootstrap server](/docs/third-party/claude-desktop/bootstrap) are separate layers that work together. In-app sign-in supplies each user's inference credential, the Entra ID token that authorizes model calls. A bootstrap server supplies per-user configuration values when the app starts. A bootstrap server does not replace sign-in: a deployment with a bootstrap server still needs each user to sign in, and signing in does not deliver configuration.

third-party/claude-desktop/web-tools Changed · +3 / -1 lines

from line 95

9595}

9696```

9797

98Set the per-entry `toolPolicy` to `"allow"` so users aren't prompted to approve each search. `headersHelper` is an executable that prints the auth header as a JSON object to stdout; it follows the same execution model as [`inferenceCredentialHelper`](/docs/third-party/claude-desktop/credential-helper) (run with no arguments, exit 0, stdout read as JSON), but the output here is a flat header map, not the `{token, headers}` shape `inferenceCredentialHelper` uses.

98Set the per-entry `toolPolicy` to `"allow"` so users aren't prompted to approve each search. `headersHelper` is an executable that prints the auth header as a JSON object to stdout; it follows the same execution model as [`inferenceCredentialHelper`](/docs/third-party/claude-desktop/credential-helper) (exit 0, stdout read as JSON) but always runs with no arguments, and the output here is a flat header map, not the `{token, headers}` shape `inferenceCredentialHelper` uses.

9999

100100| Provider | Header your script should output |

101101| -------- | ----------------------------------- |

from line 105

105105| `custom` | Whatever your search server expects |

106106

107107You can use a static `headers` object instead if you don't need a secrets manager.

108

109With `provider: "custom"`, Claude Desktop sends each search as an HTTP `POST` to `customUrl` exactly as written (nothing is substituted into the URL), with `Content-Type: application/json`, any headers from `headers` and `headersHelper`, and the body `{"q": "<search terms>"}`. Your server must answer within 15 seconds with a 2xx status and a JSON body of the form `{"results": [{"title": "...", "url": "...", "snippet": "..."}]}`. Results without a `url` are dropped, at most 10 are used, and each `snippet` is truncated to 600 characters.

108110

109111#### Gateway-side search

110112