Home Docs Claude Documentation

One capture · claude-docs

One read of Claude Documentationclaude-docs-20260814T092040Z

213 pages moved out of 213 read.

Pages moved 213 significant first

Pages read 213 in this capture

Captured 14 Aug 2026 09:20 UTC

Corpus hash dfa3e64bc187 full baseline · baseline

What this read moved

176-200 of 213, page 8 of 9

This capture is too large to show at once. Changes 176-200 of 213 are below, significant first; the rest are on the following screens.

office-agents/fsi-plugins First recorded · 123 lines, first recorded

# Install financial services plugins for Cowork ## What's included ## Add the marketplace ## Install plugins ## Available Skills ## MCP connectors ## Customize plugins for your firm ## Learn more

The first capture of this source. The page was already there, and this is what it said.

# Install financial services plugins for Cowork

> Add the open-source financial services plugin set to Cowork for financial modeling, equity research, investment banking, private equity, and wealth management workflows.

A set of open-source plugins extends Cowork with specialized
capabilities for financial services workflows: financial modeling,
equity research, investment banking, private equity, and wealth
management. The plugins also work in Claude Code.

The plugins live in a
[public GitHub repository](https://github.com/anthropics/financial-services)
that you can add as a marketplace in Cowork.

## What's included

The repository contains a core plugin and several add-on plugins that
build on it.

| Plugin                    | What it does                                                                                                                                                                |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Financial analysis (core) | Build comparable company analyses, DCF models, LBO models, and 3-statement financials. Includes all shared MCP connectors for financial data providers. Install this first. |
| Investment banking        | Draft CIMs, teasers, and process letters. Build buyer lists, run merger models, and create strip profiles.                                                                  |
| Equity research           | Write earnings updates and initiating coverage reports. Track catalysts and screen for new ideas.                                                                           |
| Private equity            | Source and screen deals, run due diligence checklists, draft IC memos, and monitor portfolio company KPIs.                                                                  |
| Wealth management         | Prep for client meetings, build financial plans, rebalance portfolios, and identify tax-loss harvesting opportunities.                                                      |

The repository also includes partner-built plugins from LSEG and S\&P
Global, which bring their financial data and analytics directly into
Cowork.

## Add the marketplace

<Steps>
  <Step title="Open Cowork">
    Open the Claude Desktop app and select the Cowork tab in the mode
    selector.
  </Step>

  <Step title="Open plugin browser">
    Select "Customize" on the left sidebar, then "Browse plugins".
  </Step>

  <Step title="Add the marketplace">
    Select "Personal", click the "+" button, then select "Add
    marketplace from GitHub". Enter the repository URL:
    `https://github.com/anthropics/financial-services`
  </Step>
</Steps>

Once added, you'll see the available financial services plugins in your
marketplace.

## Install plugins

<Steps>
  <Step title="Browse the marketplace">
    From your plugin marketplace, browse the available financial
    services plugins.
  </Step>

  <Step title="Install the core first">
    Install the financial analysis plugin first. It provides shared
    tools and data connectors that the other plugins use.
  </Step>

  <Step title="Install workflow add-ons">
    Install any additional plugins that match your workflow needs.
  </Step>
</Steps>

Once installed, plugins activate automatically. Skills are applied when
relevant, or you can invoke them manually during your Cowork session by
typing `/` or clicking the "+" button.

## Available Skills

After installation, you can invoke Skills like the following.

<Warning>
  AI-generated financial analysis should always be reviewed by a
  qualified professional before being used in decision-making.
</Warning>

| Skill                           | What it does                            |
| ------------------------------- | --------------------------------------- |
| `/comps [company]`              | Run a comparable company analysis.      |
| `/dcf [company]`                | Build a DCF valuation model.            |
| `/earnings [company] [quarter]` | Generate a post-earnings update report. |
| `/one-pager [company]`          | Create a one-page company profile.      |
| `/ic-memo [project name]`       | Draft an investment committee memo.     |
| `/source [criteria]`            | Source deals based on criteria.         |
| `/client-review [client]`       | Prep for a client meeting.              |

## MCP connectors

The financial analysis core plugin includes connectors for third-party
financial data providers including Daloopa, Morningstar, S\&P Global,
FactSet, Moody's, MT Newswires, Aiera, LSEG, PitchBook, Chronograph, and
Egnyte.

<Note>
  Access to these connectors may require a separate subscription or API
  key from the respective provider. Contact your data provider for
  details.
</Note>

## Customize plugins for your firm

These plugins are starting points. Plugins are file-based Markdown and
JSON, so no code or infrastructure is required to customize them. Edit
the plugin files directly to match your firm's workflows.

* Add your firm's terminology, processes, and formatting standards to
  skill files.
* Swap or add MCP connectors to point at your specific data providers.
* Adjust workflow instructions to reflect how your team does analysis.
* Use `/ppt-template` to teach Claude your firm's branded PowerPoint
  layouts.

## Learn more

See the [Cowork and plugins for finance](https://claude.com/blog/cowork-plugins-finance)
blog post for background on how the plugins were designed.

office-agents/outlook First recorded · 477 lines, first recorded

# Use Claude for Outlook ## What you can do ## Get started with Claude for Outlook ### Supported versions ### Install for yourself ### Deploy to your organization ### Install from a manifest file ### Grant Microsoft Graph consent #### Use your own Entra app instead ### Deploy in a US Government or national cloud ### Connect through a third-party platform ## Triage your inbox ## Draft replies in your voice ## Summarize long threads ## Read attachments inline ## Search your mailbox ## Find time and create events ## Prep for meetings ## Work across M365 apps ## Model availability ## How Claude accesses your mailbox ### When you sign in with a Claude account ### When you connect through a third-party platform ## Chat history ## Data retention and audit ## Prompt injection risks ## Recommended use during beta

The first capture of this source. The page was already there, and this is what it said.

# Use Claude for Outlook

> An Outlook add-in that integrates Claude into your inbox and calendar, for Pro, Max, Team, and Enterprise plans.

Claude for Outlook is an add-in that brings Claude into your Outlook inbox
and calendar. It is built for professionals whose work runs through email,
including private equity and investment banking associates managing deal
flow, in-house legal teams running counterparty negotiations, and
consultants tracking multiple client threads.

<Note>
  Claude for Outlook is currently in beta and available to Pro, Max, Team,
  and Enterprise plans.
</Note>

## What you can do

With Claude for Outlook, you can:

* Triage your unread inbox into what needs you, what Claude can handle,
  and what is noise.
* Draft replies, reply-alls, and forwards in your voice, landed unsent in
  Outlook's compose pane.
* Summarize long threads into decisions made, open items, and who owes
  what, with per-email citations.
* Read `.docx` and `.xlsx` attachments inline without opening them.
* Find meeting times across attendees and draft invites into Outlook's
  native appointment form.
* Prep for your next meeting with a one-page brief of recent threads and
  attached documents.

## Get started with Claude for Outlook

### Supported versions

Claude for Outlook runs on the following Outlook clients.

* Outlook on the web
* Outlook on Windows, both new Outlook and classic Outlook, with a
  Microsoft 365 subscription
* Outlook on Mac with a Microsoft 365 subscription

The following are not supported: Outlook 2016 and 2019 perpetual or
volume-licensed editions, Outlook on iOS, Outlook on Android, and
mailboxes hosted on Exchange on-premises. Exchange Online through
Microsoft 365 is required.

### Install for yourself

<Steps>
  <Step title="Open the marketplace listing">
    Go to the [Claude for Outlook listing on Microsoft AppSource](https://appsource.microsoft.com/).
  </Step>

  <Step title="Install the add-in">
    Select "Get it now" to install.
  </Step>

  <Step title="Open Claude in Outlook">
    Open Outlook, open any email, select the Claude button in the message
    ribbon, and sign in with your Claude account.
  </Step>
</Steps>

If you do not see the Claude button on the message, open the overflow menu
on the reading pane, choose Customize actions, and check Claude under
Apps. It then appears on every message and in the Home ribbon.

### Deploy to your organization

Organization admins can deploy Claude for Outlook through the Microsoft
365 Admin Center.

<Steps>
  <Step title="Allow Office Store access">
    In the [Microsoft 365 Admin Center](https://admin.microsoft.com), go
    to Settings, Org Settings, User owned apps and services, and turn on
    ["Let users access the Office Store"](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-addins-in-the-admin-center).
  </Step>

  <Step title="Open Integrated apps">
    Go to Settings, then Integrated apps.
  </Step>

  <Step title="Find the add-in">
    Search for "Claude for Outlook" in Microsoft AppSource.
  </Step>

  <Step title="Deploy">
    Deploy the add-in to your organization or to specific people. See
    [Microsoft's deployment guide](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-deployment-of-add-ins)
    for assignment options.
  </Step>

  <Step title="Grant Microsoft Graph consent">
    Complete the [Microsoft Graph admin consent](#grant-microsoft-graph-consent)
    step below so users are not prompted individually.
  </Step>
</Steps>

<Note>
  If your organization uses Microsoft Entra Privileged Identity
  Management (PIM) for admin roles, the Integrated apps page does not
  recognize roles activated through PIM, so deployment fails. This is a
  [known Microsoft issue](https://learn.microsoft.com/en-us/office/dev/add-ins/resources/resources-office-add-in-known-issues),
  tracking ID 11126536. To work around it, deploy from an admin account
  with the required role assigned as permanently active rather than
  PIM-eligible. See
  [Microsoft's troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/microsoft-365/admin/miscellaneous/cannot-deploy-add-in-integrated-apps-menu).
  Individual users can still
  [install the add-in themselves](#install-for-yourself).
</Note>

After installation, team members open Outlook, open any email, select the
Claude button in the message ribbon, and sign in with their Claude
credentials. Pinning the task pane keeps it open as you move between
messages.

<Warning>
  Organizations that have disabled "Let users access the Office Store" may
  find that admin-deployed add-ins don't appear for users. To work around
  this, deploy using the manifest XML file described below.
</Warning>

### Install from a manifest file

If your organization blocks the Microsoft Store, an IT administrator can
deploy the add-in by uploading its manifest file directly.

<Steps>
  <Step title="Download the manifest">
    Download the
    [Claude for Outlook manifest](https://pivot.claude.ai/manifest-outlook.xml)
    and save it to a secure location.
  </Step>

  <Step title="Open Integrated apps">
    In the [Microsoft 365 Admin Center](https://admin.microsoft.com), go
    to Settings, then Integrated apps.
  </Step>

  <Step title="Upload the add-in">
    Select Upload custom apps, then Office Add-in. Choose "I have a
    manifest file on this device", select the file you downloaded, and
    upload it.
  </Step>

  <Step title="Assign people">
    Choose your deployment scope: the entire organization, specific
    people, specific groups, or just yourself for testing.
  </Step>

  <Step title="Deploy">
    Review the settings and select Deploy. The add-in appears within
    minutes for most people. Full organization rollout can take up to 24
    hours on the Microsoft 365 side.
  </Step>

  <Step title="Grant Microsoft Graph consent">
    Complete the consent step in the next section.
  </Step>
</Steps>

### Grant Microsoft Graph consent

Claude for Outlook reads mail and calendar data through Microsoft Graph.
This requires a one-time tenant-wide grant from a Global Administrator
and is separate from the Integrated apps deployment.

Have a Global Administrator open the following admin consent link in a
browser where they are signed in to your Microsoft 365 tenant.

```
https://login.microsoftonline.com/organizations/v2.0/adminconsent?client_id=c2995f31-11e7-4882-b7a7-ef9def0a0266&scope=https://graph.microsoft.com/Mail.ReadWrite%20https://graph.microsoft.com/Calendars.Read%20https://graph.microsoft.com/User.Read%20offline_access&redirect_uri=https://pivot.claude.ai/auth/callback
```

The administrator sees a Microsoft permissions screen listing
`Mail.ReadWrite`, `Calendars.Read`, `User.Read`, and `offline_access`.
After they select Accept, all users in the organization
can use Claude for Outlook without additional Microsoft prompts. The grant
takes effect immediately. Only the add-in rollout in the previous step can
take up to 24 hours.

If this step is skipped, every user sees a "Need admin approval" message
when Claude first tries to read mail or calendar data.

The redirect to `pivot.claude.ai` after consent carries only the consent
outcome, never a token or authorization code. See
[Why sign-in redirects through pivot.claude.ai](/docs/office-agents/third-party-platforms#why-sign-in-redirects-through-pivotclaudeai)
for what each redirect carries and how to verify it in a network capture.

#### Use your own Entra app instead

If your organization's policy does not permit consenting to a third-party
multi-tenant application, register a single-tenant application in the
Microsoft Entra admin center and have the add-in use it instead. The data
flow is identical; the Graph token stays in the user's Outlook client
either way. The difference is that approval and Conditional Access policy
live entirely under an application your organization owns.

<Steps>
  <Step title="Register the application">
    In the Entra admin center, go to App registrations and create a new
    registration. Choose "Accounts in this organizational directory only".
  </Step>

  <Step title="Configure authentication">
    Under Authentication, add a Single-page application platform with
    redirect URI `brk-multihub://pivot.claude.ai`. In Advanced settings,
    set "Allow public client flows" to Yes.
  </Step>

  <Step title="Add Graph permissions">
    Under API permissions, add the Microsoft Graph delegated permissions
    `Mail.ReadWrite`, `Calendars.Read`, `User.Read`, and `offline_access`.
    Select "Grant admin consent" for your tenant.
  </Step>

  <Step title="Append the client ID to the manifest URL">
    Copy the application's client ID from the Overview page. Append
    `?graph_client_id=YOUR_CLIENT_ID` to the manifest URL from the
    [Install from a manifest file](#install-from-a-manifest-file) section
    and use that URL when downloading the manifest.
  </Step>
</Steps>

With this option, skip the admin consent link entirely. Users do not see a
Microsoft permissions prompt because your tenant has already consented to
your own application.

### Deploy in a US Government or national cloud

If your Microsoft 365 tenant is in GCC High, DoD, or 21Vianet, register
your own Entra application with `graph_client_id` as described above
(Anthropic's multi-tenant application exists only in the global cloud)
and set `graph_cloud` to the matching value:

| Tenant            | `graph_cloud`                      |
| ----------------- | ---------------------------------- |
| Commercial or GCC | `global` (default; may be omitted) |
| GCC High          | `us-gov-high`                      |
| DoD               | `us-gov-dod`                       |
| 21Vianet (China)  | `china`                            |

For a DoD tenant the manifest URL ends with:

```
?graph_client_id=YOUR_CLIENT_ID&graph_cloud=us-gov-dod
```

For GCC High and 21Vianet tenants, `graph_cloud` may be omitted: the
add-in detects those clouds at sign-in from the authority host Outlook
reports. Setting it explicitly is still recommended when your compliance
program requires the endpoints to be fixed in the reviewed manifest
rather than derived at runtime. DoD tenants share an authority host with
GCC High, so `graph_cloud=us-gov-dod` is always required for DoD.

### Connect through a third-party platform

If your organization routes API traffic through an internal LLM gateway,
Amazon Bedrock, Google Cloud Vertex AI, or Azure AI Foundry, you can use
the add-in without Claude accounts. This is the same gateway pattern used
by Claude Code.

For setup instructions and gateway requirements, see
[Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms).

## Triage your inbox

Ask Claude what needs your attention. Claude reads your unread mail and
attachments and sorts them into three groups: action items for you, items
Claude can handle for your review, and noise you can archive in one
selection. Each action item carries a one-line reason. Items Claude can
handle, such as scheduling asks, acknowledgments, and standard-form
documents, arrive pre-drafted.

Prompts to try:

* "What needs me?"
* "Draft replies for everything you can handle"
* "Archive all the calendar responses and newsletters"

## Draft replies in your voice

Tell Claude what you want to say. It drafts the reply into Outlook's
native compose pane, unsent. Tone is learned from your sent folder, so
the draft matches your sentence length and formality register. Claude
leaves the closing off so Outlook can append your configured signature
without duplication.
Claude chooses reply versus reply-all deliberately and warns before adding
anyone who was not on the thread.

Prompts to try:

* "Reply to this and agree to the extension, push back on the fee"
* "Reply-all thanking everyone and confirming Thursday works"
* "Forward this to Dana with a two-line summary"

## Summarize long threads

Cut at 300 lines. The page has the rest.

office-agents/overview First recorded · 43 lines, first recorded

# Claude for M365 overview ## What's available today ## Deployment

The first capture of this source. The page was already there, and this is what it said.

# Claude for M365 overview

> Claude for Excel, PowerPoint, Word, and Outlook.

Claude for M365 is a set of Claude-powered add-ins that work inside your Microsoft
365 apps. Chat with Claude about the file or email you have open, ask it
to read or edit content, and move work between Excel, PowerPoint, Word,
and Outlook without leaving the app.

## What's available today

The pages below cover each surface and the features that span them.

* [Claude for Excel](/docs/office-agents/excel): read and write cells,
  formulas, formatting, pivot tables, and charts.
* [Claude for PowerPoint](/docs/office-agents/powerpoint): read, edit,
  and generate slides using your existing templates.
* [Claude for Word](/docs/office-agents/word): draft, redline, and
  review documents with tracked changes and comment-driven editing.
* [Claude for Outlook](/docs/office-agents/outlook): triage your inbox,
  draft replies in your voice, summarize threads, and find meeting times.
  Admins must complete a one-time
  [Microsoft Graph consent](/docs/office-agents/outlook#grant-microsoft-graph-consent)
  before deployment.
* [Work across M365 apps](/docs/office-agents/work-across-apps):
  Claude for Excel, PowerPoint, Word, and Outlook share conversation
  state, so actions in one app are informed by what happened in the
  others.
* [Connectors and Skills](/docs/office-agents/connectors-and-skills):
  extend Claude with external context and reusable task recipes.
* [Dictation](/docs/office-agents/dictation): speak prompts instead
  of typing them.

## Deployment

These pages cover enterprise admin setup and observability.

* [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms):
  connect through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry,
  or an LLM gateway.
* [Security, admin auditability, and analytics](/docs/office-agents/enterprise-readiness):
  security architecture diagrams, OpenTelemetry audit, usage analytics,
  and spend tracking.

office-agents/powerpoint First recorded · 354 lines, first recorded

# Use Claude for PowerPoint ## What you can do ## Get started with Claude for PowerPoint ### Supported versions ### Install for yourself ### Deploy to your organization ### Deploy with a custom manifest ### Connect through a third-party platform ## Key features ### Build from templates ### Edit existing slides ### Generate full decks ### Create native charts and diagrams ### Template awareness ## Connectors and Skills ## Set persistent instructions ## Work across M365 apps ## Context and session management ## Models available ## Data handling ## Current limitations ### Unsupported versions ## Prompt injection risk ## Best practices ## Example use cases ### Consulting deliverables ### Iterative refinement ### Data visualization ### Deck restructuring

The first capture of this source. The page was already there, and this is what it said.

# Use Claude for PowerPoint

> A PowerPoint add-in that integrates Claude into your presentation workflow, for Pro, Max, Team, and Enterprise plans.

Claude for PowerPoint is an add-in that brings Claude into PowerPoint.
Build decks from scratch, edit specific slides without regenerating
everything, convert bullets into diagrams and native charts, and iterate
on feedback while preserving template compliance.

<Note>
Claude for PowerPoint is generally available to Pro, Max,
Team, and Enterprise plans.
</Note>

## What you can do

With Claude for PowerPoint, you can:

* Build new slides using your existing client or corporate templates.
* Make pinpoint edits to specific slides without regenerating entire
decks.
* Generate full deck structures from natural language descriptions.
* Convert bullets into diagrams and native PowerPoint charts.
* Pull external context through connectors.
* Iterate on feedback while preserving formatting and template
compliance.

## Get started with Claude for PowerPoint

### Supported versions

Claude for PowerPoint runs on the following PowerPoint builds.

* PowerPoint on the web
* PowerPoint on Windows with a Microsoft 365 subscription, build 16.0.13127.20296 or later
* PowerPoint on Mac, version 16.46 or later

### Install for yourself

<Steps>
<Step title="Open the marketplace listing">
Go to the [Claude for Microsoft 365 listing on Microsoft AppSource](https://marketplace.microsoft.com/en-us/product/office/WA200010725?tab=Overview).
</Step>

<Step title="Install the add-in">
Select "Get it now" to install.
</Step>

<Step title="Sign in">
Open PowerPoint, activate the add-in, and sign in with your Claude
account.
</Step>
</Steps>

### Deploy to your organization

Organization admins can deploy Claude for PowerPoint through the
Microsoft 365 Admin Center.

<Steps>
<Step title="Allow Office Store access">
In the [Microsoft 365 Admin Center](https://admin.microsoft.com), go
to Settings, Org Settings, User owned apps and services, and turn on
["Let users access the Office Store"](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-addins-in-the-admin-center).
</Step>

<Step title="Open Integrated apps">
Go to Settings, Integrated apps, Add-ins.
</Step>

<Step title="Find the add-in">
Search for "Claude for Microsoft 365" in Microsoft AppSource.
</Step>

<Step title="Deploy">
Assign the add-in to your organization or to specific users or
groups. Share [Microsoft's deployment guide](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-deployment-of-add-ins)
with your team for activation steps.
</Step>
</Steps>

<Note>
If your organization uses Microsoft Entra Privileged Identity
Management (PIM) for admin roles, the Integrated apps page does not
recognize roles activated through PIM, so deployment fails. This is a
[known Microsoft issue](https://learn.microsoft.com/en-us/office/dev/add-ins/resources/resources-office-add-in-known-issues),
tracking ID 11126536. To work around it, deploy from an admin account
with the required role assigned as permanently active rather than
PIM-eligible. See
[Microsoft's troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/microsoft-365/admin/miscellaneous/cannot-deploy-add-in-integrated-apps-menu).
Individual users can still
[install the add-in themselves](#install-for-yourself).
</Note>

After deployment, users can activate the Claude add-in from Tools,
Add-ins on Mac or Home, Add-ins on Windows, sign in, and start working.

<Warning>
Organizations that have disabled "Let users access the Office Store" may
find that admin-deployed add-ins don't appear for users. To work around
this, deploy using the manifest XML file described below.
</Warning>

### Deploy with a custom manifest

For IT administrators deploying to multiple users when the Office Store
is disabled:

<Steps>
<Step title="Download the manifest">
Download the [custom manifest XML file](https://pivot.claude.ai/manifest-powerpoint.xml)
and save it to a secure location.
</Step>

<Step title="Open the Admin Center">
Go to [https://admin.microsoft.com](https://admin.microsoft.com),
sign in, and open Settings, Integrated apps.
</Step>

<Step title="Upload the custom add-in">
Select "Upload custom apps", choose "Office Add-in", then
"I have a manifest file on this device". Upload the manifest.
</Step>

<Step title="Assign users">
Choose entire organization, specific users, specific groups, or just
yourself for admin testing.
</Step>

<Step title="Deploy">
Review settings and select "Deploy". The add-in is available within
minutes. Full organization rollout can take up to 24 hours.
</Step>
</Steps>

After deployment, users see Claude in PowerPoint's Home ribbon and sign
in with their Claude credentials on first use.

### Connect through a third-party platform

If your organization routes AI traffic through Amazon Bedrock, Google Cloud
Vertex AI, Azure AI Foundry, or an LLM gateway, your admin can deploy
the add-in without individual Claude accounts. See
[Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms).

## Key features

### Build from templates

Start with a client or corporate template already loaded. Describe what
you need, and Claude generates slides using the correct layouts, fonts,
and colors from the slide master. Claude reads your deck's template and
respects its formatting rules.

Example prompts:

* "Create a market sizing section, 3 slides covering TAM, SAM, SOM with
supporting visuals."
* "Add an executive summary slide using the one-column content layout."

### Edit existing slides

Select a slide and tell Claude what to change. Claude makes edits while
preserving formatting and surrounding context.

Example prompts:

* "Simplify the text on this slide."
* "Add a chart showing the quarterly trend."
* "Restructure the storyline across slides 4 to 7."

### Generate full decks

Open a blank deck and describe your goal. Claude builds a draft with
logical structure and professional defaults, which you can refine.

Example prompts:

* "Create a 10-slide deck walking through our market entry hypotheses."
* "Build an internal project update presentation with timeline and next
steps."

### Create native charts and diagrams

Convert bullet points into professional visuals such as diagrams, process
flows, or editable native PowerPoint charts. Claude produces visuals you
can edit directly, not static images.

Example prompts:

* "Turn these bullets into a process flow diagram."
* "Create a bar chart comparing Q1 to Q4 performance."

### Template awareness

Claude reads the slide master, layouts, fonts, and color scheme in your
deck and uses them when generating or editing slides. It aims to
maintain template compliance without introducing off-brand elements.

## Connectors and Skills

Claude for PowerPoint supports connectors for pulling external context
into your deck, and Skills for applying reusable task recipes. See
[Connectors and Skills](/docs/office-agents/connectors-and-skills) for
details.

## Set persistent instructions

Open Settings in the add-in sidebar and use the Instructions field to
set preferences that
apply to every conversation in PowerPoint. Instructions are useful for
brand guidelines such as "always use one-line bullets" or "use the blue
accent color for highlights", preferred slide structure, or recurring
context about your workflow.

Instructions you set in PowerPoint only apply to PowerPoint. They are
separate from Instructions you set in Excel or Word.

## Work across M365 apps

Claude for PowerPoint shares context with Claude for Excel, Word, and
Outlook, so a single conversation can span your open deck, workbook,
document, and inbox. See
[Work across M365 apps](/docs/office-agents/work-across-apps).

## Context and session management

The add-in handles long sessions for you so a single conversation can
span an entire workflow.

* **Auto-compaction**: longer conversations are automatically compacted
into new conversations to avoid running out of context. See
[Understanding usage and length limits](https://support.claude.com/en/articles/11647753-understanding-usage-and-length-limits).

Your use of Claude for PowerPoint is associated with your existing
Claude account and is subject to the same usage limits.

## Models available

Claude for M365 offers a curated subset of the Claude models: the ones
that work best for Office tasks, so the list you see in the add-in can
be shorter than what you see in Claude.ai. Your organization's model
access settings also apply, and a model appears here only if your role
permits it. See
[Manage model access for your organization](https://support.claude.com/en/articles/15694740-manage-model-access-for-your-organization)
for how those settings interact with each product. If you connect
through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an
LLM gateway, the available models come from that platform and your
admin's configuration instead of your Claude.ai model access settings.
See [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms)
for details.

## Data handling

Inputs and outputs are deleted on the backend within 30 days of receipt
or generation, except in cases outlined in
[How long do you store my organization's data?](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data).
Data is cached for a number of hours after deletion so users can access
context in recently closed presentations.

Chat history is stored locally in your browser using IndexedDB.
Conversations are not stored on Anthropic's servers, are not synced
across devices, and can be cleared from Settings at any time.
Reinstalling the add-in or switching between Claude add-ins does not
remove it. See [Data storage and retention](/docs/office-agents/data-storage)
for where it sits on disk and how long it is kept.

Claude for PowerPoint does not inherit custom data retention settings
your organization might have set. Activity is not included in Enterprise
audit logs or the Compliance API.

## Current limitations

Claude for PowerPoint is not recommended for:

* Final client deliverables without human review.
* Presentations containing highly sensitive or regulated data without
proper controls.
* Replacing your judgment on design and narrative flow.

### Unsupported versions

The add-in does not run on these PowerPoint versions.

* PowerPoint 2016 and 2019 perpetual or volume license.
* PowerPoint on iPad.
* PowerPoint on Android.
* Older builds of Microsoft 365 PowerPoint below the SharedRuntime
threshold.

## Prompt injection risk

<Warning>
Only use Claude for PowerPoint with trusted files. Files from external
sources can contain hidden instructions that manipulate the add-in into
extracting data, modifying records, or performing destructive actions.
</Warning>

External files such as downloaded templates, vendor files,
collaborative documents, and data imports can contain prompt injections that try to trick

Cut at 300 lines. The page has the rest.

office-agents/third-party-platforms First recorded · 792 lines, first recorded

# Use Claude for M365 with third-party platforms ## Connection paths ## Requirements by connection path ## Network allowlist ### Anthropic API (1P) ### Third-party platforms (3P) ## Deploy the add-in for your organization ### Run the setup wizard ### Available commands ### What the wizard provisions ### Per-user configuration ### Deploy to Outlook ### Deploy to Microsoft 365 ## Connection instructions for end users ### LLM gateway ### Bedrock, Vertex AI, or Foundry direct ### Change or update your gateway connection ## Gateway requirements for IT teams ### CORS requirements ### Required endpoints ### Required header ### Authorization header ### Model discovery ### Differences from Claude Code gateway setup ## Example gateway configuration with LiteLLM ### Route to Anthropic directly ### Route to Amazon Bedrock ### Route to Google Cloud Vertex AI ### Route to Azure ## What Anthropic collects ## Why sign-in redirects through pivot.claude.ai ### OAuth authorization-code redirects ### Why the redirect cannot target localhost ### Microsoft admin-consent redirects ### Verify this in your own environment ## Differences from signing in with a Claude account ## Troubleshooting ### "Connection refused" or network error ### 401 Unauthorized or "Invalid token" ### 403 Forbidden or "Access denied" ### 404 Not found ### 500 or other server errors ### "No models available" ### Streaming responses fail or hang ### A feature I expected is not available

The first capture of this source. The page was already there, and this is what it said.

# Use Claude for M365 with third-party platforms

> Deploy the Office add-ins through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway, without individual Claude accounts.

Organizations using Amazon Bedrock, Google Cloud Vertex AI, Azure AI
Foundry, or an LLM gateway can deploy Claude's Office add-ins without
requiring individual Claude accounts. The add-in connects through your
organization's infrastructure, keeping prompts and responses within your
trust boundary.

## Connection paths

Four connection paths are available. Your IT admin selects one during
deployment. End users see the same interface regardless.

| Path             | How it works                                                                                                                               |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| LLM gateway      | Requests route through your gateway (LiteLLM, Portkey, Kong, and others) to your chosen provider. Matches the pattern used by Claude Code. |
| Bedrock direct   | The add-in authenticates via Microsoft Entra ID and calls Amazon Bedrock directly without intermediaries.                                  |
| Vertex AI direct | The add-in authenticates through Google OAuth and calls Vertex AI directly.                                                                |
| Foundry direct   | The add-in authenticates directly to your Azure AI Foundry resource using its API key.                                                     |

## Requirements by connection path

All paths need:

* Claude for Excel, PowerPoint, Word, or Outlook installed from
  Microsoft AppSource or via admin deployment.
* Microsoft 365 with Entra ID for admin consent and token issuance.
* For Outlook: Microsoft Graph admin consent for `Mail.ReadWrite`,
  `Calendars.Read`, `User.Read`, and `offline_access`, granted via
  Anthropic's app or your own Entra app registration.

| Path             | Additional requirements                                                                                                                                                                                                                                 |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| LLM gateway      | Gateway URL and API token from your IT team.                                                                                                                                                                                                            |
| Bedrock direct   | AWS account with Claude model access enabled in target region. IAM OIDC identity provider and role configured to trust Microsoft Entra ID tokens.                                                                                                       |
| Vertex AI direct | Google Cloud project with Vertex AI API enabled and Claude model access. Google OAuth client configured with the add-in's redirect URI.                                                                                                                 |
| Foundry direct   | Azure AI Foundry resource with at least one Claude model deployed. Deployment names must use default model IDs (for example, `claude-opus-4-6`), not custom names. Resource API key from Azure Portal, your Foundry resource, Keys and Endpoint, KEY 1. |

Your organization's IT team manages these resources. Anthropic cannot
provide or reset credentials.

## Network allowlist

The add-in requires access to specific domains. The required domains
differ depending on whether your organization uses the Anthropic API
directly (1P) or a third-party platform (3P).

<Note>
  In all configurations, prompts and responses travel only to your chosen
  inference provider. Domains pointing to Anthropic (such as
  `pivot.claude.ai`) serve the add-in's interface, feature configuration,
  and operational telemetry, not prompt or response content.
</Note>

### Anthropic API (1P)

Use this table if your organization signs in with Claude accounts and
inference goes to `api.anthropic.com`.

| Domain                         | Required when             | Purpose                                                                                    |
| ------------------------------ | ------------------------- | ------------------------------------------------------------------------------------------ |
| `pivot.claude.ai`              | Always                    | Add-in host serving task pane UI, analytics, icon search, skill downloads, and telemetry.  |
| `claude.ai`                    | Always                    | Anthropic OAuth sign-in and feature-flag evaluation.                                       |
| `api.anthropic.com`            | Always                    | Claude inference API, file uploads, code-execution containers, and MCP connector registry. |
| `appsforoffice.microsoft.com`  | Always                    | Microsoft Office.js runtime script (required by all Office add-ins).                       |
| `login.microsoftonline.com`    | If using Outlook          | Microsoft Entra ID sign-in via Nested App Auth for the Graph token.                        |
| `o1158394.ingest.us.sentry.io` | Optional                  | Crash and error reporting; blocking degrades diagnostics only.                             |
| `mcp-proxy.anthropic.com`      | If using MCP connectors   | Proxy for MCP connector tool calls.                                                        |
| `bridge.claudeusercontent.com` | If using work across apps | WebSocket bridge for the work-across-apps feature.                                         |
| `graph.microsoft.com`          | If using Outlook          | Microsoft Graph mailbox and calendar API.                                                  |

### Third-party platforms (3P)

Use this table if your organization signs in with Microsoft Entra ID
and inference goes to your LLM gateway, Bedrock, Vertex AI, or Azure
AI Foundry.

| Domain                                   | Required when             | Purpose                                                                               |
| ---------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------- |
| `pivot.claude.ai`                        | Always                    | Add-in host serving task pane UI, analytics, and telemetry.                           |
| `claude.ai/api/`                         | Always                    | Feature-flag evaluation without sign-in.                                              |
| `appsforoffice.microsoft.com`            | Always                    | Microsoft Office.js runtime script.                                                   |
| `login.microsoftonline.com`              | Always                    | Microsoft Entra ID sign-in via Nested App Auth; reads admin config and issues tokens. |
| `o1158394.ingest.us.sentry.io`           | Optional                  | Crash and error reporting; blocking degrades diagnostics only.                        |
| Your LLM gateway URL                     | If using LLM gateway      | Organization's LLM gateway for inference.                                             |
| `sts.amazonaws.com`                      | If using Bedrock direct   | AWS STS for exchanging Entra ID token for temporary Bedrock credentials.              |
| `bedrock-runtime.<region>.amazonaws.com` | If using Bedrock direct   | Bedrock inference endpoint; replace `<region>` with your configured AWS region.       |
| `accounts.google.com`                    | If using Vertex AI direct | Google OAuth consent screen.                                                          |
| `oauth2.googleapis.com`                  | If using Vertex AI direct | Google OAuth token exchange and refresh.                                              |
| `aiplatform.googleapis.com`              | If using Vertex AI direct | Vertex AI global inference endpoint.                                                  |
| `<region>-aiplatform.googleapis.com`     | If using Vertex AI direct | Vertex AI regional inference endpoint; replace `<region>` with your GCP region.       |
| `<resource>.services.ai.azure.com`       | If using Foundry direct   | Azure AI Foundry inference endpoint; replace `<resource>` with your resource name.    |
| `graph.microsoft.com`                    | If using Outlook          | Microsoft Graph mailbox and calendar API.                                             |

## Deploy the add-in for your organization

Use the `claude-for-msft-365-install` plugin to configure and deploy the add-in
across your organization. The plugin provisions cloud resources (for
Bedrock or Vertex AI direct), generates the add-in manifest, and obtains
admin consent in a single guided flow.

### Run the setup wizard

[Install the plugin](https://github.com/anthropics/financial-services/tree/main/claude-for-msft-365-install)
from the financial services marketplace, then run the setup wizard
from inside Claude.

Add the marketplace in your shell:

```bash theme={null}
claude plugin marketplace add anthropics/financial-services
```

Install the plugin:

```bash theme={null}
claude plugin install claude-for-msft-365-install@claude-for-financial-services
```

Keep the plugin current before each deployment. List installed plugins
with `claude plugin list` and compare your version against the
[latest published version](https://github.com/anthropics/financial-services/blob/main/claude-for-msft-365-install/.claude-plugin/plugin.json).
If yours is older, update it:

```bash theme={null}
claude plugin update claude-for-msft-365-install@claude-for-financial-services
```

Then, from inside Claude, run the setup wizard:

```
/claude-for-msft-365-install:setup
```

The wizard walks you through the path you chose:

* **LLM gateway**: collects the gateway URL and token, determines the
  API format, generates the manifest, handles Azure admin consent.
* **Bedrock direct**: creates the IAM OIDC identity provider and role,
  generates the manifest, handles Azure admin consent.
* **Vertex AI direct**: walks through Google OAuth client creation,
  generates the manifest, handles Azure admin consent.
* **Foundry direct**: captures `azure_resource_name` and
  `azure_api_key`, then generates the manifest.

When complete, the add-in is ready for tenant-wide deployment.

<Note>
  Bedrock and Vertex AI paths require Node.js for manifest generation and
  validation. The wizard checks for it and prompts installation if
  missing.
</Note>

### Available commands

The plugin exposes the following slash commands once installed.

| Command                                          | Function                                                                                                                                                                                      |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/claude-for-msft-365-install:setup`             | Interactive wizard: provisions cloud resources, handles admin consent, writes manifest.                                                                                                       |
| `/claude-for-msft-365-install:manifest`          | Generates a customized add-in manifest XML.                                                                                                                                                   |
| `/claude-for-msft-365-install:consent`           | Generates the Azure admin-consent URL for the add-in's app registration.                                                                                                                      |
| `/claude-for-msft-365-install:update-user-attrs` | Writes per-user configuration via Microsoft Graph extension attributes.                                                                                                                       |
| `/claude-for-msft-365-install:bootstrap`         | Builds a bootstrap endpoint for per-user MCP servers, skills, and dynamic config.                                                                                                             |
| `/claude-for-msft-365-install:debug`             | Diagnoses deployment issues: stale config after a manifest update, connection failures, an add-in that does not appear, sign-in or admin-consent loops, and reading the add-in's error paste. |
| `/claude-for-msft-365-install:export-data`       | Makes a read-only copy of a user's chat history, skills, connector registrations, and settings before a device is rebuilt. See [Data storage and retention](/docs/office-agents/data-storage).     |

Run `/claude-for-msft-365-install:debug` whenever a connection or sign-in
does not behave as expected. It triages from the symptom, reads the "Copy
error details" paste from the connection-failed screen, and explains how
each connection path works, so you can resolve most third-party platform
questions without escalating.

### What the wizard provisions

The setup wizard creates resources in your cloud account based on the
connection path you choose.

| Path             | Provisioned resources                                                                                                                                                                                              |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| LLM gateway      | None. Collects your gateway URL and token, then generates the manifest.                                                                                                                                            |
| Bedrock direct   | IAM OIDC identity provider trusting Microsoft Entra ID tokens, role with `bedrock:InvokeModel` and `bedrock:InvokeModelWithResponseStream` permissions, trust policy scoped to the Claude add-in's application ID. |
| Vertex AI direct | Walks through creating a Google OAuth client in the GCP Console (not automatable via CLI), enables the Vertex AI API, captures client ID and secret for the manifest.                                              |
| Foundry direct   | None. Collects resource name and API key for the manifest.                                                                                                                                                         |

### Per-user configuration

If values vary per user, such as different gateway tokens or AWS roles
for different teams, run `/claude-for-msft-365-install:update-user-attrs`
with per-user keys after initial setup to write configuration via
Microsoft Graph extension attributes.

At load, the add-in resolves each configuration key from three sources in
order of precedence: a bootstrap endpoint, Microsoft Entra ID extension
attributes, then manifest parameters. Per-user attributes override the
manifest defaults, so one deployed manifest can serve teams with
different settings.

<Frame caption="Configuration resolution at add-in load: bootstrap, Entra ID attributes, then manifest parameters.">
  <img src="https://mintcdn.com/claude-ai/-4jzPa4NasvobarI/images/office-agents/architecture/config-discovery.png?fit=max&auto=format&n=-4jzPa4NasvobarI&q=85&s=b6c750272cf3ad9765ec2563af436806" alt="The add-in resolves each configuration key from a bootstrap endpoint, then Entra ID extension attributes, then manifest parameters." width="2398" height="1670" data-path="images/office-agents/architecture/config-discovery.png" />
</Frame>

### Deploy to Outlook

Outlook requires a separate manifest file from Excel, PowerPoint, and
Word. Microsoft uses a different add-in schema for mail applications, so
the two cannot be combined into one file. When you tell the setup wizard
you are deploying to Outlook, it generates a second file named
`manifest-outlook.xml` alongside `manifest.xml`. Upload each file as its
own custom app in the steps below.

Claude for Outlook reads mail and calendar data through Microsoft Graph,
which requires a one-time tenant-wide grant from a Global Administrator
regardless of which platform serves the model. Complete the
[Microsoft Graph admin consent](/docs/office-agents/outlook#grant-microsoft-graph-consent)
step before deployment so users are not prompted individually. The Graph
token stays in the user's Outlook client and is never sent to your
gateway or to Anthropic.

If your organization's policy does not permit consenting to a third-party
multi-tenant application, register your own single-tenant Entra
application with the same delegated Graph permissions and provide its
client ID to the setup wizard as `graph_client_id`. See
[Use your own Entra app instead](/docs/office-agents/outlook#use-your-own-entra-app-instead).

<Note>
  Claude for Outlook on third-party platforms supports Claude Opus 4.7 and
  later and Claude Sonnet 5 and later. Earlier model generations are not
  available on the Outlook surface.
</Note>

### Deploy to Microsoft 365

After the wizard generates your manifest files:

<Steps>
  <Step title="Upload the manifest">
    Open the Microsoft 365 Admin Center and go to Settings, Integrated
    apps, Upload custom apps. Select "Office Add-in" as the app type,
    then upload the `manifest.xml` file. If you are deploying Outlook,
    repeat this step with `manifest-outlook.xml` as a second custom app.
  </Step>

  <Step title="Choose who gets the add-in">
    If all users share the same configuration, select "Entire
    organization". If you wrote per-user attributes, assign to "Specific
    users/groups" matching exactly who was configured. Others would open
    the add-in with no configuration.
  </Step>

  <Step title="Finish deployment">
    Accept permissions and finish deployment.
  </Step>
</Steps>

Propagation to users takes up to 24 hours, usually faster. The add-in
appears under Tools, Add-ins on Mac or Home, Add-ins on Windows in
Excel, PowerPoint, and Word once deployed. In Outlook it appears in the
message ribbon when an email is open.

Custom manifest deployment is where most issues surface: the add-in does
not appear, users see old configuration after an update, or sign-in
fails. Run `/claude-for-msft-365-install:debug` to diagnose these, or to
sideload and validate a manifest locally before a tenant-wide upload.

<Note>
  Start with a pilot group to confirm functionality, then widen
  assignment. You can change assignment later without redeploying.
</Note>

## Connection instructions for end users

### LLM gateway

<Steps>
  <Step title="Open the add-in">
    Open Excel, PowerPoint, Word, or Outlook and launch the Claude add-in.
  </Step>

  <Step title="Select your connection mode">
    On the sign-in screen, select "Cloud provider or gateway". Then
    choose your connection: Gateway, Vertex, Bedrock, or Azure. Contact
    your IT team for connection details if you're unsure which one to
    select.
  </Step>

  <Step title="Enter your credentials">
    For Gateway, enter the gateway URL (HTTPS base URL of your LLM
    proxy, for example
    `https://llm-gateway.example.com`) and the API token your IT team
    provided. By default the add-in sends the token in the `x-api-key`
    header with every request. If your admin set
    `gateway_auth_header: authorization` in the manifest, the add-in
    sends `Authorization: Bearer <token>` instead.
  </Step>

  <Step title="Connect">
    The add-in checks the connection by sending a test request to the

Cut at 300 lines. The page has the rest.

office-agents/word First recorded · 428 lines, first recorded

# Use Claude for Word ## What you can do ## Get started with Claude for Word ### Supported versions ### Install for yourself ### Deploy to your organization ### Deploy with a custom manifest ### Connect through a third-party platform ## Key features ### Read and understand documents ### Edit selected text ### Tracked changes mode ### Comment-driven editing ### Summarize counterparty redlines ### Fill templates ### Semantic navigation ## Connectors and Skills ## Set persistent instructions ## Work across M365 apps ## Context and session management ## Models available ## Data handling ## Current limitations ### Unsupported versions ## Prompt injection risk ## Best practices ## Example use cases ### Legal contract review ### Finance memo drafting ### Document QA and consistency ### General document editing

The first capture of this source. The page was already there, and this is what it said.

# Use Claude for Word

> A Word add-in that integrates Claude into your document workflow, for Pro, Max, Team, and Enterprise plans.

Claude for Word is an add-in that brings Claude into Word. Ask questions
about your document with clickable section citations, edit selected
passages while preserving formatting, review counterparty redlines,
work through comment threads, and fill templates in your document's
styles.

<Note>
Claude for Word is generally available to Pro, Max, Team,
and Enterprise plans.
</Note>

## What you can do

With Claude for Word, you can:

* Ask questions about your document and get answers with clickable
section citations.
* Edit selected text while preserving surrounding styles, numbering,
and formatting.
* Use tracked changes mode so every edit lands as a revision you can
accept or reject in Word's native review pane.
* Have Claude work through comment threads, editing the anchored text
and replying with what it changed.
* Summarize counterparty redlines and flag the revisions worth pushing
back on.
* Fill templates with drafted content that inherits your document's
heading and paragraph styles.
* Find every provision touching a theme with semantic navigation, not
just keyword search.

## Get started with Claude for Word

### Supported versions

Claude for Word runs on the following Word builds.

* Word on the web
* Word on Windows with a Microsoft 365 subscription, Version 2205,
build 15202.10000 or later
* Word on Mac, version 16.61, build 22040100 or later

### Install for yourself

<Step title="Install the add-in">
Select "Get it now" to install.
</Step>

<Step title="Sign in">
Open Word, activate the add-in, and sign in with your Claude
account.
</Step>
</Steps>

### Deploy to your organization

Organization admins can deploy Claude for Word through the Microsoft
365 Admin Center.

<Step title="Open Integrated apps">
Go to Settings, Integrated apps, Add-ins.
</Step>

<Step title="Find the add-in">
Search for "Claude for Microsoft 365" in Microsoft AppSource.
</Step>

After deployment, users can activate the Claude add-in from Tools,
Add-ins on Mac or Home, Add-ins on Windows, sign in, and start working.

### Deploy with a custom manifest

For IT administrators deploying to multiple users when the Office Store
is disabled:

<Steps>
<Step title="Download the manifest">
Download the [custom manifest XML file](https://pivot.claude.ai/manifest-word.xml)
and save it to a secure location.
</Step>

<Step title="Open the Admin Center">
Go to [https://admin.microsoft.com](https://admin.microsoft.com),
sign in, and open Settings, Integrated apps.
</Step>

<Step title="Upload the custom add-in">
Select "Upload custom apps", choose "Office Add-in", then
"I have a manifest file on this device". Upload the manifest.
</Step>

<Step title="Assign users">
Choose entire organization, specific users, specific groups, or just
yourself for admin testing.
</Step>

<Step title="Deploy">
Review settings and select "Deploy". The add-in is available within
minutes. Full organization rollout can take up to 24 hours.
</Step>
</Steps>

After deployment, users see Claude in Word's Home ribbon and sign in
with their Claude credentials on first use.

### Connect through a third-party platform

## Key features

### Read and understand documents

Ask Claude questions about specific sections, clauses, or defined terms
in your document. Claude provides answers with clickable citations that
navigate directly to the referenced section.

<Note>
Claude recognizes common document patterns including multi-level legal
numbering, defined terms, cross-references, and standard contract
structures. Verify that outputs match your specific requirements and
your firm's standard positions.
</Note>

Example prompts:

* "What's the liability cap and is it mutual?"
* "Summarize the key commercial terms in this agreement."
* "What assumptions drive the revenue forecast in section 3?"

### Edit selected text

Select a passage and tell Claude what to change. Claude edits only the
selection while preserving surrounding styles, numbering, and
formatting. New text inherits the paragraph style, font, and numbering
of the surrounding content.

Example prompts:

* "Tighten this paragraph and drop the passive voice."
* "Rewrite this clause to make the indemnification mutual."
* "Simplify this section for a non-technical audience."

### Tracked changes mode

When you enter tracked changes mode, Claude's edits land as tracked
revisions. The original text is visible as a deletion and the new text
as an insertion, all reviewable in Word's native review pane. Review
every edit before accepting it, and undo with Word's standard Ctrl+Z
on Windows or Cmd+Z on Mac if you want to revert.

Example prompts:

* "Rewrite section 4.2 to cap damages at 12 months of fees, and make it
mutual."
* "Draft a mutual indemnification clause after section 8."

### Comment-driven editing

Claude reads comment threads in your document, understands what text
each thread is anchored to, and can work through them one by one. For
each comment, Claude edits the anchored passage and replies to the
thread with a note explaining what it did.

Example prompts:

* "Work through my open comments."
* "Address the comment on the liability section."

### Summarize counterparty redlines

When a counterparty returns a document with tracked changes, Claude can
read and summarize what they changed. Ask Claude to group changes by
severity or flag the ones worth pushing back on.

Example prompts:

* "Summarize what the other side changed and flag anything that's worth
discussing."
* "Which of these redlines are dealbreakers?"

### Fill templates

Draft sections in your document's heading and paragraph styles. Claude
uses your template's formatting when generating content, so new
headings, bullets, and table entries match what's already there. Tables
populate in place without reflowing layout or changing column widths.

Example prompts:

* "Draft the Key Risks section with four risks in the template's style."
* "Populate the summary table with revenue, gross margin, and net
retention for the last three years."

### Semantic navigation

Find every provision or passage in your document that touches a
specific theme. Claude returns thematic matches, not just keyword hits,
and each result navigates to the relevant location on click.

Example prompts:

* "Find every provision touching data retention."
* "Where does this agreement address termination?"

## Connectors and Skills

Claude for Word supports connectors for pulling external context into
your document, and Skills for applying reusable task recipes. See
[Connectors and Skills](/docs/office-agents/connectors-and-skills) for
details.

## Set persistent instructions

Open Settings in the add-in sidebar and use the Instructions field to
set preferences that
apply to every conversation in Word. Instructions are useful for tone
and style conventions such as "use formal tone" or "follow APA citation
style", document structure preferences, or recurring context about your
workflow.

Instructions you set in Word only apply to Word. They are separate from
Instructions you set in Excel or PowerPoint.

## Work across M365 apps

Claude for Word shares context with Claude for Excel, PowerPoint, and
Outlook, so a single conversation can span your open document,
workbook, deck, and inbox. See
[Work across M365 apps](/docs/office-agents/work-across-apps).

## Context and session management

The add-in handles long sessions for you so a single conversation can
span an entire workflow.

Your use of Claude for Word is associated with your existing Claude
account and is subject to the same usage limits.

## Models available

Cut at 300 lines. The page has the rest.

office-agents/work-across-apps First recorded · 151 lines, first recorded

# Work across M365 apps ## Requirements ## Enable cross-app mode ## How it works ## What you can do ### Read and write across open apps ### Pass context between apps ## Skills work across apps ## Manage access as an admin ## Data handling ## Current limitations ## Troubleshooting ### Claude doesn't see my open file ### Changes aren't appearing in the other app

The first capture of this source. The page was already there, and this is what it said.

# Work across M365 apps

> Let Claude read from one Microsoft 365 app and make changes in another in a single conversation.

Claude can coordinate between the Excel, PowerPoint, Word, and Outlook
add-ins in your Microsoft 365 suite. Instead of switching between apps
and re-providing context each time, Claude can read from one app and
make changes in another.

<Note>
Working across apps is available when you sign in with your Claude
account directly. It is not supported when connecting through Amazon
Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway.
</Note>

## Requirements

Install each Claude for M365 add-in and confirm your plan before turning
on cross-app mode.

* A paid Claude plan: Pro, Max, Team, or Enterprise.
* [Claude for Excel](/docs/office-agents/excel) installed from the
Microsoft AppSource.
* [Claude for PowerPoint](/docs/office-agents/powerpoint) installed
from the Microsoft AppSource.
* [Claude for Word](/docs/office-agents/word) installed from the
Microsoft AppSource.
* [Claude for Outlook](/docs/office-agents/outlook) installed from the
Microsoft AppSource.

## Enable cross-app mode

<Steps>
<Step title="Install each add-in">
Install Claude for Excel, PowerPoint, Word, and Outlook from the
Microsoft AppSource. Open each app and activate the add-in at
least once before using cross-app features.
</Step>

<Step title="Enable per add-in">
Open Settings in each add-in and turn on "Let Claude work across
files". Pro and Max plans have this on by default; Team and
Enterprise plans default to off. The toggle is per-device, so enable
it in every host you want to coordinate from.
</Step>
</Steps>

Once enabled, connected-app indicators appear in the sidebar when other
Excel, PowerPoint, Word, or Outlook sessions are linked.

## How it works

When you describe a task that involves multiple files or apps, Claude
coordinates automatically:

* Claude uses the Excel, PowerPoint, Word, and Outlook add-ins to read
from and write to open files and email threads.
* Context transfers between apps automatically, so you don't need to
copy and paste information manually.

You stay in one place while Claude does the switching.

## What you can do

### Read and write across open apps

Claude can read data from an open Excel workbook, PowerPoint
presentation, Word document, or Outlook email thread, and make changes
to them directly. For example:

* Pull numbers from an Excel model into a PowerPoint slide or a Word
memo.
* Update a chart in PowerPoint with the latest figures from Excel.
* Read content from a presentation and use it to populate a spreadsheet.
* Summarize a Word document into PowerPoint slides.
* Draft a Word memo using data from an Excel workbook.
* Open an attached letter of intent in Word with the Outlook thread
already loaded as context.
* Pull figures from an email thread into an open Excel model.

### Pass context between apps

Claude carries relevant context forward when working across multiple
files. If you've been building a financial model in Excel and ask Claude
to create a summary deck or draft an investment memo, Claude already
understands the model's structure and key outputs, so you don't need to
re-explain.

## Skills work across apps

Skills you've enabled in your Claude settings apply when Claude is
working in Excel, PowerPoint, Word, or Outlook during a cross-app task. If you
have a Skill that enforces your team's modeling conventions in Excel and
another that matches your slide template in PowerPoint, Claude uses each
one in the right app as it moves through the workflow.

For more on Skills, see
[Use Skills in Claude](https://support.claude.com/en/articles/12512180-use-skills-in-claude).

## Manage access as an admin

Team and Enterprise organization owners can control whether team members
can access this capability.

<Steps>
<Step title="Open organization settings">
Go to Organization settings, Office agents.
</Step>

<Step title="Toggle the setting">
Turn "Let Claude work across apps" on or off.
</Step>
</Steps>

Admins can also manage member access to the Claude for Excel,
PowerPoint, Word, and Outlook add-ins through the Microsoft 365 Admin
Center.

## Data handling

Inputs and outputs are deleted from Anthropic's backend within 30 days
of receipt or generation, except in cases outlined in
[How long do you store my organization's data?](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data).

The Claude for M365 add-ins do not inherit custom data retention
settings your organization may have set, and activity is not included in
Enterprise audit logs, the Compliance API, or data exports. Chat history
is stored locally in your browser, not on Anthropic's servers, and can
be cleared from Settings at any time.

## Current limitations

* Claude can only read from and write to files that are currently open
in Excel, PowerPoint, or Word, and the email or event currently open
in Outlook.
* Claude cannot create, open, close, or switch files directly. The files
and add-ins must be open with the feature turned on.

## Troubleshooting

### Claude doesn't see my open file

Make sure the add-in is activated in the app (Tools, Add-ins on Mac or
Home, Add-ins on Windows) and that working across apps is turned on in
the add-in settings.

### Changes aren't appearing in the other app

Claude works on open files in sequence. Wait for Claude to finish its
current action, then check the target file. You may need to ask Claude
to refresh or re-read the file.

plugins/overview First recorded · 85 lines, first recorded

# Plugins overview ## What plugins do ## Plugin directory ## Origins in Claude Code ## Plugins in Cowork ## How plugins compose capabilities ## Availability ## Next steps

The first capture of this source. The page was already there, and this is what it said.

# Plugins overview

> Extend Claude with reusable capability packages that bundle MCP connectors, skills, slash commands, and sub-agents

Plugins are reusable capability packages that extend Claude with custom functionality. They bundle together [MCP connectors](/docs/connectors/overview), [skills](/docs/skills/overview), slash commands, and sub-agents into a single shareable unit — turning Claude into a specialist tailored to your role, team, and company.

## What plugins do

Plugins let you define how you like work done, which tools and data to pull from, how to handle critical workflows, and what slash commands to expose so your team gets consistent outcomes. Every component is file-based, so plugins are easy to build, edit, and share.

As your team builds and shares plugins, Claude becomes a cross-functional expert. Best practices get baked into every interaction, so leaders and admins can spend less time enforcing processes and more time improving them.

## Plugin directory

To help you get started, Anthropic has open-sourced 11 plugins built and used internally:

| Plugin                 | What it does                                                  |
| ---------------------- | ------------------------------------------------------------- |
| **Productivity**       | Manage tasks, calendars, and daily workflows                  |
| **Enterprise search**  | Find information across your company's tools and docs         |
| **Sales**              | Research prospects, prep deals, and follow your sales process |
| **Finance**            | Analyze financials, build models, and track key metrics       |
| **Data**               | Query, visualize, and interpret datasets                      |
| **Legal**              | Review documents, flag risks, and track compliance            |
| **Marketing**          | Draft content, plan campaigns, and manage launches            |
| **Customer support**   | Triage issues, draft responses, and surface solutions         |
| **Product management** | Write specs, prioritize roadmaps, and track progress          |
| **Biology research**   | Search literature, analyze results, and plan experiments      |
| **Plugin Create**      | Create and customize new plugins from scratch                 |

Browse the full collection at [claude.com/plugins](https://claude.com/plugins-for/cowork) or use the Plugin Create plugin to build your own.

## Origins in Claude Code

Plugins originated in [Claude Code](https://code.claude.com/docs/en/plugins), where developers create and distribute them as versioned, shareable directories. A Claude Code plugin lives in a directory with a manifest (`plugin.json`) that defines its identity, version, and available components.

<Note>
  For technical details on plugin structure, manifests, and configuration, see the [Claude Code plugins reference](https://code.claude.com/docs/en/plugins-reference).
</Note>

## Plugins in Cowork

Plugins are fully supported in [Cowork](https://support.claude.com/en/articles/13345190-getting-started-with-cowork), Anthropic's agentic workspace for complex, multi-step knowledge work. In Cowork, Claude runs inside an isolated virtual machine environment, executes tasks in parallel workstreams, and writes outputs directly to your file system — and plugins extend all of that capability.

A sales plugin, for example, could connect Claude to your CRM and knowledge base, teach it your sales process, and give you slash commands for everything from prospect research to call follow-ups. You define what goes in the plugin once, and Claude pulls from that context whenever it's relevant.

## How plugins compose capabilities

| Plugin component   | What it adds                                                      | Example                                                                         |
| ------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| **Skills**         | Specialized instructions Claude follows when relevant tasks arise | A "brand voice" skill that activates when drafting external communications      |
| **MCP connectors** | Access to external tools and data                                 | A connector to a CRM that lets Claude read and update deal records              |
| **Slash commands** | Explicit, user-triggered workflows                                | `/sales:prospect-research` to kick off a structured research workflow           |
| **Sub-agents**     | Delegated workstreams that run in parallel                        | A sub-agent that handles competitive analysis while another drafts the proposal |

## Availability

Plugin support in Cowork is available as a beta for all paid Claude users. Plugins are currently saved locally to your machine. Org-wide sharing and management are coming in the weeks ahead.

| Platform          | Plugin support                                                     |
| ----------------- | ------------------------------------------------------------------ |
| **Claude Code**   | Full plugin support — create, install, and use plugins             |
| **Claude Cowork** | Full plugin support — plugins extend agentic, multi-step workflows |

Looking to submit your own plugin? See [Submitting your plugin](/docs/plugins/submit#submitting-your-plugin).

## Next steps

<Columns cols={2}>
  <Card title="Plugin directory" icon="grid-2" href="https://claude.com/plugins-for/cowork">
    Browse the full plugin collection.
  </Card>

  <Card title="Create plugins" icon="code" href="https://code.claude.com/docs/en/plugins">
    Build and distribute plugins in Claude Code.
  </Card>

  <Card title="Skills overview" icon="sparkles" href="/docs/skills/overview">
    Learn how skills work as a core plugin component.
  </Card>

  <Card title="Connectors overview" icon="plug" href="/docs/connectors/overview">
    Understand MCP connectors that plugins can bundle.
  </Card>
</Columns>

plugins/submit First recorded · 86 lines, first recorded

# Submitting your plugin ## Getting your plugin to users ## Plugin Directory: Community vs. Anthropic Verified ## What makes a good plugin ### Guiding Claude through MCP setup ### Using safe MCP connectors in plugins ## Directory terms & conditions ## Security ## Submitting your plugin ### Before you start

The first capture of this source. The page was already there, and this is what it said.

# Submitting your plugin

> Submit your plugin to the plugin directory for Cowork

The [plugin directory](https://claude.com/plugins-for/cowork) is a community-driven directory where developers can submit plugins for use in Cowork and Claude Code. In Claude Code, this directory is surfaced as the official `claude-plugins-official` marketplace and is automatically available to all users — see [Discover and install plugins](https://code.claude.com/docs/en/discover-plugins#official-anthropic-marketplace). This is a separate and complementary directory from the [Connectors Directory](/docs/connectors/directory), which is specific to MCP connectors.

## Getting your plugin to users

Once you've built a plugin, there are several ways to get it to users:

1. **Direct install** — You can install specific plugins yourself, or guide select users to install them. This is the simplest path for internal tools or small teams.
2. **Your own plugin marketplace** — You can serve your own [plugin marketplace](https://code.claude.com/docs/en/plugin-marketplaces), which allows a subset of opted-in users to access any plugin you share. This is a great fit for enterprise contexts or communities with shared tasks. See the [Claude Code docs on sharing a marketplace](https://code.claude.com/docs/en/plugin-marketplaces) for setup instructions.
3. **[Submit to the Claude plugin directory](#submitting-your-plugin)** — You can submit to the Claude plugin directory, which is made available to all users of Cowork and Claude Code.

## Plugin Directory: Community vs. Anthropic Verified

Plugins are submitted by developers and creators in the community. Anthropic performs basic automated review on submissions before adding them to the directory. Plugins with an "Anthropic Verified" badge have undergone additional review from a quality and safety perspective. That said, there are limits to what Anthropic is able to review — you should only install plugins from developers you trust.

There are no guarantees that any community plugin will become Anthropic Verified.

<Warning>
Exercise caution when installing community plugins. Always review a plugin's permissions, connected services, and data access before use.
</Warning>

## What makes a good plugin

The best plugins bundle related capabilities together into a coherent package that solves a specific job function or workflow end-to-end. Rather than exposing a single tool, a good plugin combines skills, connectors, slash commands, and sub-agents so Claude has everything it needs to handle a category of work.

For example, a sales plugin might bundle a CRM connector, a skill that teaches Claude your sales process, slash commands for common tasks like prospect research and call follow-ups, and a sub-agent that handles competitive analysis in parallel. Together, these components make Claude a specialist — individually, they're just building blocks.

Plugins can include any combination of:

* **Skills** — Task-specific instructions that Claude activates dynamically based on context
* **MCP connectors** — Connections to external tools and data sources. Plugins can contain any MCP, including remote MCPs, local MCPs, and MCPBs. The MCP configuration within a plugin is highly customizable.
* **Slash commands** — User-invoked commands for triggering specific workflows
* **Sub-agents** — Custom agent definitions for delegating complex work

### Guiding Claude through MCP setup

Plugins can include a `SETUP.md` skill to guide Claude through configuring and connecting any MCP servers bundled in the plugin. This lets you define step-by-step setup instructions that Claude follows when a user installs or activates your plugin.

### Using safe MCP connectors in plugins

While a plugin can include any MCP of any kind in its `.mcp.json` definition, we strongly encourage using connectors that already exist in the [Connectors Directory](/docs/connectors/directory) or come from well-known developers. This will increase the likelihood of verification and will reduce the number of warnings shown to users.

## Directory terms & conditions

All plugins in the directory must comply with:

* [Anthropic Software Directory Terms](https://support.claude.com/en/articles/13145338-anthropic-software-directory-terms)
* [Anthropic Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy)

## Security

Each plugin in the directory includes a link to where you can review its contents before installing. Plugins are capable of loading remote MCP servers, local MCP servers, and other local software tools to assist you in doing work. You should review any additional software that may be installed by a plugin, as community plugins may install unverified, third-party software that could be malicious or result in unintended behavior.

Best practices when using community plugins:

* Review the plugin's source code before installing
* Check which MCP connectors are included and what permissions they request
* Prefer Anthropic Verified plugins for production workflows
* Report any suspicious activity to Anthropic

## Submitting your plugin

To submit a plugin to the directory, share a GitHub link to your plugin. The repo must be public—closed-source plugins are not accepted.

Before submitting, run `claude plugin validate` to check formatting and structure. Review times vary with queue volume.

### Before you start

Both submission forms require you to be signed in with sufficient permissions:

* **claude.ai** requires a Team or Enterprise organization and directory management access. Organization Owners have this by default; on Enterprise, an Owner can delegate it through a custom role, as described in the [connector submission access requirements](/docs/connectors/building/submission#before-you-start).
* **Console** requires a Developer, Admin, or Owner role on a Console organization. Individual authors who aren't part of a claude.ai Team or Enterprise organization can sign up for Console at [platform.claude.com](https://platform.claude.com) and submit there.

To submit please use one of our in-app submission forms:

* **Claude.ai** — [https://claude.ai/admin-settings/directory/submissions/plugins/new](https://claude.ai/admin-settings/directory/submissions/plugins/new)
* **Console** — [https://platform.claude.com/plugins/submit](https://platform.claude.com/plugins/submit)

After your plugin is published, updates pushed to your GitHub repo are picked up automatically—CI mirrors changes to the public marketplace and runs automated screening on each update. You do not need to re-submit the form for updates.

<Note>
Need help building your plugin? See the [Claude Code plugin guide](https://code.claude.com/docs/en/plugins) for a complete walkthrough of plugin structure, manifests, and testing, or the [plugins reference](https://code.claude.com/docs/en/plugins-reference) for full technical specifications.
</Note>

skills/how-to First recorded · 203 lines, first recorded

# Creating custom skills ## Directory structure ## Creating a `SKILL.md` file ### Required fields ### Markdown body ### Complete example ## Adding resources ## Adding scripts ## Packaging your skill ## Testing your skill ### Before uploading ### After uploading ## Best practices ## Security considerations ## Example skills ## Related topics

The first capture of this source. The page was already there, and this is what it said.

# Creating custom skills

> Learn how to create, structure, and test your own custom skills

Custom skills extend Claude with specialized knowledge and workflows. This guide explains how to create, structure, and test your own skills.

Skills can range from simple instruction sets to multi-file packages with executable code. Effective skills:

* Solve a specific, repeatable task
* Have clear instructions Claude can follow
* Include examples when helpful
* Define when they should be used
* Focus on one workflow rather than trying to do everything

<Note>
Skills follow the [Agent Skills specification](https://agentskills.io/specification) — see the specification for more in-depth information.
</Note>

## Directory structure

A skill is a directory containing at minimum a `SKILL.md` file:

```
brand-guidelines/
├── SKILL.md
├── scripts/ # Optional: executable code
├── references/ # Optional: additional documentation
└── assets/ # Optional: templates, images, data files
```

The directory name must match the `name` field in your `SKILL.md`.

## Creating a `SKILL.md` file

The `SKILL.md` file must start with YAML frontmatter containing required metadata, followed by markdown instructions.

### Required fields

```markdown SKILL.md theme={null}
---
name: brand-guidelines
description: Apply Acme Corp brand guidelines to presentations and documents, including official colors, fonts, and logo usage.
---
```

**name**: Lowercase letters, numbers, and hyphens only. Maximum 64 characters. Must match the directory name.

**description**: Explains what the skill does and when to use it. Claude uses this to determine when to invoke your skill.

<Warning>
Claude.ai limits descriptions to **200 characters**. The [Agent Skills specification](https://agentskills.io/specification) allows up to 1024 characters, but skills uploaded to Claude.ai must use the shorter limit.
</Warning>

### Markdown body

After the frontmatter, write markdown instructions for Claude. Include:

* Step-by-step procedures
* Examples of inputs and outputs
* Templates or formatting requirements
* Edge cases to handle

Keep your main `SKILL.md` under 500 lines. Move detailed reference material to separate files.

### Complete example

```markdown SKILL.md theme={null}
---
name: brand-guidelines
description: Apply Acme Corp brand guidelines to presentations and documents, including official colors, fonts, and logo usage.
---

# Brand Guidelines

Apply these standards when creating presentations, documents, or marketing materials for Acme Corp.

## Brand colors

- Primary: #FF6B35 (Coral)
- Secondary: #004E89 (Navy Blue)
- Accent: #F7B801 (Gold)
- Neutral: #2E2E2E (Charcoal)

## Typography

- Headers: Montserrat Bold
- Body text: Open Sans Regular
- Size guidelines: H1 32pt, H2 24pt, Body 11pt

## Logo usage

Use the full-color logo on light backgrounds, white logo on dark backgrounds. Maintain minimum spacing of 0.5 inches around the logo.

## When to apply

Apply these guidelines when creating:
- PowerPoint presentations
- Word documents for external sharing
- Marketing materials
- Reports for clients

See the [assets/](assets/) folder for logo files and font downloads.
```

## Adding resources

For content too detailed for `SKILL.md`, add files to your skill directory:

* **`references/`**: Additional documentation Claude can read when needed
* **`assets/`**: Templates, images, lookup tables, schemas
* **`scripts/`**: Executable code (see below)

Reference these files in `SKILL.md` so Claude knows when to load them. Keep files focused—smaller files mean less context usage.

## Adding scripts

Skills can include executable code in Python, JavaScript/Node.js, or Bash. Place scripts in the `scripts/` directory.

Claude can install packages from standard repositories (PyPI, npm) when loading skills. Declare dependencies in your frontmatter:

```markdown SKILL.md theme={null}
---
name: data-analysis
description: Analyze CSV files and generate visualizations.
dependencies: python>=3.8, pandas>=1.5.0, matplotlib
---
```

## Packaging your skill

To upload a skill to Claude:

1. Ensure the directory name matches your skill's `name` field
2. Create a ZIP file containing the skill directory

**Correct structure:**

```
my-skill.zip
└── my-skill/
├── SKILL.md
└── scripts/
```

**Incorrect structure:**

```
my-skill.zip
├── SKILL.md # files directly in ZIP root
└── scripts/
```

## Testing your skill

### Before uploading

1. Review `SKILL.md` for clarity
2. Verify the description accurately reflects when Claude should use the skill
3. Check that all referenced files exist
4. Validate using `skills-ref validate ./my-skill` ([validation tool](https://github.com/agentskills/agentskills/tree/main/skills-ref))

### After uploading

1. Enable the skill in **Customize > Skills**
2. Try prompts that should trigger it
3. Review Claude's thinking to confirm it's loading the skill
4. Iterate on the description if Claude isn't using it when expected

## Best practices

**Keep it focused**: Create separate skills for different workflows. Multiple focused skills compose better than one large skill.

**Write clear descriptions**: Be specific about when the skill applies. Include keywords that help Claude identify relevant tasks.

**Start simple**: Begin with markdown instructions before adding scripts.

**Use examples**: Include example inputs and outputs to help Claude understand what success looks like.

**Test incrementally**: Test after each significant change.

**Leverage composability**: Claude can use multiple skills together automatically.

## Security considerations

* Don't hardcode sensitive information (API keys, passwords)
* Review any downloaded skills before enabling them
* Use MCP connections for external service access

## Example skills

See [github.com/anthropics/skills](https://github.com/anthropics/skills/tree/main/skills) for example skills you can use as templates.

## Related topics

<Columns cols={2}>
<Card title="Skills in Claude Code" icon="terminal" href="https://code.claude.com/docs/en/skills">
Create and test skills from the Claude Code CLI, including the `/skills` manager.
</Card>

<Card title="Distribute as a plugin" icon="puzzle-piece" href="/docs/plugins/submit">
Package your skill for the plugin directory.
</Card>
</Columns>

skills/overview First recorded · 54 lines, first recorded

# Skills overview ## Availability ## How skills work ## Types of skills ## Skills vs. other features ## Open standard ## Related topics

The first capture of this source. The page was already there, and this is what it said.

# Skills overview

> Extend Claude's capabilities with specialized instructions and workflows

Skills are directories containing instructions, scripts, and resources that Claude dynamically loads to handle specific tasks. Each skill has a `SKILL.md` file that defines when it should be activated and what instructions Claude should follow.

## Availability

Skills are available for users on Pro, Max, Team, and Enterprise plans. The Skills feature requires code execution to be enabled.

## How skills work

Skills use progressive disclosure to manage context efficiently:

1. **Metadata loading**: Claude reads skill names and descriptions at startup (\~100 tokens each)
2. **Activation**: When a task matches a skill's description, Claude loads the full `SKILL.md` content
3. **Resource loading**: Additional files (scripts, references) are loaded only when needed

This approach prevents context window overload while providing specialized capabilities on demand.

## Types of skills

* **Anthropic skills**: Pre-built skills for document creation (Excel, Word, PowerPoint, PDF) that activate automatically when relevant.
* **Partner skills**: Skills from partners like Notion, Figma, and Atlassian designed for seamless MCP connector integration.
* **Organization-provisioned skills**: Skills deployed organization-wide by Team and Enterprise administrators.
* **Custom skills**: Skills you create for specialized workflows—generating emails, applying brand guidelines, integrating with tools like JIRA or Linear, and more!

## Skills vs. other features

| Feature                          | Purpose                                                                           |
| -------------------------------- | --------------------------------------------------------------------------------- |
| **Skills**                       | Task-specific procedures that load dynamically                                    |
| **[Plugins](/docs/plugins/overview)** | Shareable packages that bundle skills, connectors, slash commands, and sub-agents |
| **Projects**                     | Static background knowledge always loaded in specific chats                       |
| **MCP**                          | Connects Claude to external services                                              |
| **Custom Instructions**          | Broad preferences applied to all conversations                                    |

## Open standard

Skills follow the [Agent Skills specification](https://agentskills.io/specification), a platform-agnostic standard. Skills you create can work across any platform adopting the standard.

See [Creating custom skills](/docs/skills/how-to) to learn how to build your own, or bundle skills into [plugins](/docs/plugins/overview) to share them with your team.

## Related topics

<Columns cols={2}>
  <Card title="Skills in Claude Code" icon="terminal" href="https://code.claude.com/docs/en/skills">
    Create, install, and invoke skills from the Claude Code CLI.
  </Card>

  <Card title="Plugins" icon="puzzle-piece" href="/docs/plugins/overview">
    Bundle skills with connectors and commands.
  </Card>
</Columns>

third-party/claude-desktop/bedrock First recorded · 199 lines, first recorded

# Deploy Claude Desktop on 3P with Amazon Bedrock ## Choose an authentication approach ## Set up AWS ## Prepare devices ### Bearer token ### In-app AWS sign-in #### How it works #### Allow network egress #### Notes and limitations ### Named profile ## Configure the app ### Configuration keys ## What users experience ## Troubleshoot

The first capture of this source. The page was already there, and this is what it said.

# Deploy Claude Desktop on 3P with Amazon Bedrock

> Set up AWS, choose an authentication path for your organization, and configure Claude Desktop on 3P to use Claude models on Amazon Bedrock

This page walks an IT administrator through a complete Amazon Bedrock deployment: enabling Claude in your AWS account, choosing the authentication path that fits your organization, preparing devices, and pushing the managed configuration. If you only need the list of configuration keys, skip to [Configure the app](#configure-the-app).

## Choose an authentication approach

Amazon Bedrock supports several ways to authenticate, and the right one depends on whether your end users already work with AWS and whether you need per-user identity in CloudTrail. Use the table below to pick a path before doing any AWS or device setup.

| Scenario                                   | Use                                                                               | Per-device prerequisite                 | Per-user CloudTrail identity | Notes                                                                                                                  |
| ------------------------------------------ | --------------------------------------------------------------------------------- | --------------------------------------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Proof of concept, single team              | [Bearer token](#bearer-token) (`inferenceBedrockBearerToken`)                     | None                                    | No (shared key)              | A long-lived secret distributed in the managed profile. Simplest to start; not recommended for broad rollout.          |
| Broad rollout to users without AWS tooling | [In-app AWS sign-in](#in-app-aws-sign-in) (`inferenceBedrockSso*`)                | None                                    | Yes                          | Users sign in through IAM Identity Center inside the app. No AWS CLI required. Requires app version 1.6259.0 or later. |
| Developers who already use the AWS CLI     | [Named profile](#named-profile) (`inferenceBedrockProfile`)                       | AWS CLI v2 and a pushed `~/.aws/config` | Yes                          | IT can distribute the AWS config file directly; the app runs `aws sso login` for the user when the session expires.    |
| You already operate an LLM proxy           | [Gateway provider](/docs/third-party/claude-desktop/gateway) instead of Amazon Bedrock | None                                    | At your gateway              | The proxy holds the AWS credentials; the app authenticates only to the proxy.                                          |

If a static credential in the managed profile is acceptable but an Amazon Bedrock API key is not, you can also set [`inferenceCredentialHelper`](/docs/third-party/claude-desktop/configuration#inferencecredentialhelper) to an executable that prints an Amazon Bedrock bearer token to stdout at runtime.

When more than one credential is configured, the app uses the first one present in this order: in-app AWS sign-in, named profile, credential helper, bearer token. To remove ambiguity, set `inferenceCredentialKind` explicitly (see the [Configuration reference](/docs/third-party/claude-desktop/configuration#inferencecredentialkind)).

## Set up AWS

These steps are performed once per AWS organization, regardless of which authentication approach you chose. You need an AWS account with permission to manage Amazon Bedrock model access and IAM Identity Center.

<Steps>
  <Step title="Enable Claude models in Amazon Bedrock">
    In the [Amazon Bedrock console](https://console.aws.amazon.com/bedrock/), open **Model access** and request access to the Claude models you intend to deploy. Access is granted per region, so enable the models in the same region you will set as `inferenceBedrockRegion`.
  </Step>

  <Step title="Create an IAM Identity Center permission set">
    Skip this step if you chose the bearer-token approach. The named-profile and in-app AWS sign-in approaches both use IAM Identity Center to issue per-user AWS credentials.

    In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/), create a permission set with an inline policy that allows Amazon Bedrock inference. The minimal policy is:

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Action": [
          "bedrock:InvokeModel",
          "bedrock:InvokeModelWithResponseStream"
        ],
        "Resource": "*"
      }]
    }
    ```

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

  <Step title="Federate Identity Center to your IdP (optional)">
    If your organization uses Microsoft Entra ID, Okta, or another SAML identity provider, you can configure it as the identity source for IAM Identity Center so users sign in with their existing corporate credentials. The per-device steps on this page are unchanged. See [Connect to an external identity provider](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) in the AWS documentation.
  </Step>

  <Step title="Assign users to the permission set">
    In IAM Identity Center, assign the permission set to the AWS account that hosts Amazon Bedrock, and add the users or groups who should have access.
  </Step>

  <Step title="Record the values you need for device configuration">
    From the IAM Identity Center **Settings** page, note:

    * **AWS access portal URL**: of the form `https://d-xxxxxxxxxx.awsapps.com/start` (or your custom subdomain)
    * **Identity Center region**: the region where Identity Center is enabled, which may differ from your Amazon Bedrock region
    * **AWS account ID**: the 12-digit ID of the account where you enabled Amazon Bedrock
    * **Permission set name**: the name you gave the permission set above
  </Step>
</Steps>

## Prepare devices

What each end-user device needs depends on the authentication approach you chose.

### Bearer token

No per-device preparation is required. In the [Amazon Bedrock console](https://console.aws.amazon.com/bedrock/home#/api-keys), generate an API key. The key's underlying IAM principal must be allowed the `bedrock:CallWithBearerToken` action; without it, requests return an authorization error even though the key was created. You will place the key in the managed configuration; see [Configure the app](#configure-the-app).

### In-app AWS sign-in

No per-device preparation is required. The sign-in experience uses **your organization's AWS IAM Identity Center instance**; the app registers an OIDC client dynamically with your Identity Center at runtime, so you do not create or distribute a client ID. Distribute the four `inferenceBedrockSso*` keys in the managed configuration (see [Configure the app](#configure-the-app)).

#### How it works

When all four `inferenceBedrockSso*` keys are set, the app shows a **Sign in with AWS** page at first launch. Clicking the button starts an OAuth device-authorization flow with your IAM Identity Center's OIDC endpoint and opens the AWS access portal in the system browser. The app displays a short verification code so the user can confirm that the browser prompt matches the app that requested it. Identity Center redirects the user to whichever identity provider you have configured (Entra ID, Okta, Google Workspace, or the Identity Center built-in directory).

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

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

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

#### Allow network egress

The sign-in flow and token refresh reach the IAM Identity Center endpoints for the region you set as `inferenceBedrockSsoRegion`:

* `oidc.<sso-region>.amazonaws.com`
* `portal.sso.<sso-region>.amazonaws.com`

These hosts are included automatically in the **Egress** section of the in-app configuration window when the SSO keys are set, so if you built your firewall allowlist from that output, no additional changes are needed. The browser step also reaches your AWS access portal (`*.awsapps.com`) and, if federated, your external identity provider.

#### Notes and limitations

* **All four keys required.** If only some of the `inferenceBedrockSso*` keys are set, the app logs a warning and ignores the partial configuration.
* **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.
* **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.
* **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.
* **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.

### Named profile

Each device needs AWS CLI v2 installed and an AWS config file that defines the named profile.

You do not need users to run `aws configure sso` interactively. That command is a wizard that writes a profile stanza to `~/.aws/config` (macOS) or `%USERPROFILE%\.aws\config` (Windows), and you can distribute that file directly through your device-management tooling instead. A profile that uses IAM Identity Center looks like:

```ini theme={null}
[profile claude-cowork]
sso_session = corp
sso_account_id = 123456789012
sso_role_name = ClaudeCoworkAccess
region = us-west-2

[sso-session corp]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access
```

When the cached IAM Identity Center token is missing or expired, the app prompts the user to sign in and runs `aws sso login --profile claude-cowork` itself, which opens the browser for IAM Identity Center sign-in and caches a token under `~/.aws/sso/cache/`. Users can also run the command in a terminal; the app and the CLI share the same token cache. When the token can be refreshed silently, the app does so without prompting.

To run the login command, the app locates the AWS CLI by searching the launch environment's `PATH`, the user's login-shell `PATH`, and standard install locations such as `/usr/local/bin` and `/opt/homebrew/bin` on macOS. If your fleet installs the AWS CLI somewhere else, or you want every device to use one specific binary, set `inferenceBedrockAwsCliPath` to the absolute path of the executable.

If your AWS configuration files are not at the default location, set `inferenceBedrockAwsDir` to the directory that contains them.

## Configure the app

With AWS set up and devices prepared, open the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration#open-the-configuration-window) (**Developer → Configure Third-Party Inference…**) on an evaluation device. In the **Connection** section, set **Inference provider** to **Bedrock** and fill in the **Bedrock credentials** card with the values for whichever authentication approach you chose:

| Field                | Bearer token                | In-app AWS sign-in                       | Named profile          |
| -------------------- | --------------------------- | ---------------------------------------- | ---------------------- |
| AWS region           | e.g. `us-west-2`            | e.g. `us-west-2`                         | e.g. `us-west-2`       |
| AWS bearer token     | your Amazon Bedrock API key | *leave empty*                            | *leave empty*          |
| Bedrock base URL     | *optional*                  | *optional*                               | *optional*             |
| AWS profile name     | *leave empty*               | *leave empty*                            | `claude-cowork`        |
| AWS config directory | *leave empty*               | *leave empty*                            | *only if not `~/.aws`* |
| AWS CLI path         | *leave empty*               | *leave empty*                            | *optional*             |
| AWS SSO start URL    | *leave empty*               | `https://d-xxxxxxxxxx.awsapps.com/start` | *leave empty*          |
| AWS SSO region       | *leave empty*               | e.g. `us-east-1`                         | *leave empty*          |
| AWS SSO account ID   | *leave empty*               | `123456789012`                           | *leave empty*          |
| AWS SSO role name    | *leave empty*               | `BedrockInference`                       | *leave empty*          |
| Bedrock service tier | *optional*                  | *optional*                               | *optional*             |

Under **Models**, add a **Model list** entry using the Amazon Bedrock inference-profile ID (required for profile or SSO auth; optional for bearer-token or credential-helper auth, which auto-discover), for example `us.anthropic.claude-sonnet-5`.

Then click **Export** to produce a `.mobileconfig` (macOS) or `.reg` (Windows) file for your MDM. See [Deploy with MDM](/docs/third-party/claude-desktop/mdm) for the export and deployment workflow.

### Configuration keys

The full set of `inferenceBedrock*` keys is below. Set `inferenceProvider` to `bedrock`, supply a region, and provide exactly one credential source.

| Setting                                                                                          | Type     | Availability    | Default | Description                                                                                                       |
| ------------------------------------------------------------------------------------------------ | -------- | --------------- | ------- | ----------------------------------------------------------------------------------------------------------------- |
| <span id="inferencebedrockregion" />AWS region<br />`inferenceBedrockRegion`                     | `string` | MDM + Bootstrap | —       | AWS region for the Bedrock runtime endpoint.                                                                      |
| <span id="inferencebedrockbaseurl" />Bedrock base URL<br />`inferenceBedrockBaseUrl`             | `string` | MDM + Bootstrap | —       | For VPC endpoints or gateway proxies. Host origin only.                                                           |
| <span id="inferencebedrockservicetier" />Bedrock service tier<br />`inferenceBedrockServiceTier` | `enum`   | MDM + Bootstrap | —       | Sent as the X-Amzn-Bedrock-Service-Tier header. Leave unset for on-demand. One of: `flex`, `priority`.            |
| <span id="inferencebedrockbearertoken" />AWS bearer token<br />`inferenceBedrockBearerToken`     | `string` | MDM + Bootstrap | —       | Static bearer token for inference. For providers that support profile or helper-script credentials, prefer those. |
| <span id="inferencebedrockssostarturl" />AWS SSO start URL<br />`inferenceBedrockSsoStartUrl`    | `string` | MDM + Bootstrap | —       | Enables in-app AWS sign-in (no AWS CLI needed). Set with the three SSO fields below.                              |
| <span id="inferencebedrockssoregion" />AWS SSO region<br />`inferenceBedrockSsoRegion`           | `string` | MDM + Bootstrap | —       | IAM Identity Center home region.                                                                                  |
| <span id="inferencebedrockssoaccountid" />AWS SSO account ID<br />`inferenceBedrockSsoAccountId` | `string` | MDM + Bootstrap | —       | 12-digit AWS account ID assigned to users in IAM Identity Center.                                                 |
| <span id="inferencebedrockssorolename" />AWS SSO role name<br />`inferenceBedrockSsoRoleName`    | `string` | MDM + Bootstrap | —       | IAM Identity Center permission-set name granting bedrock:InvokeModel\* on the account above.                      |
| <span id="inferencebedrockprofile" />AWS profile name<br />`inferenceBedrockProfile`             | `string` | MDM + Bootstrap | —       | AWS named profile to use for Bedrock inference credentials.                                                       |
| <span id="inferencebedrockawsdir" />AWS config directory<br />`inferenceBedrockAwsDir`           | `string` | MDM + Bootstrap | —       | Folder with AWS config/credentials. Defaults to \~/.aws when no bearer token is set.                              |
| <span id="inferencebedrockawsclipath" />AWS CLI path<br />`inferenceBedrockAwsCliPath`           | `string` | MDM + Bootstrap | —       | Absolute path to the aws executable. Leave unset to find it on PATH.                                              |

<AccordionGroup>
  <Accordion title="inferenceBedrockServiceTier details">
    Tier availability varies by model and region. Reserved capacity uses a provisioned-throughput ARN as the model ID instead of this setting. Older bundled Claude Code CLI versions ignore this key.
  </Accordion>
</AccordionGroup>

Set `inferenceModels` to a list of Amazon Bedrock inference-profile IDs, for example `us.anthropic.claude-sonnet-5`. When using a bearer token or credential helper, Claude Desktop auto-discovers available Claude models from your account if this is unset; for profile or SSO authentication, the list is required. Application-inference-profile ARNs and provisioned-throughput ARNs are also accepted; pair them with a [`labelOverride`](/docs/third-party/claude-desktop/configuration#inferencemodels) so the picker shows a readable name instead of the raw ARN. See the [Configuration reference](/docs/third-party/claude-desktop/configuration#inferencemodels).

## What users experience

The first-launch and re-authentication behavior depends on the authentication approach.

| Approach           | First launch                                                                                                                                 | Re-authentication                                                                                                                                         |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Bearer token       | The app opens directly; no user action.                                                                                                      | Never, until you rotate the key in the managed profile.                                                                                                   |
| In-app AWS sign-in | The app shows a **Sign in with AWS** page; the user approves in the browser, and the app returns to Cowork.                                  | When the IAM Identity Center access portal session expires (defaults to 8 hours; configurable up to 90 days). The app prompts in-app; no terminal needed. |
| Named profile      | The app opens directly if the AWS SSO cache is fresh; otherwise it prompts in-app and runs `aws sso login` for you, which opens the browser. | When the IAM Identity Center session expires, the app prompts in-app and re-runs `aws sso login`.                                                         |

For in-app AWS sign-in, the browser flow runs on the host (outside the Cowork sandbox), so it uses the user's existing identity-provider session and any security keys or passkeys configured on the device. The **AWS access portal session duration** setting (IAM Identity Center → **Settings** → **Authentication**) controls how long users stay signed in across app restarts. To force a user to sign in again sooner, delete their active session from the IAM Identity Center console.

If the app cannot locate the AWS CLI, it cannot drive the login itself; it instructs the user to install AWS CLI v2 and run `aws sso login --profile <name>` manually.

## Troubleshoot

To confirm which keys the app read and whether credentials validated, use **Help → Troubleshooting → Copy Managed Configuration Report**; see [Verifying the deployment](/docs/third-party/claude-desktop/installation#verifying-the-deployment) for that workflow and the common causes when the app does not enter 3P mode. Application log locations are listed in [Data storage and residency](/docs/third-party/claude-desktop/data-storage).

third-party/claude-desktop/bootstrap First recorded · 389 lines, first recorded

# Deploy with a bootstrap server ## How it works ### Availability ## Server responsibilities ### Mapping groups to profiles ## Authentication ### Separate identity provider (PKCE) #### Provider notes ### Bootstrap server as authorization server (device code) ## The HTTP contract ### Request ### Response ### Response schema ### Keys that require user consent ### Caching and `expiresAt` ### Origin pinning ## MDM configuration keys ## Troubleshooting

The first capture of this source. The page was already there, and this is what it said.

# Deploy with a bootstrap server

> Host an HTTPS endpoint that returns each user's configuration, for organizations without MDM or with role-based configuration too complex for per-group profiles

<Note>
  Requires Claude Desktop **1.10628.0** or later. Earlier builds ignore the `bootstrapUrl` keys.
</Note>

A **bootstrap server** is an HTTPS endpoint you host that authenticates each user against your identity provider and returns that user's configuration as JSON. Use it when your organization doesn't have MDM, or when configuration varies too widely for per-group profiles: per-user gateway credentials, per-team model allowlists, or per-user OpenTelemetry attribution. When one configuration or a few group-scoped profiles cover your fleet, [deploying with MDM](/docs/third-party/claude-desktop/mdm) is simpler; most MDMs support role-based distribution.

When a bootstrap response is available, it **is** the effective configuration. The MDM profile supplies the trust anchor (`bootstrapUrl`, optional `bootstrapOidc`, and the `bootstrapEnabled` opt-out), and Claude Desktop does not consult MDM for any key the bootstrap server is permitted to set. A bootstrap-settable key that your response **omits** is treated as unset, not inherited from MDM, so return every key you want applied.

<Warning>
  Your bootstrap server is fully trusted. Its response can set inference credentials, the egress allowlist, MCP servers, and every other key in the [published schema](#response-schema). Treat compromise of this endpoint as credential compromise: restrict who can deploy it, log every response, and harden it as you would any secrets-issuing service.
</Warning>

Before the server can take over, each device needs the bootstrap keys that point at it. There are two ways to get them onto a device:

* **With MDM:** deploy a profile that sets `bootstrapUrl` (and `bootstrapOidc` if you use one).
* **Without MDM:** give each user a small JSON file containing those keys, which they load from **Developer → Configure Third-Party Inference… → Import configuration**.

Either way, the bootstrap server supplies everything else after the user signs in. See [Installation and setup](/docs/third-party/claude-desktop/installation) for the surrounding workflow.

If you set `deploymentOrganizationUuid`, include it in the MDM profile or imported configuration file, and return the same value in your bootstrap response, as a plain UUID without braces in both places. Claude Desktop uses the device-side value at startup to locate sessions, skills, and plugins stored on the device.

## How it works

1. Your managed configuration (MDM or imported) sets `bootstrapUrl` (and `bootstrapOidc` if you use a separate identity provider).
2. At launch, the app authenticates the user via one of [two modes](#authentication) and sends `GET <bootstrapUrl>` with `Authorization: Bearer <token>`.
3. Your server validates the token, **authorizes** the caller against your directory or entitlement source, and returns a JSON object whose keys are the same managed-configuration key names documented in the [configuration reference](/docs/third-party/claude-desktop/configuration).
4. The app validates each key against the [response schema](#response-schema), drops anything it doesn't recognize or that fails validation, and applies the result as the effective configuration.
5. The response is cached in memory (until your `expiresAt`, or 1 hour by default). The app also re-polls in the background every 30 minutes with a conditional request, so an unchanged configuration costs your server a `304` (see [Caching and `expiresAt`](#caching-and-expiresat)).

If the user has not yet signed in, or the fetch fails with no cached response from this session, the app starts in a degraded state with no inference provider configured and prompts the user to sign in.

### Availability

The cached response is held **in memory only**; there is no on-disk fallback to a previous session's response. If your bootstrap server is unreachable when Claude Desktop launches, the user stays in the degraded sign-in state until the server recovers. A failed refetch *during* a running session keeps the in-memory response and retries, so an outage that starts mid-session does not disrupt active users until they relaunch.

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

A 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) and applies the new response at the next app launch. Plan changes accordingly: when rotating an inference credential, keep the previous credential valid until your fleet has relaunched rather than expecting propagation within a refetch interval.

## Server responsibilities

Your bootstrap endpoint is a security boundary. The response can carry inference credentials, so an unauthenticated or under-authorized endpoint leaks those credentials to anyone who can reach the URL. Host it on your private network (VPC, corporate intranet, or behind your zero-trust access proxy) rather than the public internet; reachability from managed devices is sufficient.

**Authenticate.** Verify the bearer token's signature against your identity provider's JWKS, and check `iss`, `aud`, and `exp`. Reject anything else with `401`.

**Authorize.** Verifying the token proves *who* the caller is, not that they're entitled to a configuration. Check the caller's identity claim against your directory before returning a response:

| Identity provider  | Stable per-user claim       | Group/role claim                   |
| ------------------ | --------------------------- | ---------------------------------- |
| Microsoft Entra ID | `oid` (directory object ID) | `roles` (app roles) or `groups`    |
| Okta               | `uid` or `sub`              | `groups` (via a custom claim rule) |
| Generic OIDC       | `sub`                       | provider-specific                  |

Return `403` when the token is valid but the caller is not entitled. Do not authorize on `email` or `preferred_username` alone; those claims are mutable and may be absent for guest or external-identity users.

**Key the response on the caller** when configuration needs to differ. A single default profile returned to every entitled user is valid; vary by user or group only where you need per-user credentials, model allowlists, or telemetry attribution.

### Mapping groups to profiles

The common pattern is one profile per directory group or app role. For Entra, define an app role on the registration (for example `cowork-power-user`), assign it to a group via **Enterprise applications → Users and groups**, and select the profile from the token's `roles` claim. For Okta, the equivalent is a `groups` claim on your custom authorization server; match on `payload.groups`. Moving a user between groups in your directory is picked up at the next refetch with no profile re-push to devices; the new configuration takes effect when the user's app next launches.

A reference Node.js handler showing token validation, role-based authorization, and profile selection:

```js theme={null}
import { createRemoteJWKSet, jwtVerify } from "jose";

const TENANT = process.env.ENTRA_TENANT;
const CLIENT_ID = process.env.CLIENT_ID;
const JWKS = createRemoteJWKSet(
  new URL(`https://login.microsoftonline.com/${TENANT}/discovery/v2.0/keys`),
);

const BASE = {
  inferenceProvider: "gateway",
  inferenceGatewayBaseUrl: "https://YOUR_GATEWAY_HOST",
  inferenceGatewayAuthScheme: "bearer",
};
const PROFILES = {
  default: { ...BASE, inferenceModels: ["claude-sonnet-5"] },
  power: {
    ...BASE,
    inferenceModels: ["claude-opus-5", "claude-sonnet-5"],
    coworkEgressAllowedHosts: ["pypi.org", "registry.npmjs.org"],
  },
};
const ENTITLED_ROLES = new Set(["cowork-user", "cowork-power-user"]);

export async function handleBootstrap(req, res) {
  res.set("Cache-Control", "no-store");
  const token = (req.headers.authorization ?? "").replace(/^Bearer /, "");
  let payload;
  try {
    ({ payload } = await jwtVerify(token, JWKS, {
      issuer: `https://login.microsoftonline.com/${TENANT}/v2.0`,
      audience: CLIENT_ID,
      algorithms: ["RS256"],
    }));
  } catch {
    return res.status(401).json({ error: "invalid_token" });
  }
  const roles = payload.roles ?? [];
  if (!roles.some((r) => ENTITLED_ROLES.has(r))) {
    return res.status(403).json({ error: "not_entitled" });
  }
  const profile = roles.includes("cowork-power-user")
    ? PROFILES.power
    : PROFILES.default;
  return res
    .status(200)
    .json({ ...profile, expiresAt: Date.now() + 3600_000 });
}
```

Set `Cache-Control: no-store` on the response. Without it, a reverse proxy or CDN between the app and your endpoint may cache one user's credentials and serve them to the next.

## Authentication

The bootstrap request always carries a bearer token; there is no unauthenticated mode. There are two ways to obtain that token, chosen by whether you set `bootstrapOidc` in MDM:

| Mode                                                       | When to use it                                                                                                                                                                                              | MDM keys                           |
| ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- |
| **Separate identity provider (PKCE)**                      | Users sign in through your existing OIDC provider (Microsoft Entra ID, Okta, Ping, or any compliant provider). The app runs an OAuth authorization-code grant with PKCE in the system browser.              | `bootstrapUrl` and `bootstrapOidc` |
| **Bootstrap server as authorization server (device code)** | Your bootstrap server (or the gateway it fronts) implements RFC 8414 discovery and the RFC 8628 device-code grant. One sign-in covers both the configuration fetch and inference when they share an origin. | `bootstrapUrl` only                |

### Separate identity provider (PKCE)

<Steps>
  <Step title="Register a public client in your identity provider">
    Register a native or public application with a loopback redirect URI and no client secret. The registration is identical to the one used for [gateway single sign-on](/docs/third-party/claude-desktop/gateway#set-up-single-sign-on); if you already have that, reuse it. See the [provider notes](#provider-notes) below for redirect-URI specifics.

    For Microsoft Entra ID, also set an **Application ID URI** on the registration (App registration → **Expose an API** → **Set**; accept the default `api://CLIENT_ID`). The `CLIENT_ID/.default` scope in the next step does not resolve without it.
  </Step>

  <Step title="Choose the scope your server will validate">
    The app sends the OAuth **access token** as the bearer. Your server validates that token's `aud`, so the scope you request must produce a token whose audience your server accepts. This is provider-specific:

    | Provider                           | Scope to request                                       | Resulting `aud`                      |
    | ---------------------------------- | ------------------------------------------------------ | ------------------------------------ |
    | Microsoft Entra ID                 | `openid offline_access CLIENT_ID/.default`             | your client ID                       |
    | Okta (custom authorization server) | `openid offline_access YOUR_API_SCOPE`                 | your authorization server's audience |
    | Generic OIDC                       | `openid offline_access` plus your API's resource scope | provider-specific                    |

    Include `offline_access` so the app receives a refresh token and can renew silently between launches.

    <Warning>
      For Entra, use the bare-GUID form `CLIENT_ID/.default`, **not** `api://CLIENT_ID/.default`. The `api://` form works on the initial authorize but fails on the refresh grant with `AADSTS90009` when the client and resource are the same application.
    </Warning>
  </Step>

  <Step title="Validate the token in your server">
    See [Server responsibilities](#server-responsibilities). What the token's `iss` and `aud` look like depends on your provider:

    | Provider                               | `iss` to expect                                      | `aud` to expect                                      | JWKS URL                                                       |
    | -------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------- | -------------------------------------------------------------- |
    | Microsoft Entra ID (token version `2`) | `https://login.microsoftonline.com/TENANT/v2.0`      | your client ID                                       | `https://login.microsoftonline.com/TENANT/discovery/v2.0/keys` |
    | Okta (custom authorization server)     | `https://YOUR_DOMAIN.okta.com/oauth2/AUTH_SERVER_ID` | the audience configured on that authorization server | `<issuer>/v1/keys`                                             |

    **Entra token version.** A new Entra app registration emits v1-format access tokens by default, with `iss` = `https://sts.windows.net/TENANT/` and `aud` = `api://CLIENT_ID`. Set the accepted-token-version field in the registration's **Manifest** to `2` so tokens match the table above. The portal shows this field as either `accessTokenAcceptedVersion` or `api.requestedAccessTokenVersion` depending on the manifest view; set whichever you see. If you cannot change it, your server must accept both the v1 and v2 forms.

    **Group and role claims.** Entra does not emit `groups` or `roles` in access tokens by default. Enable the groups claim under App registration → **Token configuration**, or define **App roles** and assign users via **Enterprise applications**. The `oid` claim is always present. For Okta, add a `groups` claim on your custom authorization server with a group filter.
  </Step>

  <Step title="Configure and export from Claude Desktop">
    Install Claude Desktop on an admin workstation (see [Installation](/docs/third-party/claude-desktop/installation)). From the menu bar, open **Developer → Configure Third-Party Inference…**. In the **Source** section, fill in the **Bootstrap config URL** card:

    | Field                                     | Value                                                   |
    | ----------------------------------------- | ------------------------------------------------------- |
    | Bootstrap config URL                      | `https://YOUR_BOOTSTRAP_HOST/user/bootstrap`            |
    | Bootstrap OIDC parameters → Client ID     | `YOUR_CLIENT_ID`                                        |
    | Bootstrap OIDC parameters → Issuer URL    | `https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0` |
    | Bootstrap OIDC parameters → Scopes        | `openid offline_access YOUR_CLIENT_ID/.default`         |
    | Bootstrap OIDC parameters → Redirect port | leave empty for Entra; set for Okta                     |

    Click **Sign in** to test against your typed values. Once authenticated, the card shows the keys your server supplied. Click **Export** and choose the template format your MDM expects (`.mobileconfig`, ADMX, Intune OMA-URI JSON, or `.reg`). See [Deploy the configuration](/docs/third-party/claude-desktop/mdm#4-deploy-the-configuration) for per-platform instructions.
  </Step>
</Steps>

#### Provider notes

| Provider           | Redirect URI to register                                                       | Redirect port field                      | Additional setup                                                                                                                                                                           |
| ------------------ | ------------------------------------------------------------------------------ | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Microsoft Entra ID | `http://127.0.0.1/callback` under **Mobile and desktop applications**          | Leave empty (any local port allowed)     | Manifest: set the accepted-token-version field to `2`. **Expose an API**: set the Application ID URI. **Token configuration**: add the `groups` claim if your server authorizes on groups. |
| Okta               | `http://127.0.0.1:53180/callback` (any fixed port) on a **Native** application | Set to the registered port               | Create a custom authorization server with an audience your bootstrap server validates.                                                                                                     |
| Other OIDC         | `http://127.0.0.1/callback`                                                    | Set only if exact-port match is enforced | None                                                                                                                                                                                       |

Use `127.0.0.1`, not `localhost`.

This page covers only the bootstrap sign-in. Authentication for inference is independent of bootstrap and depends on what your response provisions; see the relevant provider page ([gateway SSO](/docs/third-party/claude-desktop/gateway#single-sign-on-with-your-identity-provider), [Google Cloud's Agent Platform](/docs/third-party/claude-desktop/vertex), [Amazon Bedrock](/docs/third-party/claude-desktop/bedrock), [Microsoft Foundry](/docs/third-party/claude-desktop/foundry)).

### Bootstrap server as authorization server (device code)

Set only `bootstrapUrl` in MDM. The app discovers your authorization endpoints via RFC 8414 and runs an RFC 8628 device-code grant. The bearer is reused for inference when `inferenceGatewayBaseUrl` shares the `bootstrapUrl` origin and `inferenceCredentialKind` is `interactive`, so the user signs in once for both.

<Steps>
  <Step title="Publish RFC 8414 discovery metadata">
    Serve a metadata document under the `bootstrapUrl` path. If `bootstrapUrl` ends in `/bootstrap` or `/user/bootstrap`, that suffix is stripped to form the issuer base.

    ```text theme={null}
    GET https://YOUR_BOOTSTRAP_HOST/.well-known/oauth-authorization-server
    ```

    ```json theme={null}
    {
      "issuer": "https://YOUR_BOOTSTRAP_HOST",
      "token_endpoint": "https://YOUR_BOOTSTRAP_HOST/oauth/token",
      "device_authorization_endpoint": "https://YOUR_BOOTSTRAP_HOST/oauth/device"
    }
    ```

    Every endpoint URL must share the `bootstrapUrl` origin. Metadata that points off-origin is rejected.
  </Step>

  <Step title="Implement the device-code grant">
    `POST` to `device_authorization_endpoint` returns:

    ```json theme={null}
    {
      "device_code": "EXAMPLE-DEVICE-CODE-OPAQUE-TO-CLIENT",
      "user_code": "ABCD-EFGH",
      "verification_uri": "https://YOUR_BOOTSTRAP_HOST/activate",
      "verification_uri_complete": "https://YOUR_BOOTSTRAP_HOST/activate?user_code=ABCD-EFGH",
      "interval": 5,
      "expires_in": 600
    }
    ```

    `verification_uri` and `verification_uri_complete` must share the `bootstrapUrl` origin; federate behind your own pages rather than returning an upstream provider's URL directly. The app opens the verification URL in the user's browser and shows the user code.

    The app polls `token_endpoint` with `grant_type=urn:ietf:params:oauth:grant-type:device_code` and the `device_code`. Return `{"error":"authorization_pending"}` until the user approves, then:

    ```json theme={null}
    { "access_token": "eyJhbGciOiJSUzI1NiIs...", "expires_in": 3600 }
    ```

    The polling interval is clamped between 1 and 30 seconds; the grant times out after 5 minutes; token TTL is clamped between 5 minutes and 24 hours.
  </Step>

  <Step title="Serve the configuration endpoint">
    On `GET <bootstrapUrl>` with a valid bearer, look up the user from the token claims and return their configuration (see [the HTTP contract](#the-http-contract)).
  </Step>
</Steps>

## The HTTP contract

### Request

```http theme={null}
GET /user/bootstrap HTTP/1.1
Host: YOUR_BOOTSTRAP_HOST
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
If-None-Match: "abc123"
```

The path is whatever you set in `bootstrapUrl`; there is no required path. Redirects are **not** followed: a `3xx` is treated as an error so a same-origin open redirect cannot exfiltrate the bearer. The request times out after 30 seconds.

### Response

Return `200 OK` with `Content-Type: application/json` and a JSON object whose keys are a subset of the [published response schema](#response-schema). Keys use the exact managed-configuration key names. Unknown keys, keys that fail validation, and keys outside that schema are silently dropped; one bad key never invalidates the rest.

```json theme={null}
{
  "inferenceProvider": "gateway",
  "inferenceGatewayBaseUrl": "https://llm-gateway.example.corp",
  "inferenceCredentialKind": "interactive",
  "inferenceModels": ["claude-opus-5", "claude-sonnet-5"],
  "managedMcpServers": [{ "name": "internal-tools", "url": "https://mcp.example.corp/sse", "transport": "sse" }],
  "coworkEgressAllowedHosts": ["*.example.corp", "pypi.org"],
  "otlpResourceAttributes": { "user.email": "[email protected]", "team": "trading" },
  "expiresAt": 1778700000
}
```

| Status                  | App behavior                                                                                                                                                                                                                                                                                         |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `200`                   | Parse and apply.                                                                                                                                                                                                                                                                                     |
| `304`                   | Re-serve the cached response (the app sends `If-None-Match` when it has one).                                                                                                                                                                                                                        |
| `401`, `403`            | Discard the cached token and prompt the user to sign in again. A `401` on a background refresh keeps the running session and retries without prompting. Return `401` when the token is missing, expired, or the wrong audience; return `403` when the token is valid but the caller is not entitled. |
| Other non-2xx, or `3xx` | Fetch error. Falls back to the last good response from this session if one exists; otherwise the app stays in the degraded sign-in state.                                                                                                                                                            |

<Warning>
  A `200` that is not a JSON object (an empty body, an HTML page from a captive portal or load balancer, or a JSON array) is a parse error. Make sure intermediate proxies do not rewrite the response.
</Warning>

### Response schema

The full set of bootstrap-settable keys is published as a machine-readable JSON Schema, generated from the same source as the [configuration reference](/docs/third-party/claude-desktop/configuration) and updated with each release:

* [`/third-party/claude-desktop/schemas/bootstrap-config-v2.schema.json`](/docs/third-party/claude-desktop/schemas/bootstrap-config-v2.schema.json) (recommended): nested response format with a discriminated `inference` object.
* [`/third-party/claude-desktop/schemas/bootstrap-config-v1.schema.json`](/docs/third-party/claude-desktop/schemas/bootstrap-config-v1.schema.json): flat key format, kept for configurations authored before the v2 cutover. The app accepts either format.

Reference the schema with `"$schema"` in your response template, or with `# yaml-language-server: $schema=…` in YAML, for autocomplete and validation.

The response can supply any key in that schema, including inference credentials, model allowlists, MCP servers, the egress allowlist, telemetry endpoints, and the organization banner.

<Note>
  Organization plugins and skills can be delivered over the network by returning `organizationPluginsUrl` in the bootstrap response when using [device-code mode](#bootstrap-server-as-authorization-server-device-code), or through the filesystem `org-plugins/` directory described in [Connectors and extensions](/docs/third-party/claude-desktop/extensions). Network delivery is not available in PKCE mode.

Cut at 300 lines. The page has the rest.

third-party/claude-desktop/built-in-connectors First recorded · 31 lines, first recorded

# Built-in connectors ## Available servers ## How built-in servers behave

The first capture of this source. The page was already there, and this is what it said.

# Built-in connectors

> MCP servers bundled inside Claude Desktop on 3P: which servers ship in the app, how built-in entries work, and where each one is documented

Claude Desktop ships copies of some MCP servers inside the app itself. A built-in server runs as a local process on the user's device and calls the data provider directly, so no data or tokens pass through Anthropic's infrastructure. There is nothing to install or host on your side: a [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers) entry activates the server, and the app runs it.

A built-in entry names the bundled server in a `server` field, in place of the `url`, `transport`, or `command` fields that remote and stdio entries use. An entry that mixes `server` with any remote or stdio field is rejected.

## Available servers

| Server | `server` value | What Claude can reach | Setup guide |
| ------------- | -------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Microsoft 365 | `microsoft365` | Outlook mail and calendar, OneDrive, SharePoint, and Teams, through Microsoft Graph | [Connect to Microsoft 365, local connector](/docs/third-party/claude-desktop/connectors-m365#local-connector) |
| Web search | `websearch` | Web search through Brave, Tavily, Exa, or a search endpoint you host | [Built-in web search](/docs/third-party/claude-desktop/web-tools#built-in-web-search) |
| GitHub (beta) | `github` | Repositories, issues, pull requests, and other GitHub data, on github.com or GitHub Enterprise Server | [Connect to GitHub, local connector](/docs/third-party/claude-desktop/connectors-github#local-connector) |

Each guide covers its server in full, including how the built-in server compares with the remote alternative where one exists. The GitHub built-in server is in beta, and the **Add server** menu marks it with a **Beta** pill.

<Note>
In the in-app configuration window, the **Add server** menu lists built-in servers separately from remote templates. A remote template (Box, or the Microsoft 365 remote connector) only pre-fills the form for a server that runs outside the app. The servers on this page are the ones bundled inside the app.
</Note>

## How built-in servers behave

All built-in servers share the same model:

* **Managed configuration only.** A built-in server activates only from a `managedMcpServers` entry. Users cannot add one themselves and cannot remove one you deploy.
* **Local execution.** The server runs on the user's device, and its network calls go directly to the data provider (Microsoft, your search provider, or GitHub). No Anthropic host is in the data path.
* **Sign-in on the device.** Where the server needs user credentials (Microsoft 365 and GitHub), the user signs in from the app, and tokens are stored encrypted on the device. **Disconnect** in connector settings signs the user out. The web search server has no user sign-in; you supply the search key in the entry.
* **Tool approvals.** Each entry accepts the same per-tool [`toolPolicy`](/docs/third-party/claude-desktop/configuration#managedmcpservers) as any managed server. Without a policy, built-in write tools ask the user before each call, and a small set of irreversible actions (sending mail or merging a pull request, for example) stays at ask or stricter no matter what the policy says.
* **Versioned with the app.** Each built-in server requires a Claude Desktop version that includes it. On older versions, the server is missing from the **Add server** menu, **Test connection** reports that it is not included, and a deployed entry is dropped. The fix is to upgrade Claude Desktop.

third-party/claude-desktop/chat First recorded · 74 lines, first recorded

# Chat in Claude Desktop on 3P ## What a Chat conversation can reach ## What a Chat conversation cannot do ## Advanced file analysis ## Configuration ## Where Chat data lives

The first capture of this source. The page was already there, and this is what it said.

# Chat in Claude Desktop on 3P

> What Chat can and cannot do in Claude Desktop on 3P, and how to configure it

Chat in Claude Desktop on third-party (3P) is a conversational surface for quick questions and drafting. Unlike [Cowork](/docs/cowork/overview) and [Code](/docs/third-party/claude-desktop/code), which run agentic sessions with access to folders you grant and a code-execution environment, a Chat conversation runs with a deliberately small tool surface: it can search and fetch the web under your admin configuration, read files attached to the conversation, read the project's memory when the conversation is inside a project, and write files into a scratch space of its own, and nothing else on the machine. Chat is off by default and is enabled with a single configuration key.

Like everything else in 3P mode, Chat conversations run against your configured inference provider, and conversation history lives on the user's device. See [User identity and local data](/docs/third-party/claude-desktop/data-storage#chat-conversations) for exactly what is written where and what can leave the device.

## What a Chat conversation can reach

| Capability | Scope |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Web search | Same options and rules as Cowork and Code sessions; depends on your provider or a configured search server. See [Web search](/docs/third-party/claude-desktop/web-tools#web-search). |
| Web fetch | Runs in the app on the device, never inside a sandbox. Every fetch is checked against `coworkEgressAllowedHosts`; with no allowlist configured, fetch is disabled. See [Web fetch](/docs/third-party/claude-desktop/web-tools#web-fetch). |
| Attached files | Read-only access to files the user attaches to the conversation. Each attachment is copied or hard-linked into the conversation's local uploads directory. |
| Project memory | For a conversation inside a project, read-only access to that project's [memory](/docs/third-party/claude-desktop/data-storage#memory): the notes written during Cowork sessions in that project. Not used if memory was paused when the conversation started, or for conversations outside a project. |
| Scratch directory | A per-conversation working directory where Claude can create and edit files (documents, data files, HTML artifacts) and offer them to the user for download or preview. |
| Managed MCP servers | The servers you provision via [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers) are available in Chat with the same approval model as Cowork sessions: a tool's `toolPolicy` of `"allow"` pre-approves it, `"blocked"` blocks it, and `"ask"` requires user approval on every call. A tool with no policy asks the user, who can allow it once or grant standing approval, as in Cowork. |
| Clarifying questions | Claude can present multiple-choice questions to the user (the `AskUserQuestion` tool). |
| Code execution | Off by default. When you enable [advanced file analysis](#advanced-file-analysis), Claude can additionally run code in an offline local sandbox against attached files. |

`disabledBuiltinTools` and `builtinToolPolicy` apply in Chat the same way they do in Cowork and Code sessions. For example, adding `"WebFetch"` removes web fetch from Chat conversations too.

## What a Chat conversation cannot do

In a Chat conversation, Claude cannot:

* **Read or write the filesystem** beyond the conversation's own uploads and scratch directories and, inside a project, the project's memory (read-only). Chat conversations never receive folder access: the tool for requesting folder access is removed, and the app refuses folder grants to a Chat conversation even when requested through internal interfaces.
* **Run code on the host.** There is no shell access. With advanced file analysis off (the default), the sandbox VM is never started for Chat; with it on, code runs only inside the offline sandbox described below, never on the host itself.
* **Act without asking.** Chat conversations always run in the default permission mode. Auto mode and other reduced-supervision modes are rejected for Chat regardless of `autoModeEnabled`.
* **Create or run scheduled tasks**, or list the ones that exist.
* **Escalate into an agentic session.** The tools that launch Code sessions or dispatch background agent tasks are removed. When a request needs capabilities Chat doesn't have, Claude says so and suggests starting the task in Cowork instead.
* **Read other conversations.** The tools that list sessions or read other sessions' transcripts are removed, so a Chat conversation cannot search or quote your other chats, Cowork sessions, or Code sessions.
* **Write memory.** Chat conversations cannot add to or change [memory](/docs/third-party/claude-desktop/data-storage#memory); inside a project they read the project's memory as described above, and outside a project they use no memory.

These restrictions are enforced in the app's main process, not just hidden in the UI.

## Advanced file analysis

By default, Chat can read attached files only in the formats Claude understands natively. Setting `chatAdvancedFileAnalysisEnabled` to `true` lets Claude also run code against attachments. This is useful for spreadsheets, PowerPoint files, and other formats that need parsing, and for inline data analysis on attached data.

The execution environment is intentionally narrower than the Cowork sandbox:

* Code runs in the same isolated local VM that Cowork uses. For Chat, the VM starts only when analysis is coming: on the first analysis call, or at the start of a turn with files attached.
* The sandbox has **no network access**. This is unconditional for Chat and independent of `coworkEgressAllowedHosts`: an allowlist that opens egress for Cowork sessions does not open it for Chat analysis.
* The only conversation data the sandbox sees is the conversation's attached files (read-only), its scratch directory (writable), and, for a conversation inside a project, that project's memory (read-only), plus read-only reference material bundled by the app. No user folders, and no other sessions' working directories or transcripts.
* Each command runs independently; results land in the scratch directory, where Claude can offer them to the user as downloads or artifacts.

The data flow end to end: an attached file is copied into the conversation's local uploads directory, mounted read-only into the sandbox when analysis runs, and any outputs are written to the conversation's scratch directory on local disk. File content leaves the device only as conversation context sent to your configured inference provider, in web search queries to your configured search backend, through web fetches your egress allowlist permits, in a connector tool call permitted by your `toolPolicy` configuration and the user's approvals, or, if you have enabled [content capture](/docs/third-party/claude-desktop/telemetry#content-capture), in telemetry to your own collector.

<Note>
Advanced file analysis uses the same shell tool as Cowork's sandbox, so adding `"Bash"` to `disabledBuiltinTools` disables it even when `chatAdvancedFileAnalysisEnabled` is `true`. Running it requires the sandbox VM bundle, which the app downloads from Anthropic unless you deployed the offline installer (see [required egress paths](/docs/third-party/claude-desktop/telemetry#required-egress-paths)).
</Note>

## Configuration

| Key | Default | Effect |
| -------------------------------------------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------- |
| [`chatTabEnabled`](/docs/third-party/claude-desktop/configuration#chattabenabled) | off | Makes Chat available. Chat is opt-in: it appears in the app only when this key is explicitly `true`. |
| [`chatAdvancedFileAnalysisEnabled`](/docs/third-party/claude-desktop/configuration#chatadvancedfileanalysisenabled) | off | Allows code execution on attached files in the offline sandbox, as described above. Has no effect unless Chat is enabled. |

When `chatTabEnabled` is `true`, Claude Desktop presents Chat and Cowork together as **Home** in its sidebar, next to **Code**. From Home, the user chooses **Chat** or **Cowork** in the message box, and the sidebar lists chats and tasks together. When the key is unset or `false`, the sidebar shows **Cowork** in place of Home and the message box offers no choice. If [`coworkTabEnabled`](/docs/third-party/claude-desktop/configuration#coworktabenabled) is `false` while Chat is enabled, the message box offers Chat only.

<Note>
This layout applies to Claude Desktop 1.26832.0 and later. Earlier versions show **Chat** (when enabled), **Cowork**, and **Code** as separate tabs, controlled by the same keys.
</Note>

Enforcement of `chatTabEnabled` happens in the app's main process: when the key is unset or `false`, Chat does not appear in the app, and the app additionally refuses to start or continue a Chat conversation, including conversations created before an admin turned the key off.

The rule that at least one surface must stay enabled counts Chat only when `chatTabEnabled` is explicitly `true`: a configuration that disables Cowork and Code without enabling Chat re-enables Cowork with a validation warning, rather than leaving users with an empty app. With `chatTabEnabled` set to `true`, a chat-only configuration is valid.

## Where Chat data lives

Chat conversations are stored on the local device, in the same per-session layout as Cowork sessions: conversation history, attachment copies, scratch outputs, and a tamper-evident audit log, all under the application-data directory. Nothing is synced to a server, and there is no server-side index of past conversations. See [Chat conversations](/docs/third-party/claude-desktop/data-storage#chat-conversations) on the data-storage page for the breakdown.

third-party/claude-desktop/claude-api First recorded · 21 lines, first recorded

# Deploy Claude Desktop on 3P with the Claude API ## Choose an authentication approach ## Configure the app ### Configuration keys

The first capture of this source. The page was already there, and this is what it said.

# Deploy Claude Desktop on 3P with the Claude API

> Configure Claude Desktop on 3P to send inference directly to Anthropic's Claude API instead of a cloud-provider-hosted Claude deployment

To use Anthropic's Claude API directly as the inference provider, set [`inferenceProvider`](/docs/third-party/claude-desktop/configuration#inferenceprovider) to `anthropic` and supply an API key as described below. This is the first-party path: inference goes straight to Anthropic rather than to a Claude deployment hosted in your Amazon, Google, or Microsoft tenancy.

<Note>
  When `inferenceProvider` is `anthropic`, inference traffic goes to Anthropic's API endpoints rather than staying within your cloud provider. The data-residency and compliance statements on these pages do not apply to this option.
</Note>

## Choose an authentication approach

A static API key in the managed configuration is the simplest path. For environments where static API keys aren't permitted, set [`inferenceCredentialHelper`](/docs/third-party/claude-desktop/configuration#inferencecredentialhelper) to an executable that fetches a short-lived credential at runtime; see [Write a credential helper](/docs/third-party/claude-desktop/credential-helper).

## Configure the app

### Configuration keys

| Setting                                                                              | Type     | Availability    | Default | Description                                                                                   |
| ------------------------------------------------------------------------------------ | -------- | --------------- | ------- | --------------------------------------------------------------------------------------------- |
| <span id="inferenceanthropicapikey" />Claude API key<br />`inferenceAnthropicApiKey` | `string` | MDM + Bootstrap | —       | Leave blank to fetch a key via browser sign-in, or to supply the key via a credential helper. |

third-party/claude-desktop/code First recorded · 66 lines, first recorded

# Code in Claude Desktop on 3P ## How configuration propagates ### Always applied ### Applied as managed policy ## Interaction with Claude Code's own managed settings ## Further reading ## Disabling Code

The first capture of this source. The page was already there, and this is what it said.

# Code in Claude Desktop on 3P

> How Claude Desktop on 3P configuration applies to the embedded Claude Code engine

Code in Claude Desktop on third-party (3P) is the embedded [Claude Code](https://code.claude.com/docs/en/overview) interface. It runs the same Claude Code engine as the standalone CLI, with a graphical session manager, and it inherits your Claude Desktop on 3P configuration automatically.

## How configuration propagates

When the app starts a Code session, it translates your Claude Desktop on 3P [configuration keys](/docs/third-party/claude-desktop/configuration) into the equivalent Claude Code settings and passes them to the session. You configure one profile, and Cowork and Code both honor it.

Each key reaches Claude Code through one of two mechanisms, and the distinction matters if you also deploy Claude Code's own managed settings (see [the next section](#interaction-with-claude-code%E2%80%99s-own-managed-settings)).

### Always applied

These keys are passed directly to the Claude Code process as environment variables or launch options. They take effect on every Code session and cannot be overridden by user-level Claude Code settings or by a separately deployed `managed-settings.json`.

| Claude Desktop on 3P key                                                                                                                                               | Effect in Code sessions                                                                                                                                                                                                  |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `inferenceProvider` and all provider credential keys (`inferenceGateway*`, `inferenceVertex*`, `inferenceBedrock*`, `inferenceFoundry*`, `inferenceCredentialHelper*`) | Selects the inference backend and supplies credentials. Code sessions use the same provider, endpoint, and credentials as Cowork sessions.                                                                               |
| `inferenceModels`                                                                                                                                                      | Populates the model picker. The first entry is the default for new Code sessions.                                                                                                                                        |
| `autoModeEnabled`                                                                                                                                                      | Offers **Auto mode** in the Code session's permission selector. A separately deployed Claude Code managed-settings file that sets `disableAutoMode` to `"disable"` overrides this and keeps Auto mode hidden; see below. |
| `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.                                              |
| `builtinToolPolicy`                                                                                                                                                    | Tools set to `"ask"` require approval on each call in Code sessions, enforced via a PreToolUse hook and Claude Code `permissions.ask` rules.                                                                             |
| `managedMcpServers`                                                                                                                                                    | Makes the same managed MCP servers available in Code sessions. The app handles the connection and authentication; the Code session sees only the resulting tool list.                                                    |
| `otlpEndpoint`, `otlpProtocol`, `otlpHeaders`, `otlpResourceAttributes`                                                                                                | Routes Claude Code's OpenTelemetry metrics and logs to your collector. See [Telemetry](/docs/third-party/claude-desktop/telemetry).                                                                                           |
| `disableEssentialTelemetry`, `disableNonessentialTelemetry`                                                                                                            | Disables Claude Code's crash reporting and usage telemetry to Anthropic, mirroring Cowork.                                                                                                                               |
| `disableAutoUpdates`                                                                                                                                                   | The embedded Claude Code engine never self-updates regardless of this key; its version is managed by the app's own updater.                                                                                              |
| `inferenceMaxTokensPerWindow`, `inferenceTokenWindowHours`                                                                                                             | The token budget is shared across Cowork and Code sessions and enforced before each turn.                                                                                                                                |

### Applied as managed policy

These keys are translated into Claude Code [managed settings](https://code.claude.com/docs/en/settings#settings-files) and supplied to the session as policy. They take precedence over user and project settings, but they participate in Claude Code's managed-settings precedence if you have also deployed a separate Claude Code policy.

| Claude Desktop on 3P key   | Claude Code policy it produces                                                                                                                                                                                                                                                                                                                               |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `coworkEgressAllowedHosts` | A network sandbox restricted to your hosts plus the inference and telemetry endpoints, `WebFetch` permission rules for the same hosts, and `allowManagedDomainsOnly`.                                                                                                                                                                                        |
| `allowedWorkspaceFolders`  | A filesystem sandbox (`sandbox.filesystem.allowRead` with `allowManagedReadPathsOnly`) scoped to your allowed roots. The roots are also passed as `additionalDirectories` at launch, which is always applied independent of managed-settings precedence. The app also refuses to start a Code session outside an allowed root.                               |
| `managedMcpServers`        | An `allowedMcpServers` list containing only your managed servers, with `allowManagedMcpServersOnly` set so users cannot add their own from Claude Code's side. 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. |

## Interaction with Claude Code's own managed settings

Claude Code can also be configured directly by deploying a [`managed-settings.json` file](https://code.claude.com/docs/en/settings#settings-files), an OS configuration profile for Claude Code, or (with Anthropic authentication) server-managed settings. If a device has any of these, Claude Code treats it as the administrator policy and, by default, **ignores** the policy values Claude Desktop supplies from the [Applied as managed policy](#applied-as-managed-policy) table. The [Always applied](#always-applied) keys are unaffected.

To have Claude Desktop's restrictions apply on top of your Claude Code policy, set `parentSettingsBehavior` to `"merge"` in the Claude Code managed settings you deploy:

```json managed-settings.json theme={null}
{
  "parentSettingsBehavior": "merge"
}
```

With `"merge"`, Claude Desktop's policy values are layered under your Claude Code policy. Your values win any conflict, deny and allow lists are unioned, and Claude Desktop's values are filtered so they can only tighten policy, never loosen it. See [`parentSettingsBehavior`](https://code.claude.com/docs/en/settings#available-settings) in the Claude Code settings reference. Requires Claude Code v2.1.133 or later, which ships with Claude Desktop on 3P.

<Note>
  In a third-party deployment there is no Anthropic authentication, so Claude Code's server-managed settings tier is never present. If you have not separately deployed a Claude Code `managed-settings.json` or OS profile, Claude Desktop's policy applies automatically and you do not need to set `parentSettingsBehavior`.
</Note>

## Further reading

* [Claude Code settings reference](https://code.claude.com/docs/en/settings)
* [Claude Code sandboxing](https://code.claude.com/docs/en/sandboxing)
* [Settings precedence](https://code.claude.com/docs/en/settings#settings-precedence)

## Disabling Code

To turn off Code, set `isClaudeCodeForDesktopEnabled` to `false` in your Claude Desktop on 3P configuration. Users can no longer open Code. Cowork is unaffected, and so is [Chat](/docs/third-party/claude-desktop/chat#configuration) if you have enabled it.

third-party/claude-desktop/configuration First recorded · 824 lines, first recorded

# Configuration reference ## How keys are read ### Value types ### Linux ## Reference ## Connection ### Anthropic ### Bedrock ### Foundry ### Gateway ### Models ### Vertex ## Workspace ### Authentication ### Chat surface ### Code surface ### Cowork surface ### Workspace ## Connectors ### Authentication ### Extensions ### MCP ## Telemetry & updates ### Auto update ### OTLP ## Limits ### Token limits ## Appearance ### Feature discovery ## Plugins ## Source ### Bootstrap ## Guides ### Recommended security profiles ### Tool permissions for managed MCP servers

The first capture of this source. The page was already there, and this is what it said.

# Configuration reference

> Every managed-configuration key Claude Desktop on 3P supports, what it controls, and recommended security profiles

<Tip>Most settings on this page are easier to configure in the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration). Use this reference when you're scripting an MDM policy or bootstrap response by hand.</Tip>

Claude Desktop on third-party (3P) is configured entirely through OS-native managed preferences: a `.mobileconfig` profile on macOS, registry policy on Windows, or a root-owned JSON file on Linux. This page documents every supported key. For the desktop release each key first appeared in, see the [configuration changelog](/docs/third-party/claude-desktop/configuration-changelog).

The easiest way to author a configuration is the in-app configuration window (**Developer → Configure Third-Party Inference…**), which validates values, shows per-provider requirements, and exports directly to `.mobileconfig` or `.reg`. Use this reference when you need to author policy by hand, audit an existing profile, or understand exactly what a key does.

## How keys are read

| Platform | Managed (MDM) location                                                            | Local (user) location                                    |
| -------- | --------------------------------------------------------------------------------- | -------------------------------------------------------- |
| macOS    | `/Library/Managed Preferences/<user>/com.anthropic.claudefordesktop.plist`        | `~/Library/Application Support/Claude-3p/configLibrary/` |
| Windows  | `HKLM\SOFTWARE\Policies\Claude` (machine), `HKCU\SOFTWARE\Policies\Claude` (user) | `%LOCALAPPDATA%\Claude-3p\configLibrary\`                |
| Linux    | `/etc/claude-desktop/managed-settings.json`                                       | `~/.config/Claude-3p/configLibrary/`                     |

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

When a managed source is present, it wins and locally written values are ignored. The exception is a managed source that sets only the update keys (`disableAutoUpdates` and `autoUpdaterEnforcementHours`): those two keys are enforced from the managed source, but the rest of the configuration stays local and user-editable. Configuration is read **once at launch**, so fully quit and reopen the app after any change. 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.

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

### Value types

Write every value as a **string** in the OS preference store, even booleans and arrays.

| Documented type  | What to write                                                          | Example                                       |
| ---------------- | ---------------------------------------------------------------------- | --------------------------------------------- |
| string           | Plain string                                                           | `vertex`                                      |
| boolean          | `"true"` or `"false"` (or `1` / `0`)                                   | `"true"`                                      |
| integer          | Decimal string                                                         | `"3600"`                                      |
| string\[] (JSON) | JSON array **encoded as a string** (not a native plist/registry array) | `["claude-sonnet-5","claude-opus-5"]`         |
| object (JSON)    | JSON object mapping name to value, as a string                         | `{"X-Org-Id":"team1"}`                        |
| object\[] (JSON) | JSON array of objects, as a string                                     | see [`managedMcpServers`](#managedmcpservers) |

<Warning>
  The most common configuration mistake is writing array- or object-typed keys as native plist/registry structures. Keys like `inferenceModels`, `inferenceGatewayOidc`, `managedMcpServers`, `coworkEgressAllowedHosts`, and `otlpHeaders` must be **JSON strings**. In a `.mobileconfig`, that means a single `<string>` element containing `[...]` or `{...}` — not an `<array>`, not a `<dict>`, and not separate keys with dotted names like `inferenceGatewayOidc.clientId`.
</Warning>

On Windows, write registry values as `REG_SZ`, directly under the policy key rather than nested in a subkey (the app never reads subkeys). `REG_DWORD` is also accepted for boolean and integer keys and is read as its decimal value. Avoid `REG_EXPAND_SZ`: the app counts it toward machine policy being present but cannot read its contents. The app cannot see `REG_QWORD`, `REG_MULTI_SZ`, or `REG_BINARY` values at all.

### Linux

The managed source on Linux is a single JSON file, `/etc/claude-desktop/managed-settings.json`, with keys at the top level exactly as named in the [reference](#reference) — no wrapper object, no nesting:

```json theme={null}
{
  "inferenceProvider": "gateway",
  "inferenceGatewayBaseUrl": "https://gateway.example.com/v1",
  "inferenceGatewayApiKey": "sk-example",
  "inferenceCustomHeaders": { "X-Tenant-Id": "acme" }
}
```

Because the file is real JSON, array- and object-typed keys use native JSON values — the string-encoding rule above applies to plist and registry sources only. (String-encoded values are also accepted, so a profile generated for another platform can be reused.)

The file is only honored when it can't be edited by the user it configures:

* `managed-settings.json` must be a regular file (not a symlink), owned by root, and not group- or world-writable.
* `/etc/claude-desktop` itself must be a directory (not a symlink), owned by root, and not group- or world-writable.

A file that fails these checks is rejected: none of its settings are applied, the app treats the device as managed but unreadable, and local settings are also disabled until the file is fixed and the app is relaunched. The reason is logged to `main.log` in the app's logs directory — `~/.config/Claude/logs/` (or `~/.config/Claude-3p/logs/` once the app is running in 3P mode); search for `managed-settings.json`. The same log names any key that fails schema validation.

There is no per-user managed location on Linux; per-user configuration goes through the in-app configuration window, which writes to the local `configLibrary` directory above.

## Reference

The reference below is generated from the configuration schema and grouped to match the sidebar of the in-app configuration window. The **Availability** column shows whether a key can be set in an MDM profile, returned from a [bootstrap server](/docs/third-party/claude-desktop/bootstrap), or both.

## Connection

| Setting                                                                                                                                          | Type      | Availability    | Default | Description                                                                                                                                                                        |
| ------------------------------------------------------------------------------------------------------------------------------------------------ | --------- | --------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <span id="inferencecustomheaders" />Custom inference headers<br />`inferenceCustomHeaders`                                                       | `object`  | MDM + Bootstrap | —       | Extra HTTP headers sent on every inference request to the configured provider. For tenant routing, org IDs, Bedrock Guardrails, etc. Previously named `inferenceGatewayHeaders`.   |
| <span id="inferencesessionlifetimesec" />Sign-in session lifetime<br />`inferenceSessionLifetimeSec`                                             | `integer` | MDM + Bootstrap | —       | How long a sign-in stays valid under your IdP’s session policy. Shows a re-authenticate banner before it expires.                                                                  |
| <span id="inferencecredentialhelper" />Helper script<br />`inferenceCredentialHelper`                                                            | `string`  | MDM + Bootstrap | —       | Absolute path to an executable that prints the credential, optionally with per-request headers.                                                                                    |
| <span id="inferencecredentialhelperttlsec" />Helper script TTL<br />`inferenceCredentialHelperTtlSec`                                            | `integer` | MDM + Bootstrap | `3600`  | Helper output is cached for this many seconds. Re-runs at the next session start after expiry. Defaults to `3600`.                                                                 |
| <span id="inferencecredentialhelpertimeoutsec" />Credential helper timeout<br />`inferenceCredentialHelperTimeoutSec`                            | `integer` | MDM + Bootstrap | `60`    | Maximum wait for the helper executable to finish. Raise this if the helper opens a browser for interactive sign-in. Defaults to `60`. Range: 1–600.                                |
| <span id="inferencecredentialhelpersilentrefreshenabled" />Re-run helper for silent refresh<br />`inferenceCredentialHelperSilentRefreshEnabled` | `boolean` | MDM + Bootstrap | `true`  | On credential expiry, re-run the helper (CLAUDE\_HELPER\_CONTEXT=mid-session-refresh) to recover silently. Turn off if the helper can’t run non-interactively. Defaults to `true`. |
| <span id="usercontentrendererurl" />Artifact preview iframe origin<br />`userContentRendererUrl`                                                 | `string`  | MDM + Bootstrap | —       | HTTPS origin of the user-content-renderer deployment used for artifact and file previews. Defaults to the commercial host when unset.                                              |
| <span id="inferenceprovider" />Inference provider<br />`inferenceProvider`                                                                       | `enum`    | MDM + Bootstrap | —       | Selects the inference backend. Setting this key activates third-party mode. One of: `gateway`, `anthropic`, `bedrock`, `mantle`, `vertex`, `foundry`.                              |
| <span id="inferencecredentialkind" />Credential kind<br />`inferenceCredentialKind`                                                              | `enum`    | MDM + Bootstrap | —       | Selects the credential source. When set, only that source is used (no fallback). One of: `static`, `helper-script`, `interactive`, `vendor-profile`, `oauth`, `workforce`.         |

<AccordionGroup>
  <Accordion title="inferenceCustomHeaders details">
    Sent on every inference and model-discovery request (joined into the CLI's `ANTHROPIC_CUSTOM_HEADERS`).

    Use this for fleet-wide constants. For per-user or per-session values, have the **credential helper script** emit JSON with a `headers` field; those are merged over these static entries (helper wins on conflict).
  </Accordion>

  <Accordion title="inferenceCredentialHelper details">
    Claude runs the executable with no arguments and reads **stdout** (trimmed). Exit code must be `0`; any output on **stderr** is logged but ignored. **Stdout must contain only one of the formats below** (no banners, prompts, or log lines).

    **Output format** is either:

    * a single bare token (the API key / bearer token), or
    * a JSON object `{"token": "...", "headers": {"Name": "Value", ...}}` when per-request headers are needed (merged over **Custom inference headers**, helper wins on conflict)

    The helper receives `CLAUDE_HELPER_CONTEXT` in its environment (`interactive`, `mid-session-refresh`, `background`, `scheduled-task`, `setup-test`) so it can decide whether to prompt the user — see the credential-helper docs for the full contract.

    Result is cached for the TTL below. On TTL expiry the helper is re-invoked transparently (no user prompt, no relaunch).

    **Expiry and refresh:** the app checks the active credential's expiry before each turn and refreshes silently when possible (re-runs the helper, or uses the stored refresh token for interactive sign-in kinds). If the provider returns HTTP 401 mid-turn, the same silent refresh is attempted before surfacing an error. When silent refresh fails, a prompt appears with a provider-specific action (re-sign-in for interactive kinds; admin-contact for static credentials). Applies to all providers, and to both Cowork and Code.

    **Typical use:** a shell script that pulls from Keychain, 1Password CLI, or an internal secret broker. Example:

    `security find-generic-password -s anthropic-api -w`

    If this field is set, static credential fields (API key, bearer token) are ignored. The helper always wins.
  </Accordion>

  <Accordion title="inferenceProvider details">
    The app activates 3P mode only when this is set and the required credential keys for the selected provider are present and valid; otherwise it launches in standard mode. Keys for providers other than the selected one are ignored. Each provider's required keys are documented on its dedicated page under Inference providers.
  </Accordion>
</AccordionGroup>

### Anthropic

| Setting                                                                              | Type     | Availability    | Default | Description                                                                                   |
| ------------------------------------------------------------------------------------ | -------- | --------------- | ------- | --------------------------------------------------------------------------------------------- |
| <span id="inferenceanthropicapikey" />Claude API key<br />`inferenceAnthropicApiKey` | `string` | MDM + Bootstrap | —       | Leave blank to fetch a key via browser sign-in, or to supply the key via a credential helper. |

### Bedrock

| Setting                                                                                          | Type     | Availability    | Default | Description                                                                                                       |
| ------------------------------------------------------------------------------------------------ | -------- | --------------- | ------- | ----------------------------------------------------------------------------------------------------------------- |
| <span id="inferencebedrockregion" />AWS region<br />`inferenceBedrockRegion`                     | `string` | MDM + Bootstrap | —       | AWS region for the Bedrock runtime endpoint.                                                                      |
| <span id="inferencebedrockbaseurl" />Bedrock base URL<br />`inferenceBedrockBaseUrl`             | `string` | MDM + Bootstrap | —       | For VPC endpoints or gateway proxies. Host origin only.                                                           |
| <span id="inferencebedrockservicetier" />Bedrock service tier<br />`inferenceBedrockServiceTier` | `enum`   | MDM + Bootstrap | —       | Sent as the X-Amzn-Bedrock-Service-Tier header. Leave unset for on-demand. One of: `flex`, `priority`.            |
| <span id="inferencebedrockbearertoken" />AWS bearer token<br />`inferenceBedrockBearerToken`     | `string` | MDM + Bootstrap | —       | Static bearer token for inference. For providers that support profile or helper-script credentials, prefer those. |
| <span id="inferencebedrockssostarturl" />AWS SSO start URL<br />`inferenceBedrockSsoStartUrl`    | `string` | MDM + Bootstrap | —       | Enables in-app AWS sign-in (no AWS CLI needed). Set with the three SSO fields below.                              |
| <span id="inferencebedrockssoregion" />AWS SSO region<br />`inferenceBedrockSsoRegion`           | `string` | MDM + Bootstrap | —       | IAM Identity Center home region.                                                                                  |
| <span id="inferencebedrockssoaccountid" />AWS SSO account ID<br />`inferenceBedrockSsoAccountId` | `string` | MDM + Bootstrap | —       | 12-digit AWS account ID assigned to users in IAM Identity Center.                                                 |
| <span id="inferencebedrockssorolename" />AWS SSO role name<br />`inferenceBedrockSsoRoleName`    | `string` | MDM + Bootstrap | —       | IAM Identity Center permission-set name granting bedrock:InvokeModel\* on the account above.                      |
| <span id="inferencebedrockprofile" />AWS profile name<br />`inferenceBedrockProfile`             | `string` | MDM + Bootstrap | —       | AWS named profile to use for Bedrock inference credentials.                                                       |
| <span id="inferencebedrockawsdir" />AWS config directory<br />`inferenceBedrockAwsDir`           | `string` | MDM + Bootstrap | —       | Folder with AWS config/credentials. Defaults to \~/.aws when no bearer token is set.                              |
| <span id="inferencebedrockawsclipath" />AWS CLI path<br />`inferenceBedrockAwsCliPath`           | `string` | MDM + Bootstrap | —       | Absolute path to the aws executable. Leave unset to find it on PATH.                                              |

<AccordionGroup>
  <Accordion title="inferenceBedrockServiceTier details">
    Tier availability varies by model and region. Reserved capacity uses a provisioned-throughput ARN as the model ID instead of this setting. Older bundled Claude Code CLI versions ignore this key.
  </Accordion>
</AccordionGroup>

### Foundry

| Setting                                                                                              | Type     | Availability    | Default | Description                                                                                                                           |
| ---------------------------------------------------------------------------------------------------- | -------- | --------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| <span id="inferencefoundryresource" />Azure AI Foundry resource name<br />`inferenceFoundryResource` | `string` | MDM + Bootstrap | —       | Azure AI Foundry resource name used to construct the endpoint URL.                                                                    |
| <span id="inferencefoundryapikey" />Azure AI Foundry API key<br />`inferenceFoundryApiKey`           | `string` | MDM + Bootstrap | —       | API key for Azure AI Foundry inference.                                                                                               |
| <span id="inferencefoundrytenantid" />Entra ID tenant ID<br />`inferenceFoundryTenantId`             | `string` | MDM + Bootstrap | —       | Directory (tenant) ID of the Entra ID app registration that has the Cognitive Services scope.                                         |
| <span id="inferencefoundryclientid" />Entra ID client ID<br />`inferenceFoundryClientId`             | `string` | MDM + Bootstrap | —       | Application (client) ID of the Entra ID app registration. Device-code sign-in requires the app to allow public client flows.          |
| <span id="inferencefoundryauthflow" />Entra ID sign-in flow<br />`inferenceFoundryAuthFlow`          | `enum`   | MDM + Bootstrap | —       | How Entra sign-in runs: device code (default), system browser, or the OS identity broker. One of: `device-code`, `browser`, `broker`. |

<AccordionGroup>
  <Accordion title="inferenceFoundryAuthFlow details">
    * **`device-code`** (default) — shows a code to enter at microsoft.com/devicelogin. The app registration must have **Allow public client flows** enabled.
    * **`browser`** — opens the system browser for an authorization-code (PKCE) sign-in on a loopback redirect URI. The app registration must include `http://127.0.0.1/callback` under the **Mobile and desktop applications** platform (Entra ignores the loopback port, but not the path). Works with **Allow public client flows** disabled, and is unaffected by Conditional Access policies that block device-code authentication.
    * **`broker`** — signs in through the OS identity broker (Web Account Manager on Windows, Company Portal on macOS), so it can satisfy Conditional Access policies that require a compliant/managed device or token protection. The app registration must include the broker redirect URIs `ms-appx-web://Microsoft.AAD.BrokerPlugin/{client-id}` (Windows) and `msauth.com.anthropic.claudefordesktop://auth` (macOS) under the **Mobile and desktop applications** platform. Not supported on Linux.

    App versions that predate this key always use device code; versions that predate the broker option treat `broker` as unset and use device code.
  </Accordion>
</AccordionGroup>

### Gateway

| Setting                                                                                            | Type     | Availability    | Default  | Description                                                                                                                                      |
| -------------------------------------------------------------------------------------------------- | -------- | --------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| <span id="inferencegatewaybaseurl" />Gateway base URL<br />`inferenceGatewayBaseUrl`               | `string` | MDM + Bootstrap | —        | Full URL of the inference gateway endpoint.                                                                                                      |
| <span id="inferencegatewayapikey" />Gateway API key<br />`inferenceGatewayApiKey`                  | `string` | MDM + Bootstrap | —        | API key for the configured inference gateway.                                                                                                    |
| <span id="inferencegatewayauthscheme" />Gateway auth scheme<br />`inferenceGatewayAuthScheme`      | `enum`   | MDM + Bootstrap | `bearer` | How the gateway credential is sent on the wire (Authorization: Bearer vs x-api-key header). One of: `bearer`, `x-api-key`. Defaults to `bearer`. |
| <span id="inferencegatewayoidcauthflow" />Gateway sign-in flow<br />`inferenceGatewayOidcAuthFlow` | `enum`   | MDM + Bootstrap | —        | How the IdP sign-in runs: system browser (default) or the OS Microsoft Entra broker. One of: `browser`, `broker`.                                |
| <span id="inferencegatewayoidc" />Gateway SSO IdP (OIDC)<br />`inferenceGatewayOidc`               | `object` | MDM + Bootstrap | —        | External IdP for gateway sign-in. The user’s token from this issuer is sent to the gateway as the Bearer credential.                             |

<AccordionGroup>
  <Accordion title="inferenceGatewayOidcAuthFlow details">
    * **`browser`** (default) — opens the system browser for an authorization-code (PKCE) sign-in on a loopback redirect URI. See the **IdP setup** notes on `inferenceGatewayOidc` for redirect-URI registration.
    * **`broker`** — signs in through the OS identity broker (Web Account Manager on Windows, Company Portal on macOS). Requires the IdP to be **Microsoft Entra ID** — the `issuer` on `inferenceGatewayOidc` must be `https://login.microsoftonline.com/{tenant-id}/v2.0`. The broker satisfies Conditional Access policies that require a compliant/managed device or token protection, and needs no `127.0.0.1/callback` loopback redirect. The Entra app registration must include the broker redirect URIs `ms-appx-web://Microsoft.AAD.BrokerPlugin/{client-id}` (Windows) and `msauth.com.anthropic.claudefordesktop://auth` (macOS) under the **Mobile and desktop applications** platform. Not supported on Linux.

    Broker mode mints a token in the customer's own Entra tenant with the customer-configured `scopes`, and forwards it to the customer's own gateway; both endpoints of that trust relationship are inside the customer's control.
  </Accordion>

  <Accordion title="inferenceGatewayOidc details">
    **External IdP mode.** The app discovers `<issuer>/.well-known/openid-configuration`, runs an OIDC authorization-code-with-PKCE flow in the system browser with `clientId`, and sends the resulting token as `Authorization: Bearer` on every inference request — see **Bearer token type** below for how the gateway validates it.

    **Bearer token type.** `id_token` (the default) sends the OIDC ID token — the gateway validates signature + `iss` + `aud`, where `aud` is the `clientId` configured here. `access_token` sends the OAuth access token — the gateway validates as an OAuth resource server against the audience/scope the IdP issued the token for; set `scopes` to the gateway's registered API scope (required in this mode). Use `access_token` for gateways that expect a resource-server token (Portkey, Kong, Envoy JWT filter, AWS API Gateway authorizers).

    **The gateway MUST validate `iss` AND `aud`, not just the signature.** Signature + issuer alone accepts *any* token from the same tenant, including tokens issued to unrelated apps. In `id_token` mode the audience is the `clientId`:

    ```yaml theme={null}
    # LiteLLM example — `audience` is REQUIRED, not optional
    general_settings:
      litellm_jwtauth:
        public_key_url: https://login.microsoftonline.com/<tenant>/discovery/v2.0/keys
        audience: <clientId>           # ⚠ omitting this accepts any token from the tenant
    ```

    **IdP setup.** The app's loopback callback binds `http://127.0.0.1:<port>/callback` (RFC 8252 §7.3). Register `127.0.0.1`; most IdPs do **not** treat `localhost` and `127.0.0.1` as interchangeable. **Entra:** register a public-client app, add a *Mobile and desktop applications* redirect URI of `http://127.0.0.1/callback`. (Microsoft's docs say the path is wildcarded for loopback; in practice it is not: `http://127.0.0.1` without `/callback` fails with `AADSTS50011`. The port IS wildcarded.) Grant `openid profile email offline_access` (delegated, no admin consent); in `access_token` mode **also** add the gateway API's delegated permission under *API permissions* (and ensure the gateway's own app registration exposes that scope via *Expose an API*) — without it Entra rejects the sign-in with `AADSTS65001`. **Okta:** register a *Native* app with the exact redirect URI `http://127.0.0.1:<port>/callback` and set `redirectPort` here to that port (Okta requires an exact match).

    **Refresh:** `offline_access` returns a refresh token; the app refreshes the bearer silently before expiry. When refresh fails (revoked, idle past the IdP's window), the user re-authenticates in the browser. **Google Workspace caveat (`id_token` mode only):** Google never returns `id_token` on a refresh-token grant, so a Google-backed gateway in `id_token` mode will prompt a browser sign-in roughly once per ID-token TTL (\~1h). Entra and Okta return a fresh `id_token` and are unaffected; `access_token` mode is unaffected on all IdPs.

    **Leave this unset** for a gateway that hosts its own RFC 8414 metadata at `<baseUrl>/.well-known/oauth-authorization-server` (the original gateway-as-AS path).

    | Field                             | Type      | Default    | Description                                                                                                                                                |
    | --------------------------------- | --------- | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | `clientId`                        | `string`  | —          | OAuth client ID of the desktop app registration at your identity provider (public client, PKCE).                                                           |
    | `issuer`                          | `string`  | —          | HTTPS issuer with OIDC discovery. Set this, or set the authorization and token URLs instead.                                                               |
    | `authorizationUrl`                | `string`  | —          | HTTPS authorization endpoint. Used with the token URL when no issuer is set.                                                                               |
    | `tokenUrl`                        | `string`  | —          | HTTPS token endpoint. Used with the authorization URL when no issuer is set.                                                                               |
    | `bearerTokenType`                 | `enum`    | `id_token` | Which token to send as the gateway bearer. Use access token for gateways that validate as an OAuth resource server. One of: `id_token`, `access_token`.    |
    | `scopes`                          | `string`  | —          | Space-separated scopes. Required in access-token mode: set the gateway’s API scope. offline\_access is appended automatically unless disabled below.       |
    | `appendOfflineAccess`             | `boolean` | `true`     | Automatically append offline\_access to scopes so the IdP returns a refresh token for silent refresh.                                                      |
    | `resource`                        | `string`  | —          | Absolute URL identifying the gateway as the access-token audience. Sent as the RFC 8707 resource parameter when set; leave unset for Microsoft Entra ID.   |
    | `redirectPort`                    | `integer` | —          | Fixed loopback port for the sign-in redirect ([http://127.0.0.1:PORT/callback](http://127.0.0.1:PORT/callback)). Leave unset to use a free port each time. |
    | `additionalRedirectReferrerHosts` | `string`  | —          | Space-separated hostnames also accepted as the referrer of the sign-in callback. Only needed when the IdP completes sign-in from a different host.         |
  </Accordion>
</AccordionGroup>

### Models

| Setting                                                                             | Type       | Availability    | Default | Description                                                                                                           |
| ----------------------------------------------------------------------------------- | ---------- | --------------- | ------- | --------------------------------------------------------------------------------------------------------------------- |
| <span id="modeldiscoveryenabled" />Model discovery<br />`modelDiscoveryEnabled`     | `boolean`  | MDM + Bootstrap | —       | Auto-populate the model picker from the provider at launch.                                                           |
| <span id="modelprefer1mcontext" />Default to 1M context<br />`modelPrefer1mContext` | `boolean`  | MDM + Bootstrap | —       | When a user has no saved selection, start the picker on the 1M-context variant of the default model if it offers one. |
| <span id="inferencemodels" />Model list<br />`inferenceModels`                      | `object[]` | MDM + Bootstrap | —       | Override the auto-discovered model list. First entry is the default.                                                  |

<AccordionGroup>
  <Accordion title="modelDiscoveryEnabled details">
    Auto-populate the model picker from the provider's model-list endpoint at launch. For gateway and Anthropic providers, a config that doesn't set this key skips discovery automatically when the model list below already makes it unnecessary; the toggle here only sets it explicitly on or off. Turn off if the endpoint isn't reachable from your network, or to use a fixed list. When off, the model list below is required and must use full model IDs (aliases like sonnet/opus are resolved via discovery).
  </Accordion>

  <Accordion title="modelPrefer1mContext details">
    When a user has no saved selection, start the picker on the 1M-context variant of the default model (the first listed model, or the first model your endpoint returns under discovery) if it offers one. A saved selection is always kept; users who picked a model before this version need to pick the 1M row once, after which it persists. Equivalent to setting `prefer1m` on the default entry of `inferenceModels`, but also applies under dynamic discovery.
  </Accordion>

  <Accordion title="inferenceModels details">
    Use the **provider's exact model ID**: Vertex publisher IDs (`claude-sonnet-5`), Bedrock inference-profile IDs (`us.anthropic.claude-sonnet-5`), or Foundry deployment names. The first entry is the default. Entries may be plain ID strings or objects.

    **Gateway:** the `name` must be the exact ID your gateway's `/v1/models` endpoint returns. If you set `supports1m` on an alias (`sonnet`) but discovery returns the full ID, the variant won't appear.

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

    ```json theme={null}
    [{"name": "claude-sonnet-5", "supports1m": true}, "claude-opus-4-8"]
    ```

    **Default to 1M context** (`prefer1m`) makes the 1M-context variant the default picker selection when this entry is the default model (the first entry); users can still switch to the standard variant, and an explicit user pick is always kept. No effect without `supports1m`. Under dynamic discovery (no explicit list), the equivalent flat key in the **Models** group applies instead:

    ```json theme={null}
    [{"name": "claude-opus-4-8", "supports1m": true, "prefer1m": true}]
    ```

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

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

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

    ```json theme={null}
    [{"name": "us.anthropic.claude-opus-4-8", "anthropicFamilyTier": "opus"}]
    ```

    | Field                 | Type      | Default | Description                                                                                                                                                                    |
    | --------------------- | --------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
    | `name`                | `string`  | —       | Model ID exactly as the provider expects it. The first entry is the default model.                                                                                             |
    | `labelOverride`       | `string`  | —       | Shown in the model picker. Leave blank to auto-format from the ID.                                                                                                             |
    | `supports1m`          | `boolean` | —       | Adds a 1M-context variant of this model to the picker. Set only if the deployment accepts 1M-token context for it.                                                             |
    | `prefer1m`            | `boolean` | —       | Make the 1M-context variant the default picker selection when this model is the default (first) entry. Users can still choose the standard variant.                            |
    | `anthropicFamilyTier` | `enum`    | —       | Which Claude tier this model stands in for. Pins the bare alias (e.g. ‘opus’) and, for opus/fable, the refusal fallback. One of: `sonnet`, `opus`, `haiku`, `fable`, `mythos`. |
    | `isFamilyDefault`     | `boolean` | —       | When several models share a tier alias, marks this one as the model the alias resolves to. Otherwise the first listed wins.                                                    |
  </Accordion>
</AccordionGroup>

### Vertex

| Setting                                                                                                                        | Type     | Availability    | Default | Description                                                                                                                                         |
| ------------------------------------------------------------------------------------------------------------------------------ | -------- | --------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| <span id="inferencevertexprojectid" />GCP project ID<br />`inferenceVertexProjectId`                                           | `string` | MDM + Bootstrap | —       | Google Cloud project ID for Vertex AI inference.                                                                                                    |
| <span id="inferencevertexregion" />GCP region<br />`inferenceVertexRegion`                                                     | `string` | MDM + Bootstrap | —       | GCP region where your Vertex AI Claude models are deployed.                                                                                         |
| <span id="inferencevertexbaseurl" />Vertex AI base URL<br />`inferenceVertexBaseUrl`                                           | `string` | MDM + Bootstrap | —       | PSC endpoint, if using one.                                                                                                                         |
| <span id="inferencevertexoauthclientid" />Vertex OAuth client ID<br />`inferenceVertexOAuthClientId`                           | `string` | MDM + Bootstrap | —       | Desktop-app OAuth client ID. Enables Sign in with Google instead of a credentials file.                                                             |
| <span id="inferencevertexoauthclientsecret" />Vertex OAuth client secret<br />`inferenceVertexOAuthClientSecret`               | `string` | MDM + Bootstrap | —       | Secret for the Desktop-app OAuth client above.                                                                                                      |
| <span id="inferencevertexoauthscopes" />Vertex OAuth scopes<br />`inferenceVertexOAuthScopes`                                  | `string` | MDM + Bootstrap | —       | Override the Google OAuth scopes (space-separated). Leave blank for the default.                                                                    |
| <span id="inferencevertexoauthloginhint" />Vertex OAuth login hint<br />`inferenceVertexOAuthLoginHint`                        | `string` | MDM + Bootstrap | —       | Pre-fill Google's account chooser and forward to your federated IdP. \{username} expands to the OS login name.                                      |
| <span id="inferencevertexworkforceaudience" />Workforce Identity audience<br />`inferenceVertexWorkforceAudience`              | `string` | MDM + Bootstrap | —       | Workforce-pool provider audience. When set, sign-in uses your own IdP plus a GCP STS exchange instead of a Google identity.                         |
| <span id="inferencevertexworkforceuserproject" />Workforce Identity billing project<br />`inferenceVertexWorkforceUserProject` | `string` | MDM + Bootstrap | —       | GCP project for STS billing and quota. Defaults to the Vertex project ID above.                                                                     |
| <span id="inferencevertexworkforceauthflow" />Workforce Identity sign-in flow<br />`inferenceVertexWorkforceAuthFlow`          | `enum`   | MDM + Bootstrap | —       | How the IdP sign-in runs: system browser (default) or the OS Microsoft Entra broker. One of: `browser`, `broker`.                                   |
| <span id="inferencevertexworkforceoidc" />Workforce Identity IdP (OIDC)<br />`inferenceVertexWorkforceOidc`                    | `object` | MDM + Bootstrap | —       | Your organization’s OIDC IdP. The app runs an authorization-code-with-PKCE flow against this issuer and exchanges the returned ID token at GCP STS. |
| <span id="inferencevertexcredentialsfile" />GCP credentials file path<br />`inferenceVertexCredentialsFile`                    | `string` | MDM + Bootstrap | —       | Absolute path to service-account JSON. Leave blank to fall back to ADC.                                                                             |

<AccordionGroup>
  <Accordion title="inferenceVertexWorkforceAuthFlow details">
    * **`browser`** (default) — opens the system browser for an authorization-code (PKCE) sign-in on a loopback redirect URI. See the **IdP setup** notes on `inferenceGatewayOidc` for redirect-URI registration; the same rules apply here.
    * **`broker`** — signs in through the OS identity broker (Web Account Manager on Windows, Company Portal on macOS). Requires the workforce-pool IdP to be **Microsoft Entra ID** — the `issuer` on `inferenceVertexWorkforceOidc` must be `https://login.microsoftonline.com/{tenant-id}/v2.0`. The broker satisfies Conditional Access policies that require a compliant/managed device or token protection, and needs no `127.0.0.1/callback` loopback redirect. The Entra app registration must include the broker redirect URIs `ms-appx-web://Microsoft.AAD.BrokerPlugin/{client-id}` (Windows) and `msauth.com.anthropic.claudefordesktop://auth` (macOS) under the **Mobile and desktop applications** platform. Not supported on Linux.

Cut at 300 lines. The page has the rest.

third-party/claude-desktop/configuration-changelog First recorded · 722 lines, first recorded

# Configuration changelog

The first capture of this source. The page was already there, and this is what it said.

# Configuration changelog

> Managed configuration keys by the Claude Desktop release they first shipped in

Configuration keys by Claude Desktop release. Each section lists keys added in that release, with the MDM key name (for plist/registry deployment) and the equivalent JSON shape (for local-file or bootstrap remote configuration).

<Update label="v1.30096.1" description="2026-08-13">
  <div className="cfg-keys">
    | MDM key                                                                                           | Type     | Description                                                                                                                                                                            |
    | ------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | [`otlpAuthMode`](/docs/third-party/claude-desktop/configuration#otlpauthmode)                          | `enum`   | Collector authentication                                                                                                                                                               |
    | [`otlpHeadersHelper`](/docs/third-party/claude-desktop/configuration#otlpheadershelper)                | `string` | OpenTelemetry headers helper script                                                                                                                                                    |
    | [`inferenceGatewayOidc.resource`](/docs/third-party/claude-desktop/configuration#inferencegatewayoidc) | `string` | New subfield: RFC 8707 resource indicator sent on gateway sign-in and token refresh so the IdP audience-restricts the access token to the gateway; leave unset for Microsoft Entra ID. |
  </div>

  **JSON (e.g. for non-MDM users or Bootstrap):**

  ```json theme={null}
  {
    "otlp": {
      "authMode": "<none|inference-credential>",
      "headersHelper": "<string>"
    },
    "inference": {
      "credential": {
        "oidc": {
          "resource": "<string>"
        }
      }
    }
  }
  ```

  **Changed:**

  * `inferenceBedrockBaseUrl` and `inferenceVertexBaseUrl`: only affects users who entered the bootstrap server URL themselves (in Settings or a local config file). Those users are now asked once to allow a Bedrock or Vertex endpoint that server delivers (and again if it changes) before it takes effect, the same `trustBootstrapDelivery` consent prompt `inferenceGatewayBaseUrl` already shows; the provider's default endpoint is used until they allow it. Managed deployments (bootstrap URL set by device management, or `trustBootstrapDelivery: true`) see no change.
</Update>

<Update label="v1.28929.0" description="2026-08-11">
  <div className="cfg-keys">
    | MDM key                                                                                     | Type      | Description                                                                                                          |
    | ------------------------------------------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------- |
    | [`modelPrefer1mContext`](/docs/third-party/claude-desktop/configuration#modelprefer1mcontext)    | `boolean` | Default to 1M context                                                                                                |
    | [`claudeAiImport.enabled`](/docs/third-party/claude-desktop/configuration#claudeaiimport)        | `boolean` | New subfield: turns history import on; the banner and import actions stay off until set to `true` (default `false`). |
    | [`claudeAiImport.bannerBehavior`](/docs/third-party/claude-desktop/configuration#claudeaiimport) | `enum`    | New subfield: when the import banner appears: `off` (default), `detect`, or `show`.                                  |
  </div>

  **JSON (e.g. for non-MDM users or Bootstrap):**

  ```json theme={null}
  {
    "models": {
      "prefer1mContext": "<boolean>"
    },
    "claudeAiImport": {
      "enabled": "<boolean>",
      "bannerBehavior": "<off|detect|show>"
    }
  }
  ```

  **Changed:**

  * `inferenceGatewayBaseUrl` delivered by a bootstrap server now goes through the `trustBootstrapDelivery` consent prompt: unless the bootstrap URL came from device management or `trustBootstrapDelivery` is `true`, each user is asked once to allow the address, and again if it changes, before it takes effect.
</Update>

<Update label="v1.26832.0" description="2026-08-06">
  <div className="cfg-keys">
    | MDM key                                                                                               | Type      | Description                                                                             |
    | ----------------------------------------------------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------- |
    | [`updateViaUpdatesHost`](/docs/third-party/claude-desktop/configuration#updateviaupdateshost)              | `boolean` | Check for updates on releases.claude.com                                                |
    | [`allowedWorkspaceFolders[].mode`](/docs/third-party/claude-desktop/configuration#allowedworkspacefolders) | `enum`    | New subfield: `ro` makes the folder read-only in Cowork; Code enforces file tools only. |
  </div>

  **JSON (e.g. for non-MDM users or Bootstrap):**

  ```json theme={null}
  {
    "autoUpdate": {
      "viaUpdatesHost": "<boolean>"
    }
  }
  ```

  `trustBootstrapLocalExec` was renamed to `trustBootstrapDelivery`; the previous name is still accepted.
</Update>

<Update label="v1.25927.0" description="2026-08-04">
  <div className="cfg-keys">
    | MDM key                                                                                                          | Type      | Description                              |
    | ---------------------------------------------------------------------------------------------------------------- | --------- | ---------------------------------------- |
    | [`inferenceGatewayOidcAuthFlow`](/docs/third-party/claude-desktop/configuration#inferencegatewayoidcauthflow)         | `enum`    | Gateway sign-in flow                     |
    | [`inferenceVertexWorkforceAuthFlow`](/docs/third-party/claude-desktop/configuration#inferencevertexworkforceauthflow) | `enum`    | Workforce Identity sign-in flow          |
    | [`trustBootstrapLocalExec`](/docs/third-party/claude-desktop/configuration#trustbootstrapdelivery)                    | `boolean` | Trust bootstrap-delivered local commands |
    | [`skillCreationEnabled`](/docs/third-party/claude-desktop/configuration#skillcreationenabled)                         | `boolean` | Allow user-created skills                |
  </div>

  **JSON (e.g. for non-MDM users or Bootstrap):**

  ```json theme={null}
  {
    "inference": {
      "credential": {
        "authFlow": "<browser|broker>"
      }
    },
    "bootstrap": {
      "trustBootstrapLocalExec": "<boolean>"
    },
    "workspace": {
      "skillCreationEnabled": "<boolean>"
    }
  }
  ```

  **Changed:**

  * `claudeAiImport`, `deploymentDisplayName`, and `deploymentDisplaySubtitle` now accept values from MDM and a local configuration file as well as a bootstrap server, and `disableDeepLinkRegistration`, `microsoftAuthBroker`, `userContentRendererUrl`, `inferenceFoundryTenantId`, `inferenceFoundryClientId`, `inferenceCredentialHelper` (with its TTL, timeout, and silent-refresh keys), `inferenceBedrockProfile`, `inferenceBedrockAwsDir`, `inferenceBedrockAwsCliPath`, and `inferenceVertexCredentialsFile` can now be delivered by a bootstrap server. The keys that name a local executable go through the `trustBootstrapLocalExec` consent prompt.
  * `managedMcpServers` gains a built-in `github` server: set `server` to `github` and supply your own GitHub OAuth app client ID with the device flow enabled. The new `host`, `toolsets`, and `readOnly` subfields point the connector at a GitHub Enterprise Server instance, choose which toolsets load, and offer read tools only.
  * `managedMcpServers[].oauth.authFlow` is a new subfield that lets a managed connector sign in through the operating system's Microsoft Entra account broker on Windows and macOS, so Conditional Access policies that require a managed device no longer block it. Devices without a broker keep using browser sign-in.
  * `enduserAttribution` is renamed to the corrected spelling `endUserAttribution`. The previous spelling is still accepted and now records a configuration warning.
  * `organizationPluginsUrl` is deprecated and removed from the configuration reference. The key is still honored, but organization plugins are better configured with `allowedPluginMarketplaces`.
</Update>

<Update label="v1.24012.11" description="2026-08-03">
  No configuration changes in this release.
</Update>

<Update label="v1.24012.9" description="2026-07-24">
  <div className="cfg-keys">
    | MDM key                                                                                                        | Type      | Description                     |
    | -------------------------------------------------------------------------------------------------------------- | --------- | ------------------------------- |
    | [`mcpPersistentAlwaysAllowEnabled`](/docs/third-party/claude-desktop/configuration#mcppersistentalwaysallowenabled) | `boolean` | Allow persistent tool approvals |
  </div>

  **JSON (e.g. for non-MDM users or Bootstrap):**

  ```json theme={null}
  {
    "mcp": {
      "persistentAlwaysAllowEnabled": "<boolean>"
    }
  }
  ```
</Update>

<Update label="v1.24012.0" description="2026-07-21">
  <div className="cfg-keys">
    | MDM key                                                                                      | Type      | Description                    |
    | -------------------------------------------------------------------------------------------- | --------- | ------------------------------ |
    | [`enduserAttribution`](/docs/third-party/claude-desktop/configuration#enduserattribution)         | `boolean` | End-user attribution           |
    | [`userContentRendererUrl`](/docs/third-party/claude-desktop/configuration#usercontentrendererurl) | `string`  | Artifact preview iframe origin |
  </div>

  **JSON (e.g. for non-MDM users or Bootstrap):**

  ```json theme={null}
  {
    "deploymentDisplayName": "<string>",
    "deploymentDisplaySubtitle": "<string>",
    "enduserAttribution": "<boolean>",
    "userContentRendererUrl": "<string>"
  }
  ```
</Update>

<Update label="v1.22209.3" description="2026-07-19">
  No configuration changes in this release.
</Update>

<Update label="v1.22209.0" description="2026-07-16">
  <div className="cfg-keys">
    | MDM key                                                                            | Type      | Description          |
    | ---------------------------------------------------------------------------------- | --------- | -------------------- |
    | [`otlpTracesEnabled`](/docs/third-party/claude-desktop/configuration#otlptracesenabled) | `boolean` | Export traces (beta) |
  </div>

  **JSON (e.g. for non-MDM users or Bootstrap):**

  ```json theme={null}
  {
    "otlp": {
      "tracesEnabled": "<boolean>"
    }
  }
  ```
</Update>

<Update label="v1.21459.3" description="2026-07-16">
  No configuration changes in this release.
</Update>

<Update label="v1.21459.0" description="2026-07-14">
  <div className="cfg-keys">
    | MDM key                                                                                                            | Type      | Description                                                                                                  |
    | ------------------------------------------------------------------------------------------------------------------ | --------- | ------------------------------------------------------------------------------------------------------------ |
    | [`disableFeatureDiscovery`](/docs/third-party/claude-desktop/configuration#disablefeaturediscovery)                     | `boolean` | Hide feature announcements                                                                                   |
    | [`inferenceModels[].prefer1m`](/docs/third-party/claude-desktop/configuration#inferencemodels)                          | `boolean` | New subfield: make the 1M-context variant the default picker selection when this model is the default entry. |
    | [`managedMcpServers[].envHelper`](/docs/third-party/claude-desktop/configuration#managedmcpservers)                     | `string`  | New subfield: helper executable that prints environment variables as JSON for a managed stdio server.        |
    | [`managedMcpServers[].envHelperTtlSec`](/docs/third-party/claude-desktop/configuration#managedmcpservers)               | `integer` | New subfield: maximum age in seconds of a cached `envHelper` result (default 300).                           |
    | [`managedMcpServers[].headersHelperRefreshBufferSec`](/docs/third-party/claude-desktop/configuration#managedmcpservers) | `integer` | New subfield: how many seconds before credential expiry the `headersHelper` re-runs (default 60).            |
    | [`toolSearchEnabled`](/docs/third-party/claude-desktop/configuration#toolsearchenabled)                                 | `boolean` | Enable tool search                                                                                           |
  </div>

  **JSON (e.g. for non-MDM users or Bootstrap):**

  ```json theme={null}
  {
    "featureDiscovery": {
      "disabled": "<boolean>"
    },
    "workspace": {
      "toolSearchEnabled": "<boolean>"
    }
  }
  ```

  **Changed:**

  * `chatTabEnabled` and `chatAdvancedFileAnalysisEnabled` are no longer Beta: the Chat tab and advanced file analysis are generally available. Availability and defaults are unchanged, and both remain opt-in.
  * `orgPluginSettings[].tools.permission` accepts a new `ask-session` value. In this release the value is accepted but behaves as `ask` (a prompt on every use); the once-per-session approval flow is not yet enabled.
</Update>

<Update label="v1.20186.9" description="2026-07-14">
  No configuration changes in this release.
</Update>

<Update label="v1.20186.0" description="2026-07-09">
  No configuration changes in this release.
</Update>

<Update label="v1.19367.0" description="2026-07-07">
  <div className="cfg-keys">
    | MDM key                                                                                                | Type      | Description                                                                       |
    | ------------------------------------------------------------------------------------------------------ | --------- | --------------------------------------------------------------------------------- |
    | [`inferenceFoundryAuthFlow`](/docs/third-party/claude-desktop/configuration#inferencefoundryauthflow)       | `enum`    | Entra ID sign-in flow                                                             |
    | [`microsoftAuthBroker`](/docs/third-party/claude-desktop/configuration#microsoftauthbroker)                 | `enum`    | Microsoft 365 native sign-in broker                                               |
    | [`managedMcpServers[].startupTimeoutSec`](/docs/third-party/claude-desktop/configuration#managedmcpservers) | `integer` | New subfield: maximum wait in seconds for the server to start and list its tools. |
  </div>

  **JSON (e.g. for non-MDM users or Bootstrap):**

  ```json theme={null}
  {
    "inference": {
      "credential": {
        "authFlow": "<device-code|browser>"
      }
    },
    "authentication": {
      "microsoftAuthBroker": "<auto|disabled>"
    }
  }
  ```

  **Changed:**

  * `isDesktopExtensionEnabled` — default changed from `true` to `false`: Desktop Extensions (`.dxt`, `.mcpb`) no longer load unless explicitly enabled.
  * `allowedPluginMarketplaces` (beta) — can now be delivered per-user through the bootstrap server; previously MDM-only.
</Update>

<Update label="v1.18286.2" description="2026-07-07">
  No configuration changes in this release.
</Update>

<Update label="v1.18286.0" description="2026-07-02">
  **Removed:**

  * `disableDefaultPlugins` — third-party deployments always skip the default plugin marketplaces and standard deployments always include them, so the key no longer has an effect.
</Update>

<Update label="v1.17377.2" description="2026-07-01">
  No configuration changes in this release.
</Update>

<Update label="v1.17377.1" description="2026-06-30">
  <div className="cfg-keys">
    | MDM key                                                                                                                    | Type       | Description                                                                                                                              |
    | -------------------------------------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
    | [`allowedPluginMarketplaces`](/docs/third-party/claude-desktop/configuration#allowedpluginmarketplaces)                         | `object[]` | Admin-configured plugin marketplace git URLs appear under the Directory's Organization tab. (MDM-only; not settable via bootstrap JSON.) |
    | [`inferenceVertexWorkforceOidc.omitOfflineAccess`](/docs/third-party/claude-desktop/configuration#inferencevertexworkforceoidc) | `boolean`  | New subfield: omit `offline_access` from the OIDC scope request.                                                                         |
  </div>

  **JSON (Non-MDM User, Bootstrap Remote):**

  ```json theme={null}
  {
    "inference": {
      "credential": {
        "oidc": {
          "omitOfflineAccess": "<boolean>"
        }
      }
    }
  }
  ```
</Update>

<Update label="v1.15962.2" description="2026-06-30">
  No configuration changes in this release.

Cut at 300 lines. The page has the rest.

third-party/claude-desktop/connectors-github First recorded · 110 lines, first recorded

# Connect to GitHub ## Choose a connector ## Remote connector ## Local connector ### Set up the local connector ### How users sign in ### Control what Claude can do

The first capture of this source. The page was already there, and this is what it said.

# Connect to GitHub

> Give Claude access to your organization's GitHub repositories, issues, and pull requests, either through GitHub's hosted MCP server or a server built into the desktop app.

When Claude Desktop is deployed on third-party inference, Claude can work with your organization's GitHub data (repositories, issues, pull requests, and more) through GitHub's open-source [github-mcp-server](https://github.com/github/github-mcp-server). Two connectors are available: a [remote connector](#remote-connector), where the desktop app connects to GitHub's hosted copy of the server, and a [local connector](#local-connector), a copy of the server built into the desktop app. In both cases the device talks to GitHub directly; no GitHub data or tokens pass through Anthropic's infrastructure.

## Choose a connector

Both connectors expose the same family of GitHub tools; they differ in where the server runs and how users authenticate. Use this table to pick one, then follow that connector's section below.

|                          | Remote connector                                                                     | Local connector                                                                                                  |
| ------------------------ | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
| Where the server runs    | GitHub's infrastructure                                                              | On the user's device, bundled in the app                                                                         |
| Authentication           | A personal access token you issue and distribute                                     | OAuth device flow; no tokens to issue or distribute                                                              |
| Credential handling      | Token delivered through the entry's `headers` or a headers helper script             | User signs in; the token is acquired and stored encrypted on the device                                          |
| GitHub Enterprise Server | Not available; github.com only                                                       | Supported; set `host`                                                                                            |
| Tool surface controls    | Per-tool [`toolPolicy`](/docs/third-party/claude-desktop/configuration#managedmcpservers) | `toolsets`, `readOnly`, and per-tool [`toolPolicy`](/docs/third-party/claude-desktop/configuration#managedmcpservers) |
| Claude Desktop version   | Any version that supports managed MCP servers                                        | Requires a version that includes the bundled server (beta)                                                       |

## Remote connector

GitHub hosts a copy of github-mcp-server on its own infrastructure. Claude Desktop on 3P connects to it as a standard remote [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers) entry, authenticated with a GitHub personal access token: the device connects straight to GitHub's endpoint, and the token travels only in the request headers from the user's device.

```json theme={null}
{
  "name": "GitHub",
  "url": "https://api.githubcopilot.com/mcp/",
  "transport": "http",
  "headersHelper": "/opt/org/bin/github-token"
}
```

The `headersHelper` executable prints the request headers as a flat JSON object to stdout, for example `{"Authorization": "Bearer GITHUB_PAT"}`, and follows the execution model described under [short-lived credentials with a headers helper](/docs/third-party/claude-desktop/extensions#short-lived-credentials-with-a-headers-helper). Use it to fetch a per-user fine-grained token from your secrets manager. A static `headers` object also works, but it puts the same token on every device, so every session acts as that one identity; prefer the helper, a narrowly scoped fine-grained token, or the [local connector](#local-connector), which needs no tokens at all.

Check the endpoint URL, the supported authentication methods, and the token scopes your tools need against [GitHub's github-mcp-server documentation](https://github.com/github/github-mcp-server), which is the source of truth for the hosted server. GitHub Enterprise Server instances are not reachable through GitHub's hosted endpoint; use the local connector instead.

## Local connector

Claude Desktop includes a built-in copy of github-mcp-server and runs it as a local process when a `managedMcpServers` entry sets `server` to `github`. The server calls github.com, or your GitHub Enterprise Server instance, directly from the device.

Users sign in to GitHub from the app through the OAuth device flow, so there are no personal access tokens to issue, distribute, or rotate. You register one OAuth app in your GitHub organization and ship its client ID in the entry; each user then authorizes their own sign-in.

The local connector is in beta, and the in-app configuration window marks it with a **Beta** pill.

### Set up the local connector

<Steps>
  <Step title="Register a GitHub OAuth app">
    In your GitHub organization, open **Settings → Developer settings → OAuth Apps → New OAuth App** and register an app for Claude Desktop:

    1. Set **Application name** and **Homepage URL** to values your users will recognize on the authorization screen.
    2. Enter any valid URL as the **Authorization callback URL**. The device flow does not use a redirect, but GitHub requires the field.
    3. After registering, select **Enable Device Flow** on the app's settings page and save. Sign-in fails without it.
    4. Note the app's **Client ID**. Do not create a client secret; the device flow does not use one, and Claude Desktop never asks for it.

    A GitHub App works in place of an OAuth app: put its client ID in the same field. Its permissions come from the app registration itself (the entry's `scope` field is ignored), it must be installed where users need access, and its user tokens expire after about eight hours, so users sign in again more often than with an OAuth app.
  </Step>

  <Step title="Add the managed entry">
    In the Claude Desktop [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration), open **Connectors**, select **Add server**, and choose **GitHub** under the **Built-in** group. Enter the client ID from step 1, select **Test connection** to verify that the bundled server starts and lists its tools, and select **Save**.

    If you manage configuration through JSON or a plist directly, add an entry to [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers) with the `server` field set to `github`:

    ```json theme={null}
    {
      "name": "GitHub",
      "server": "github",
      "clientId": "OAUTH_APP_CLIENT_ID_FROM_STEP_1"
    }
    ```

    | Field        | Required | Description                                                                                                                                                                                               |
    | ------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | `name`       | Yes      | Unique display name, shown to users in connector settings.                                                                                                                                                |
    | `server`     | Yes      | Must be `github`.                                                                                                                                                                                         |
    | `clientId`   | Yes      | The client ID of the OAuth app (or GitHub App) from step 1.                                                                                                                                               |
    | `host`       | No       | Base URL of your GitHub Enterprise Server instance, for example `https://github.example.com`. Leave unset for github.com. HTTPS is required.                                                              |
    | `scope`      | No       | Space-separated OAuth scopes to request at sign-in, for example `repo read:org`. Defaults to `repo read:org read:user`. Ignored for GitHub Apps.                                                          |
    | `toolsets`   | No       | Comma-separated [github-mcp-server toolsets](https://github.com/github/github-mcp-server) to enable, for example `context,repos,issues,pull_requests`. Defaults to the bundled server's default toolsets. |
    | `readOnly`   | No       | `true` starts the server with read tools only; write tools are not registered at all.                                                                                                                     |
    | `toolPolicy` | No       | Per-tool approval locks, the same as for any managed server. See [`toolPolicy`](/docs/third-party/claude-desktop/configuration#managedmcpservers).                                                             |

    In the in-app configuration window, the GitHub form offers the client ID, GitHub Enterprise Server URL, toolsets, and read-only fields; set `scope` through exported JSON or your device-management tool if you need a non-default scope set.
  </Step>

  <Step title="Allow the required network hosts">
    The server and the sign-in flow call GitHub directly from the device, so in addition to the [base egress hosts](/docs/third-party/claude-desktop/telemetry#required-egress-paths), devices need outbound HTTPS access to:

    | Host             | Purpose                   |
    | ---------------- | ------------------------- |
    | `github.com`     | OAuth device-flow sign-in |
    | `api.github.com` | GitHub API calls          |

    GitHub Enterprise Server deployments need access to the instance's own host instead. No egress to any Anthropic host is needed for GitHub data.
  </Step>
</Steps>

### How users sign in

The first time a user opens the GitHub connector, Claude Desktop shows a short code and opens GitHub's device-authorization page in the system browser. The user enters the code, reviews the requested access, and approves it. The resulting token is stored encrypted on the device and reused until it is revoked, it expires, or the entry's identity fields change; **Disconnect** in connector settings deletes it.

### Control what Claude can do

Three levers narrow the local connector, from coarsest to finest:

* **`readOnly`** removes every write tool from the server. Claude never sees them.
* **`toolsets`** selects which github-mcp-server tool groups are registered, so you can expose repositories and pull requests without, for example, the Actions tools.
* **`toolPolicy`** locks the approval state per tool. Without a policy, write tools ask the user before each call. A few irreversible GitHub actions (merging a pull request, pushing commits, or triggering a workflow, for example) stay at ask or stricter no matter what the policy says.

The default `repo` OAuth scope grants read and write access to repositories the user can reach, so pair a broad scope with `readOnly` or a restrictive `toolPolicy` rather than relying on the scope alone to keep sessions read-only. A narrower `scope` list, or a GitHub App with minimal permissions, limits what the token itself can do.

third-party/claude-desktop/connectors-m365 First recorded · 342 lines, first recorded

# Connect to Microsoft 365 ## Choose a connector ## Remote connector ### How the connection works ### Set up the remote connector ### Sign in as a user ### Allow the required network hosts ### Troubleshoot sign-in errors ## Local connector ### Set up the local connector ### Configure scopes ### Grant write scopes ### How users sign in ### Token storage and sign-out ### Troubleshoot the local connector

The first capture of this source. The page was already there, and this is what it said.

# Connect to Microsoft 365

> Give Claude access to your organization's Outlook, OneDrive, SharePoint, and Teams data through a connector you register in your own Microsoft Entra tenant.

<Info>
  The remote connector is hosted by Anthropic. Data in transit passes through Anthropic's infrastructure, which is based in the United States. Anthropic does not collect or store any data that transits through the server. To keep all Microsoft 365 traffic between the user's device and Microsoft instead, use the [local connector](#local-connector).
</Info>

When Claude Desktop is deployed on third-party inference, Claude can read your organization's Microsoft 365 data (Outlook mail and calendar, OneDrive, SharePoint, and Teams) through a connector registered in your own Microsoft Entra tenant. Two connectors are available: a [remote connector](#remote-connector) hosted by Anthropic, and a [local connector](#local-connector) built into the desktop app.

## Choose a connector

Both connectors provide the same read and search tools; they differ in data path and authentication. Write actions (sending mail, managing drafts and calendar events, and working with files) are available on the local connector when you grant [write scopes](#grant-write-scopes). For write actions on the remote connector, contact your Anthropic representative. Use this table to pick one, then follow that connector's section below.

|                                 | Remote connector                                                         | Local connector                                                       |
| ------------------------------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| Microsoft 365 data path         | Transits Anthropic's infrastructure (no storage)                         | Stays between the user's device and Microsoft                         |
| App registrations you own       | One desktop client app, plus tenant consent to Anthropic's connector app | One dedicated public client app                                       |
| Token exchange                  | On-behalf-of exchange in Anthropic's infrastructure                      | Tokens acquired and stored on the device                              |
| Allowlisting with Anthropic     | Required (two to three business days)                                    | Not needed                                                            |
| Device egress                   | `login.microsoftonline.com` and the connector host                       | `login.microsoftonline.com` and `graph.microsoft.com`                 |
| Device-based Conditional Access | Not supported (the server-side exchange has no device identity)          | Supported on managed Windows and Mac devices through brokered sign-in |
| Write actions                   | Contact your Anthropic representative                                    | Available with [write scopes](#grant-write-scopes)                    |
| US Government clouds            | Separate connector deployment; contact your Anthropic representative     | Built in; set `azureCloud`                                            |

## Remote connector

When Claude Desktop is deployed on third-party inference, Claude can read your organization's Microsoft 365 data (Outlook mail and calendar, OneDrive, SharePoint, and Teams) through Anthropic's Microsoft 365 connector service. The desktop app authenticates with an app registration you create in your own Microsoft Entra tenant, and the connector service performs the Microsoft Graph calls on the signed-in user's behalf.

Anthropic's connector service receives the desktop's delegated access token on each request and exchanges it on-behalf-of the user for a short-lived Graph token. Neither token is persisted server-side beyond the request, and Anthropic never holds your tenant's client secrets or the user's refresh token (the refresh token stays encrypted on the user's device).

Setup takes about fifteen minutes and requires a Global Administrator or Cloud Application Administrator in your Entra tenant.

### How the connection works

Three applications participate in the sign-in chain. Understanding which one each ID refers to makes the setup steps below easier to follow.

| Application             | Owner                           | Purpose                                                                      |
| ----------------------- | ------------------------------- | ---------------------------------------------------------------------------- |
| Desktop client app      | You (registered in your tenant) | What Claude Desktop signs in as. Public client, PKCE, no secret.             |
| Anthropic connector app | Anthropic (multi-tenant)        | Receives the desktop's token and calls Microsoft Graph on the user's behalf. |
| Microsoft Graph         | Microsoft                       | The Microsoft 365 data APIs.                                                 |

Claude Desktop signs in through your desktop client app, receives a token scoped to the Anthropic connector app, and sends that token to Anthropic's connector service. The connector service exchanges it for a Graph token using the on-behalf-of flow and makes Graph calls as the signed-in user.

### Set up the remote connector

The four steps below cover tenant consent, app registration, allowlisting, and desktop configuration.

<Steps>
  <Step title="Consent the Anthropic connector app into your tenant">
    A tenant administrator must consent to Anthropic's multi-tenant connector app once for the organization. This creates a service principal in your tenant; no secret is exchanged.

    Open the following URL after replacing `YOUR_TENANT_ID` with the Directory (tenant) ID shown in **Entra admin center → Overview**.

    ```text theme={null}
    https://login.microsoftonline.com/YOUR_TENANT_ID/adminconsent?client_id=07c030f6-5743-41b7-ba00-0a6e85f37c17
    ```

    The consent screen lists the delegated Microsoft Graph permissions the connector requests. All are read-only:

    | Scope                                     | Purpose                                                     |
    | ----------------------------------------- | ----------------------------------------------------------- |
    | `User.Read`                               | Read the signed-in user's profile                           |
    | `Mail.Read`, `Mail.Read.Shared`           | Read mail in the user's and shared mailboxes                |
    | `Calendars.Read`, `Calendars.Read.Shared` | Read events in the user's and shared calendars              |
    | `Files.Read.All`                          | Read files the user can access in OneDrive and SharePoint   |
    | `Sites.Read.All`                          | Read SharePoint site content the user can access            |
    | `Chat.Read`, `ChatMessage.Read`           | Read Teams chat messages the user can access                |
    | `offline_access`                          | Allow the desktop to refresh its token without re-prompting |

    Review the permissions and select **Accept**.

    <Note>
      FedRAMP and GovCloud deployments use a different connector app ID and a
      different connector service hostname. Contact your Anthropic representative
      for the app ID to use in this URL and in the scope string in step 4, and for
      the connector URL to use in step 4.
    </Note>
  </Step>

  <Step title="Register a desktop client app in your tenant">
    Create the public client that Claude Desktop will sign in as.

    1. In **Entra admin center → App registrations → New registration**, set **Name** to `Claude Desktop` (or your preferred name), set **Supported account types** to *Accounts in this organizational directory only*, and add a **Redirect URI** of platform *Mobile and desktop applications* with the value `http://127.0.0.1/callback`.
    2. Select **Register**, then note the **Application (client) ID** and **Directory (tenant) ID** shown on the overview page.
    3. Under **API permissions → Add a permission → APIs my organization uses**, search for `Anthropic` (or paste the connector app ID from step 1), select **Delegated permissions → access\_as\_user**, then **Add permissions**.
    4. Select **Grant admin consent for \{your organization}**.

    No client secret is needed; this is a public client that uses PKCE.
  </Step>

  <Step title="Send Anthropic your IDs">
    Anthropic maintains an allowlist of tenant and client IDs that may call the connector service. Email your Anthropic representative, or open a support ticket, with your Directory (tenant) ID and the Application (client) ID from step 2. Allowlisting is typically completed within two to three business days, as it requires a connector service deployment.

    Until the allowlist is updated, sign-in will succeed but the connector returns *Client application is not authorized for this resource*.
  </Step>

  <Step title="Configure Claude Desktop">
    In the Claude Desktop [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration), open **Connectors**, select **Add server → Microsoft 365**, and enter the values below.

    | Field     | Value                                                                      |
    | --------- | -------------------------------------------------------------------------- |
    | Client ID | The Application (client) ID from step 2                                    |
    | Tenant ID | Your Directory (tenant) ID                                                 |
    | Scope     | `api://07c030f6-5743-41b7-ba00-0a6e85f37c17/access_as_user offline_access` |

    Select **Save**, then deploy the configuration through your device-management tool as usual.

    If you manage configuration through JSON or a plist directly instead of the in-app configuration window, add the following entry to [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers).

    ```json theme={null}
    {
      "name": "m365",
      "url": "https://microsoft365.mcp.claude.com/mcp",
      "transport": "http",
      "oauth": {
        "clientId": "APPLICATION_CLIENT_ID_FROM_STEP_2",
        "tenantId": "DIRECTORY_TENANT_ID",
        "scope": "api://07c030f6-5743-41b7-ba00-0a6e85f37c17/access_as_user offline_access"
      }
    }
    ```
  </Step>
</Steps>

### Sign in as a user

After the configuration is deployed, each user opens **Customize → Connectors** in Claude Desktop and selects **Connect** next to Microsoft 365. Their browser opens to your tenant's sign-in page; once they consent, the connector is ready to use in conversations.

### Allow the required network hosts

In addition to the [base egress hosts](/docs/third-party/claude-desktop/telemetry#required-egress-paths), Claude Desktop needs outbound HTTPS access to the hosts below. The connector service itself calls `graph.microsoft.com` from Anthropic's infrastructure, so user devices do not need egress to Graph.

| Host                          | Purpose                                                       |
| ----------------------------- | ------------------------------------------------------------- |
| `login.microsoftonline.com`   | Microsoft Entra sign-in                                       |
| `microsoft365.mcp.claude.com` | The connector service (substitute your deployment's hostname) |

### Troubleshoot sign-in errors

The errors below are the ones most commonly seen during setup. Each maps to a specific step that was missed or misconfigured.

| Error                                                    | Cause                                                                                                                               | Fix                               |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- |
| `AADSTS50011` redirect mismatch                          | Redirect URI is not exactly `http://127.0.0.1/callback`, or was registered under *Web* instead of *Mobile and desktop applications* | Re-check step 2.1                 |
| `AADSTS50194` multi-tenant required                      | Tenant ID is missing from the configuration                                                                                         | Add Tenant ID in step 4           |
| `AADSTS65001` admin consent required                     | Step 1 was not completed, or step 2.4 was skipped                                                                                   | Complete admin consent            |
| `Client application is not authorized for this resource` | Anthropic allowlist not yet updated                                                                                                 | Wait for confirmation from step 3 |
| `AADSTS9000411` duplicate prompt parameter               | Older Claude Desktop build                                                                                                          | Upgrade to the current release    |

## Local connector

Claude Desktop includes a built-in copy of the Microsoft 365 server. As an alternative to the remote connector, you can configure the app to run that server as a local process on each user's machine: the user signs in to Microsoft Entra on the device, and the server calls Microsoft Graph directly from the device. No Microsoft 365 data or tokens pass through Anthropic's infrastructure.

Choose the local connector when your data-residency requirements do not allow Microsoft 365 content to transit infrastructure outside your control, when your tenant enforces device-based Conditional Access policies (such as *Require compliant device*) that the remote connector's server-side token exchange cannot satisfy, or when you want to avoid the allowlisting step. The [comparison table](#choose-a-connector) above summarizes the differences.

### Set up the local connector

<Steps>
  <Step title="Register a public client app for local mode">
    <Warning>
      Do not reuse the desktop client app you registered for the remote connector. That app is consented only for the connector's own scope, so its tokens can reach nothing but the connector service. The local-mode app needs Microsoft Graph permissions directly, and adding those to the remote connector app's client ID would let any token minted for it read Microsoft 365 data directly, tenant-wide. Register a separate app dedicated to local mode.
    </Warning>

    1. In **Entra admin center → App registrations → New registration**, set **Name** to `Claude Desktop M365 Local` (or your preferred name) and set **Supported account types** to *Accounts in this organizational directory only*.
    2. Under **Authentication**, open the **Redirect URI configuration** tab and select **Add redirect URI** (on older versions of the portal, select **+ Add a platform** instead). Choose the **Mobile and desktop applications** card (the Windows, UWP, and Console card, not the iOS / macOS card, which takes a bundle ID rather than a redirect URI). Leave the suggested redirect URIs unchecked, enter `http://localhost` in the **Custom redirect URIs** box, and select **Configure**. This is the standard loopback redirect for desktop apps: during browser sign-in, Microsoft Entra redirects to a listener on the device itself, so the response never leaves the machine. For brokered sign-in on managed devices, also add the per-platform broker redirect URI shown under [How users sign in](#how-users-sign-in). Add it to the same platform by selecting **Edit** on the **Mobile and desktop applications** section that appears on the Authentication page, rather than adding another platform, and select **Save** at the top when you finish (on older versions of the portal, add the broker URI via the **Add URI** row inside the platform section instead). After you save, Microsoft Entra may display the `msauth` URI under a separate **iOS / macOS** section. That placement is expected because both sections map to `publicClient.redirectUris` in the app's manifest.
    3. Under **Authentication**, set **Allow public client flows** to **Yes**, and select **Save**. The control is on the **Settings** tab under **Web and SPA settings** (on older versions of the portal, under **Advanced settings**). Brokered sign-in on managed devices issues token requests without a redirect URI, so Microsoft Entra relies on this setting to classify the app as a public client. With it set to No, brokered silent token acquisition fails with `AADSTS7000218`. To prevent device-code phishing, apply a tenant Conditional Access policy that blocks the device-code authentication flow. Conditional Access policies target the resource a token is requested for rather than the requesting client, so scope the policy to All resources, not to this registration.
    4. Under **API permissions → Add a permission → Microsoft Graph → Delegated permissions**, add the scopes the connector will request (the default set is listed under [Configure scopes](#configure-scopes)), then select **Grant admin consent for \{your organization}**.
    5. Note the **Application (client) ID** and **Directory (tenant) ID** from the overview page.
  </Step>

  <Step title="Configure Claude Desktop">
    In the Claude Desktop [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration), open **Connectors**, select **Add server**, and choose **Microsoft 365** under the **Built-in** group. Enter the values below, then select **Test connection** to verify that the server starts and lists its tools, and select **Save**.

    | Field       | Value                                                                                                       |
    | ----------- | ----------------------------------------------------------------------------------------------------------- |
    | Tenant ID   | Your Directory (tenant) ID                                                                                  |
    | Client ID   | The Application (client) ID from step 1                                                                     |
    | Azure cloud | `global` (default), `us-gov-high`, or `us-gov-dod`                                                          |
    | Access      | Leave empty for standard read access, or list scopes explicitly (see [Configure scopes](#configure-scopes)) |

    If you manage configuration through JSON or a plist directly, add an entry to [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers) with the `server` field set to `microsoft365`:

    ```json theme={null}
    {
      "name": "Microsoft 365",
      "server": "microsoft365",
      "tenantId": "DIRECTORY_TENANT_ID",
      "clientId": "APPLICATION_CLIENT_ID_FROM_STEP_1"
    }
    ```

    | Field        | Required | Description                                                                                                                                                                   |
    | ------------ | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | `name`       | Yes      | Unique display name, shown to users in connector settings.                                                                                                                    |
    | `server`     | Yes      | Must be `microsoft365`. Built-in entries use this field instead of `url`, `transport`, or `command`; an entry that mixes `server` with those fields is rejected.              |
    | `clientId`   | Yes      | The Application (client) ID of the local-mode app from step 1.                                                                                                                |
    | `tenantId`   | Yes      | Your Directory (tenant) ID.                                                                                                                                                   |
    | `azureCloud` | No       | `global` (default), `us-gov-high`, or `us-gov-dod`. Selects the Microsoft Entra and Microsoft Graph hosts for US Government clouds.                                           |
    | `scope`      | No       | Space-separated delegated Graph scopes to request instead of the default read set. A string array named `scopes` is also accepted. See [Configure scopes](#configure-scopes). |
    | `toolPolicy` | No       | Per-tool approval locks, the same as for any managed server. See [`toolPolicy`](/docs/third-party/claude-desktop/configuration#managedmcpservers).                                 |

    The server ships inside the app, so nothing else needs to be installed on the device, and it activates only from managed configuration; users cannot add it themselves. Deploy the configuration through your device-management tool as usual.
  </Step>

  <Step title="Allow the required network hosts for local mode">
    The local connector calls Microsoft directly from the device, so in addition to the [base egress hosts](/docs/third-party/claude-desktop/telemetry#required-egress-paths), devices need outbound HTTPS access to:

    | Host                        | Purpose                   |
    | --------------------------- | ------------------------- |
    | `login.microsoftonline.com` | Microsoft Entra sign-in   |
    | `graph.microsoft.com`       | Microsoft Graph data APIs |

    US Government cloud deployments use `login.microsoftonline.us` and `graph.microsoft.us` (or `dod-graph.microsoft.us` for `us-gov-dod`) instead, matching the `azureCloud` setting. GCC High (`us-gov-high`) support has been confirmed in customer deployments. No egress to any Anthropic host is needed for Microsoft 365 data with the local connector.
  </Step>
</Steps>

### Configure scopes

With no `scope` field, the connector requests the standard read set at sign-in:

| Scope                                     | Purpose                                                                |
| ----------------------------------------- | ---------------------------------------------------------------------- |
| `User.Read`                               | Read the signed-in user's profile                                      |
| `Mail.Read`, `Mail.Read.Shared`           | Read mail in the user's and shared mailboxes                           |
| `Calendars.Read`, `Calendars.Read.Shared` | Read events in the user's and shared calendars, and find meeting times |
| `Files.Read.All`                          | Read files the user can access in OneDrive and SharePoint              |
| `Sites.Read.All`                          | Read SharePoint site content the user can access                       |
| `Chat.Read`                               | Read Teams chat messages the user can access                           |
| `OnlineMeetings.Read`                     | Read the user's online meetings                                        |
| `offline_access`                          | Refresh tokens without re-prompting                                    |

To request a different set, list scopes in the entry's `scope` field. The connector then requests exactly that list (plus `User.Read` and `offline_access`, which are always included). Use the list to narrow the read surface, to add the optional read scopes below, or to add [write scopes](#grant-write-scopes). Whatever you list must also be consented on the app registration from step 1; keep the two lists in sync.

Three optional read scopes are not in the standard set:

* `ChannelMessage.Read.All` adds Teams channel messages to chat search results. Requires tenant-admin consent.
* `OnlineMeetingTranscript.Read.All` enables reading meeting transcripts. Requires tenant-admin consent.
* `MailboxSettings.Read` enables reading mail filters and automatic-reply settings.

Until the first two are granted, chat search omits channel results and transcript requests return a permission error.

The `scope` field accepts only scopes the connector can use. An entry containing an unrecognized scope name is rejected as a whole at configuration load, with an error in the app's main log listing the valid names, and the connector does not appear.

<Note>
  Narrowing or removing `scope` shrinks what the connector requests at the next sign-in, but it does not narrow tokens already obtainable for the registration: Microsoft Entra issues tokens carrying every scope previously consented for the app, regardless of what is requested. To revoke access, remove the consent in Entra under **Enterprise applications → your app → Permissions**.
</Note>

The connector provides these read and search tools:

| Tool                                            | What it does                                                                       |
| ----------------------------------------------- | ---------------------------------------------------------------------------------- |
| `outlook_email_search`                          | Search Outlook mail                                                                |
| `outlook_calendar_search`                       | Search calendar events                                                             |
| `find_meeting_availability`                     | Find free meeting times                                                            |
| `chat_message_search`                           | Search Teams chat (1:1 and group; channel messages need `ChannelMessage.Read.All`) |
| `sharepoint_search`, `sharepoint_folder_search` | Search SharePoint and OneDrive                                                     |
| `read_resource`                                 | Fetch a specific item, such as a message, event, or file                           |

Granting write scopes enables write tools; see [Grant write scopes](#grant-write-scopes).

### Grant write scopes

With only read scopes granted, the connector is read-only. To let Claude take actions in Microsoft 365 (sending mail, managing drafts, labels, filters, and calendar events, and working with files in OneDrive and SharePoint), grant write scopes: add them to the entry's `scope` field and consent them on the app registration from step 1, the same as any other scope. Each write tool appears only when its scope is in the entry's list, so granting a subset of the write scopes exposes a matching subset of the tools, and removing the write scopes from the list returns the connector to read-only. Write tools require Claude Desktop version 1.19367.0 or later.

| Scope                       | What it enables                                                                                               |
| --------------------------- | ------------------------------------------------------------------------------------------------------------- |
| `Mail.Send`                 | Send mail, send drafts, and forward mail                                                                      |
| `Mail.ReadWrite`            | Create, update, and delete drafts; trash, untrash, and delete messages; apply and remove labels on messages   |
| `Calendars.ReadWrite`       | Create, update, delete, and respond to calendar events                                                        |
| `Files.ReadWrite.All`       | Create, update, rename, move, copy, and delete files and folders the user can edit in OneDrive and SharePoint |
| `MailboxSettings.ReadWrite` | Manage labels, mail filters, and automatic replies                                                            |

Sending drafts and forwarding mail also require a mail read scope (one of `Mail.Read`, `Mail.ReadWrite`, or `Mail.Read.Shared`) for the pre-send checks; the standard read set already includes one.

Every write tool requires user approval on each call by default. Administrators can change a tool's approval state with [`toolPolicy`](/docs/third-party/claude-desktop/configuration#managedmcpservers), except for the send tools (`outlook_send_mail`, `outlook_send_draft`, `outlook_forward_mail`, `outlook_create_event`, `outlook_update_event`): an `allow` setting for them resolves to `ask`, so they always require approval on each call.

### How users sign in

After the configuration is deployed, the connector appears in **Customize → Connectors** in Claude Desktop. Sign-in starts when the user selects **Connect**.

On both Windows and macOS, sign-in goes through the device's native authentication broker when the device is set up for it: a system account-picker dialog appears instead of the browser, and the issued tokens carry the device identity claim that device-based Conditional Access policies (such as *Require compliant device*) evaluate. When the broker is unavailable, sign-in opens the system browser instead. The requirements for each platform are listed below.

Browser sign-in works on tenants without device-based Conditional Access policies. It satisfies device policies only when the browser itself carries the device identity: on Windows, a browser signed in with the work account on an Entra-joined device (such as Microsoft Edge) provides this; on macOS, deploy Microsoft's Enterprise SSO browser integration, or use brokered sign-in instead.

<AccordionGroup>
  <Accordion title="Requirements for brokered sign-in on Windows">
    Brokered sign-in on Windows requires Claude Desktop version 1.13576.0 or later.

    * Windows 10 or later (desktop editions). The broker (Web Account Manager, or WAM) is built into Windows; no separate install is needed.
    * The device is joined or registered to Entra ID (Entra joined, Entra hybrid joined, or Entra registered). For device-based Conditional Access, the device must also be marked compliant in Intune or hybrid-joined, as your policy requires.
    * The broker redirect URI is registered on the local-mode app under **Mobile and desktop applications**, with `APPLICATION_CLIENT_ID` replaced by the Application (client) ID from step 1:

    ```text theme={null}
    ms-appx-web://Microsoft.AAD.BrokerPlugin/APPLICATION_CLIENT_ID
    ```

    If the broker rejects the app's sign-in request, or a brokered attempt fails with an error the broker cannot recover from, the connector falls back to the system browser automatically and stays on the browser flow until Claude Desktop restarts. A user canceling the broker dialog does not trigger the fallback. On tenants that require a compliant device, tool calls then fail with `AADSTS53003`, unless the browser itself carries the device identity (see above); fix the broker requirement that caused the fallback (most often a missing broker redirect URI) and restart the app. A fallback is recorded in the connector's log file as a `local_auth_broker_fallback` event.
  </Accordion>

Cut at 300 lines. The page has the rest.

third-party/claude-desktop/credential-helper First recorded · 54 lines, first recorded

# Write a credential helper ## What the helper must do ## When the helper runs ## Timeouts and caching ## Turn off mid-session re-runs

The first capture of this source. The page was already there, and this is what it said.

# Write a credential helper

> Supply Claude Desktop on 3P with a short-lived inference token by running an executable you provide

A credential helper is an executable on the user's machine that prints an inference token to stdout. Claude Desktop on 3P runs it whenever it needs a credential for the configured inference provider, caches the result for a configurable time, and re-runs it when the credential expires. Use a helper when your token comes from an internal secret broker, a CLI, or an SSO flow that the built-in interactive sign-in options don't cover.

Configure the helper with the `inferenceCredentialHelper` key; see the [Configuration reference](/docs/third-party/claude-desktop/configuration#inferencecredentialhelper) for the full list of helper-related keys.

<Note>
`inferenceCredentialHelper` supplies credentials for the inference connection only. An MCP server deployed through [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers) uses the separate per-server `headersHelper` key, which follows the same execution model but prints a flat JSON header map and has its own cache and renewal settings (`headersHelperTtlSec`, default 300, versus `inferenceCredentialHelperTtlSec`, default 3600). See [Short-lived credentials with a headers helper](/docs/third-party/claude-desktop/extensions#short-lived-credentials-with-a-headers-helper).
</Note>

## What the helper must do

Claude Desktop runs the executable at the configured path with no arguments and reads stdout. The exit code must be `0`. Anything written to stderr is logged for diagnostics but otherwise ignored.

Stdout must contain exactly one of the following, with no banners, prompts, or log lines mixed in:

* **A single bare token.** The whole trimmed stdout becomes the bearer token.
* **A JSON object**, when per-request headers are needed:

```json theme={null}
{ "token": "...", "headers": { "X-Org-Route": "prod" } }
```

Headers from the JSON object are merged over [`inferenceCustomHeaders`](/docs/third-party/claude-desktop/configuration#inferencecustomheaders); the helper's value wins on a conflict.

## When the helper runs

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

| Value | Meaning |
| --------------------- | ----------------------------------------------------------------------------------------------- |
| `interactive` | The user started a session and is present. Interactive sign-in is acceptable. |
| `mid-session-refresh` | A running session's credential expired. Prefer a silent refresh; the user is waiting on a turn. |
| `scheduled-task` | A scheduled task started with no user present. |
| `setup-test` | The in-app configuration window's connection test. |
| `background` | A background probe or health check. |

A well-behaved helper should attempt its silent path (cached token, refresh-token grant) for any value other than `interactive`, and exit non-zero rather than block on user input when that path is exhausted. Claude Desktop treats a non-zero exit as a refresh failure and surfaces it to the user.

The legacy variable `CLAUDE_HELPER_MANUAL_RUN=1` is also set when `CLAUDE_HELPER_CONTEXT` is `setup-test`, for scripts written before the context variable existed. New scripts should branch on `CLAUDE_HELPER_CONTEXT` instead.

The helper runs with a `PATH` that includes the user's login-shell `PATH` and standard install locations in addition to the app's launch environment, so a script can invoke tools such as `aws` or `gcloud` by name even when the app was launched from the Dock or Finder rather than a terminal.

## Timeouts and caching

The helper's output is cached for `inferenceCredentialHelperTtlSec` seconds (default 3600). After expiry it re-runs at the next session start.

Each run is bounded by `inferenceCredentialHelperTimeoutSec` seconds (default 60, maximum 600). When Claude Desktop re-runs the helper to recover a session mid-turn (`CLAUDE_HELPER_CONTEXT=mid-session-refresh`), the timeout is additionally clamped to 20 seconds so a slow helper can't stall the turn. A helper's silent path should comfortably finish within that window.

## Turn off mid-session re-runs

By default, when a running session's credential is rejected, Claude Desktop re-runs the helper with `CLAUDE_HELPER_CONTEXT=mid-session-refresh` to recover without interrupting the user. If your helper can't run safely outside the `interactive` context, set `inferenceCredentialHelperSilentRefreshEnabled` to `false`. Claude Desktop then keeps the cached credential until the next session start and surfaces an expiry prompt instead of re-running the helper mid-session.

third-party/claude-desktop/data-storage First recorded · 93 lines, first recorded

# User identity and local data ## Identity ## Where data lives ## Memory ## Chat conversations ## Credentials ### Transient credential files ## Removing data

The first capture of this source. The page was already there, and this is what it said.

# User identity and local data

> How Claude Desktop on 3P identifies users and where it stores conversations, settings, and credentials on disk

Claude Desktop on third-party (3P) has no Anthropic account. There is no sign-in step, no cloud-stored conversation history, and no per-user state on Anthropic infrastructure. Identity and persistence are entirely local to the device.

## Identity

When the app first launches in 3P mode, it generates a random UUID and writes it (base64-encoded) to the `ant-did` file in the application-data directory. This identifier, together with the `deploymentOrganizationUuid` from your managed configuration, is what's attached to telemetry events. It is random per device and per OS-user account, and Anthropic cannot trace it back to a real device or person.

The OpenTelemetry export to your own collector is the exception: it identifies the user directly. Each exported record carries an `enduser.id` resource attribute with the user's identity and a `process.owner` attribute with the operating-system login name, so attributing activity to named users needs no collector-side correlation. See [User attribution](/docs/third-party/claude-desktop/telemetry#user-attribution) for where the identity comes from and the `endUserAttribution` key that controls it.

## Where data lives

Claude Desktop on 3P stores everything under a dedicated directory, separate from standard Claude Desktop, so the two modes can coexist on one machine without interfering.

| Platform | Application data                           | Logs                                   |
| -------- | ------------------------------------------ | -------------------------------------- |
| macOS    | `~/Library/Application Support/Claude-3p/` | `~/Library/Logs/Claude-3p/`            |
| Windows  | `%LOCALAPPDATA%\Claude-3p\`                | (under the application-data directory) |

<Note>
  On Windows, earlier Claude Desktop releases stored this data under `%APPDATA%\Claude-3p\` (the Roaming profile). On first launch after upgrading, the app moves the existing directory to `%LOCALAPPDATA%` automatically; if Roaming is redirected to a network share, conversation history and configuration are copied and large regenerable caches are re-downloaded. Update any external tooling, backup jobs, or endpoint policies that reference the old path. macOS paths are unchanged.
</Note>

Within the application-data directory:

| Path                                                         | Contents                                                                                                                                                                                                                                                                                                             |
| ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ant-did`                                                    | The random device identifier described above.                                                                                                                                                                                                                                                                        |
| `configLibrary/`                                             | Locally authored configuration (from the in-app configuration window). `_meta.json` records which saved configuration is applied; each is a `<id>.json` file alongside it. Ignored when a managed profile is present.                                                                                                |
| `local-agent-mode-sessions/.../cowork_account_settings.json` | User-level preferences set in the app (display name, locale, memory toggle).                                                                                                                                                                                                                                         |
| `local-agent-mode-sessions/`                                 | Cowork and Chat conversation history. One `local_<uuid>.json` file plus a working directory per session, scoped by account and organization ID. The working directory includes an `uploads/` subdirectory with copies of files attached to the conversation and an `outputs/` subdirectory for files Claude creates. |
| `local-agent-mode-sessions/.../memory/`                      | Cowork memory: a `CLAUDE.md` instructions file plus a `memory/` subdirectory of Markdown notes Claude writes about the user's preferences, projects, and feedback. See [Memory](#memory).                                                                                                                            |
| `local-agent-mode-sessions/.../spaces/<projectId>/memory/`   | Markdown memory notes for one project, used by Cowork sessions and Chat conversations inside that project. See [Memory](#memory).                                                                                                                                                                                    |
| `local-agent-mode-sessions/.../<sessionId>/audit.jsonl`      | Append-only log of session events (tool invocations, permission decisions, file operations). Each entry is HMAC-chained to the previous one so edits or deletions are detectable; the companion `.audit-key` file holds the per-session signing key, encrypted via the OS keychain.                                  |
| `claude-code-sessions/`                                      | Code conversation history, in the same per-session layout.                                                                                                                                                                                                                                                           |
| `claude-code/`, `claude-code-vm/`                            | Claude Code binary and VM workspace data for Code sessions.                                                                                                                                                                                                                                                          |
| `vm_bundles/`                                                | Cached copy of the Cowork sandbox VM bundle.                                                                                                                                                                                                                                                                         |
| `cowork_plugins/`                                            | User-installed and [org-provisioned](/docs/third-party/claude-desktop/extensions#organization-plugins-admin) plugins. Created on first plugin install.                                                                                                                                                                    |
| `IndexedDB/`, `Local Storage/`, `Session Storage/`           | Renderer-side UI state (window layout, recent folders, preferences).                                                                                                                                                                                                                                                 |

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

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

Separately from the application-data directory, Claude Desktop writes user-visible outputs (Artifacts and scheduled-task results) to `~/Claude/` in your home directory, or `~/Documents/Claude/` on legacy installs. This folder is intended for you to browse directly and is not removed when you delete the application-data directory.

## Memory

During Cowork sessions, Claude writes short Markdown files recording what it has learned about the user — working preferences, project context, and corrections — and reads them at the start of subsequent sessions. These files live under `local-agent-mode-sessions/.../memory/memory/` and never leave the device.

Users can review and delete individual entries, or pause memory for new sessions and conversations (existing files are kept but not read or updated), under **Settings → Cowork → Memory**. The same page exposes a **Global instructions** editor for the `CLAUDE.md` file that is included in every session.

Each [project](/docs/cowork/guide/projects) also keeps its own memory under `local-agent-mode-sessions/.../spaces/<projectId>/memory/`. Cowork sessions inside a project read and update the project's memory rather than the files under `local-agent-mode-sessions/.../memory/memory/`. A Chat conversation inside a project can read the project's memory but cannot change it, as described under [Chat conversations](#chat-conversations).

## Chat conversations

[Chat](/docs/third-party/claude-desktop/chat) conversations follow the same storage model as Cowork sessions: each conversation is a session state file plus a working directory under `local-agent-mode-sessions/`, in the layout described in the table above. The state file records the conversation; the working directory holds the transcript, an `uploads/` directory with copies (or hard links) of files attached to the conversation, an `outputs/` directory for files Claude creates during the conversation (its scratch space), and the same HMAC-chained `audit.jsonl` event log. Because attachments are hard-linked where the filesystem allows it, edits made to the original file while the conversation is open can be visible to the conversation. Conversation content leaves the device only as inference requests to your configured provider, as web search queries to your configured search backend, through web access your egress configuration allows, in connector tool calls permitted by your `toolPolicy` configuration and the user's approvals, and, if you have enabled [content capture](/docs/third-party/claude-desktop/telemetry#content-capture), in telemetry to your own collector.

For the questions security reviews most often ask about Chat:

* **Memory is read-only and applies only inside projects.** A Chat conversation inside a project can read that project's memory unless memory was paused when the conversation started, but cannot add to or change it. Chat conversations outside a project do not read or update memory.
* **Past chats are not searchable.** There is no index of conversation content, server-side or local (history exists only as the per-session files above), and a Chat conversation has no tools for listing or reading other sessions' transcripts. Each conversation is isolated to its own directory.
* **The advanced file analysis sandbox writes only inside the session directory.** When [advanced file analysis](/docs/third-party/claude-desktop/chat#advanced-file-analysis) is enabled, code runs in a local sandbox with no network access. The sandbox writes only to the conversation's `outputs/` directory, and reads its `uploads/` directory plus, for a conversation inside a project, that project's memory.

Deleting a conversation's session state file and working directory removes all of this; there is no other copy.

## Credentials

Inference credentials are handled according to how they're delivered:

* **Managed configuration** (for example, `inferenceGatewayApiKey`, `inferenceBedrockBearerToken`): read from the OS preference store or registry at launch and held in memory. The app also writes resolved credentials to a small set of transient, owner-only files for its own session processes, described below.
* **OAuth tokens** (in-app Google sign-in, MCP servers with `oauth: true`): stored in the application-data directory, encrypted with the operating system's secure storage (Keychain on macOS, DPAPI on Windows).
* **Credential-helper output**: held in memory for `inferenceCredentialHelperTtlSec` seconds, then discarded and re-fetched.

### Transient credential files

Parts of each session run as separate processes: the sandbox VM for Cowork sessions, and the Claude Code runtime for Code sessions. Processes that cannot receive credentials through an in-memory channel read them from short-lived files that the app writes for them. All of these files are created with owner-only permissions and are cleaned up automatically:

| Path (within the application-data directory) | Contents                                                                                                                                                                                                                                                                        | Lifecycle                                                                                                                                                                                                                                                                                   |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `host-creds-<random-id>.json`                | The resolved inference credential (bearer token or API key, plus the endpoint), as environment values for background Claude Code worker processes. Written atomically with owner-only permissions (mode `0600` on macOS; per-user ACLs on Windows).                             | Rewritten on each credential refresh; deleted when the app quits; leftovers from a crash are removed at the next launch. The random path segment is regenerated when you sign out of the inference provider or its credentials are rotated, so a process holding the old path loses access. |
| `ccd-session-secrets/<session-id>/`          | File-based credentials for Code sessions: Google Cloud application default credentials for Google Cloud's Agent Platform, or AWS configuration files for Amazon Bedrock. The directory is created with owner-only permissions (mode `0700` on macOS; per-user ACLs on Windows). | Created when the session starts; removed when the session ends; the whole directory is swept before the next Code session starts and when you sign out of the inference provider.                                                                                                           |
| Per-session working directory                | For Cowork sessions, the same file-based credentials (Google Cloud's Agent Platform and Amazon Bedrock) are written into the session's working directory, which is mounted into the sandbox VM.                                                                                 | Scoped to the session; removed with the session directory.                                                                                                                                                                                                                                  |

Aside from these files, credentials delivered through managed configuration are held in memory only.

## Removing data

To fully reset a device's Claude Desktop on 3P state, delete the application-data directory above and the `~/Claude/` user-files folder. To return to standard Claude Desktop without removing data, choose the Anthropic sign-in option on the sign-in screen; to also remove the locally authored 3P configuration, delete the `configLibrary/` directory.

Conversation history exists only in this directory, so deleting it is unrecoverable.

third-party/claude-desktop/entra-broker First recorded · 68 lines, first recorded

# Sign in through the OS identity broker ## What the broker is ## Why use the broker ## Where the broker is used ## Platform support ## Register the Entra ID application ## Prepare devices ## Token storage ## Troubleshoot

The first capture of this source. The page was already there, and this is what it said.

# Sign in through the OS identity broker

> Use the operating system's native Microsoft Entra sign-in broker so Claude Desktop on 3P satisfies device-based Conditional Access policies

Several Claude Desktop on 3P features authenticate to Microsoft Entra ID, including the Microsoft Foundry inference provider and the Microsoft 365 connector. Each of these can run its Entra sign-in through the operating system's native identity broker instead of a browser or device code. This page covers what the broker is, when to choose it, and the prerequisites that apply wherever the app uses it. The feature-specific pages linked under [Where the broker is used](#where-the-broker-is-used) describe how to turn it on for each feature.

## What the broker is

The OS identity broker is the operating system's built-in Microsoft sign-in component. On Windows it is Web Account Manager (WAM), which ships with Windows 10 and later. On macOS it is provided by the Intune Company Portal app together with the Microsoft Enterprise SSO plug-in. When Claude Desktop signs in through the broker, the operating system shows its own account picker, the user selects or signs in to a work account, and the broker issues the token. Nothing opens in a web browser, and the app never handles the user's password.

## Why use the broker

The broker is the most reliable sign-in flow for Microsoft Entra Conditional Access policies that require a compliant or managed device, or that require token protection, because it always carries the device identity claim those policies evaluate. Device-code sign-in never carries that claim. Browser sign-in carries it only when the browser itself is integrated with device identity (for example, Microsoft Edge signed in with the work account on an Entra-joined Windows device, or a macOS browser with Microsoft's Enterprise SSO integration deployed). The broker satisfies these policies on any supported device without relying on browser configuration.

The broker also removes the need for a `localhost` or `127.0.0.1` loopback redirect on the device, which some network policies block, and it is not affected by Conditional Access policies that block the device-code authentication flow.

## Where the broker is used

| Feature | How to enable it | Page |
| ------------------------------------ | ------------------------------------------ | -------------------------------------------------------------------------------- |
| Microsoft Foundry inference provider | Set `inferenceFoundryAuthFlow` to `broker` | [Microsoft Foundry](/docs/third-party/claude-desktop/foundry#in-app-entra-id-sign-in) |

The [Microsoft 365 connector](/docs/third-party/claude-desktop/connectors-m365#how-users-sign-in) also uses the OS broker for its own Entra sign-in. Its broker setup is documented on that page, and its app registration needs the same settings described under [Register the Entra ID application](#register-the-entra-id-application).

## Platform support

Brokered sign-in is available on Windows and macOS. Linux has no OS identity broker; on Linux the app rejects a broker configuration with an error that names the browser flow as the alternative.

What happens when the broker is unavailable on a supported device depends on the feature. Where the broker is selected explicitly (for example, Foundry inference with `inferenceFoundryAuthFlow` set to `broker`), the app shows that same error rather than falling back to a browser or device-code flow, because a silent fallback would bypass the device policy the broker was chosen to satisfy. Features that use the broker opportunistically fall back to the system browser instead; the [Microsoft 365 connector](/docs/third-party/claude-desktop/connectors-m365#how-users-sign-in) works this way, as documented on that page.

## Register the Entra ID application

Brokered sign-in places two requirements on the Entra ID app registration that the feature signs in against. These are in addition to whatever API permissions the feature itself needs.

Under **Authentication**, set **Allow public client flows** to **Yes**. The control is on the **Settings** tab under **Web and SPA settings** (on older versions of the portal, under **Advanced settings**). Brokered token requests carry no client secret, so Entra ID relies on this setting to classify the app as a public client. With it set to No, brokered sign-in fails with error code `AADSTS7000218`.

Under **Authentication**, add the broker redirect URI for each platform you deploy to under the **Mobile and desktop applications** platform:

| Platform | Redirect URI |
| -------- | ---------------------------------------------------------------- |
| Windows | `ms-appx-web://Microsoft.AAD.BrokerPlugin/APPLICATION_CLIENT_ID` |
| macOS | `msauth.com.anthropic.claudefordesktop://auth` |

Replace `APPLICATION_CLIENT_ID` in the Windows value with the registration's own Application (client) ID. The macOS value is a fixed string.

## Prepare devices

On Windows, WAM is built into the operating system. The device must be Entra joined, Entra hybrid joined, or Entra registered so the broker has a work account to present. For Conditional Access policies that require a compliant device, the device must also be marked compliant in Intune (or hybrid joined) as your policy requires.

On macOS, the broker is provided by Intune Company Portal. Each device needs:

* Intune Company Portal installed.
* An Extensible SSO configuration profile of type Redirect, pointed at the Microsoft Enterprise SSO plug-in, deployed through your MDM. The broker is unavailable without it.
* Enrollment in an MDM and registration in Entra ID. For Conditional Access policies that require a compliant device, the device must also be marked compliant in Intune as your policy requires. For MDMs other than Intune, use the partner device-compliance integration that reports compliance to Intune and Entra.

## Token storage

The operating system's broker holds the credential and renews it silently from the device's primary refresh token. The app stores only a reference to the signed-in account, not a refresh token. When the broker can no longer renew silently (for example, the device falls out of compliance or the user's sessions are revoked in Entra), the app prompts the user to sign in again.

## Troubleshoot

If sign-in fails with error code `AADSTS7000218`, **Allow public client flows** is set to No on the app registration. Set it to **Yes** under **Authentication**.

If sign-in fails with error code `AADSTS50011` or `AADSTS900971`, the platform's broker redirect URI is missing from the app registration or does not exactly match the value under [Register the Entra ID application](#register-the-entra-id-application). Add or correct it under **Authentication → Mobile and desktop applications**.

If sign-in fails with a message that the OS identity broker is unavailable, the device does not meet the requirements under [Prepare devices](#prepare-devices). On macOS, confirm Company Portal is installed and the Enterprise SSO configuration profile is deployed. On Windows, confirm the device is Entra joined or registered.

The broker writes its own diagnostic log outside the app. On Windows, WAM events appear in Event Viewer under **Applications and Services Logs → Microsoft → Windows → AAD → Operational**. On macOS, Company Portal writes to the unified log; view it with `log show --predicate 'subsystem == "com.microsoft.CompanyPortalMac"' --last 1h` in Terminal. The app's own log records when a brokered sign-in was attempted and the error it returned; see [Data storage and residency](/docs/third-party/claude-desktop/data-storage) for the log location.

third-party/claude-desktop/extensions First recorded · 323 lines, first recorded

# MCP, plugins, skills, and hooks ## Managed MCP servers (admin) ### Short-lived credentials with a headers helper ### Supported MCP servers ### Productivity suites ## Plugin marketplaces (admin) ### Create the marketplace repository ### Configure the marketplace ### Marketplace installation preferences ### Marketplace credentials ### Roll out marketplace updates ## Organization plugins (admin) ### Plugin directory location ### Plugin structure ### Auto-installing organization plugins ### Updating organization plugins ## User extensions ## Controlling user extensions ## Related topics

The first capture of this source. The page was already there, and this is what it said.

# MCP, plugins, skills, and hooks

> Extend Claude Desktop on 3P with connectors, plugin marketplaces, organization plugins, skills, and hooks for administrators and end users

Claude Desktop on third-party (3P) supports the same extensibility model as standard Claude Desktop ([MCP connectors](/docs/connectors/overview), [skills](/docs/skills/overview), and [plugins](/docs/plugins/overview)), with the key difference that administrators provision them through managed configuration and the filesystem rather than the claude.ai admin console.

There are three layers, in order of precedence:

| Layer                | Provisioned by | Delivered via                                                                                                                                            |
| -------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Managed MCP servers  | Admin          | `managedMcpServers` configuration key                                                                                                                    |
| Organization plugins | Admin          | A [plugin marketplace](#plugin-marketplaces-admin) git repository (recommended) or a [system-wide directory](#organization-plugins-admin) on each device |
| User extensions      | End user       | In-app Connectors and Plugins UI                                                                                                                         |

Admins can disable the user layer entirely; see [Controlling user extensions](#controlling-user-extensions).

## Managed MCP servers (admin)

Use the `managedMcpServers` configuration key to deploy MCP servers (remote HTTP/SSE or local stdio command) to every device. These appear in the user's connector list automatically, can't be removed by the user, and support per-tool policy locks (`allow` / `ask` / `blocked`). The same key also activates the servers bundled inside the app (Microsoft 365, web search, and GitHub); see [Built-in connectors](/docs/third-party/claude-desktop/built-in-connectors).

The **Connectors** section of the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration) provides a form for each server: name, per-tool policy, headers or a headers helper script, transport, and URL.

<Frame caption="A managed MCP server in the Connectors section of the in-app configuration window.">
  <img src="https://mintcdn.com/claude-ai/JnLDSb03Rtghdgpj/images/third-party/config-window-managed-mcp.png?fit=max&auto=format&n=JnLDSb03Rtghdgpj&q=85&s=294cce4e42a951fc5479c36676c3b3b5" alt="In-app configuration window showing a managed MCP server named sentry, with fields for name, tool policy, headers, headers helper script, Streamable HTTP transport, and URL." width="1794" height="1432" data-path="images/third-party/config-window-managed-mcp.png" />
</Frame>

In the exported configuration, each server is one entry in the `managedMcpServers` array:

```json theme={null}
[
  {
    "name": "internal-search",
    "url": "https://mcp.example.corp",
    "oauth": true,
    "toolPolicy": { "search": "allow", "delete_document": "blocked" }
  },
  {
    "name": "ticketing",
    "url": "https://tickets.example.corp/mcp",
    "headersHelper": "/usr/local/bin/corp-sso-token",
    "headersHelperTtlSec": 900
  }
]
```

See the [`managedMcpServers` schema](/docs/third-party/claude-desktop/configuration#managedmcpservers) in the configuration reference for every field, including static headers, OAuth, and the headers-helper executable for short-lived tokens.

In the in-app configuration window, each server you add under **Connectors** has a **Test this connection** button that runs a live MCP `initialize` and `tools/list` against the server using the headers or OAuth settings you've entered, then shows the round-trip latency, the discovered tool list, or the error returned. Use it to validate reachability and credentials before exporting the configuration.

### Short-lived credentials with a headers helper

For short-lived header credentials, configure the helper per server:

| Key                             | Default | What it does                                                                              |
| ------------------------------- | ------- | ----------------------------------------------------------------------------------------- |
| `headersHelper`                 | None    | Executable that prints the request headers as a flat JSON object to stdout.               |
| `headersHelperTtlSec`           | 300     | Seconds the returned headers stay valid.                                                  |
| `headersHelperRefreshBufferSec` | 60      | Seconds before expiry that the helper re-runs. Set it above the helper's typical runtime. |

The helper follows the [`inferenceCredentialHelper`](/docs/third-party/claude-desktop/credential-helper) execution model, with three differences: a 30-second time limit, no `CLAUDE_HELPER_CONTEXT`, and no prompting for input. The helper applies only to servers provisioned through managed configuration and never replaces the `Authorization` header on `oauth` entries.

While the connection is open, only the TTL schedule triggers renewal; a failed request never re-runs the helper. A failed run does not interrupt the connection; Claude Desktop keeps the current headers and retries. A failure while the server is connecting shows the server as needing authentication.

<Note>
  Mid-session renewal requires Claude Desktop 1.21459.0 or later. Earlier versions run the helper only when the server connects.
</Note>

### Supported MCP servers

Any MCP server reachable from the user's device over HTTPS works with Claude Desktop on 3P, including public servers from third parties and internal servers you build and host (including on internal gateways).

<Note>
  Claude Desktop does not present a TLS client certificate when connecting to MCP servers, so a server that requires mutual TLS (mTLS) client-certificate authentication fails to connect. Terminate the client-certificate requirement before the MCP endpoint (for example, at a gateway or reverse proxy), and authenticate the connection with headers or OAuth instead.
</Note>

The [Claude connector directory](https://claude.com/connectors) is the canonical catalog of vetted servers. **Every connector in the directory that is not labeled "Made by Anthropic" is accessible in Claude Desktop on 3P** and can be deployed via `managedMcpServers` or installed by users. Connectors labeled "Made by Anthropic" are hosted on Anthropic infrastructure and are available only in standard Claude Desktop.

<Note>
  Some connectors return [MCP Apps](/docs/connectors/building/mcp-apps/getting-started), interactive widgets that Claude Desktop renders in place of a plain-text tool result. Each widget loads in a sandboxed iframe on `*.claudemcpcontent.com`, and setting [`disableNonessentialServices`](/docs/third-party/claude-desktop/configuration#disablenonessentialservices) to `true` blocks that origin, so Claude Desktop shows the connector's text result instead of the widget. The same key also blocks artifact previews, connector favicons, and the connector directory lookup. To keep MCP Apps rendering, leave `disableNonessentialServices` unset or `false`, and allow the widget hosts listed under [Required egress paths](/docs/third-party/claude-desktop/telemetry#required-egress-paths) at your perimeter firewall.
</Note>

### Productivity suites

Google Workspace and Microsoft 365 each have a dedicated setup path:

<Columns cols={2}>
  <Card title="Google Workspace" icon="google" href="https://developers.google.com/workspace/guides/configure-mcp-servers">
    Gmail, Calendar, Drive, Docs, and more via Google's own Workspace MCP servers. See [Google's setup guide](https://developers.google.com/workspace/guides/configure-mcp-servers) to get started.
  </Card>

  <Card title="Microsoft 365" icon="microsoft" href="/docs/third-party/claude-desktop/connectors-m365">
    Outlook, OneDrive, SharePoint, and Teams. Requires registering an app in your Entra tenant and an Anthropic allowlist step.
  </Card>
</Columns>

## Plugin marketplaces (admin)

A **plugin marketplace** is a git repository that lists one or more Claude plugins. Claude Desktop clones the repository on each device, shows the plugins under **Settings → Plugins → Organization**, and keeps them in sync with the ref you pin. You control which plugins are available, which install automatically, and which are required.

This is the recommended way to distribute organization plugins. Use the [system-wide directory](#organization-plugins-admin) path instead when end-user devices cannot reach a git server.

<Note>
  Plugin marketplaces are in beta and require Claude Desktop 1.17377.1 or later.
</Note>

<Note>
  The `allowedPluginMarketplaces` key configures **Cowork** only. [**Code**](/docs/third-party/claude-desktop/code) reads Claude Code's own plugin configuration on the host instead; to deploy a marketplace there, use Claude Code's [`extraKnownMarketplaces` and `strictKnownMarketplaces`](https://code.claude.com/docs/en/plugin-marketplaces#managed-marketplace-restrictions) settings. The same marketplace repository works for both; only the configuration path differs.
</Note>

### Create the marketplace repository

A marketplace repository contains a `.claude-plugin/marketplace.json` file at its root that lists each plugin and its location. The format is shared with Claude Code; see [Create and distribute a plugin marketplace](https://code.claude.com/docs/en/plugin-marketplaces) for the full schema and walkthrough.

```json .claude-plugin/marketplace.json theme={null}
{
  "name": "acme-internal",
  "owner": { "name": "Acme IT" },
  "plugins": [
    {
      "name": "expense-policy",
      "source": "./plugins/expense-policy",
      "description": "Answers questions about Acme travel and expense policy"
    }
  ]
}
```

Put plugin content directly in the marketplace repository with a relative `source` path. Plugins whose `source` points at a different repository are listed in the Organization tab but are not fetched or auto-installed.

The marketplace `name` must match `^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$` and must not be one of the reserved values `unknown`, `org`, or `org-provisioned`.

### Configure the marketplace

You can add marketplaces directly in the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration): in the **Plugins** section, click **Add marketplace** and choose **Blank**, **GitHub repo**, or **Git URL**. The form validates the entry against the repository and exports the encoded JSON for you.

<Frame caption="The Plugins section of the in-app configuration window, with the Add marketplace menu and the organization plugins folder.">
  <img src="https://mintcdn.com/claude-ai/JnLDSb03Rtghdgpj/images/third-party/config-window-plugin-marketplaces.png?fit=max&auto=format&n=JnLDSb03Rtghdgpj&q=85&s=a9bdd6d5bdbf22716340aedf1cc2d16b" alt="In-app configuration window Plugins section showing the plugin marketplaces card with an open Add marketplace menu offering Blank, GitHub repo, and Git URL, above the organization plugins folder path with two loaded plugins." width="1792" height="1238" data-path="images/third-party/config-window-plugin-marketplaces.png" />
</Frame>

To write the configuration by hand instead, add the repository to the [`allowedPluginMarketplaces`](/docs/third-party/claude-desktop/configuration) configuration key. The key is read from an MDM profile, local configuration, or the [bootstrap server](/docs/third-party/claude-desktop/bootstrap) response. In an MDM profile the value is a JSON array encoded as a string (see [Value types](/docs/third-party/claude-desktop/configuration#value-types)); writing a native plist array instead of a string is the most common reason the Organization tab does not appear. In a local configuration file or the bootstrap response the value is a native JSON array.

```xml .mobileconfig (macOS) theme={null}
<key>allowedPluginMarketplaces</key>
<string>[{"source":"github","repo":"acme-corp/claude-plugins","ref":"a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0","credentialKind":"userGit","installationPreference":"auto_install"}]</string>
```

On Windows, write the same string to the `allowedPluginMarketplaces` value in the registry policy key your deployment already uses (`HKLM\SOFTWARE\Policies\Claude` for machine policy). Keep the value in the same hive as the rest of your configuration: when machine policy is present, the app ignores user policy entirely; see [Deploy the configuration](/docs/third-party/claude-desktop/mdm#4-deploy-the-configuration) for the exact rule. For GitLab, Bitbucket, or a self-hosted git server, use `"source": "git"` with a full HTTPS `url` instead of `repo`.

| Field                    | Description                                                                                                                                                                                |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `source`                 | **Required.** `"github"` (with `repo`) or `"git"` (with `url`).                                                                                                                            |
| `repo`                   | GitHub repository in `owner/name` format.                                                                                                                                                  |
| `url`                    | Full HTTPS clone URL. Use a bare URL with no embedded credentials; set `credentialKind` for authentication.                                                                                |
| `ref`                    | Branch name, tag name, or full 40-character commit SHA. **Required, and must be a full commit SHA,** when `installationPreference` is `"auto_install"` or `"required"`.                    |
| `path`                   | Subdirectory containing `.claude-plugin/marketplace.json` when not at the repository root.                                                                                                 |
| `expectedName`           | If set, the clone is rejected unless the `name` in `marketplace.json` matches this value exactly, so a change to the manifest name cannot silently replace another configured marketplace. |
| `credentialKind`         | `"anonymous"` (default), `"userGit"`, or `"credentialHelper"`. See [Marketplace credentials](#marketplace-credentials).                                                                    |
| `credentialHelper`       | Path to an executable that prints an access token on stdout. Required, and only valid, when `credentialKind` is `"credentialHelper"`.                                                      |
| `installationPreference` | `"available"` (default), `"auto_install"`, or `"required"`. See [Marketplace installation preferences](#marketplace-installation-preferences).                                             |

You can configure multiple marketplaces; each appears as its own sub-tab under **Settings → Plugins → Organization**. If an admin-configured marketplace has the same `repo`, `url`, or manifest `name` as one the user added themselves, the admin entry replaces the user's.

### Marketplace installation preferences

| `installationPreference` | Behavior                                                                                                                                                                                                      |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `"available"`            | Plugins appear in the Organization tab for users to install manually. Nothing is installed automatically.                                                                                                     |
| `"auto_install"`         | Every plugin is installed automatically the first time the pinned `ref` is seen. Users can uninstall individual plugins; when you later change the `ref`, each plugin is installed again at the new revision. |
| `"required"`             | Every plugin is installed automatically and re-asserted on every sync. Users cannot uninstall or disable required plugins.                                                                                    |

<Warning>
  `"auto_install"` and `"required"` marketplaces must pin `ref` to a full 40-character commit SHA. Claude Desktop refuses to auto-install from a branch or tag name so that the exact plugin content deployed to every device is deterministic and auditable.
</Warning>

### Marketplace credentials

Claude Desktop clones marketplace repositories on the host operating system, outside the Cowork VM. The credential is used only for this clone and is never passed into the VM or exposed to the model.

| `credentialKind`     | How it authenticates                                                                                                                                                                                                                             |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `"anonymous"`        | No credential is sent. Use for public repositories.                                                                                                                                                                                              |
| `"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.   |
| `"credentialHelper"` | Runs the executable at `credentialHelper` and uses its trimmed stdout as the HTTPS password with username `x-access-token`. Follows the same stdout contract as an [inference credential helper](/docs/third-party/claude-desktop/credential-helper). |

Because the clone happens on the host, the repository 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.

### Roll out marketplace updates

To push a new plugin version to your fleet, commit the change to the marketplace repository, update the `ref` in `allowedPluginMarketplaces` to the new commit SHA, and distribute the updated managed configuration. Devices sync to the new revision on the next app launch or plugin settings refresh. To remove a marketplace, delete its entry; Claude Desktop unregisters it and uninstalls its plugins on the next sync.

## Organization plugins (admin)

<Tip>
  For most deployments, distribute organization plugins via a [plugin marketplace](#plugin-marketplaces-admin) instead. Marketplaces let you manage plugin content in git and roll out updates by changing a single configuration value, rather than pushing files to every device. Use the directory path below when end-user devices cannot reach a git server.
</Tip>

[Plugins](/docs/plugins/overview) bundle MCP connectors, skills, slash commands, hooks, and sub-agents into a single directory. On this path, admins distribute plugins by placing them in a system-wide directory on each device, typically via the same MDM or software-distribution channel used for the app itself.

### Plugin directory location

| Platform | Path                                               |
| -------- | -------------------------------------------------- |
| macOS    | `/Library/Application Support/Claude/org-plugins/` |
| Windows  | `C:\Program Files\Claude\org-plugins\`             |

On Windows, the directory is under `Program Files` (not `ProgramData`) so that only administrators can create or modify it. Claude Desktop treats the presence of this directory as an admin-provisioned source.

### Plugin structure

Each subdirectory of `org-plugins/` is one plugin. The directory name is the plugin's canonical name.

```text theme={null}
org-plugins/
└── code-reviewer/
    ├── .claude-plugin/
    │   └── plugin.json
    ├── version.json
    ├── .mcp.json
    ├── agents/
    │   └── code-reviewer.md
    ├── commands/
    │   └── find-all-bugs.md
    └── skills/
        └── security-review/
            └── SKILL.md
```

| File                         | Purpose                                                                                                                                                                                                                                                                                                                                                  |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `.claude-plugin/plugin.json` | **Required.** Plugin manifest (name, description, version). Directories without this file are ignored.                                                                                                                                                                                                                                                   |
| `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.                                                                       |
| `.mcp.json`                  | MCP servers bundled with this plugin. A JSON object keyed by server name: `{"mcpServers": {"<name>": {"type": "http", "url": "...", "oauth": true}}}`. Each 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. |
| `agents/`                    | Sub-agent definitions.                                                                                                                                                                                                                                                                                                                                   |
| `commands/`                  | Slash-command definitions.                                                                                                                                                                                                                                                                                                                               |
| `skills/`                    | [Skill](/docs/skills/overview) directories.                                                                                                                                                                                                                                                                                                                   |
| `hooks/`                     | Hook definitions that run on agent lifecycle events.                                                                                                                                                                                                                                                                                                     |

<Note>
  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).
</Note>

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

<Note>
  Symlinks inside a plugin are followed as long as the target resolves to a path inside the plugin directory. Symlinks that point outside the plugin (for example, `skills/foo/SKILL.md → /etc/hosts`) are skipped. A symlinked top-level plugin directory (for example, `org-plugins/my-plugin → /opt/shared/my-plugin`) is also followed.
</Note>

<Note>
  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`.
</Note>

### Auto-installing organization plugins

By default, organization plugins appear in the user's plugin browser as available to install, and each user opts in. To install a plugin automatically for every user, set `installationPreference` in the plugin's `.claude-plugin/plugin.json`:

```json theme={null}
{
  "name": "code-reviewer",
  "version": "1.0.0",
  "description": "Internal code review assistant",
  "installationPreference": "required"
}
```

| Value                      | Behavior                                                                                                                                              |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `"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. |
| `"auto_install"`           | Installs automatically when the user signs in. Users can uninstall it, and it stays uninstalled for that user.                                        |
| `"available"` (or omitted) | Default. Users install manually from the plugin browser.                                                                                              |

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

### Updating organization plugins

To roll out a new version of a plugin:

1. Update the plugin contents in `org-plugins/<name>/` via your software-distribution tool
2. Bump the `version` string in `version.json`
3. Users pick up the change on their next app launch

## User extensions

Unless restricted by an admin, end users can add their own extensions through the in-app UI:

* **Plugins:** install plugins (which can bundle skills, hooks, slash commands, and sub-agents) from the Plugins settings page
* **Skills:** create and upload their own [skills](/docs/skills/overview), including by asking Claude to save one in a conversation
* **Connectors:** install local desktop extensions (`.mcpb`) from the Connectors settings page
* **Local MCP servers:** add local MCP server processes from **Settings → Developer**, when enabled by the admin

End users cannot add remote MCP servers; remote servers are available only via admin-provisioned `managedMcpServers` or organization plugins. User-added extensions are stored in the user's [local data directory](/docs/third-party/claude-desktop/data-storage) and apply only to that device.

## Controlling user extensions

Admins can restrict or disable each user-extension surface independently via managed configuration:

| Key                                   | Effect when `false`                                                                                                 |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `isLocalDevMcpEnabled`                | Users cannot add their own local MCP servers from **Settings → Developer**.                                         |
| `isDesktopExtensionEnabled`           | Users cannot install local `.mcpb` desktop extensions.                                                              |
| `isDesktopExtensionSignatureRequired` | (When `true`) Unsigned `.mcpb` extensions are rejected.                                                             |

Cut at 300 lines. The page has the rest.