What this read moved
1–7 of 7third-party/claude-desktop/admin-console Changed · +5 / -5 lines
from line 8
88
99With 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.
1010
11Prompts, responses, and files go to your inference provider, as they do with MDM or a bootstrap server. Anthropic holds your user list and the settings you save. If you turn on usage analytics, Anthropic also holds token and session counts from your users' apps. Anthropic never holds provider credentials. For the full list of what Anthropic stores, see [Where your data goes](#where-your-data-goes).
11Prompts, responses, and files go to your inference provider, as they do with MDM or a bootstrap server. Anthropic holds your user list and the settings you save. If you turn on usage analytics, Anthropic also holds token and session counts from your users' apps. Anthropic never holds provider credentials such as API keys or your users' tokens. For the full list of what Anthropic stores, see [Where your data goes](#where-your-data-goes).
1212
1313## How it works
1414
from line 28
2828| --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
2929| 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). |
3030| Conversation history, projects, memory, and uploaded files | **No.** They stay on the device. |
31| Provider credentials, API keys, bearer tokens, and MCP secrets | **No.** They stay on the device, and the console refuses to save them. |
31| Provider credentials, API keys, bearer tokens, and MCP secrets | **No**, except the client secret of a Google Desktop-app OAuth client, which Google doesn't treat as confidential. You can enter one for [Google sign-in to your provider](#choose-how-users-authenticate-to-your-provider) or for a [managed MCP server that signs in with Google](/docs/third-party/claude-desktop/mcp-sign-in#where-the-client-secret-goes). Everything else stays on the device, and the console refuses to save it. |
3232| Plugin and skill content | **No.** It stays in your own repositories or on devices. The console stores marketplace locations and installation settings, not content. |
3333| OpenTelemetry export, if you configure a collector | **No.** It goes to your collector only. |
3434| User accounts (name and work email), group membership, and administrator roles | **Yes.** |
3535| Single sign-on and SCIM connection settings, if you use them | **Yes.** |
36| The configuration your administrators save, organization-wide and per group | **Yes.** Anthropic delivers it to users' apps. It contains no credentials. |
36| The configuration your administrators save, organization-wide and per group | **Yes.** Anthropic delivers it to users' apps. It contains no credentials other than a Google Desktop-app OAuth client secret, if you enter one. |
3737| 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. |
3838| Usage analytics: session, token, and estimated-cost counts per user, conversation, and model | **Yes**, if you turn on the **Report desktop usage to this organization** switch on the **Telemetry & updates** page. The switch is off by default. Users' apps report new counts only while the switch is on, and turning the switch off doesn't delete counts that Anthropic has already received. The counts contain no prompt, response, or file content. [Usage analytics](#usage-analytics) lists exactly what each report contains. |
3939
from line 97
9797| **Appearance** | Banner text and colors, end-user attribution, and whether the app shows feature announcements and configuration deprecation warnings |
9898| **Plugins** | The [plugin marketplaces](#plugin-marketplaces) that users' apps fetch, and how each one installs |
9999
100The 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 on the device, as described under [Choose how users authenticate to your provider](#choose-how-users-authenticate-to-your-provider).
100The console refuses API keys, tokens, and secrets anywhere in the configuration, including in request headers and MCP server settings. The one exception is the client secret of a Google Desktop-app OAuth client, for [Google sign-in to your inference provider](#choose-how-users-authenticate-to-your-provider) or a [managed MCP server that signs in with Google](/docs/third-party/claude-desktop/mcp-sign-in#where-the-client-secret-goes), which Google doesn't treat as confidential. Users authenticate to your provider on the device, as described under [Choose how users authenticate to your provider](#choose-how-users-authenticate-to-your-provider).
101101
102102Most 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).
103103
from line 126
126126
127127#### Managed MCP servers that need authentication
128128
129A managed MCP server that supports OAuth needs nothing on the device. Set **OAuth** on the server's entry on the **Connectors** page to **Auto-register (dynamic client registration)** or **Bring your own client**, and Claude Desktop signs each user in through the browser, as described under [OAuth sign-in](/docs/third-party/claude-desktop/extensions#oauth-sign-in). For a server that needs a secret, such as a confidential OAuth client secret, a request header that carries a token, or environment variables for a local server, enter the absolute path of a helper script on the device that prints it, in the **Client secret helper script**, **Headers helper script**, or **Environment helper script** field. The [`managedMcpServers` schema](/docs/third-party/claude-desktop/configuration#managedmcpservers) describes each script's output format. Install that script at the same absolute path on every device, as with the inference helper script.
129A managed MCP server that supports OAuth needs nothing on the device. Set **OAuth** on the server's entry on the **Connectors** page to **Auto-register (dynamic client registration)** or **Bring your own client**, and Claude Desktop signs each user in through the browser, as described under [OAuth sign-in](/docs/third-party/claude-desktop/extensions#oauth-sign-in). For a server that needs a secret, such as a confidential OAuth client secret, a request header that carries a token, or environment variables for a local server, enter the absolute path of a helper script on the device that prints it, in the **Client secret helper script**, **Headers helper script**, or **Environment helper script** field. The [`managedMcpServers` schema](/docs/third-party/claude-desktop/configuration#managedmcpservers) describes each script's output format. Install that script at the same absolute path on every device, as with the inference helper script. [Set up sign-in for managed MCP servers](/docs/third-party/claude-desktop/mcp-sign-in) explains how to tell whether a server needs a client ID or also a client secret, and [Connect to Google Cloud](/docs/third-party/claude-desktop/connectors-google-cloud) and [Connect to Box](/docs/third-party/claude-desktop/connectors-box) walk through two servers that need both.
130130
131131### Localhost base URLs
132132
third-party/claude-desktop/configuration Changed · +5 / -5 lines
from line 286
286286
287287 **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:
288288
289 ```json theme={null} theme={null} theme={null} theme={null} theme={null}
289 ```json theme={null}
290290 [{"name": "claude-sonnet-5", "supports1m": true}, "claude-opus-4-8"]
291291 ```
292292
from line 294
294294
295295 **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:
296296
297 ```json theme={null} theme={null} theme={null} theme={null} theme={null}
297 ```json theme={null}
298298 [{"name": "arn:aws:bedrock:us-east-1:123:application-inference-profile/abc", "labelOverride": "Claude Opus (Prod)"}]
299299 ```
300300
301301 **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:
302302
303 ```json theme={null} theme={null} theme={null} theme={null} theme={null}
303 ```json theme={null}
304304 [{"name": "us.anthropic.claude-opus-4-8", "anthropicFamilyTier": "opus"}]
305305 ```
306306
from line 334
334334 <Accordion title="inferenceModelPricing details">
335335 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.
336336
337 ```json theme={null} theme={null} theme={null} theme={null} theme={null}
337 ```json theme={null}
338338 {"inferenceModelPricingEnabled": true, "inferenceModelPricingMultiplier": 0.9, "inferenceModelPricing": [{"name": "claude-sonnet-4-6", "inputPerMtok": 2.4, "outputPerMtok": 12, "cacheReadPerMtok": 0.24, "cacheWritePerMtok": 3}]}
339339 ```
340340
from line 954
954954 <Accordion title="orgPluginSettings details">
955955 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):
956956
957 ```json theme={null} theme={null} theme={null} theme={null} theme={null}
957 ```json theme={null}
958958 [{"serverName": "internal-search", "tools": [{"toolName": "delete_document", "permission": "blocked"}]}]
959959 ```
960960
third-party/claude-desktop/connectors-box New page · 72 lines, new page
# Connect to Box ## How the connection works ## Set up the Box server
A whole new page. There's nothing to diff it against, so here is what it says.
# Connect to Box
> Give Claude access to your organization's Box content through Box's remote MCP server, with an OAuth client a Box admin creates and a client secret helper script on each device.
When Claude Desktop is deployed on third-party inference, Claude can work with your organization's Box content through Box's remote MCP server at `https://mcp.box.com`. The device talks to Box directly. No Box data or tokens pass through Anthropic's infrastructure.
## How the connection works
Box's MCP server requires an OAuth client that a Box admin creates, and Box's token endpoint requires that client's secret. The Enterprise Admin Console stores client secrets only for Google Desktop-app clients, so for Box each device supplies the secret through a helper script, as described under [Where the client secret goes](/docs/third-party/claude-desktop/mcp-sign-in#where-the-client-secret-goes). That page also explains each **OAuth** field.
## Set up the Box server
<Steps>
<Step title="Create the client in Box">
In the Box Admin Console, create integration credentials for the Box MCP server as described in Box's [remote MCP server guide](https://developer.box.com/guides/box-mcp/remote), with `http://127.0.0.1:53280/callback` as the redirect URI, and copy the generated client ID and client secret.
</Step>
<Step title="Install the secret helper script on every device">
Write a script that prints the client secret as the JSON object `{"clientSecret": "…"}` and nothing else on stdout (the full contract is under [Where the client secret goes](/docs/third-party/claude-desktop/mcp-sign-in#where-the-client-secret-goes)). On macOS, save the script (for example at `/usr/local/bin/box-mcp-secret`) and mark it executable:
```bash theme={null}
#!/bin/sh
printf '{"clientSecret":"%s"}' "YOUR_BOX_CLIENT_SECRET"
```
On Windows, save it as a `.cmd` file, for example `C:\Program Files\Corp\box-mcp-secret.cmd`:
```bat theme={null}
@echo off
echo {"clientSecret":"YOUR_BOX_CLIENT_SECRET"}
```
A secret written into the script is readable by anyone who can read the file. Where your devices have a secret store or vault CLI, have the script read the secret from there instead.
Distribute the script through your device management to the same absolute path on every device, in a location users can't modify. An entry holds one path for the whole organization, so if your fleet mixes macOS and Windows, add one entry per platform with its own name and script path, and assign each to the matching group of users with [per-group permission policies](/docs/third-party/claude-desktop/admin-console#per-group-permission-policies).
</Step>
<Step title="Add the server in the Enterprise Admin Console">
In the Enterprise Admin Console ([claude.ai](https://claude.ai) → **Organization settings**), open the **Connectors** page under **Desktop 3P**. Under **Managed MCP servers**, click **Add → Blank** and fill in the entry:
| Field | Value |
| ------------------------------- | ----------------------------------------------------------------------------------- |
| **Name** | `Box` |
| **Transport** | **Streamable HTTP** |
| **URL** | `https://mcp.box.com` |
| **OAuth** | **Bring your own client** |
| **Client ID** | The client ID from step 1 |
| **Client secret helper script** | The script's absolute path from step 2, for example `/usr/local/bin/box-mcp-secret` |
| **Authorization server** | `["https://api.box.com"]` |
Click **Save changes**. Users' apps pick up the new entry as described under [Configuration updates](/docs/third-party/claude-desktop/admin-console#configuration-updates). Devices need outbound HTTPS access to `mcp.box.com`, `account.box.com`, and `api.box.com`.
If you manage configuration through MDM or a bootstrap server instead, the equivalent entry can carry the secret inline:
```json theme={null}
{
"name": "Box",
"transport": "http",
"url": "https://mcp.box.com",
"oauth": {
"clientId": "YOUR_BOX_CLIENT_ID",
"clientSecret": "YOUR_BOX_CLIENT_SECRET",
"authorizationServer": ["https://api.box.com"]
}
}
```
</Step>
<Step title="Have users connect">
Each user opens **Customize → Connectors** in Claude Desktop, clicks **Connect** next to **Box**, and signs in to Box in the browser.
</Step>
</Steps>
third-party/claude-desktop/connectors-google-cloud New page · 75 lines, new page
# Connect to Google Cloud ## How the connection works ## Set up the BigQuery server ## Other Google servers ## Troubleshoot sign-in errors
A whole new page. There's nothing to diff it against, so here is what it says.
# Connect to Google Cloud
> Give Claude access to BigQuery and Google's other remote MCP servers with an OAuth client from your own Google Cloud project, set up in the Enterprise Admin Console.
When Claude Desktop is deployed on third-party inference, Claude can work with your organization's BigQuery and other Google data through Google's remote MCP servers, for example the BigQuery server at `https://bigquery.googleapis.com/mcp`. The device talks to Google directly: users' Google tokens stay on the device, and no Google data passes through Anthropic's infrastructure.
## How the connection works
Google's remote MCP servers don't support dynamic client registration, and Google's token endpoint requires the client secret even for a client of the **Desktop app** type. You create one Desktop-app OAuth client in your Google Cloud project, enter its client ID and client secret in the server's entry, and each user signs in with their own Google account. Google doesn't treat a Desktop-app client secret as confidential, so the Enterprise Admin Console stores it with the entry, as described under [Where the client secret goes](/docs/third-party/claude-desktop/mcp-sign-in#where-the-client-secret-goes). That page also explains each **OAuth** field.
## Set up the BigQuery server
<Steps>
<Step title="Prepare the Google Cloud project">
In the Google Cloud project that holds your BigQuery data, enable the BigQuery MCP server and grant each user the **MCP Tool User** role (`roles/mcp.toolUser`) together with the BigQuery roles their queries need. Google's [Use the BigQuery MCP server](https://docs.cloud.google.com/bigquery/docs/use-bigquery-mcp) guide covers both.
</Step>
<Step title="Create a Desktop-app OAuth client in Google Cloud">
If the project has no OAuth consent screen, configure one first in the Google Cloud Console under **APIs & Services → OAuth consent screen**. Choose the **Internal** user type when all users are in your Google Workspace organization. With **External**, add every user as a test user while the app is in testing, or Google blocks their sign-in.
Then open **APIs & Services → Credentials**, choose **Create credentials → OAuth client ID**, and select **Desktop app** as the application type. When Google shows the new client, copy its **Client ID** (ends in `.apps.googleusercontent.com`) and **Client secret** (begins with `GOCSPX-`). You don't add redirect URIs, because Desktop-app clients accept loopback redirects automatically.
</Step>
<Step title="Add the server in the Enterprise Admin Console">
In the Enterprise Admin Console ([claude.ai](https://claude.ai) → **Organization settings**), open the **Connectors** page under **Desktop 3P**. Under **Managed MCP servers**, click **Add → Blank** and fill in the entry:
| Field | Value |
| ------------------------ | ------------------------------------- |
| **Name** | `BigQuery` |
| **Transport** | **Streamable HTTP** |
| **URL** | `https://bigquery.googleapis.com/mcp` |
| **OAuth** | **Bring your own client** |
| **Client ID** | The client ID from step 2 |
| **Client secret** | The client secret from step 2 |
| **Authorization server** | `["https://accounts.google.com"]` |
<Frame caption="A BigQuery entry on the Connectors page with OAuth set to Bring your own client.">
<img src="https://mintcdn.com/claude-ai/l0HgWAJ4dDJ1-I-u/images/third-party/admin-console-managed-mcp-oauth.png?fit=max&auto=format&n=l0HgWAJ4dDJ1-I-u&q=85&s=efa91a216efb8f99c1e4aefc0ed5b16a" alt="Managed MCP server entry named BigQuery in the Enterprise Admin Console, with Transport set to Streamable HTTP, the BigQuery MCP URL, OAuth set to Bring your own client, and the Client ID, Client secret, and Authorization server fields filled in." width="1952" height="1705" data-path="images/third-party/admin-console-managed-mcp-oauth.png" />
</Frame>
Click **Save changes**. Users' apps pick up the new entry as described under [Configuration updates](/docs/third-party/claude-desktop/admin-console#configuration-updates). Devices need outbound HTTPS access to `bigquery.googleapis.com`, `accounts.google.com`, and `oauth2.googleapis.com`.
If you manage configuration through MDM or a bootstrap server instead, the equivalent [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers) entry is:
```json theme={null}
{
"name": "BigQuery",
"transport": "http",
"url": "https://bigquery.googleapis.com/mcp",
"oauth": {
"clientId": "CLIENT_ID.apps.googleusercontent.com",
"clientSecret": "GOCSPX-YOUR_CLIENT_SECRET",
"authorizationServer": ["https://accounts.google.com"]
}
}
```
</Step>
<Step title="Have users connect">
Each user opens **Customize → Connectors** in Claude Desktop, clicks **Connect** next to **BigQuery**, and approves Google's consent screen in the browser. Claude Desktop asks Google for offline access automatically, so the token refreshes in the background without another sign-in.
</Step>
</Steps>
## Other Google servers
Google's other remote MCP servers take the same **Client ID**, **Client secret**, and **Authorization server** values. For the [Google Workspace servers](https://developers.google.com/workspace/guides/configure-mcp-servers) (Gmail, Drive, Calendar, Docs, Sheets, Slides, and Chat), that guide lists each server's URL and prerequisites, including a Google Cloud project enrolled in Google's [Workspace Developer Preview Program](https://developers.google.com/workspace/preview).
## Troubleshoot sign-in errors
These messages appear in `main.log` in the [logs directory](/docs/third-party/claude-desktop/data-storage#where-data-lives) on the user's device.
| Message | Cause | Fix |
| ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `client_secret is missing` after the browser sign-in succeeds | The entry has no **Client secret** | Enter the secret of the client named in **Client ID**, with **Authorization server** set to `["https://accounts.google.com"]` |
| `invalid_client` | The secret doesn't belong to the client named in **Client ID**, or was deleted in Google Cloud | In **APIs & Services → Credentials**, add a new secret to that client and update **Client secret** in the server's entry. Users then click **Connect** again |
third-party/claude-desktop/mcp-sign-in New page · 72 lines, new page
# Set up sign-in for managed MCP servers ## Choose the OAuth setting ## Where the client secret goes ## OAuth fields ## Settings for common servers ## Troubleshoot sign-in ## Related connector guides
A whole new page. There's nothing to diff it against, so here is what it says.
# Set up sign-in for managed MCP servers
> Decide whether a managed MCP server needs an OAuth client that you register and whether it also needs that client's secret, fill in the OAuth fields, and read the sign-in error messages.
For a remote [managed MCP server](/docs/third-party/claude-desktop/extensions#managed-mcp-servers-admin) that uses OAuth, Claude Desktop signs each user in through the browser: the user clicks **Connect**, signs in to the server's identity provider (the OAuth service its vendor runs, for example Google or Box), and Claude Desktop stores the resulting token encrypted on the device. What you configure depends on that identity provider. Some register Claude Desktop as a client automatically, some require an OAuth client that you register, and some also require that client's secret.
This page is for administrators who add servers on the **Connectors** page of the [Enterprise Admin Console](/docs/third-party/claude-desktop/admin-console). The [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration) has the same fields, and in an MDM or bootstrap configuration they are the `oauth` keys of a [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers) entry. For the redirect URI, discovery, and token handling in detail, see [OAuth sign-in](/docs/third-party/claude-desktop/extensions#oauth-sign-in).
## Choose the OAuth setting
In the Enterprise Admin Console ([claude.ai](https://claude.ai) → **Organization settings**), open the **Connectors** page under **Desktop 3P**. Each remote entry under **Managed MCP servers** has an **OAuth** menu. Choose the setting that matches what the server's identity provider requires.
| If the identity provider | **OAuth** setting | What you register at the identity provider | Fields to fill in |
| ------------------------------------------------------------------------------------------ | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Supports dynamic client registration | **Auto-register (dynamic client registration)** | Nothing. Claude Desktop registers itself as a client on each device when the user first clicks **Connect** | None |
| Requires an OAuth client that you register (no dynamic client registration) | **Bring your own client** | A public OAuth client (native or desktop application type) with redirect URI `http://127.0.0.1:53280/callback` and no secret | **Client ID** |
| Requires a registered client and rejects token requests that don't carry the client secret | **Bring your own client** | An OAuth client with redirect URI `http://127.0.0.1:53280/callback`, plus its client secret | **Client ID**, **Authorization server**, and the secret in **Client secret** or **Client secret helper script** |
Leave the **OAuth** menu set to **None** for a server that needs no sign-in or that authenticates with request headers. The menu also lists **Anthropic-hosted client identity (requires Claude.ai sign-in)**, which this page doesn't cover.
Choose **Bring your own client** when the identity provider's documentation has you create an OAuth app, client, or integration and copy its client ID. You also need the secret when that client comes with one and the identity provider offers no public or PKCE-only client type. Otherwise start with **Auto-register (dynamic client registration)**. Single-tenant Microsoft Entra apps and identity providers that publish no discovery document need the extra fields listed under [OAuth fields](#oauth-fields).
Test each server yourself before you announce it: sign in to Claude Desktop as a member of the organization and click **Connect**. The Enterprise Admin Console has no connection test for MCP servers. If the setting doesn't match the server, **Connect** fails as described under [Troubleshoot sign-in](#troubleshoot-sign-in).
## Where the client secret goes
Add a client secret only when the identity provider refuses sign-in without one. The console stores a value in **Client secret** only for a Google OAuth client of the **Desktop app** type: the value begins with `GOCSPX-`, **Authorization server** is exactly `["https://accounts.google.com"]`, and **Tenant ID** is empty. Google doesn't treat a Desktop-app client secret as confidential, so the console accepts it. A Google **Web application** client's secret has the same `GOCSPX-` prefix but is confidential, so always create a **Desktop app** client.
For every other identity provider the secret stays on the device. Install a script that prints the secret, at the same absolute path on every device, and enter that path in the **Client secret helper script** field. The script must print exactly one JSON object, `{"clientSecret": "…"}`, on stdout and exit with code `0` within 30 seconds. Claude Desktop runs it each time the server connects or refreshes its sign-in in the background. The console stores only the path, so distribute the script through your device management, as described under [When a helper script is the right choice](/docs/third-party/claude-desktop/admin-console#when-a-helper-script-is-the-right-choice), and see [Connect to Box](/docs/third-party/claude-desktop/connectors-box) for a minimal script. A configuration delivered by MDM or a bootstrap server can instead carry any identity provider's secret inline in `oauth.clientSecret`.
**Authorization server** is required whenever **Client secret** or **Client secret helper script** is set. Claude Desktop sends the secret only to the token endpoint of the issuer you name there, so a misconfigured or compromised MCP server can't redirect the token exchange, and the secret, to another server.
## OAuth fields
These fields appear when **OAuth** is set to **Bring your own client**. The [`managedMcpServers` reference](/docs/third-party/claude-desktop/configuration#managedmcpservers) lists every `oauth` key and its minimum Claude Desktop version.
| Field | When to set | What to enter |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Client ID** | You registered a client at the identity provider | The client ID from that registration |
| **Client secret** | The identity provider requires the secret and the client is a Google Desktop-app client | The secret, beginning `GOCSPX-` |
| **Client secret helper script** | The identity provider requires the secret (any identity provider) | The absolute path of the script on the device. Set this or **Client secret**, not both; in a configuration file that sets both, the script wins |
| **Authorization server** | Required with a secret or secret helper script. Optional otherwise, to pin sign-in to a known issuer | A JSON array holding the authorization server's `issuer` value exactly as its metadata states it, for example `["https://accounts.google.com"]` (no trailing slash) or `["https://api.box.com"]` |
| **Authorization URL** and **Token URL** | The identity provider publishes no discovery document | Both HTTPS endpoints, always as a pair. Hidden when **Tenant ID** or **Authorization server** is set |
| **Tenant ID** | The client is a single-tenant Microsoft Entra app | Your Directory (tenant) ID. Requires **Scope** |
| **Scope** | Required with **Tenant ID**. Optional otherwise | Space-separated scopes for the authorize request. Leave empty to request the scopes the server advertises |
| **Sign-in flow** | Shown after you enter **Tenant ID**. Set it when your devices have the [OS identity broker](/docs/third-party/claude-desktop/entra-broker) | **OS identity broker (WAM / Company Portal)**. The default is **System browser** |
| **Callback host** and **Callback port** | The redirect URI you registered uses `localhost` or a port other than `53280` | The host and port from that registration. Microsoft Entra ID accepts any loopback port, so leave both empty for Entra |
| **Additional redirect referrer hosts** | The identity provider completes sign-in from a host other than the one in its authorization URL, and `main.log` names a rejected referrer host | That hostname. Separate several with spaces |
## Settings for common servers
Add each server in this table with **Add → Blank**, the **Streamable HTTP** transport, and the values shown.
| Server | URL | **OAuth** setting | What you register |
| ------ | ---------------------------- | ----------------------------------------------- | ----------------- |
| Linear | `https://mcp.linear.app/mcp` | **Auto-register (dynamic client registration)** | Nothing |
| Notion | `https://mcp.notion.com/mcp` | **Auto-register (dynamic client registration)** | Nothing |
| Sentry | `https://mcp.sentry.dev/mcp` | **Auto-register (dynamic client registration)** | Nothing |
## Troubleshoot sign-in
These messages appear in Claude Desktop, or in `main.log` in the [logs directory](/docs/third-party/claude-desktop/data-storage#where-data-lives) on the user's device.
| What the user sees or `main.log` records | Cause | Fix |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| "Couldn't connect to \{server} because it doesn't support automatic client registration" (Claude Desktop 2.110.0 or later), or `main.log` records that the authorization server does not support dynamic client registration | **OAuth** is **Auto-register** but the identity provider requires a client that you register | Register a public client with redirect URI `http://127.0.0.1:53280/callback`, set **OAuth** to **Bring your own client**, and fill in **Client ID** |
| The browser step succeeds, then the connection fails and `main.log` records the token endpoint's error, for example `client_secret is missing` | The entry has a **Client ID** but the identity provider also requires the secret | Add the secret and **Authorization server** as described under [Where the client secret goes](#where-the-client-secret-goes) |
| `main.log` names a rejected referrer host during sign-in | The identity provider completes sign-in from a host other than the one in its authorization URL | Add that hostname to **Additional redirect referrer hosts** |
## Related connector guides
[Connect to Google Cloud](/docs/third-party/claude-desktop/connectors-google-cloud) and [Connect to Box](/docs/third-party/claude-desktop/connectors-box) walk through two servers that need a client you register and its secret. [Connect to GitHub](/docs/third-party/claude-desktop/connectors-github) and [Connect to Microsoft 365](/docs/third-party/claude-desktop/connectors-m365) cover those connectors end to end, including the [built-in servers](/docs/third-party/claude-desktop/built-in-connectors) that run inside the app. Some partners publish a plugin marketplace rather than an MCP server; add those on the **Plugins** page, as described under [Plugin marketplaces](/docs/third-party/claude-desktop/admin-console#plugin-marketplaces).
government/config/overview Changed · +1 / -1 lines
from line 35
3535
3636## When changes take effect
3737
38Settings that govern the admin portal, such as whether organizations may manage seat tiers, apply immediately. Settings that govern the Claude applications themselves, such as the Claude Desktop banner, product availability, and telemetry endpoint, are delivered to each member's application the next time it refreshes its configuration, which happens when the application is launched or the member signs in. You do not need to push anything, but members who are currently running the application may need to restart it to pick up a change. Lowering the session idle timeout applies to new sign-ins only, and so does raising or removing the maximum session length. Lowering the maximum session length, or setting one for the first time, also reaches members who are already signed in, taking up to one idle timeout period to do so, as described under [Maximum session length](/docs/government/config/settings#maximum-session-length).
38Settings that govern the admin portal, such as whether organizations may manage seat tiers, apply immediately. Settings that govern the Claude applications themselves, such as the Claude Desktop banner, product availability, and telemetry endpoint, are delivered to each member's application the next time it refreshes its configuration, which happens when the application is launched or the member signs in. You do not need to push anything, but members who are currently running the application may need to restart it to pick up a change. Claude Desktop prompts for that restart, and requires it once the [Restart deadline for configuration changes](/docs/government/config/settings#restart-deadline-for-configuration-changes) has passed. Lowering the session idle timeout applies to new sign-ins only, and so does raising or removing the maximum session length. Lowering the maximum session length, or setting one for the first time, also reaches members who are already signed in, taking up to one idle timeout period to do so, as described under [Maximum session length](/docs/government/config/settings#maximum-session-length).
3939
4040## Working with the list
4141
third-party/claude-desktop/extensions Changed · +1 / -1 lines
from line 59
5959
6060The value is the same on every device and for every delivery method (device management, a local configuration file, or a [bootstrap server](/docs/third-party/claude-desktop/bootstrap)). On identity providers that accept any port on a loopback redirect URI (the [RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) native-app pattern), a registration of `http://127.0.0.1/callback` also matches.
6161
62With `"oauth": true`, Claude Desktop registers its own public client through dynamic client registration and lists this URI as the client's only redirect URI, so the authorization server must offer a registration endpoint and accept an `http` loopback redirect URI. With a client you registered yourself, set `oauth.clientId` and add the URI to that registration. If the registration uses `localhost` or another port, set `oauth.callbackHost` or `oauth.callbackPort` to match; both require `clientId`.
62With `"oauth": true`, Claude Desktop registers its own public client through dynamic client registration and lists this URI as the client's only redirect URI, so the authorization server must offer a registration endpoint and accept an `http` loopback redirect URI. With a client you registered yourself, set `oauth.clientId` and add the URI to that registration. If the registration uses `localhost` or another port, set `oauth.callbackHost` or `oauth.callbackPort` to match; both require `clientId`. [Set up sign-in for managed MCP servers](/docs/third-party/claude-desktop/mcp-sign-in) explains how to tell which servers need a client that you register, when a client secret is also required, and where the secret goes.
6363
6464An `http` or `sse` entry with no `oauth`, no `headersHelper`, and no `Authorization` header is treated as `"oauth": true` when its server asks for authentication (Claude Desktop 1.24012.0 or later). This redirect URI applies to MCP server sign-in only. [Gateway single sign-on](/docs/third-party/claude-desktop/gateway#set-up-single-sign-on) and [bootstrap sign-in](/docs/third-party/claude-desktop/bootstrap#provider-notes) register their own loopback redirect URI.
6565