Capture
One read of Claude Documentation
213 pages moved out of 213 read.
claude-science/admin-controls First recorded · 80 lines, first recorded
# Admin controls ## Identity and access ## Capability toggles ## Connectors ## Data and privacy ## Audit and compliance ## Usage, models, and billing ## Offboarding and local data
The first capture of this source. The page was already there, and this is what it said.
# Admin controls > Members sign in to Claude Science with their Claude account, so your identity and billing controls apply automatically. Members sign in to Claude Science with their Claude account, so your identity and billing controls apply automatically. Because the app stores conversations on each member's computer rather than on Anthropic's servers, most of the data-handling controls Anthropic provides don't reach that data today. The tables show, for each admin setting, whether it governs Claude Science in beta. Status values describe Claude Science specifically; other Claude products may differ. Legend: Supported / Partial / Not available / Not applicable ## Identity and access | Admin setting | Status in Claude Science beta | Note | | --------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SSO (SAML / OIDC) | Supported | Sign-in goes through claude.ai, so your SSO policy applies automatically. | | SCIM / Directory Sync | Supported | Deprovisioning a member revokes their access. | | Domain capture | Supported | Inherited from claude.ai account creation. | | Members management | Supported | Adding or removing org members controls who can sign in. | | Built-in roles | Supported | All built-in roles get access once the product is enabled for the org. | | Custom roles | Supported | Custom roles can grant or deny access to the app. | | Groups | Supported | Roles assigned through groups carry through. | | IP allowlisting | Partial | Claude inference is IP-gated. Gating remote compute (running code on the member's own SSH hosts or cloud accounts) is on the roadmap. Custom connectors and local operation are outside this setting's scope. | | Session duration | Partial | Limits the browser sign-in step only; the app stays signed in after that. | ## Capability toggles | Admin setting | Status in Claude Science beta | Note | | -------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Org enable toggle | Supported | Off by default for Team and Enterprise; an Owner or Primary Owner turns it on under Organization settings > Claude Science. Assigning seats doesn't turn it on. | | Completion feedback (thumbs) | Supported | The org toggle hides the feedback buttons, same as Chat. | | Organization custom instructions | Supported | The org's custom instructions are applied to the app's model calls, the same as Chat. | | Skills allowlist | Partial | Org-published skills appear, but members can also install local skills without restriction. Adding admin control is on the roadmap. | | Web search | Not available | The app offers web search regardless of this setting. Adding admin control is on the roadmap. | | Code execution | Not available | This setting controls Chat's hosted code sandbox only. Claude Science runs code locally regardless of this setting; that's core to the product. | | Code execution network allowlist | Not available | This setting controls Chat's hosted code sandbox only and is not yet available for Claude Science in Organization settings. Claude Science's local sandbox keeps its own allowlist, which members manage in the app and administrators can extend per device with the sandbox network keys in the [configuration file reference](/docs/claude-science/configuration-file-reference). | | Location metadata | Not applicable | The app doesn't derive, store, or send any geolocation data. | | Memory | Not applicable | The claude.ai Memory setting doesn't control memory in Claude Science. The app keeps its own memory locally on the member's device, and it's off by default. | | Projects | Not applicable | No Projects integration; the app uses local workspaces instead. | ## Connectors | Admin setting | Status in Claude Science beta | Note | | ---------------------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Org-published Directory connectors | Supported | Connectors the admin publishes are available in the app. | | Per-role connector restrictions | Partial | Enforced for Directory connectors, not for connectors members add locally. | | Org plugin allowlist | Partial | Org-published plugins appear automatically; members can still add their own local skills and connectors. Adding admin control to restrict local skills and connectors is on the roadmap. | | Connector tunnels | Partial | Directory connectors the admin publishes reach the app through tunnels. Local connectors the member adds run on their own computer, so tunnels don't apply. Custom remote connectors the member adds don't route through tunnels. | | Custom connector restrictions | Not available | Members can add their own custom connectors regardless of the organization allowlist. Adding admin control is on the roadmap. | | Desktop Extension allowlist | Not applicable | Desktop Extension directory isn't available in the app. | ## Data and privacy | Admin setting | Status in Claude Science beta | Note | | ------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | CMEK | Supported | Applies to the product's model traffic the same as Chat. | | Data processing geography | Partial | Covers Anthropic-hosted processing, not remote compute you configure (code the member runs on their own SSH hosts or cloud accounts) or the member's computer (same as Claude Code). | | HIPAA | Partial | HIPAA-ready organizations can enable the Claude Science beta, but usage isn't covered under the BAA. | | Custom Data Retention | Not available | The auto-delete window doesn't cover local data or the usage logs Anthropic keeps for this product. | ## Audit and compliance | Admin setting | Status in Claude Science beta | Note | | --------------- | ----------------------------- | ----------------------------------------------------------------------------------- | | Audit log | Not available | No events recorded yet; on the roadmap. | | Compliance API | Not available | Admins can't export or delete this product's data through the API. | | Org data export | Not available | The export doesn't include data stored on members' computers (same as Claude Code). | ## Usage, models, and billing | Admin setting | Status in Claude Science beta | Note | | --------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Usage limits | Supported | Usage counts toward the same 5-hour and weekly limits as Claude Code and Cowork. | | Billing and seats | Supported | Uses the same seat as the rest of claude.ai. | | Model access controls | Supported | Uses the standard model API, so the org's allowed-model list and model access grants apply to both the model picker and the calls themselves. | | Usage analytics | Supported | Open Analytics from the user menu; the Claude Science tab shows usage, and spend is filterable by product on the Overview tab. | ## Offboarding and local data | Admin setting | Status in Claude Science beta | Note | | ------------------------ | ----------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Offboarding (local data) | Not available | Removing a member doesn't wipe data already on their computer. | | Local deletion signal | Not available | Deleting local data doesn't notify Anthropic to drop the matching server-side record early. This is on the roadmap. |
claude-science/annotations First recorded · 19 lines, first recorded
# Annotations ## Leaving an annotation ## Sending annotations to Claude
The first capture of this source. The page was already there, and this is what it said.
# Annotations > Annotations let you attach comments to specific parts of an artifact instead of describing a location in prose. Annotations let you attach comments to specific parts of an artifact instead of describing a location in prose. Select text in a Markdown, plain-text, LaTeX, or code file; select text in a PDF (one page at a time); click a point on an image or figure; or turn on **Annotate** and click an element in a rendered HTML report. Tables and other artifact types can't be annotated. Session transcripts can also be annotated. ## Leaving an annotation * Select content and click the **Annotate** pill. * Type your comment and press Cmd/Ctrl+Enter (or click **Save**). * The annotation appears as a highlighted badge (text) or numbered pin (images). Hover to read it; click to **Edit** or **Delete**. ## Sending annotations to Claude Saving an annotation doesn't send it. Pending annotations collect in an **N comments** chip on the composer and are sent with your next message. This lets you batch several annotations and send them together, or send them one at a time. Claude receives each annotation with its filename, the quoted selection (or marked image), and your note. Once sent, annotations are consumed: they leave the artifact and appear as cards on the message. Annotations don't have threads or a resolve state. To revise an artifact again after Claude updates it, annotate the new version. Limits: annotation text is capped at 1,000 characters. PDF selections can't cross page breaks. Annotations aren't included in downloads and don't appear in the **Files** grid.
claude-science/artifacts First recorded · 35 lines, first recorded
# Artifacts ## Working with artifacts ## Versions ## Provenance ## Deleting artifacts
The first capture of this source. The page was already there, and this is what it said.
# Artifacts > An artifact is a file Claude saves into the project: a figure, processed dataset, report, notebook, or other output. An artifact is a file Claude saves into the project: a figure, processed dataset, report, notebook, or other output. Artifacts are stored on your computer in the app's data folder and persist until you delete them. Other files Claude writes during a session are temporary and are cleared a few hours after the session ends; ask Claude to save a scratch file if you want to keep it. ## Working with artifacts Click a linked file in the conversation to open it in a tab beside the chat. HTML artifacts have zoom controls, including fit to width; images zoom up to their native resolution. Open **Files** in the sidebar for a searchable grid of every artifact in the project. From an artifact's menu you can: Open, Open beside session, **View in context**, **Provenance**, Versions, **Copy link**, **Star**, **Rename**, **Download**, or **Delete**. Renaming doesn't break links. **Delete** removes all versions permanently. Files you attach or drop into the composer are listed under **Your uploads**. To copy artifacts outside the app, use **Download** for a single file, or open the project's folder under \~/.claude-science and copy the files directly. ## Versions When Claude saves the same filename again in the same session, the artifact gains a new version. You can also edit text-based artifacts (Markdown, code, plain text) directly: click **Edit content**, make changes, and **Save** to create a new version. Images, PDFs, HTML, and tables can't be edited in place. When an artifact file is open, a version stepper and a diff toggle appear. In diff mode, you can choose which earlier version to compare against; the previous version is the default. Older versions are read-only; to restore one, ask Claude to save it again. Links Claude puts in the conversation point to the specific version that existed at the time. ## Provenance Every artifact version records how it was made. Open **Provenance** from an artifact's menu to see five tabs: * **Messages**: the conversation around the save. * **Code**: a reproducible script, downloadable as a script or notebook. * **Execution Log**: every command that ran. * **Environment**: the environment name, language version, and every installed package with its version. * **Review**: findings from [the reviewer](/docs/claude-science/the-reviewer). The **Execution Log** is the authoritative record of what ran. If the **Code** tab and the log disagree, trust the log. ## Deleting artifacts Deleting a session keeps its artifacts and their provenance. Deleting a project deletes all of its sessions, artifacts, and project-scoped memory.
claude-science/changelog First recorded · 92 lines, first recorded
# Claude Science changelog
The first capture of this source. The page was already there, and this is what it said.
# Claude Science changelog > Release notes for Claude Science, including new features, improvements, and bug fixes by version. <Update label="0.1.27" description="August 7, 2026"> * On macOS, installs that showed an environment setup error in their first session now repair themselves automatically after updating; the Featured connectors become available once the repair finishes, which can take a few minutes * Star a session from its menu to keep it in a Starred section at the top of your project's session list * Get notified when any of your sessions finishes or needs your input, even while you work in another project. In-app notifications are on by default; sound and desktop notifications are under Settings > General > Notifications * Set reasoning effort for a single session from the session options next to the message box; the value in Settings stays the default for new sessions * On Pro and Max plans, see your credit balance and monthly spend limit and turn usage credits on or off under Settings > Usage * When you ask for a plan, Claude now waits for your approval before running code or marking steps done * Lots of other miscellaneous improvements and fixes </Update> <Update label="0.1.21" description="July 21, 2026"> **New** * **Improved context preservation.** On Max, Team, and Enterprise plans, sessions go much further before older messages are summarized. * **Works on corporate networks.** Sign in and install packages on networks with corporate proxies, TLS inspection, or authenticated package mirrors. Mirror credentials go in Settings. No config files needed. * **Search your memories.** Find anything Claude remembers from the memory screen. Results are highlighted and jump to where they live. The screen also loads faster now. * **Archive projects.** Tidy your project list without deleting anything; archived projects keep all their data and can be brought back anytime. * **Password sign-in for SSH machines.** Adding a remote machine that asks for a password instead of a key is now supported. You're prompted when it's needed, and the password is never saved to disk. * **Compute monitor.** See every running kernel with its memory and CPU use from the new Compute tab. Kernels can be stopped if needed with optional feedback sent to the agent such as "redo this analysis using less memory". **Improvements and fixes** * **Richer artifact previews.** HTML files show rendered thumbnails, Word documents show text previews, large CSVs show their structure, and PDFs show their first page. * **Parquet files open as tables.** See a parquet file's columns and first rows right in the app, even for very large files. * **Memories stay in their project.** Notes from one project no longer surface in another. * **Annotations travel with your message.** Annotations you've added appear above the message box and carry over when you open a side chat. * **Less disk space for huge files.** When Claude saves the same very large file over and over, it can now keep just the latest version instead of every copy. * **The conversation view holds still.** Images no longer shove the page as they load, "View in context" lands on the right message, and mentioning a file always attaches the right one. * **Edit messages with attachments.** Editing an earlier message now supports file mentions, attachments, and uploads. * **Many other miscellaneous fixes and improvements.** </Update> <Update label="0.1.18" description="July 9, 2026"> **Features** * Sessions now pause and ask for your confirmation before spending extra usage. Billed usage credits are never drawn on a dismissible warning alone. * Claude can now monitor how much memory and processing power its computations are using, and plan its work accordingly. * Search from inside a project: the project view now has a search button that opens the same search as Cmd+K. * Download any artifact from any surface: every artifact menu now includes a download option. * Starred artifacts now pin to a new Starred section at the top of the Library, with a star badge. **Fixes** * Fixed a crash that could prevent very large sessions from loading. * Fixed several ways a running session could stall or stop early, including long thinking pauses being cut off mid-run and sessions resuming incorrectly after a crash. * Fixed the app sometimes becoming unresponsive after an automatic update. * Code blocks now switch correctly when your system switches between light and dark mode. * Lots of other miscellaneous improvements and fixes. </Update> <Update label="0.1.17" description="July 8, 2026"> * **Fixed a bug where idle sessions were consuming usage.** * Lots of other miscellaneous improvements and fixes. </Update> <Update label="0.1.16" description="July 7, 2026"> **Features** * Auto-review is now available on the Pro plan: turn it on from the session settings, and it stays off until you do. * Artifact previews: zoom HTML artifacts (including fit to width), zoom images to native resolution, and choose which version an artifact diff compares against * Import skills from private GitHub repositories using your own GitHub credentials * LaTeX previews now resolve cross-references — \ref, \eqref, and section numbering render the way your document intended * Dashboard upgrades: a project switcher with live per-project status, project names on the "Now" cards, a visible search button, and ⌘K search now matches project descriptions too * Annotate artifacts faster: drag image annotation pins to reposition them, and use @/# mentions in annotation comments **Fixes** * Pasted attachments no longer disappear before their first use, very large text and JSON previews no longer freeze the tab, and a stale usage-limit banner now clears itself once your usage limit resets * Cloning a repo or unpacking an archive no longer floods the chat with every image it contains * The Reviewer no longer gets stuck on "Reviewing…" or hides its findings tray * Flaky read-only connector tool calls now retry once automatically instead of failing your turn, and connector setup errors tell you what's actually wrong * A corrupt pasted image no longer breaks the transcript * Upgrading with a very large history database no longer fails partway through * Fixed a crash when the browser's auto-translate feature modified the page * Lots of other miscellaneous improvements and fixes </Update> <Update label="0.1.15" description="July 1, 2026"> * Corporate networks: environment builds now work behind TLS-inspecting proxies (such as Zscaler or Netskope). On macOS, corporate root CAs in your keychain are picked up automatically for conda/pip package downloads; on macOS or Linux you can also point at a CA-bundle file under Settings > Network > Package mirror. The mirror card's Check button now verifies TLS trust with the same bundle the builds use. (In-session `pip`/`curl` and the Desktop app's guest-VM builds are not covered) * Package mirrors: point conda and pip at your organization's internal mirror (Artifactory/Nexus) via Settings > Network > Package mirror. Setting a mirror also drops the public package hosts from the sandbox network allowlist * OpenAlex now requires a free API key for full-text access. Claude Science resolves access automatically or asks you in the session when a key is needed; you can also add and validate a key anytime under Settings > Credentials * New Context usage view: see how full a session's context window is and where tokens go, from the + menu in the composer * Lots of other miscellaneous improvements and fixes </Update> <Update label="0.1.14" description="June 30, 2026"> * Public launch of Claude Science </Update>
claude-science/cloud-storage First recorded · 19 lines, first recorded
# Cloud storage
The first capture of this source. The page was already there, and this is what it said.
# Cloud storage > Connect Amazon S3, Google Cloud Storage, or Azure Blob Storage so Claude can read data and write results in place, with your permission. Connect Amazon S3, Google Cloud Storage, or Azure Blob Storage so Claude can read data and write results in place, with your permission. In **Settings > Credentials**, choose **AWS**, **Google Cloud**, or **Microsoft Azure**, then Connect. Provide the credential (access key, service-account JSON, HMAC key, service principal, or connection string) and list the bucket names (AWS, GCP) or **Blob containers** (Azure) this credential covers. S3-compatible stores use the AWS form with the **S3-compatible endpoint** field; you'll need to allowlist that endpoint host separately. Listing a bucket adds its address to the sandbox network allowlist so code can reach it without a per-call card. Access within the bucket is still limited to the credential's permissions. Credentials are encrypted on your computer and sent only to the provider they belong to. Claude reads and writes objects with ordinary code using the provider's Python library (`boto3`, Azure SDK). **Settings > Storage** lists connected credentials and lets you browse and import objects (up to 100 GB) or export artifacts. <Note> From code, reach Google Cloud Storage with an **HMAC key** via `boto3`, or use the import/export flow. `gsutil`, `gcloud storage`, and the google-cloud-storage Python library use path-style addresses that aren't reachable from the sandbox. </Note> <Warning> Any code Claude writes can use credentials you add here. If a bucket should never be reachable from an analysis session, don't add its credential. </Warning>
claude-science/command-line-settings First recorded · 71 lines, first recorded
# Command line settings ## Commands ## Global flags ## The login link ## Flags for serve ## Dangerous flags ## Environment variables ## See also
The first capture of this source. The page was already there, and this is what it said.
# Command line settings
> Reference for the claude-science command: every subcommand, the serve flags, the single-use login link, and the environment variables Claude Science reads.
Reference for the claude-science command: every subcommand, the serve flags, the single-use login link, and the environment variables Claude Science reads.\
claude-science serve starts Claude Science and opens the web app in your browser at a single-use login link. Everyday use is that one command. The others manage the running program: they mint login links, report status, follow logs, install updates, and merge data directories.
## Commands
| Command | What it does |
| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `claude-science serve` | Start the background program and open the web app in your browser at a single-use login link. One runs per data directory; Ctrl-C stops it. |
| `claude-science open` | Mint a fresh login link from the running program and open it in your browser. |
| `claude-science url` | Print a fresh login link alone on standard output and nothing else. |
| `claude-science status` | Print whether the program is running, the version, and the port, as JSON. |
| `claude-science logs` | Print the newest log file from the data directory. `--tail` follows it live. |
| `claude-science stop` | Stop the program cleanly. |
| `claude-science update` | Check for and install an update. `--check` only reports; --to `<version>` installs a specific version, which is also how you roll back. Updates are signature-verified and replace the binary atomically. |
| `claude-science import` `<path>` | Merge another data directory, or its database file, into this one. |
| `claude-science --version` | Print the version. |
| `claude-science` `<command>` --help | Print help for any command. |
<Note>
`import` has no preview and no undo. Back up the data directory before you run it; running the same import a second time is safe.
</Note>
## Global flags
These two work on every command.
| Flag | Default | What it does |
| -------------------- | ------------------------------- | ------------------------------- |
| `--data-dir` `<dir>` | `~/.claude-science` | The data directory to use. |
| `--config` `<file>` | `~/.claude-science/config.toml` | The configuration file to read. |
## The login link
When serve starts, it prints a line of the form `Web UI -> http://localhost:<port>/?nonce=...`. The nonce is a one-time password: it signs one browser tab in and then expires, about three minutes after it is printed. The signed-in tab stays signed in until you restart the program.\
You never need to keep a link. claude-science open mints a fresh one and opens it in your browser whenever you want to sign in again. For a machine you reach over SSH, claude-science url prints a fresh link alone on standard output: run it there, then open the printed link through your tunnel. The app listens on 127.0.0.1 unless you change --host, so it is reachable only from your own machine.
## Flags for serve
| Flag | Default | What it does |
| ------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `--port` `<n>` | `8000` | The port the web app is served on. 0 picks a free port. |
| `--no-browser` | off | Do not open a browser. url prints a login link any time you want one. |
| `--detached` | off | Run in the background. Implies --no-browser. |
| `--no-auto-update` | off | Do not check for or install updates. For a pinned or centrally managed install. |
| `--host` `<address>` | 127.0.0.1 | The address the app listens on. Anything else exposes the app to your network; prefer an SSH tunnel. |
| `--base-path` `</prefix>` | unset | Serve the app under a URL prefix behind a reverse proxy. |
| `--allow-origin` `<url>` | unset | An extra browser Origin allowed to connect; repeat the flag for more than one. It does not change which sites Claude can reach. |
| `--sandbox-port` `<n>` | port + 1 | The separate origin that previews of generated HTML are served from, so a previewed page cannot read your session. |
| `--verbose` | off | Show startup and info log lines on the console; by default they go only to the log file. |
## Dangerous flags
<Warning>
`--dangerously-no-sandbox` runs code with full read and write access to your home directory and an unrestricted network. `--dangerously-skip-approvals` approves every permission card automatically, for everything, until you restart without the flag; questions addressed to you still appear. Neither belongs in everyday use.
</Warning>
## Environment variables
`DO_NOT_TRACK`, set to any value, turns usage analytics off. It is the same switch as `disable_telemetry = true` in the configuration file. `GITHUB_TOKEN` is optional and is used only against `api.github.com`, to lift the rate limit when you install a skill from a GitHub repository. Claude Science also reads the standard proxy variables (`HTTPS_PROXY`, `HTTP_PROXY`, `NO_PROXY`, and `ALL_PROXY`); see [Use Claude Science on a corporate network](/docs/claude-science/corporate-networks#connect-through-an-outbound-proxy). The proxy address variables are the one case where the environment overrides the configuration file, and `NO_PROXY` is merged with the `no_proxy` key rather than replacing it. Every other setting belongs in the configuration file.
## See also
<CardGroup cols={1}>
<Card title="Remote compute clusters" href="/docs/claude-science/remote-compute-clusters">
Connect an SSH host and run jobs on it.
</Card>
</CardGroup>
claude-science/compute-providers First recorded · 37 lines, first recorded
# Compute providers ## Connecting Modal ## Running cloud jobs ## Container images ## Model endpoints ### NVIDIA BioNeMo NIM
The first capture of this source. The page was already there, and this is what it said.
# Compute providers > Claude Science can run jobs on an external cloud provider you control, and connect to model servers that serve scientific models over HTTP. Claude Science can run jobs on Modal using a Modal account you own and control. You connect your account, jobs run on it, and Modal bills you directly. Anthropic doesn't provide or bill compute and never sees a payment method. ## Connecting Modal In Settings > Compute > **Cloud providers**, click Connect on the Modal card. If you've signed in with the Modal CLI (`modal token new`), the app reads `~/.modal.toml` automatically; click Check again after the file exists. Alternatively, paste a **Token ID** and **Token secret** in Settings > Credentials, under Modal. Tokens are stored encrypted on your computer and never shown to Claude. ## Running cloud jobs When work needs a GPU or more memory than your machine has, Claude proposes a job and a **Start a Modal job?** card appears. The card shows the Modal profile, exact machine spec (for example, H100, 8 CPUs, 32 GiB), a note that billing is per-second, and the maximum billable time. It links to Modal's pricing page. Approve per job, or for the conversation or project. A separate card asks before Claude opens a Modal setup shell (capped at 30 minutes, no GPU). Input files are limited to 1 GiB per submit. For larger inputs, Claude can stage data to a Modal Volume and mount it into the job. Outputs written to `./out/` (up to 5 GiB) are returned with logs. <Note> Closing the app doesn't cancel a running Modal job; it continues billing until it finishes or times out. </Note> Cost controls: there's no spend ceiling. Each job is approved individually with its machine and time limit visible. **Concurrent jobs** (default 10, set on the Modal page under Settings > Compute) caps simultaneous containers that Claude Science on this machine can run. **Default container timeout** is 12 hours (maximum 23), enforced by Modal. Track spend on Modal's dashboard. On the Modal page under Settings > Compute you can set the Modal environment and the default application name used for containers. ## Container images Claude derives a container image from the environment a job needs and builds it once on Modal's build servers, then reuses that image for later jobs until the environment changes. Claude tracks built images in the Details document on the Modal page under Settings > Compute. ## Model endpoints Claude Science can connect to a model server (hosted, or a container you run) that serves a scientific model over HTTP, and call it directly from analyses. ### NVIDIA BioNeMo NIM In Settings > Compute, under Model endpoints, click Connect on NVIDIA BioNeMo NIM. Import the skills from the BioNeMo Agent Toolkit, add your NVIDIA NGC API credential, and connect to NVIDIA-hosted API endpoint, or choose to run the model as a local container (On a machine with an NVIDIA GPU). Once connected, ask Claude to start a local Docker NIM container or set up a remote connection for a specific NIM skill from the BioNeMo Agent Toolkit.
claude-science/configuration-file-reference First recorded · 48 lines, first recorded
# Configuration file reference ## Network configuration ### App connection keys ### Package download keys ### Sandbox network keys ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Configuration file reference > Claude Science's config.toml file: where it lives, how its values interact with the Settings page, and the network-related keys for the outbound proxy, certificate bundles, package mirror, and sandbox network allowlist. Claude Science reads optional settings from a TOML file at `~/.claude-science/config.toml` on macOS and Linux. Every key has a default, so the app starts with no file present; administrators deploy the file with device management to set fleet policy. The file is read once at startup, so changes take effect after a restart. The `claude-science` command accepts `--config <file>` to read a different file for one run. ## Network configuration The network-related keys, grouped by the TOML table each belongs to. For the package-mirror keys (`[conda] channel_mirror`, `pip_index_url`, and `ca_bundle`) and the proxy key (`[network] proxy`), a value set in the file takes precedence over the matching Settings control, which then shows as managed by your organization so a member cannot override it. The `[sandbox.network]` lists are additive instead: they add to the member-managed lists under **Settings** > **Network** and lock nothing. The `[network] ca_bundle`, `no_proxy`, and `mcp_x509_strict` keys and `[conda] allow_insecure_mirror` have no in-app control. ### App connection keys The `[network]` table configures the app's own connections to Anthropic. | Key | Type | Default | Effect | | ----------------- | ------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `proxy` | string (URL) | unset | The outbound proxy for the app's HTTP and HTTPS connections, for example `http://proxy.example.corp:8080`. Supply Basic-authentication credentials in the address. An `https://` (TLS-to-proxy) address applies to the app's own connections only; sandboxed package downloads connect directly when the proxy is `https://`, so prefer `http://`. A proxy variable in the app's environment (including `ALL_PROXY`) takes precedence over this key, which takes precedence over the Settings proxy field and the macOS system proxy settings. | | `no_proxy` | string (comma-separated) | unset | Hosts that bypass the proxy, as exact hostnames or domain suffixes in one comma-separated string, for example `".example.corp,registry.example.corp"`. Combined with the `NO_PROXY` environment variable and, when the macOS system settings supply the proxy address, the system's bypass list. Loopback addresses always bypass the proxy. | | `ca_bundle` | string (absolute path) | unset | PEM file added to the app's default TLS trust for sign-in, the Claude API, Anthropic-hosted connectors, and update checks; use it for a corporate root behind TLS inspection. It covers the app's own connections only, while package downloads use `[conda] ca_bundle`. The value must be an absolute path outside the app's data directory (`~/.claude-science`), temporary directories, and any directory you have granted Claude write access to; a system location such as `/etc/claude-science/corporate-ca.pem` is recommended. The file must exist, parse as a PEM bundle, and contain no private key; a failing value is ignored with a warning. | | `mcp_x509_strict` | `"auto"`, `"relaxed"`, or `"strict"` | `"auto"` | How strictly local connectors check a corporate certificate's profile. With `"auto"`, Claude Science relaxes the strict check when it detects TLS inspection from a configured `[network] ca_bundle`. Connectors pick up a change at their next relaunch. | ### Package download keys The `[conda]` table configures where analysis environments fetch packages from and how those downloads verify certificates. | Key | Type | Default | Effect | | ----------------------- | ---------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `channel_mirror` | string (URL) | unset | Base URL of an internal conda mirror. Channel names resolve beneath it, so `<channel_mirror>/conda-forge/noarch/repodata.json` must return the conda-forge index. Setting it removes the public conda hosts from the sandbox allowlist and admits the mirror host, which environment builds contact directly from the workstation, not through an outbound proxy. Must be `https://` on port 443 or 8443 (an `http://` URL is accepted only when `allow_insecure_mirror` is set), by DNS name, with no embedded credentials. A deployed value these rules reject prevents the app from starting. | | `pip_index_url` | string (URL) | unset | A PEP 503 simple index for Python packages, for example an Artifactory or Nexus PyPI remote ending in `/simple`. Setting it removes the public Python hosts from the sandbox allowlist. Same URL rules as `channel_mirror`, including the startup failure on an invalid value. | | `ca_bundle` | string (absolute path) | unset | A complete PEM bundle (public roots plus your corporate roots) that package downloads verify against, replacing the default trust list; in this release the bundle alone may not be sufficient for pip, which verifies against the operating system's trust store. This key affects package downloads only and never fixes sign-in; behind TLS inspection, set `[network] ca_bundle` as well. When unset, Linux uses your distribution's system certificate bundle. Same path rules as `[network] ca_bundle`. | | `allow_insecure_mirror` | boolean | `false` | Allows `http://` mirror URLs in this file (the Settings page accepts `https://` only). Off by default because a plaintext mirror lets an on-path attacker substitute packages. | ### Sandbox network keys The `[sandbox.network]` table adjusts the network allowlist the analysis sandbox enforces. Members see the same allowlist under **Settings** > **Network**. | Key | Type | Default | Effect | | ----------------- | ---------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `enabled` | boolean | `true` | When `false`, code Claude runs has no network access: package installs and data fetches inside the analysis fail, while the app's own connections are unaffected. This is a no-network mode, not a way to skip the allowlist. | | `allowed_domains` | array of strings | `[]` | Domains added to the built-in allowlist, as exact hostnames or wildcards such as `*.example.org`. | | `denied_domains` | array of strings | `[]` | Domains added to the built-in denylist. A denied domain is blocked even if it also appears on the allowlist, and the built-in denylist entries cannot be removed. | ## Related resources * [Use Claude Science on a corporate network](/docs/claude-science/corporate-networks): how to apply these keys for a proxy, TLS inspection, or an internal mirror * [Network requirements](/docs/claude-science/network-requirements): the built-in allowlist and denylist these keys adjust * [Manage Claude Science on devices](/docs/claude-science/manage-on-devices): deploying `config.toml` with device management * [Command line settings](/docs/claude-science/command-line-settings): the `--config` and `--data-dir` flags
claude-science/connectors-and-skills First recorded · 48 lines, first recorded
# Connectors and skills ## Featured connectors ## Using connectors ## Skills
The first capture of this source. The page was already there, and this is what it said.
# Connectors and skills > Connectors give Claude access to external data sources during an analysis. Connectors give Claude access to external data sources during an analysis. Skills are written instructions Claude loads when relevant, covering how to run a method, which tools to use, and what to verify. Both are managed in Settings and apply across all projects. ## Featured connectors Claude Science includes Featured connectors to public life-sciences databases. All are on by default and can be turned off individually in **Settings > Connectors**. Featured connectors are read-only and don't require an account or key. Some underlying databases have non-commercial or attribution terms; review each source's license for your use case. | Connector | Sources | | ------------------------- | ---------------------------------------------------- | | Genomes | Ensembl (incl. VEP), UCSC | | Genes & Ontologies | MyGene, UniProt, GO, Reactome, OLS | | Variants | gnomAD, ClinVar, dbSNP | | Human Genetics | GWAS Catalog, eQTL Catalogue, FinnGen, BioBank Japan | | Clinical Genomics | ClinGen, CIViC, Open Targets | | Expression | GTEx | | Regulation | ENCODE, JASPAR, UniBind | | Protein Annotation | InterPro, Pfam, Human Protein Atlas, STRING | | Structures & Interactions | PDB, AlphaFold, EMDB, Complex Portal, IntAct | | RNA | Rfam | | Omics Archives | GEO, ArrayExpress, PRIDE, MGnify, MetaboLights | | Cancer Models | cBioPortal | | Chemistry | PubChem, ChEBI, Rhea, BindingDB | | Drug Regulatory | FDA drug data, openFDA | | Literature Graph | OpenAlex, arXiv | | Research Resources | Grants.gov, Antibody Registry | Additional Featured connectors: **BioMart**, **CellGuide** (CELLxGENE cell types), **ZINC** (purchasable chemical space), and **Ketcher Chemistry** (2D molecule sketcher). Four Directory connectors are available from the [connector directory](https://claude.com/connectors) and are accessible in Claude Science and other Claude products: **PubMed**, **Clinical Trials**, **ChEMBL**, and **bioRxiv**. On Team and Enterprise plans, directory connectors appear only after an admin adds them. By choosing to enable connectors, you authorize Claude to use the optional enabled resources on your behalf and confirm you have the necessary rights and licenses. These resources and content they reach may be subject to third-party terms (viewable in Settings), and you are solely responsible for compliance. ## Using connectors Name a source in your request, or describe what you need and Claude chooses from available connector tools. Connector queries appear in the conversation as expandable code steps. Featured connectors you've previously enabled run without a permission card. Connectors you add yourself prompt for approval per tool, with Once, This conversation, This project, or Global scope. The databases behind Featured connectors are on the network allowlist in groups under Settings > Network. Turning off a group disables the connectors that depend on it. ## Skills **Settings > Skills** lists the skills Claude can load. Featured science skills include literature review, indication dossier, and model-specific skills for AlphaFold2, Boltz-2, Chai-1, ESMFold2, OpenFold3, ProteinMPNN (with LigandMPNN and SolubleMPNN), DiffDock, ESM-2, Evo 2, Borzoi, scGPT, and scvi-tools. Claude loads a skill automatically when the work calls for it. Type **/** in the composer to open the skill picker and insert one explicitly. **Add skill** lets you create your own via **Chat with Claude**, **Write from scratch**, **Upload a skill**, or **Import from GitHub**. **Import from GitHub** works with private repositories too, once you add a GitHub token under **Settings > Credentials**. You can also ask Claude to distill a workflow from an existing session into a skill.
claude-science/core-concepts First recorded · 57 lines, first recorded
# Core concepts ## Projects and sessions ## Files stay on your computer ## Permission cards ## Plans ## Sandbox ## Delegation ## Memory ## Composer shortcuts
The first capture of this source. The page was already there, and this is what it said.
# Core concepts > A project groups related sessions and the artifacts they produce. ## Projects and sessions A project groups related sessions and the artifacts they produce. Projects also let you set up custom instructions for Claude to read at the start of every session. Folder permissions you grant persist across sessions within a project. A session is one conversation thread. Each session has its own workspace folder and multiple running kernels. ## Files stay on your computer Claude reads and writes files in place, in the folders you grant. Anthropic doesn't host or store your files; file content that Claude reads to answer a prompt is sent to Anthropic's API as part of that conversation and handled under Anthropic's standard retention policy. If you sign in to Claude Science on a different computer, your files, artifacts, and conversation history don't follow you there. The one exception to working in place is **Attach files** in the composer: attached files are copied into the application's local data folder so they stay with the conversation. <Warning> Don't move, rename, or delete files inside \~/.claude-science directly. Doing so can break artifact links and version history. Manage artifacts through the app. </Warning> ## Permission cards A permission card appears in the conversation each time Claude needs a new kind of access. The card names exactly what's being requested. You can allow or deny each one. | Action | Card title | Scope options | | ---------------------- | ----------------------------------------------------------- | ------------------------------------------------- | | Read or write a folder | Access `<folder>` on your computer? | Read-only or Read & write; persists until revoked | | Run code | Run Python code? / Run a shell command? / Install packages? | Once or Always | | Reach a network host | Connect to `<target>`? | Persists until revoked | | Use a connector tool | Use `<tool>`? | Once, This conversation, This project, or Global | | Run a remote job | Run this job on `<host>`? / Start a Modal job? | Once, This conversation, This project, or Global | All standing grants are listed in Settings > Permissions and can be revoked there. ## Plans Claude might choose to propose a plan before starting multi-step work. You approve the plan or iterate with Claude on refining it; plan text can't be edited directly. Approved plan steps appear in the conversation and are marked complete as work finishes. ## Sandbox All code Claude writes runs inside an operating-system sandbox on your computer. The sandbox can read and write only the workspace and the folders you've granted. Its network is deny-by-default: outbound connections go through a local proxy that allows only package managers, the scientific databases behind Featured connectors, and hosts you've approved. ## Delegation **Delegation** lets Claude split a request into independent tracks that run in parallel. Turn it on or off per session in the session settings menu; your last choice becomes the default for new sessions. When work splits, a marker appears in the conversation for each track with a status indicator. Click a marker to open that track's transcript. **Stop** ends the whole session; individual tracks can't be stopped separately. ## Memory Memory lets Claude save short facts about you, your projects, and your files across sessions. Memory is off by default. Turn it on in Settings > Memory. Saved facts are stored in the app's local database on your computer; they aren't synced to Anthropic. The Memory settings page lists every saved fact. You can edit, delete, add, or clear facts there. A per-session toggle in the session settings menu turns memory off for that session only. ## Composer shortcuts * `@` inserts an artifact or uploaded file by name * `#` inserts a past session by title * `/` inserts a skill
claude-science/corporate-networks First recorded · 216 lines, first recorded
# Use Claude Science on a corporate network ## Setup at a glance ## What works on a corporate network ## Point package installs at an internal mirror ### Mirror credentials ### Mirror traffic and your other network controls ## Connect through an outbound proxy ### Proxy settings in the configuration file ### macOS system proxy settings ### How the environment variables reach the app ## Work behind TLS inspection ### Corporate root for app connections ### Corporate root for package downloads ### What the certificate settings do not cover ## Troubleshooting corporate network errors ### Token exchange failed: unable to get local issuer certificate ### The proxy requires its own sign-in (HTTP 407) ### Package downloads are being blocked by network policy ### HTTP 401 or 403 during an environment build ### HTTP 401 on the mirror check ### Green check, then nothing provides the package ### CONNECT tunnel failed, response 403, naming an amazonaws.com host ### https mirrors must use port 443 or 8443 ### Local connectors fail with certificate errors behind inspection
The first capture of this source. The page was already there, and this is what it said.
# Use Claude Science on a corporate network
> How to run Claude Science behind an outbound proxy, a TLS-inspecting proxy, an internal package mirror, and an egress firewall, with the settings your network team needs for each.
Claude Science runs on each member's computer and connects out for sign-in, the Claude API, and package and research hosts, usually through controls your IT organization manages on a corporate network. This page shows the administrator who runs those controls how to point Claude Science at an internal package mirror, configure an outbound proxy and TLS inspection, and hand the firewall team the [network requirements](/docs/claude-science/network-requirements) it needs.
Claude Science makes three kinds of outbound connections, each passing through a different part of your network policy:
* The app's own connections (sign-in, the Claude API, Anthropic-hosted connectors, update checks) traverse your outbound proxy and TLS inspection.
* The analysis sandbox's connections (package hosts and research databases, when Claude runs code) are filtered by the app's own network allowlist; package downloads can be redirected to your internal mirror.
* Interactive previews load display libraries from public content-delivery networks in the browser, as ordinary browser traffic governed by your endpoint's web policy.
## Setup at a glance
1. Check the [support table](#what-works-on-a-corporate-network) for your operating systems and network shape.
2. Hand the [network requirements](/docs/claude-science/network-requirements) page to the team that manages your proxy or firewall allowlist.
3. [Point package installs at your internal mirror](#point-package-installs-at-an-internal-mirror) if the public package hosts are blocked, and deploy the mirror credential.
4. [Connect through an outbound proxy](#connect-through-an-outbound-proxy) if your network uses one.
5. If your proxy inspects TLS, [deploy your corporate root certificate](#work-behind-tls-inspection) as two bundles: one for the app, and a differently built one for package downloads.
6. [Deploy the settings with device management](/docs/claude-science/manage-on-devices#deploy-configuration-with-device-management) rather than by hand.
7. If sign-in or a first build fails, match the error against [Troubleshooting](#troubleshooting-corporate-network-errors).
## What works on a corporate network
| Network shape | macOS | Linux |
| ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Explicit outbound HTTP proxy (HTTP CONNECT) | Supported; detected automatically from the system settings | Supported |
| Proxy that requires Basic authentication | Supported, with credentials in the proxy address | Supported, with credentials in the proxy address |
| Proxy that requires NTLM, Negotiate, or Kerberos authentication | Not supported | Not supported |
| Network that only publishes a PAC or WPAD file | Not supported | Not supported |
| SOCKS proxy | Not supported | Not supported |
| TLS inspection on the app's own connections (Zscaler, Netskope, and similar) | Supported with a CA bundle setting | Supported with a CA bundle setting |
| TLS inspection on conda package downloads | Supported with a CA bundle setting | Supported with a CA bundle setting |
| TLS inspection on pip package downloads | Supported, with the corporate root also installed in the operating system's trust store (see [Corporate root for package downloads](#corporate-root-for-package-downloads)) | Supported, with the corporate root also installed in the operating system's trust store (see [Corporate root for package downloads](#corporate-root-for-package-downloads)) |
| Internal package mirror (Artifactory, Nexus) | Supported | Supported |
| Internal package mirror reached only through the corporate proxy | Not supported | Not supported |
| Authenticated package mirror | Supported, with the credential saved in Settings | Supported, with the credential saved in Settings |
| Local connectors (the bundled research tools) behind TLS inspection | Not supported | Not supported |
## Point package installs at an internal mirror
When your network blocks the public package hosts (`conda.anaconda.org`, `repo.anaconda.com`, `pypi.org`), point Claude Science at your internal artifact repository instead, and every environment build fetches packages through it. Set the mirror for a fleet with the `[conda] channel_mirror` and `pip_index_url` keys in a [deployed `config.toml`](/docs/claude-science/manage-on-devices#deploy-configuration-with-device-management), or for a single machine under **Settings** > **Network** > **Package mirror**, where the same two settings are called the conda channel mirror and the pip index URL. The steps below use the Settings page, the quickest way to test a mirror URL before you deploy it.
Set both a conda channel mirror and a pip index: analysis environments are built from conda packages, so a pip index alone leaves the first build stuck trying to reach the public conda host.
<Steps>
<Step title="Enter the conda channel mirror">
Open **Settings** > **Network**, select **Configure** on the **Package mirror** row, and paste the base URL of your conda mirror. For JFrog Artifactory that is the conda API root or a virtual conda repository, for example `https://yourorg.jfrog.io/artifactory/api/conda/conda-all`.
</Step>
<Step title="Enter the pip index URL">
Paste your Python package index, including the `/simple` suffix that Artifactory and Nexus PyPI remotes use, for example `https://yourorg.jfrog.io/artifactory/api/pypi/pypi-remote/simple`.
</Step>
<Step title="Save, then run the check">
Select **Save**, then **Check**: a green result confirms the mirror answered, and a `401` or `403` on an authenticated mirror is expected until a credential is saved (see [Mirror credentials](#mirror-credentials)). The mirror takes effect for the next package operation without a restart. On a machine with an outbound proxy, confirm with a test environment build rather than the check alone (see [Mirror traffic and your other network controls](#mirror-traffic-and-your-other-network-controls)).
</Step>
</Steps>
The mirror must serve the standard conda channel layout, with one base URL, one directory per channel, and one per platform beneath it:
```text theme={null}
<channel mirror>/
conda-forge/
noarch/repodata.json
noarch/<package>.conda
linux-64/repodata.json
osx-arm64/...
bioconda/
noarch/...
```
Your mirror must serve at least `conda-forge` (every environment uses it) and `bioconda` for R and bioinformatics work; other channels a member requests (for example `pytorch` or `nvidia`) resolve under the same mirror base, so serve those too if needed. Anaconda's commercial `defaults` channel is rejected while a mirror is configured, so members should use `conda-forge` instead.
<Note>
Do not point the conda mirror at a remote repository configured for a single channel (for example one whose upstream is `https://conda.anaconda.org/conda-forge`): it returns an empty index that the check reports green while every build then fails with `nothing provides <package>`. Use a remote that proxies the conda host root (`…/artifactory/api/conda/conda-remote`), a virtual conda repository, or the conda API root with channel-named remote repositories beneath it.
</Note>
Mirror URLs must use `https://`, name a host by DNS name rather than IP address, and use port 443 or 8443, so an Artifactory instance on its stock port 8081 needs a 443 or 8443 listener or a reverse proxy in front of it. Credentials embedded in the URL are rejected at save time. The Settings page accepts `https://` mirrors only, while Claude Science also accepts an `http://` mirror from `config.toml` when `[conda] allow_insecure_mirror` is set. Validate mirror URLs before distributing a `config.toml`, since an invalid deployed value prevents the app from starting.
### Mirror credentials
For a mirror that requires authentication, enter one username and access token under **Settings** > **Network** > **Package mirror** > **Mirror credentials**, using an account scoped to reading the mirror, then run the check so it signs in with the credential. The one credential is presented to both the conda-mirror host and the pip-index host, so if those need different accounts, keep one of them anonymous; the credential is sent only to `https://` mirror hosts.
Claude Science stores the credential encrypted in its local database, using a key kept in a file only the member's account can read (on macOS, a copy of that key is in the keychain for recovery), and also writes the credential, automatically, to a plaintext `.netrc` at `~/.claude-science/conda/.netrc` that the conda and pip download tools read during environment builds. Code that runs while an environment builds (a package's `setup.py`, for example) can read that file, Claude's analysis code cannot read either location, and a `.netrc` in the member's home directory is not used for these downloads. For a fleet that manages credentials centrally, deploy that `.netrc` file yourself instead, one `machine <mirror hostname>` block per mirror host with `login` and `password` lines and no comments, and use either the file or Settings, not both: a credential saved in Settings rewrites the file from the saved value at the save and at every restart and environment build, while a file deployed with no credential saved in Settings is left alone.
Environments a member registers from an existing project folder install their packages inside the analysis sandbox during a session, where the credential is hidden by design, so those environments need a mirror that allows anonymous reads.
### Mirror traffic and your other network controls
Configuring a mirror removes the public package hosts from the sandbox's network allowlist and admits the mirror host in their place, so a misconfigured mirror fails with an error that names the mirror rather than falling back to the public hosts. To keep the public hosts reachable alongside the mirror, re-add them under **Settings** > **Network** (`pypi.org`, `*.pypi.org`, `files.pythonhosted.org` for pip, and `conda.anaconda.org`, `repo.anaconda.com`, `anaconda.org`, `*.anaconda.org` for conda).
Environment builds connect to the mirror host directly, never through your outbound proxy: the workstation needs a direct route (typically your VPN or internal network), any workstation firewall must allow the mirror host as a direct destination, and a proxy allowlist entry alone does not reach it. A package failure that names the mirror on a proxy-only network therefore means the mirror is unreachable directly, and a SaaS repository such as `yourorg.jfrog.io` works only if the workstation can reach it directly, so on a proxy-only network host the mirror inside your network. On a proxy-configured machine the **Check** button and a real build can take different paths, so treat a test environment build as the authoritative signal (a known limitation).
Mirrors that redirect package files to path-style object-storage URLs (such as `s3.us-west-2.amazonaws.com/<bucket>/...`) fail with `CONNECT tunnel failed, response 403`, because path-style object-storage hosts are on a built-in denylist that cannot be overridden; have the mirror serve the files itself, or redirect to bucket-qualified hostnames such as `<bucket>.s3.us-west-2.amazonaws.com` and add that hostname under **Settings** > **Network** > **Allowed domains**. The check warns at save time when it sees a redirect to a denied host. The package manager that builds environments ships inside the app, so a first build on a locked-down network downloads no tooling from GitHub.
## Connect through an outbound proxy
Claude Science reads its proxy configuration once at startup, so restart it after a change. The first source that sets a proxy address wins:
1. The standard proxy variables in its own process environment: `HTTPS_PROXY`, `HTTP_PROXY`, and `NO_PROXY` (lowercase spellings also work). `ALL_PROXY` fills in for either proxy variable that is unset, an empty variable counts as unset, and `NO_PROXY="*"` sends all traffic directly.
2. The `[network] proxy` key in `config.toml`, the form to [deploy with device management](/docs/claude-science/manage-on-devices#deploy-configuration-with-device-management).
3. The proxy field under **Settings** > **Network**, where a member can paste a proxy address by hand. It takes effect at the next restart, and when `config.toml` sets the proxy, the field shows as managed by your organization so members cannot override it.
4. On macOS only, an explicit web proxy configured in the system's network settings, which Claude Science detects automatically.
Write the proxy as an `http://` URL; if it requires a username and password, embed them in the address and percent-encode special characters (for example, `@` in a password becomes `%40`):
```text theme={null}
HTTPS_PROXY=http://username:[email protected]:8080
HTTP_PROXY=http://username:[email protected]:8080
NO_PROXY=.example.corp
```
An `https://` (TLS-to-proxy) address works for the app's own connections only. Sandboxed package downloads tunnel only through `http://` proxies, so with an `https://` address they skip the proxy and connect directly; an `http://` address keeps every connection on the proxy.
Claude Science always bypasses the proxy for loopback addresses (`localhost`, `127.0.0.1`, and their IPv6 equivalents), whether or not they appear in `NO_PROXY`, so the app and its background service can always talk to each other. Add your internal domains to `NO_PROXY`; entries match a host exactly or as a domain suffix (`.example.corp` and `example.corp` behave the same), and CIDR ranges such as `10.0.0.0/8` are not matched. `NO_PROXY` entries from the environment, the configuration file, and (when the system settings supply the proxy address) the macOS bypass list are combined.
### Proxy settings in the configuration file
For a fleet, set `[network] proxy` and `no_proxy` in `config.toml`; both keys and their formats are in the [configuration file reference](/docs/claude-science/configuration-file-reference#app-connection-keys).
### macOS system proxy settings
Claude Science detects an explicit system web proxy automatically, so a machine whose proxy your MDM already sets needs no Claude Science configuration unless the proxy requires authentication. macOS keeps an authenticated proxy entry's credentials in the keychain, where Claude Science cannot read them, so connections through the detected proxy fail with HTTP 407 (see [the troubleshooting entry](#the-proxy-requires-its-own-sign-in-http-407)); set `[network] proxy` with the credentials in the address instead. When the network publishes only a PAC or WPAD file, Claude Science detects it and names the PAC URL in the sign-in error, but does not evaluate it. Set `[network] proxy` to the proxy the PAC file resolves to for Anthropic's hosts.
### How the environment variables reach the app
How the variables reach the app depends on the operating system:
* On macOS, the menu-bar app reads `~/.claude-science/env`, a file of `KEY=VALUE` lines (`export KEY=VALUE` also works), when it launches. Put the three variables there, then quit and reopen the app; an app started from the Dock or Finder does not see variables exported in a terminal. The file's `NO_PROXY` entries merge with the other sources rather than replacing them.
* On Linux, export the variables in the shell or service unit that starts `claude-science serve`. The `env` file is read only by the macOS app.
Only Basic proxy authentication, supplied in the proxy address, is supported; NTLM, Negotiate, and Kerberos proxies are not, and neither are networks whose only published proxy configuration is a PAC or WPAD file, because Claude Science does not evaluate PAC files.
<Note>
For a proxy that only speaks NTLM or Kerberos, a local relay such as `cntlm` or `px` works: the relay runs on the workstation, authenticates to your corporate proxy with the user's credentials, and exposes a plain HTTP proxy on the loopback interface. Point `HTTPS_PROXY` and `HTTP_PROXY` at the relay (for example `http://127.0.0.1:3128`). The loopback bypass governs which destinations skip the proxy, not whether the proxy can be reached, so a loopback relay works as a proxy address.
</Note>
Environment builds reach a configured [package mirror](#point-package-installs-at-an-internal-mirror) directly, not through the proxy. Separately, the `claude-science update` terminal command is its own process: it honors proxy variables exported in that shell but not the macOS `env` file, so export the variables in the terminal first. The background updater inside the running app uses the app's proxy settings.
## Work behind TLS inspection
A TLS-inspecting proxy such as Zscaler or Netskope re-signs every HTTPS connection with a certificate from your organization's own root certificate authority, which Claude Science's built-in list of public roots does not include, so until you give it that root, sign-in and package downloads fail certificate verification (the sign-in error is listed under [Troubleshooting](#troubleshooting-corporate-network-errors)).
Two settings carry the corporate root and behave differently. Set the one that matches the traffic, and read the warning in [Corporate root for package downloads](#corporate-root-for-package-downloads) before reusing one file for both.
### Corporate root for app connections
The `[network] ca_bundle` key in `config.toml` points at a PEM file whose certificates Claude Science adds to its default trust for sign-in, the Claude API, Anthropic-hosted connectors, and update checks; the public roots stay in place, so the file holds only your corporate root. The path rules are in the [configuration file reference](/docs/claude-science/configuration-file-reference#app-connection-keys). A failing value is ignored with a warning rather than stopping the app, so a sign-in error behind inspection usually means the bundle did not load, and the app re-reads the bundle every few minutes, so a corrected file takes effect without a restart. When you deploy a `config.toml`, deploy the bundle files alongside it.
### Corporate root for package downloads
Conda package downloads for the analysis sandbox use their own setting, `[conda] ca_bundle`, the complete list of roots those downloads trust, so it must contain the public roots your packages come from as well as your corporate root. On Linux, when the key is not set, Claude Science uses your distribution's system certificate bundle (maintained by `update-ca-certificates` or `update-ca-trust`), so a Linux image that already trusts your corporate root needs no setting at all.
`[conda] ca_bundle` affects package downloads only and never fixes sign-in. The CA bundle path field on the Settings page sets this same `[conda]` key, so filling it in helps package downloads only. Behind TLS inspection you also need `[network] ca_bundle`, which has no Settings field and is set in `config.toml`.
pip verifies package downloads against the operating system's trust store, and in this release setting `[conda] ca_bundle` alone may not be sufficient for pip, so also install the corporate root in that trust store: on Linux with `update-ca-certificates` or `update-ca-trust`, and on macOS in the system keychain through your MDM.
```toml theme={null}
[conda]
ca_bundle = "/etc/claude-science/complete-bundle.pem"
```
The same path rules apply as for `[network] ca_bundle`; the [configuration file reference](/docs/claude-science/configuration-file-reference#package-download-keys) lists them.
<Warning>
Do not point `[conda] ca_bundle` at the single-root file you use for `[network] ca_bundle`: the package-download setting replaces the whole trust list, so a file containing only your corporate root breaks every package download on any network your proxy does not inspect, such as a laptop on home Wi-Fi. Build the `[conda]` bundle from your system's public roots plus the corporate root.
</Warning>
### What the certificate settings do not cover
Code that Claude runs inside a session, such as a `pip install` typed into a cell or an R `install.packages()` call, does not see either bundle; behind TLS inspection, have Claude install packages into an environment rather than in a cell.
The local connectors (the bundled research tools) do not work behind TLS inspection in this release: they run in their own Python environment, and nothing delivers your corporate root to that environment, so their connections fail certificate verification. This is a known limitation. Claude Science does detect TLS inspection from your configured CA bundle and relax the connectors' strict certificate-profile check, which stops them from rejecting a corporate root whose Basic Constraints extension is not marked critical, but that relaxation adds no trust. The Anthropic-hosted connectors keep working once `[network] ca_bundle` is set. Connector installs that use `npm` also keep npm's own certificate configuration.
Voice dictation's server-side speech recognition uses a WebSocket connection that is covered by neither the certificate settings nor the proxy settings, so it does not work behind TLS inspection or a mandatory proxy; in the browser, dictation falls back to the browser's own speech recognition.
Certificate environment variables set in a shell, such as `SSL_CERT_FILE`, `CURL_CA_BUNDLE`, or `PIP_CERT`, never reach package downloads, because those run in an isolated environment. Use the `ca_bundle` keys instead.
## Troubleshooting corporate network errors
### Token exchange failed: unable to get local issuer certificate
Sign-in completes in the browser, then fails with this error when Claude Science's own connection to Anthropic hits TLS inspection without trusting your corporate root. The member sees a notice that the network inspects secure connections, with this error beneath it. Set `[network] ca_bundle` to a PEM file containing your corporate root (see [Corporate root for app connections](#corporate-root-for-app-connections)) and confirm the bundle warning is gone from the app log (`claude-science logs` prints it).
### The proxy requires its own sign-in (HTTP 407)
Sign-in fails with this message when the proxy demands credentials the app is not sending, because the proxy address carries none or the proxy was detected from the macOS system settings, which never supply credentials. Include the Basic-authentication credentials in the proxy address (percent-encoding special characters) under **Settings** > **Network** > **Proxy address**, in `[network] proxy`, or in `HTTPS_PROXY`, then restart the app. Only Basic authentication works, so a proxy that requires NTLM, Negotiate, or Kerberos cannot be satisfied this way. During an environment build, a proxy authentication failure surfaces as a generic HTTP 502 error rather than a 407 message.
### Package downloads are being blocked by network policy
An environment build reports this (often with HTTP 502) when it tries to reach the public package hosts on a network that blocks them and no mirror is configured. Configure the mirror under **Settings** > **Network** > **Package mirror**, with both the conda channel mirror and the pip index set.
### HTTP 401 or 403 during an environment build
The mirror requires authentication and the build is not presenting a credential it accepts. Check that a credential is saved under **Settings** > **Network** > **Package mirror** > **Mirror credentials** (or, on a fleet that deploys the `.netrc` file directly, that the file has a block for the exact mirror hostname); a credential in `~/.netrc` in the home directory is ignored for these downloads.
### HTTP 401 on the mirror check
With no saved credential, a `401` is expected because the check sends none; enter the credential under **Mirror credentials** and run the check again. When a credential is saved, the check signs in with it, so a `401` means the token is wrong or expired. On a proxy-configured machine the check and a build can also take different network paths (see [Mirror traffic and your other network controls](#mirror-traffic-and-your-other-network-controls)).
### Green check, then nothing provides the package
The conda mirror URL points at an Artifactory remote repository configured for a single channel, which returns an empty index that the check accepts; see the note in [Point package installs at an internal mirror](#point-package-installs-at-an-internal-mirror) for the mirror URL forms that work.
### CONNECT tunnel failed, response 403, naming an amazonaws.com host
The mirror redirects package files to path-style cloud object storage, which the sandbox blocks. Switch the mirror to serve the files itself or to use bucket-qualified storage URLs, as described in [Mirror traffic and your other network controls](#mirror-traffic-and-your-other-network-controls).
### https mirrors must use port 443 or 8443
The mirror is listening on a port the sandbox cannot tunnel to. Put a 443 or 8443 listener or a reverse proxy in front of it, then save the `https://` URL again.
### Local connectors fail with certificate errors behind inspection
The local research connectors report certificate failures, while the Anthropic-hosted connectors keep working once `[network] ca_bundle` is set, because the corporate root does not reach the local connectors' own Python environment (see [What the certificate settings do not cover](#what-the-certificate-settings-do-not-cover)). This is a known limitation on TLS-inspected networks.
claude-science/custom-connectors First recorded · 15 lines, first recorded
# Custom connectors
The first capture of this source. The page was already there, and this is what it said.
# Custom connectors > Add any Model Context Protocol (MCP) server as a Remote (HTTPS web server) or Local command (program on your computer). In **Settings > Connectors** > **Add connector**, choose Remote or Local command and enter a **Name** (lowercase letters, digits, hyphens). For Remote, enter the server URL; Advanced settings covers transport (**SSE** or **Streamable HTTP**), OAuth client settings, and the **Headers helper command**. For Local command, enter the command; Advanced settings covers arguments and environment variables. **Browse Connectors Directory** opens the public directory. Remote servers that need login take you through the provider's sign-in page. Every tool from a custom connector starts at **Ask each time**. On the connector's page, set individual tools to **Always allow** or **Block** under **Tools**, or turn on Skip approvals for the whole connector. <Warning> Skip approvals disables the per-call card for every tool on that connector. Only use connectors from developers you trust. </Warning> Local-command connectors run inside the sandbox with the same network limits as Claude's code and a per-connector writable directory. Environment variables for local connectors are saved unencrypted in a configuration file readable by your account only; don't put high-value secrets there.
claude-science/enable-claude-science First recorded · 69 lines, first recorded
# Enable Claude Science ## Availability ## Turn on Claude Science ### Reviewing role access ### Setting up connectors for the organization ## Who gets access after you enable ## What members see ## HIPAA organizations ## Turn off Claude Science
The first capture of this source. The page was already there, and this is what it said.
# Enable Claude Science > Claude Science is a desktop app for scientific research. Claude Science is a desktop app for scientific research. It's off by default for Team and Enterprise organizations. Turning it on in Organization settings > Claude Science walks you through a short setup wizard that covers what's not supported yet, which roles get access, and which connectors to publish. ## Availability Claude Science is in beta. | Plan | Claude Science app access | | ----------- | ------------------------------------- | | Team | Off; turn on in Organization settings | | Enterprise | Off; turn on in Organization settings | | Pro and Max | On; no admin action needed | | Free | Not available | If your organization has HIPAA compliance enabled, Claude Science app access is also off by default. You can turn it on, but usage isn't covered under your Business Associate Agreement (BAA) and the app shouldn't be used with protected health information (PHI). ## Turn on Claude Science Go to Organization settings > Claude Science.\ Turn on the Enable for your organization toggle. The setup wizard opens.\ Complete each step of the wizard, then select Enable Claude Science.\ Members with access can [download Claude Science](https://claude.com/product/claude-science) and sign in with their claude.ai account. You need an Owner or Primary Owner role to turn Claude Science on or off. If you have the Admin role, you can add members and assign seats, but you can't turn on Claude Science. Ask an Owner or Primary Owner to turn it on. ### Reviewing role access This step appears only on Enterprise plans. It lists any custom roles that already include the Claude Science capability. Built-in roles get access automatically. To change which custom roles have access, select Configure in role settings, or continue and adjust roles later. ### Setting up connectors for the organization Enable the data sources your team will use in Claude Science. Featured connectors are built by Anthropic and curated for scientific research.\ Local connectors ship with the app and run on each member's computer. Members can turn individual local connectors off in the app.\ Directory connectors are additional life sciences connectors from the Claude connector directory. On Team and Enterprise plans, these appear only after an Owner adds them to the organization's connector allowlist. This step is shown read-only if your organization has HIPAA compliance enabled. Add connectors from Organization settings > Connectors after enabling. By continuing, you authorize your team to let Claude use the optional enabled resources on their behalf. These resources and content they reach may be subject to third-party terms (viewable in Settings), and your users are solely responsible for compliance. ## Who gets access after you enable Turning on the organization toggle controls whether Claude Science is accessible to your organization at all. Adding members or assigning seats doesn't turn it on. Once it's on, roles control which members can use it: Built-in roles include the Claude Science entitlement, so those members can download and sign in immediately.\ Custom roles (Enterprise plans only) need the Claude Science capability added. Members on a custom role without the capability see the app as unavailable even after you enable it for the organization.\ A custom role whose Capability access setting is All capabilities already includes Claude Science. The All generally available setting excludes beta capabilities such as Claude Science, so for those roles also select the Claude Science capability. This is the same pattern as other Claude apps you enable per organization. ## What members see Once Claude Science is enabled and a member's role includes the entitlement, they can download the app from claude.com/product/claude-science and sign in with their claude.ai account. If the organization toggle is off, claude.ai stops members at sign-in with a message such as "Claude Science has not been enabled for your account. Contact your organization administrator." On Enterprise plans, members whose custom role doesn't include the capability are stopped the same way. Members who belong to more than one organization on claude.ai, such as a personal account alongside yours, need to choose your organization when claude.ai asks which one to connect. Before they select Authorize, they can also select Switch organization on the authorization screen to change that choice. A member who connects a Free personal account instead sees "Claude Science requires a Pro or Max subscription." and can select Switch account to sign in again and choose your organization. ## HIPAA organizations Organizations with HIPAA compliance enabled can turn on Claude Science during the beta, but usage isn't covered under your BAA. The setup wizard shows this notice on step 1, and the connectors step is read-only because the wizard's quick-enable path doesn't include the per-connector HIPAA attestation. Add connectors from Organization settings > Connectors instead, where the attestation is required. ## Turn off Claude Science Go to Organization settings > Claude Science and turn off the Enable for your organization toggle. Members can no longer sign in to the app. Data already on members' computers stays there; see [How Claude Science works with your data](/docs/claude-science/how-claude-science-works-with-your-data) for details.
claude-science/get-started First recorded · 58 lines, first recorded
# Get started ## Install ## Sign in and complete setup ## Run your first analysis ## Troubleshooting first launch
The first capture of this source. The page was already there, and this is what it said.
# Get started
> Install Claude Science on macOS or Linux, sign in with your Claude account, and run your first analysis.
## Install
macOS: Download the installer from claude.com/product/claude-science and double-click to install. On first launch, the app sets up its runtime and starter Python and R environments, which takes a few minutes, then opens a new tab in your default browser. If no browser tab appears, choose Open from the menu bar icon.
<Note>
Although Claude Science opens in a browser tab, it's a local application, not a website: there's no public URL to visit. Open it from the application itself, with the menu bar icon on macOS or the `claude-science` command on Linux. On a remote server, the sign-in link reaches your browser through an SSH tunnel; see [Run on a remote Linux server](/docs/claude-science/run-on-remote-linux-server).
</Note>
Linux: install the sandbox dependencies, then run the installer. The sandbox needs bubblewrap 0.8.0 or later and socat, and installing them takes administrator (`sudo`) access; if you don't have it, ask your system administrator to install them.
* Ubuntu or Debian: `sudo apt-get update && sudo apt-get install -y curl bubblewrap socat`
* Fedora or RHEL: `sudo dnf install -y curl bubblewrap socat`
* Arch: `sudo pacman -S curl bubblewrap socat`
Ubuntu 24.04's repositories carry a new enough bubblewrap and Ubuntu 22.04's don't; on any distribution, confirm with `bwrap --version` that the installed version is 0.8.0 or later before you start Claude Science.
```bash theme={null}
curl -fsSL https://claude.ai/install-claude-science.sh | bash
```
```bash theme={null}
claude-science serve
```
First launch prints a local URL right away, then continues setting up its starter Python and R environments. To run Claude Science on a remote server and use it from your computer, see [Run on a remote Linux server](/docs/claude-science/run-on-remote-linux-server).
## Sign in and complete setup
When the app opens in your browser, sign in with your Claude account. If the OAuth redirect can't return to the app (for example, through an SSH tunnel), use the Paste a code option on the sign-in screen instead. No API key is required.
After sign-in, a setup wizard walks you through enabling connectors and skills and setting which websites Claude can access. You can change these at any time in Settings.
<Note>
Claude Science keeps all of its data in a single folder (`~/.claude-science`) in your home directory; on Linux, the `claude-science` command itself installs to `~/.local/bin`. It doesn't modify your existing conda installation, R libraries, or shell configuration.
</Note>
<Warning>
Deleting that folder removes all projects, artifacts, and conversation history. Deleting the folder and the application removes Claude Science entirely.
</Warning>
## Run your first analysis
* Open the Example project, or create a new one.
* Start a conversation. Reference a folder on your computer by typing its path or using the @ picker in the composer.
* Review the folder-access card when it appears and choose whether to allow it.
* Review the code-execution card when Claude proposes running code and choose whether to allow it.
* Results appear as artifacts in the Files panel.
## Troubleshooting first launch
* macOS says the application isn't supported, or the app icon appears crossed out: the download page picked the build for the wrong processor. Return to the download page and choose Mac (Intel) or Mac (Apple Silicon) to match your Mac. To check which you have, open the Apple menu, choose About This Mac, and look at the Chip or Processor line.
* No browser tab appeared: on macOS, choose Open from the menu bar icon. On Linux, copy the printed URL into a browser on the same machine, or run `claude-science url` to print a fresh one.
* Linux refuses to start: a sandbox dependency is missing (install bubblewrap and socat as shown in the Install section), too old, or blocked. Check your bubblewrap version with `bwrap --version`, then match the error message to its fix in the [Linux troubleshooting table](/docs/claude-science/run-on-remote-linux-server#troubleshooting).
* Sign-in stops at claude.ai: your account is on the Free plan (upgrade required), the redirect couldn't return (use Paste a code), or your Team or Enterprise organization hasn't [enabled Claude Science](/docs/claude-science/enable-claude-science) yet.
claude-science/glossary First recorded · 51 lines, first recorded
# Glossary
The first capture of this source. The page was already there, and this is what it said.
# Glossary > One-sentence definitions for the terms you meet in Claude Science, from annotation to workspace. One-sentence definitions for the terms you meet in Claude Science, from annotation to workspace. **[Annotation](/docs/claude-science/annotations)**: a comment you pin to part of an artifact by selecting it; Claude reads pending annotations as instructions on its next turn. **[Artifact](/docs/claude-science/artifacts)**: any file Claude makes and saves for you, listed in its session's Files view. **Cell**: one block of code Claude runs in a kernel; the cell, its output, and the environment it ran in are recorded in the session's Notebook. **Cloud provider**: your own account at a cloud service where Claude can start jobs; you pay that provider directly. **Connector**: an outside data source or tool wired into Claude over MCP; Claude Science includes a featured set, you can access partner connectors from the Connectors Directory, and you can add your own under Settings > Connectors. **Data directory**: the `~/.claude-science` folder on your computer holding the database, artifacts, session workspaces, and logs. **[Environment](/docs/claude-science/tools-and-environments)**: a named set of installed packages (conda) that a kernel runs in, reused across sessions. **Execution log**: the slice of a session's Notebook cells that produced a given artifact version, shown as a tab in its Provenance pane. **Kernel**: the live Python or R process that runs a session's cells and keeps variables in memory between them. **Memory**: notes Claude keeps about you and your projects across sessions, which you can review and edit. **Model endpoint**: a scientific domain-specific model server you register under Settings > Compute, that runs locally or connects to a vendor's hosted solution, that Claude sends single prediction requests to. **Network allowlist**: the list under Settings of every outside host that sandboxed code may reach. **Permission card**: the card that replaces the message box when Claude needs your permission for running code, running a job, accessing a network host, a folder, a connector tool, or re-configuring Claude Science; you allow or deny it. **Provenance (the artifact record)**: the panel behind every artifact version showing the code, cells, conversation, environment, and findings that produced it. **[Reviewer](/docs/claude-science/the-reviewer)**: the independent agent that re-examines Claude's claims and artifacts at checkpoints, recording each issue it raises as a finding on the artifact's Review tab; on some plans it runs in the background automatically. **Sandbox**: the isolated environment all of Claude's code runs in; reaching outside it needs your approval. **Scope**: how long an approval lasts (Once, This conversation, This project, or Global), with every standing grant listed and revocable under Settings > Permissions. **Session**: one conversation thread inside a project, with its own kernel and workspace. **Skill**: an installable package of instructions and helper code that teaches Claude a method or tool. **Specialist**: a named set of skills, connectors, and instructions that a session answers as. **SSH host**: a remote machine (server, cluster node, or a job submission host) added by its SSH name, that Claude can run jobs on, or dispatch jobs from. **Version**: one immutable save of an artifact; saving again adds a new version on top instead of overwriting. **Workspace**: the per-session folder on disk where Claude's code reads and writes files before they are saved as artifacts.
claude-science/how-claude-science-works-with-your-data First recorded · 21 lines, first recorded
# How Claude Science works with your data ## What Anthropic receives ## Remote compute ## Connectors ## What this means for you as an admin
The first capture of this source. The page was already there, and this is what it said.
# How Claude Science works with your data > Claude Science is a local-first application. Claude Science is a local-first application. Conversation history and artifacts are stored only on the member's device. Anthropic doesn't host a session store for the app and has nothing to browse, sync, or export. Prompts and completions sent to the model are processed by Anthropic and handled under Anthropic's standard retention and Trust & Safety policies. The following sections cover what Anthropic does receive. ## What Anthropic receives Each time the app calls Claude, the prompt and Claude's response travel to Anthropic's servers and are logged under Anthropic's standard retention policy for model traffic (see How long do you store my organization's data in the Privacy Center), the same policy that applies to other Claude products. If your organization has CMEK enabled, model-call logging follows the same CMEK handling as your other Claude products. Your organization's Custom Data Retention setting doesn't change that retention period; that setting governs conversation, project, and artifact data stored on Anthropic's servers, which this product doesn't create. The app also sends product-usage telemetry (event counts and timings, not conversation content), which can be turned off through device configuration. ## Remote compute When a member chooses to connect the app to remote compute (an owned server or cloud account they control), the app sends code and data directly to that destination. That traffic doesn't pass through Anthropic. Admins can't yet restrict whether members can connect to remote compute. For setup details, see [Remote compute clusters](/docs/claude-science/remote-compute-clusters) and [Compute providers](/docs/claude-science/compute-providers) in the user documentation. ## Connectors Directory connectors you publish as an admin are reached through Anthropic's hosted connector service, so your directory connector permissions and tunnels apply. Connectors a member adds locally (either running on their own computer or pointing at a custom URL) talk to their app directly, without routing through Anthropic. ## What this means for you as an admin Because conversations and artifacts live on members' computers, the Anthropic-side data controls (Custom Data Retention, Org Data Export, and the Compliance API) don't reach them. Device management is the control you have for that data: your device management software (such as your MDM or EDR) governs the app's local folder the same way it governs any other local application data. Identity controls (SSO, SCIM, roles) apply because sign-in goes through claude.ai; see [Admin controls](/docs/claude-science/admin-controls) for what IP allowlisting and session duration cover.
claude-science/legal-and-compliance First recorded · 36 lines, first recorded
# Legal and compliance ## Legal agreements ### License ## Usage policy ### Acceptable use ### Authentication and credential use ## Security and trust ### Trust and safety ### Security vulnerability reporting
The first capture of this source. The page was already there, and this is what it said.
# Legal and compliance > Legal agreements, compliance certifications, and security information for Claude Science. Legal agreements, compliance certifications, and security information for Claude Science. ## Legal agreements ### License Your use of Claude Science is subject to:\ [Commercial Terms](https://www.anthropic.com/legal/commercial-terms) - for Team and Enterprise users\ [Consumer Terms of Service](https://www.anthropic.com/legal/consumer-terms) - for Pro and Max users ## Usage policy ### Acceptable use Claude Science usage is subject to the [Anthropic Usage Policy](https://www.anthropic.com/legal/aup). Advertised usage limits for Pro and Max plans assume ordinary, individual usage of Claude Science. ### Authentication and credential use Claude Science authenticates with Anthropic's servers using OAuth tokens. OAuth authentication is intended exclusively for purchasers of Claude Pro, Max, Team, and Enterprise subscription plans and is designed to support ordinary use of Claude Science and other native Anthropic applications. More information about how users can authenticate with OAuth tokens can be found in [Logging in to your Claude account](https://support.claude.com/en/articles/13189465-logging-in-to-your-claude-account).\ Anthropic reserves the right to take measures to enforce these restrictions and may do so without prior notice.\ For questions about permitted authentication methods for your use case, please [contact sales](https://www.anthropic.com/contact-sales?utm_source=claude_science\&utm_medium=docs\&utm_content=legal_compliance_contact_sales). ## Security and trust ### Trust and safety You can find more information in the [Anthropic Trust Center](https://trust.anthropic.com) and [Transparency Hub](https://www.anthropic.com/transparency). ### Security vulnerability reporting Anthropic manages its security program through HackerOne. [Use this form to report vulnerabilities](https://hackerone.com/4f1f16ba-10d3-4d09-9ecc-c721aad90f24/embedded_submissions/new).\ © Anthropic PBC. All rights reserved. Use is subject to applicable Anthropic Terms of Service.
claude-science/literature-access First recorded · 30 lines, first recorded
# Literature access ## Available credentials
The first capture of this source. The page was already there, and this is what it said.
# Literature access > Claude retrieves open-access full text without credentials; add publisher keys or a library proxy to reach paywalled text you're entitled to. Claude retrieves open-access full text without credentials. To reach paywalled text you're entitled to, add publisher keys or your library's proxy in the Claude Science app: select the gear icon and choose **Settings**, then select **Credentials**, then choose **Literature access (journals, etc.)** in the **Services** list. No key bypasses a paywall. <Note> These panels live in the Claude Science app's own **Settings**, separate from your claude.ai account and organization settings. If you've added custom credentials, the **Services** list appears below your **Custom** credentials. </Note> Given a DOI or title, Claude tries in order: an open-access copy (Unpaywall, Semantic Scholar, PubMed Central), CrossRef full-text links, publisher routes you hold keys for, your library proxy, then the publisher page. Retrieved files (PDF, XML, or text) are saved into the session. ## Available credentials Each credential in the **Literature access (journals, etc.)** form is optional and independent. | Credential | Effect | | ---------------------------------------------- | ------------------------------------------------------------- | | **Elsevier API key** + institutional token | Enables the Elsevier route (subscription still required) | | **Springer Nature API key** | Enables the Springer Nature route | | **Semantic Scholar API key** | Speeds the Semantic Scholar step | | **NCBI API key** | Raises the PubMed rate limit from 3 to 10 requests per second | | **CORE API key** | Gives skills access to the CORE open-access aggregator | | Institutional **EZproxy URL** + session cookie | Retries publisher links through your library | OpenAlex has its own entry in the same **Services** list: add a free **OpenAlex API key** there (create one on the [OpenAlex API settings page](https://openalex.org/settings/api)). OpenAlex requires a key on every request, so OpenAlex-backed literature search needs one configured. NCBI, EBI, and OurResearch (Unpaywall) ask callers to provide a contact email. The first time this applies, a **Share a contact email with research data services?** card appears. Sharing an email enables the Unpaywall step. You can also set this in the app's **Settings**, on the **General** tab, under **Contact email**. Claude paces requests to each provider at one per second, backs off when asked, and identifies itself in every request. Paywalled HTML isn't scraped.
claude-science/manage-on-devices First recorded · 46 lines, first recorded
# Manage Claude Science on devices ## Where the app stores data ## Deploy configuration with device management ## Telemetry ## Endpoint detection and response ## Required updates
The first capture of this source. The page was already there, and this is what it said.
# Manage Claude Science on devices > Claude Science is a desktop application that stores all member content locally. Claude Science is a desktop application that stores all member content locally. This page covers what IT and endpoint teams need to know: where the app writes data, how to deploy configuration with device management, what telemetry is sent, and what members see when Anthropic requires an update. ## Where the app stores data The app writes to two locations on each member's computer: Configuration: \~/.claude-science/config.toml holds all app settings. Every key is optional; the app starts with no file present. This is the file to deploy through device management.\ Data: the app's data directory holds conversations, generated artifacts, delegation configurations, and workspace files in a per-organization subfolder (orgs/`<organization-id>`/), stored as a local database plus files. Authentication tokens and the shared package environment live under \~/.claude-science/ regardless of the data directory, so endpoint backup or wipe policies that target the data directory don't affect sign-in state. Your endpoint tooling governs these folders the same way it governs any other local application data. There's no Anthropic-hosted copy, so Custom Data Retention, Org Data Export, and the Compliance API don't reach them. ## Deploy configuration with device management To set configuration keys organization-wide, deploy \~/.claude-science/config.toml through your MDM or endpoint tool. Claude Science doesn't read a system-level managed-preferences file, so there's no native MDM configuration channel. Deploying the per-member config.toml is the supported approach. The keys most relevant to admins are: | Key | Effect | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | disable\_telemetry = true | Stops the app from sending product-usage telemetry to Anthropic. | | data\_dir = "`<path>`" | Moves conversations, artifacts, and workspaces to a managed location (for example, a volume your backup tooling covers). | | \[update] auto\_update = false | Prevents the app from updating itself; pair with your own distribution channel. | | \[sandbox.network] enabled = false | Blocks network access from the app's local code-execution sandbox. The similarly named \[sandbox] network\_isolated key does not control this. | The [configuration file reference](/docs/claude-science/configuration-file-reference) documents the network-related keys and their defaults, and [Use Claude Science on a corporate network](/docs/claude-science/corporate-networks) covers the proxy, TLS-inspection, and mirror settings. ## Telemetry The app sends product-usage telemetry (event counts and timings, not conversation content) to Anthropic. There's no in-app setting for this; consent is covered by your organization's acceptance of Anthropic's commercial terms. To turn telemetry off on managed devices, use either of: Set disable\_telemetry = true in \~/.claude-science/config.toml (deployable through MDM).\ Set the DO\_NOT\_TRACK environment variable on the device. Both are device-level settings. There's no per-member or per-organization telemetry toggle in Organization settings. ## Endpoint detection and response Claude Science runs analysis code inside a local sandbox on the member's computer. On macOS, sandboxed analysis processes run as ordinary child processes and are visible to host-level EDR tools. On Linux, they run inside a separate PID namespace with an isolated process view, so host-level EDR won't see them as ordinary children of the app. ## Required updates Anthropic may set a minimum supported version of the app. When a member's installed version falls below that floor, the app shows a full-page notice that the installed version is no longer supported and blocks further use until the member updates. Admins don't configure this floor; it's set by Anthropic. If your organization distributes the app through its own channel with auto-update disabled, plan to push updates promptly when Anthropic raises the floor.
claude-science/monitor-usage First recorded · 27 lines, first recorded
# Monitor Claude Science usage ## Analytics ## Admin API
The first capture of this source. The page was already there, and this is what it said.
# Monitor Claude Science usage > Claude Science usage counts against each member's standard weekly quota and uses the same seat as the rest of claude.ai. Claude Science usage counts against each member's standard weekly quota and uses the same seat as the rest of claude.ai. You can track adoption in Analytics and through the Admin API. ## Analytics Open Analytics from the user menu and select the Claude Science tab to see adoption and session metrics for this product. To see spend, or to compare active members across products, select Claude Science in the product filter on the Overview tab. The Monitor usage link in Organization settings > Claude Science opens Analytics. ## Admin API The Claude Enterprise Admin API (Enterprise plans only) returns Claude Science usage alongside your other products. Per-member metrics (GET /v1/organizations/analytics/users, science\_metrics object): | Field | Description | | --------------------------- | ------------------------------------------------------------------------------------------------------------- | | distinct\_session\_count | Number of distinct Claude Science sessions. Null on aggregated rows where a distinct count can't be computed. | | message\_count | Number of messages sent in Claude Science sessions. | | delegation\_count | Number of delegations (handoffs to a specialized agent) in Claude Science sessions. | | remote\_compute\_job\_count | Number of remote compute jobs launched from Claude Science sessions. | | skills\_used\_count | Total number of skill invocations in Claude Science sessions. | See the Admin API reference for authentication and the full schema.
claude-science/network-requirements First recorded · 103 lines, first recorded
# Network requirements ## App connections ### Full-text and literature retrieval ## Analysis sandbox domains ### Package management domains ### Research database domains ### Optional compute integrations ### Domains the sandbox always blocks ## Domains the member's browser loads ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Network requirements > The domains Claude Science connects to, grouped for a proxy or firewall allowlist: the app's connections to Anthropic, the analysis sandbox's package and research domains, the domains a package mirror adds and removes, and the built-in list of domains it always blocks. Claude Science connects to a small, fixed set of domains for sign-in, the Claude API, and the app's own literature search, and to a larger, member-adjustable set of package and research domains when Claude runs analysis code. This page lists them for the team that manages your proxy or firewall allowlist. Connections are outbound-only and almost entirely HTTPS on TCP 443 (an internal package mirror may use 8443). The app's own domains are fixed, apart from open-access full-text downloads (covered below); the analysis-sandbox domains are a built-in allowlist whose groups members can adjust during onboarding or under **Settings** > **Network**. The domains fall into three groups: the app's own connections every member needs, the analysis sandbox's package and research domains, and the domains the member's browser loads. For the proxy and TLS-inspection settings, see [Use Claude Science on a corporate network](/docs/claude-science/corporate-networks). ## App connections Every Claude Science install makes these connections, which travel through the member's outbound proxy and TLS inspection, so they need the proxy and corporate-certificate settings from the corporate networks page. All are outbound HTTPS on TCP 443. | Domain | Required when | Purpose | | --------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | `claude.ai` | Always | Browser-based sign-in, usage analytics, feature configuration, and the catalog of available connectors | | `platform.claude.com` | Always | Completing sign-in (the OAuth token exchange) | | `api.anthropic.com` | Always | The Claude API for every request Claude makes, plus account and usage information | | `*.mcp.claude.com` | When members use the Anthropic-hosted connectors | PubMed, ClinicalTrials.gov, ChEMBL, and bioRxiv connectors | | `storage.googleapis.com` | When automatic updates are on | Update manifests and installers | | `api.github.com`, `codeload.github.com` | When members import skills from a GitHub repository | Fetching the skill repository's contents | Custom connectors and remote compute that members add reach whatever hosts they are configured with, so allow those case by case. Claude Science's crash-reporting channel is off and sends no traffic in this release, so it needs no allowlist entry. ### Full-text and literature retrieval When Claude searches the scientific literature or retrieves full text, the app itself contacts these hosts over its own connections, which pass through your outbound proxy and TLS inspection like the app connections above, so the proxy must allow them even though several are also on the sandbox allowlist. Full-text downloads come from wherever the open-access copy of an article is hosted, so on a network that allows only listed hosts, expect retrieval of some full-text copies to fail; the domains below keep literature search and PubMed retrieval working. | Domain | Required when | Purpose | | ------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------- | | `api.unpaywall.org` | When Claude retrieves full text | Locating open-access copies of articles | | `doi.org` | When Claude resolves a DOI | DOI resolution | | `eutils.ncbi.nlm.nih.gov`, `www.ncbi.nlm.nih.gov` | When Claude searches PubMed | PubMed/PMC article records and full-text files | | `api.semanticscholar.org`, `api.crossref.org` | When Claude searches the literature | Scholarly search and citation metadata | | `api.openalex.org` | When a member adds an OpenAlex API key | Validating the stored key | | `api.elsevier.com`, `api.springernature.com` | Only when the member has stored those publishers' API keys | Publisher full-text APIs | ## Analysis sandbox domains When Claude runs code, its network access passes through a local filtering proxy that allows only the domains on the sandbox's built-in allowlist, grouped by purpose below. These are member-level controls with no organization-level setting: members can turn off any group except package management, during onboarding or under **Settings** > **Network**, and add allowed domains of their own in Settings. An administrator can instead use the per-device configuration file, whose `[sandbox.network]` keys add allowed or denied domains, or disable sandbox networking entirely. ### Package management domains These domains are always on the sandbox allowlist and supply Python, R, and system packages when Claude builds an analysis environment. | Domain | Purpose | | ----------------------------------------------------------------------------------------- | ----------------------------------------------- | | `pypi.org`, `*.pypi.org`, `files.pythonhosted.org` | Python packages from PyPI | | `conda.anaconda.org`, `repo.anaconda.com`, `anaconda.org`, `*.anaconda.org`, `*.conda.io` | conda packages | | `cran.r-project.org`, `cloud.r-project.org`, `bioconductor.org`, `www.bioconductor.org` | R packages from CRAN and Bioconductor | | `registry.npmjs.org` | npm packages for connectors that need them | | `github.com`, `*.github.com`, `*.githubusercontent.com` | Tools and packages published as GitHub releases | Claude Science itself does not require GitHub; the package manager ships inside the app. The GitHub domains are used only when a package Claude installs is published as a GitHub release or a member imports a skill from a GitHub repository, and blocking them fails only those operations. When you configure a conda channel mirror, Claude Science removes only the conda hosts (`conda.anaconda.org`, `repo.anaconda.com`, `anaconda.org`, `*.anaconda.org`) from the allowlist, and a Python index mirror removes only `pypi.org`, `*.pypi.org`, and `files.pythonhosted.org`. The `*.conda.io`, CRAN and Bioconductor, npm, and GitHub rows stay. A removed host is reachable again if a member re-adds it under **Settings** > **Network** or an administrator lists it in `[sandbox.network] allowed_domains`, which takes precedence over the removal. Environment builds contact the mirror host directly from the workstation, not through the outbound proxy, so it must be reachable directly (over your VPN or internal network if the mirror is internal, HTTPS on TCP 443 or 8443). A proxy allowlist entry alone does not make the mirror reachable for builds, and build-time mirror traffic will not appear in your proxy logs. See [Point package installs at an internal mirror](/docs/claude-science/corporate-networks#point-package-installs-at-an-internal-mirror). ### Research database domains These groups are on by default and can be turned off during onboarding or anytime under **Settings** > **Network**. | Group | Domains | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NCBI and NIH | `*.ncbi.nlm.nih.gov`, `*.nih.gov`, `cactus.nci.nih.gov` | | Genomics and biology | `rest.ensembl.org`, `grch37.rest.ensembl.org`, `*.ensembl.org`, `reactome.org`, `*.reactome.org`, `rest.kegg.jp`, `*.kegg.jp`, `cellguide.cellxgene.cziscience.com`, `gnomad.broadinstitute.org`, `gtexportal.org`, `jaspar.elixir.no`, `www.encodeproject.org`, `mygene.info`, `rfam.org`, `www.cbioportal.org`, `sparql.rhea-db.org`, `bindingdb.org`, `www.bindingdb.org`, `r12.finngen.fi`, `pheweb.jp`, `api.genome.ucsc.edu`, `unibind.uio.no` | | Proteomics | `rest.uniprot.org`, `*.uniprot.org`, `string-db.org`, `*.string-db.org`, `*.ebi.ac.uk`, `search.foldseek.com`, `rcsb.org`, `*.rcsb.org`, `*.proteinatlas.org` | | Literature and citations | `api.semanticscholar.org`, `api.biorxiv.org`, `www.biorxiv.org`, `api.crossref.org`, `doi.org`, `api.openalex.org`, `arxiv.org`, `*.arxiv.org` | | Clinical and pharma | `api.fda.gov`, `clinicaltrials.gov`, `*.clinicaltrials.gov`, `api.clinpgx.org`, `api.platform.opentargets.org`, `cancer.sanger.ac.uk`, `actionability.clinicalgenome.org`, `search.clinicalgenome.org`, `erepo.genome.network`, `civicdb.org`, `api.grants.gov`, `www.antibodyregistry.org`, `cartblanche22.docking.org`, `files.docking.org` | ### Optional compute integrations These domains matter only when a member turns on the matching integration. | Domain | Required when | Purpose | | --------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `health.api.nvidia.com` | When members enable NVIDIA-hosted BioNeMo inference | NVIDIA's hosted inference endpoint; a member can enter a different endpoint host when connecting BioNeMo under **Settings** > **Compute** | | `nvcr.io` | When members run NVIDIA NIM containers locally | Pulling NVIDIA container images | | `api.modal.com`, `*.w.modal.host` | When members connect a Modal account for remote compute | Modal's API and its dynamic worker hosts, reached from the member's machine | ### Domains the sandbox always blocks The sandbox blocks a built-in list of common destinations for moving data out of an organization (anonymous file-upload and paste services, chat and webhook endpoints that accept posted data without an account, reverse-tunnel services, and path-style cloud object storage addresses), and neither members nor configuration can remove entries from it. The blocklist is enforced only inside the analysis sandbox, so it does not affect the app's own connections, such as the update check to `storage.googleapis.com` listed under App connections above. For the path-style object-storage entries (`s3.amazonaws.com`, `s3.<region>.amazonaws.com`, `storage.googleapis.com`, `commondatastorage.googleapis.com`, and `r2.cloudflarestorage.com`), a bucket named in the URL path is blocked, while a bucket named in the hostname (for example `<bucket>.s3.us-west-2.amazonaws.com` or `<bucket>.storage.googleapis.com`) can be added to the allowlist under **Settings** > **Network**. If your package mirror or a cloud workflow stores data in object storage, address the bucket by hostname. ## Domains the member's browser loads Sign-in pages and interactive previews load in the member's web browser, so they are governed by your web-filtering policy rather than the outbound proxy or the sandbox allowlist. If your policy blocks these domains, sign-in pages fail to load or interactive previews render blank or broken. | Domain | Purpose | | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `claude.ai` | The sign-in authorization page | | `console.anthropic.com` | The sign-in fallback page, which shows a one-time code the member pastes into the app when the browser cannot return to the app's local callback address | | `cdn.jsdelivr.net`, `esm.sh`, `unpkg.com`, `cdnjs.cloudflare.com` | JavaScript display libraries for interactive previews | | `3dmol.org`, `3dmol.csb.pitt.edu` | Molecular structure viewer | | `*.claudemcpcontent.com` | Isolated frames that display Claude's HTML previews and interactive connector output. A standard desktop install serves these frames from the app's own local address, so this entry matters mainly where members open Claude Science from a non-local address | ## Related resources * [Use Claude Science on a corporate network](/docs/claude-science/corporate-networks): proxy, TLS-inspection, and package-mirror settings * [Configuration file reference](/docs/claude-science/configuration-file-reference): the network keys in the configuration file * [Manage Claude Science on devices](/docs/claude-science/manage-on-devices): deploying the configuration file with device management
claude-science/overview First recorded · 20 lines, first recorded
# Claude Science ## Requirements
The first capture of this source. The page was already there, and this is what it said.
# Claude Science > Anthropic's AI workbench for rigorous science. Claude Science is a desktop application that pairs Claude with an analysis environment on your computer. Available in beta on macOS and Linux. You describe a research task or analysis in plain language; Claude writes and runs Python, R, or shell code in a sandbox, reads the folders you grant it, pulls data from scientific databases through connectors, and saves results as versioned artifacts with a full provenance record. A background reviewer can check Claude's claims against the work that was actually run. Your files stay on your computer, and code runs in a sandbox. You approve each new folder, network host, and remote job before Claude can use it. <Note> Claude can make mistakes. The reviewer reduces, but doesn't eliminate, errors. It checks claims against the execution record and doesn't re-run analyses. Verify results before relying on them in research, publication, or downstream decisions. Claude Science is a research tool and isn't intended for clinical or diagnostic use. </Note> ## Requirements * A Claude account on a Pro, Max, Team, or Enterprise plan. On Team and Enterprise plans, an Owner must [enable Claude Science for the organization](/docs/claude-science/enable-claude-science) first. * macOS 13 or later (Apple silicon or Intel), or Linux x64 on a glibc-based distribution. * About 5 GB of free disk space for the runtime and starter environments. * On Linux: socat, bubblewrap 0.8.0 or later, and unprivileged user namespaces permitted by the kernel.
claude-science/remote-compute-clusters First recorded · 33 lines, first recorded
# Remote compute clusters ## Adding a host ## Running jobs ## Host details
The first capture of this source. The page was already there, and this is what it said.
# Remote compute clusters > Connect a machine you can reach over SSH (a lab workstation or an HPC login node) so Claude can run jobs on it. Connect a machine you can reach over SSH (a lab workstation or an HPC login node) so Claude can run jobs on it. Use it to connect to a remote workstation with a GPU, or your existing HPC cluster. Claude Science uses your existing `~/.ssh/config`, authenticates with your key or `ssh-agent`, and installs nothing on the host itself. ## Adding a host Go to **Settings > Compute** > **SSH hosts** > **Add SSH host**.\ Choose or type an alias from your `~/.ssh/config`. The address, user, port, and any `ProxyJump` come from that file.\ Optionally add notes about the host (partition, account code, module loads, whether software can be installed). Claude reads these before the first job.\ Optionally override **User**, **Port**, or **Identity file** under **Advanced**.\ Click **Add**. Adding a host runs a read-only probe that records CPUs, memory, GPUs, CUDA driver, presence of conda/modules/Apptainer, scratch directories, and whether `sbatch` exists. On SLURM clusters it reads partitions. Results are saved as editable notes on the host's detail page; re-run with **Probe**. ## Running jobs Workstations run jobs as detached processes. SLURM clusters receive jobs via `sbatch`. Jobs survive connection loss. On the host's detail page, set **Scratch directory** (must be on a shared filesystem for SLURM) and **Concurrent job limit** (default 100). When Claude proposes a remote job, a **Run this job on `<host>`?** card shows the command and script. Approve with **Once**, **This conversation**, **This project**, or **Global** scope. On approval, the job script and inputs are copied to a job directory under the scratch directory. <Warning> Remote jobs run outside the sandbox, as your user on the host, with access to everything your account can read and write there. </Warning> Default job timeout is 30 minutes; tell Claude before submitting longer work. When a job finishes, outputs are pulled back into the session. Files over the size threshold (about 100 MB by default) stay on the host, and Claude records their paths. ## Host details Claude reads host-specific instructions from the Details document on the host's detail page. It holds notes that describe the host's setup and how to run jobs on it: how environments are activated, where data and packages live, and the cluster's scheduling conventions. Claude updates these as it works with the host, and you can edit them at any time.
claude-science/run-on-remote-linux-server First recorded · 83 lines, first recorded
# Run on a remote Linux server ## Install dependencies ## Install Claude Science ## Forward the ports from your computer ## Start Claude Science ## Sign in ## Keep it up to date ## Troubleshooting
The first capture of this source. The page was already there, and this is what it said.
# Run on a remote Linux server
> Install Claude Science on a cloud VM or lab server and use it from your own browser through an SSH tunnel.
Claude Science runs on a remote Linux server (a cloud VM or a lab machine) the same way it runs on a workstation: the application and your data stay on the server, and you use the web app from your computer's browser through an SSH tunnel. Setup takes about five minutes, plus a few minutes of environment setup on first launch.
<Note>
This page covers running all of Claude Science on a remote machine. To keep Claude Science on your own computer and have it run jobs on a machine you reach over SSH, see [Remote compute clusters](/docs/claude-science/remote-compute-clusters).
</Note>
The server needs x64 Linux on a glibc-based distribution (arm64 and musl-based distributions such as Alpine aren't supported), about 5 GB of free disk space, and the system packages below. Your Claude account needs a Pro, Max, Team, or Enterprise plan; see [Requirements](/docs/claude-science/overview#requirements).
## Install dependencies
Claude runs code inside a sandbox, and the sandbox needs two system packages: bubblewrap and socat. On Ubuntu or Debian:
```bash theme={null}
sudo apt-get update && sudo apt-get install -y curl bubblewrap socat
```
<Note>
The sandbox requires bubblewrap 0.8.0 or later; check with `bwrap --version`. Ubuntu 24.04 ships a new enough version, and Ubuntu 22.04 doesn't. The sandbox isn't optional: Claude Science refuses to start rather than run code unsandboxed.
</Note>
## Install Claude Science
```bash theme={null}
curl -fsSL https://claude.ai/install-claude-science.sh | bash
```
The installer downloads the current release, verifies its checksum, and installs the `claude-science` command in `~/.local/bin`. If it prints a PATH line at the end, add that line to your shell profile. Then confirm the command works:
```bash theme={null}
. ~/.profile
claude-science --version
```
## Forward the ports from your computer
Set up the tunnel before you start Claude Science: the sign-in link it prints is only valid for about three minutes.
By default, the web app listens only on the server's localhost, so it isn't exposed to the network. An SSH tunnel makes it reachable from your computer. Claude Science uses two ports: one for the web app (8000) and a separate one for previews of generated HTML, served from its own origin so a previewed page can't read your session. The preview port is always the web app port plus one, so 8001 by default. Forward both. In a terminal on your computer:
```bash theme={null}
ssh -L 8000:localhost:8000 -L 8001:localhost:8001 [email protected]
```
Leave that terminal open; the tunnel lasts as long as the SSH connection. If you work on the server through VS Code's Remote-SSH extension, it forwards ports automatically as the app uses them; check its Ports panel to confirm both ports are forwarded.
## Start Claude Science
On the server:
```bash theme={null}
claude-science serve --no-browser
```
First launch prints the sign-in link, of the form `http://localhost:8000/?nonce=...`, right away, and continues setting up its starter Python and R environments; the setup can take a few minutes and about 5 GB of disk. If port 8000 or 8001 is taken on either machine, pass a different port to serve (for example `--port 8765`; previews then use the next port up, 8766) and change the `ssh -L` forwards to match.
To run it in the background instead, use `claude-science serve --no-browser --detached`. `claude-science status` reports whether it's running, and `claude-science stop` stops it.
## Sign in
Open the printed link in your computer's browser. The link is single-use and expires about three minutes after it's printed; run `claude-science url` on the server to print a fresh one at any time. Restarting with `claude-science stop` then `claude-science serve --no-browser` also prints a fresh link.
Sign in with your Claude account. If the sign-in redirect can't find its way back through the tunnel, choose **Paste a code** on the sign-in screen. Then complete the setup wizard as described in [Get started](/docs/claude-science/get-started).
## Keep it up to date
`claude-science update` checks for and installs updates. See [Command line settings](/docs/claude-science/command-line-settings) for the full command reference, including `logs` and the `serve` flags.
## Troubleshooting
| Symptom | What it means |
| ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `command not found: claude-science` | `~/.local/bin` isn't on your PATH yet. Run `. ~/.profile` or open a new terminal. |
| An error mentioning `bwrap too old` | The server's bubblewrap is older than 0.8.0. Upgrade it, or use a distribution that ships a newer version, such as Ubuntu 24.04 or later. |
| An error mentioning `cannot create unprivileged user namespaces` | The kernel or an AppArmor profile blocks the sandbox from creating user namespaces; some Ubuntu 24.04 images restrict this. The error message names the exact setting to change for your distribution. |
| The sign-in link shows an expired-link page | Links are single-use and valid for about three minutes. Run `claude-science url` on the server and open the fresh link; restarting with `claude-science stop` then `claude-science serve --no-browser` also prints one. |
| Sign-in stops at claude.ai | The redirect couldn't return through the tunnel (choose **Paste a code**), your account is on the Free plan (an upgrade is required), or your Team or Enterprise organization hasn't [enabled Claude Science](/docs/claude-science/enable-claude-science) yet. |
| Interactive HTML previews render as static snapshots after a short delay (charts don't respond) | The tunnel isn't forwarding the preview port. Add the second `-L` forward; the preview port is the web app port plus one (8001 by default). |
| The browser can't reach `localhost:8000` | The tunnel isn't up; rerun the `ssh -L` command. If the tunnel is up, confirm Claude Science is running on the server with `claude-science status`. |
| The installer reports no binary for your platform | Claude Science on Linux needs x64 with glibc. arm64 servers and musl-based distributions such as Alpine aren't supported. |
claude-science/run-on-windows-wsl First recorded · 90 lines, first recorded
# Run on Windows with WSL ## Enable WSL ## Install dependencies ## Install Claude Science ## Run it ## First launch ## Keep it running ## Troubleshooting
The first capture of this source. The page was already there, and this is what it said.
# Run on Windows with WSL
> Claude Science doesn't ship a native Windows build yet, but the Linux binary runs well under Windows Subsystem for Linux (WSL 2).
Claude Science doesn't ship a native Windows build yet, but the Linux binary runs well under Windows Subsystem for Linux (WSL 2). Setup takes about five minutes.
## Enable WSL
In PowerShell, run as Administrator:
```powershell theme={null}
wsl --install -d Ubuntu-24.04
```
Reboot if Windows prompts you to, then open **Ubuntu 24.04** from the Start Menu and create your Linux user when asked.
<Note>
Use Ubuntu 24.04 or newer. Claude Science's sandbox requires bubblewrap 0.8.0 or later, and Ubuntu 22.04 ships an older version. WSL 2 is also required (WSL 1 can't run the sandbox); `wsl --install` sets up WSL 2 by default. If you have an older WSL setup, check with `wsl -l -v` and upgrade with `wsl --set-version Ubuntu-24.04 2`.
</Note>
## Install dependencies
Inside the Ubuntu terminal:
```bash theme={null}
sudo apt update && sudo apt install -y curl bubblewrap socat
```
## Install Claude Science
Run the installer inside Ubuntu. It downloads the current release, verifies its checksum, and installs the `claude-science` command:
```bash theme={null}
curl -fsSL https://claude.ai/install-claude-science.sh | bash
```
Then confirm the command is on your PATH:
```bash theme={null}
. ~/.profile
claude-science --version
```
<Note>
Install from inside Ubuntu rather than downloading the binary with a Windows browser and copying it across. The installer verifies the download and keeps you on the stable release channel.
</Note>
## Run it
```bash theme={null}
claude-science serve --port 8765 --no-browser
```
First launch prints progress to the terminal and ends with a local URL. Copy that URL into any Windows browser: WSL 2 forwards `localhost` automatically, so the link works from Windows as-is. The URL contains a one-time sign-in token; to print a fresh one later, run:
```bash theme={null}
claude-science url
```
Then sign in with your Claude account and complete the setup wizard as described in [Get started](/docs/claude-science/get-started).
## First launch
On first launch, Claude Science sets up its starter Python and R environments and the bundled connectors for scientific databases and tools. On a fresh install this takes several minutes, and longer on a slow connection. While setup runs, some connectors can show a load error; most clear on their own once setup finishes. If a connector's error says its automatic retries are paused, turn the connector off and on again in **Settings** > **Connectors**, or restart Claude Science (`claude-science stop`, then the `serve` command above), to retry it.
## Keep it running
The app runs inside the WSL virtual machine, so it stops when WSL shuts down. Closing your last Ubuntu terminal shuts the VM down after a short idle period, and `wsl --shutdown` stops it immediately.
To start Claude Science again from PowerShell without opening an Ubuntu terminal:
```powershell theme={null}
wsl -d Ubuntu-24.04 -- ~/.local/bin/claude-science serve --port 8765 --no-browser
```
Leave that PowerShell window open; it keeps the VM alive. To run it in the background of an existing Ubuntu session instead:
```bash theme={null}
claude-science serve --port 8765 --no-browser --detached
```
## Troubleshooting
| Symptom | What it means |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `command not found: claude-science` | `~/.local/bin` isn't on your PATH yet. Run `. ~/.profile` or open a new terminal. |
| An error mentioning `bwrap too old` | Your Ubuntu version ships an older bubblewrap. Use Ubuntu 24.04 or newer. |
| `daemon already running on port 8765` | Claude Science is already running. Run `claude-science url` and open the printed link; there's no need to start it again. |
| `port 8765 is already in use` | A different program holds that port. Pick another with `--port 8080`. |
| The browser can't reach `localhost:8765` | Confirm the daemon is still running in WSL. If you use a custom `.wslconfig` network mode, try the WSL address (run `hostname -I` inside Ubuntu) instead of `localhost`. |
claude-science/the-reviewer First recorded · 28 lines, first recorded
# The reviewer ## Examples of what the reviewer checks ## How Claude responds to findings ## Adding your own review criteria ## Controls
The first capture of this source. The page was already there, and this is what it said.
# The reviewer > A built-in verification step that independently re-reads Claude's recent responses, the approved plan, saved artifacts, and the execution record, then checks whether its claims match what ran. The reviewer is a built-in verification step that independently re-reads Claude's recent responses, the approved plan, saved artifacts, and the execution record, then checks whether Claude's claims match what actually ran. It runs automatically after responses and periodically during long work, and you can trigger it any time with **Request review**. Automatic review is on by default on Max, Team, and Enterprise plans; on the Pro plan it starts off, and you can turn it on per session. ## Examples of what the reviewer checks * A result reported as computed when nothing ran. * A value in the response that contradicts the file it came from. * A citation that doesn't support the claim attributed to it. * A reference whose DOI resolves to a different article. * An approved plan step that wasn't completed. * A conclusion not supported by the method used. This isn't a complete list. The reviewer checks whether claims match the record; it doesn't re-run analyses. It can flag a conclusion that doesn't follow from the method that was run, but it doesn't judge whether that method was the right choice for your research question. Go to Settings > Specialists to customize the Reviewer or create your own specialist to perform additional reviews and judgments customized to the way you work. ## How Claude responds to findings If the reviewer finds something, a **Reviewer · N findings** card appears in the conversation. Each finding shows the claim, the evidence, and a link into the transcript. Claude reads the findings and addresses them in its next message, either by correcting the work or by explaining why the finding doesn't apply. You can open the reviewer's full reasoning from the card. ## Adding your own review criteria In **Settings** > **Specialists**, open **Reviewer** and add checks in the **Instructions** field. Your criteria are added to every review; they can't remove or weaken built-in checks. ## Controls Auto-review is a per-session toggle in the session settings menu. It starts on for Max, Team, and Enterprise plans and off for the Pro plan. Reviews run against your plan's usage.
claude-science/tools-and-environments First recorded · 40 lines, first recorded
# Tools and environments ## Starter environments ## Task environments ## Installing packages ## GPUs
The first capture of this source. The page was already there, and this is what it said.
# Tools and environments > Claude writes and runs Python, R, and shell commands. Claude writes and runs Python, R, and shell commands. Python and R run in a persistent kernel that keeps variables in memory across steps in a session. The kernel ends after about 30 minutes idle, when a package install restarts its environment, or when the session ends. ## Starter environments First launch creates two read-only conda environments in \~/.claude-science: * Python: numpy, pandas, scipy, matplotlib, seaborn, pillow * R: tidyverse, ggplot2, jsonlite ## Task environments When work needs packages the starters don't have, Claude reuses an existing named environment or proposes creating a new one (for example, single-cell or structural-biology). A permission card shows the environment name and initial packages. Environments are shared across all projects on the machine. To list or delete environments, ask Claude; there's no settings page for them. ## Installing packages Claude installs from these sources by default: * Conda: micromamba from the conda-forge, bioconda, defaults, and pytorch channels * Python: pip from PyPI * R: CRAN and Bioconductor A package installed into an environment is permanent and available in every session and project using that environment. A package installed inline in a code cell (`pip install` or `install.packages()`) lasts only until the kernel restarts. To keep a package, ask Claude to install it into the environment. For tools without a package, Claude downloads source, builds it in the sandbox with compilers from conda-forge, and saves the build as an artifact for reuse. The sandbox has no root access or system package manager. `apt` and `sudo` aren't available; Claude uses conda-forge or builds from source instead. Package sources can't be redirected to a different server. ## GPUs If your Linux machine has GPUs, the sandbox makes them available to code Claude runs, including on multi-GPU machines. You first need to turn GPU access on in the Settings > Compute pane. <Note> Allowing GPU access reduces the default sandboxing configuration applied by Claude Science. </Note> If your machine has no GPU, Claude notes this when a task needs one and can run the work on the remote compute you've connected. See Remote compute clusters and External compute providers.
claude-science/whats-not-available-yet First recorded · 28 lines, first recorded
# What's not available yet ## Audit and compliance ## Data retention ## Connector and domain allowlists ## Session duration ## Offboarding
The first capture of this source. The page was already there, and this is what it said.
# What's not available yet > Claude Science is in beta, and some admin controls you use with other Claude products don't govern it yet. Claude Science is in beta, and some admin controls you use with other Claude products don't govern it yet. The setup wizard lists some of these when you enable the product; this page has the full detail. See [Admin controls](/docs/claude-science/admin-controls) for the complete per-setting table. ## Audit and compliance Audit log: no Claude Science events are written to the organization audit log yet. This is on the roadmap.\ Compliance API: admins can't export or delete Claude Science data through the Compliance API. Because conversations live on members' computers, there's no Anthropic-side data for the API to reach; see [Manage on devices](/docs/claude-science/manage-on-devices) for endpoint-level options.\ Org data export: the organization export doesn't include data stored on members' computers. ## Data retention Custom Data Retention: your auto-delete window applies to conversations, projects, and artifacts stored on Anthropic's servers. Claude Science doesn't store that data on Anthropic's servers, so the setting has nothing to act on.\ Local deletion signal: when a member deletes local Claude Science data, Anthropic isn't notified to drop the matching server-side model-traffic log early. The log still expires under Anthropic's standard retention. ## Connector and domain allowlists Your organization's connector and domain allowlists apply to Directory connectors you publish, but don't restrict connectors a member adds locally (running on their own computer or pointing at a custom URL). Adding admin control over local and custom connectors is on the roadmap. Skills allowlists work the same way: org-published skills are visible; there's no admin control over which featured skills members can enable. ## Session duration Your session-duration setting limits the browser sign-in step only. After a member signs in, the app holds its own token and stays signed in beyond that window. ## Offboarding Removing a member from your organization revokes their ability to sign in, but doesn't wipe Claude Science data already on their computer. Use your device management software to handle local data on offboarding.
claude-tag/admins/add-connections First recorded · 244 lines, first recorded
# Give Claude access to your tools ## Your first Access bundle ### Why create more than one bundle ## Decide what to connect ### Create a dedicated account per service ### Limit access to specific resources ## Connect a service that isn't in the list ## Allow a host without a credential ### Add a domain ### Broad web access through the environment ### Allow all hosts ### Web search vs. network requests ## Add a connection ### Set allowed websites ### Restrict by path or method ### Connections vs claude.ai connectors ## Attach plugins ## Verify the connection saved ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Give Claude access to your tools
> An Access bundle bundles the credentials Claude Tag acts with. See how to create the dedicated service accounts, what to connect first, and how allowed websites limit reach.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<div className="tm-stepbar">
<a className="tm-stepbar-seg tm-done" href="/docs/docs/claude-tag/admins/pair-workspace">1 · Pair workspace</a>
<a className="tm-stepbar-seg tm-current" href="/docs/docs/claude-tag/admins/add-connections">2 · Give access</a>
<a className="tm-stepbar-seg" href="/docs/docs/claude-tag/admins/set-spend-limit">3 · Spend limit</a>
<a className="tm-stepbar-seg" href="/docs/docs/claude-tag/admins/test-it">4 · See it work</a>
</div>
<div className="tm-stepmeta">
<div className="tm-stepmeta-row"><span className="tm-stepmeta-label">Role you need</span><span>Owner in your Claude organization to create the bundle; an Admin can add credentials to a bundle that already exists. You'll also need a credential for each service, created by you or by that service's admin.</span></div>
<div className="tm-stepmeta-row"><span className="tm-stepmeta-label">Before this step</span><span>A <a href="/docs/docs/claude-tag/admins/pair-workspace">paired workspace</a></span></div>
<div className="tm-stepmeta-row"><span className="tm-stepmeta-label">Do I need this?</span><span><span className="tm-meta-pill tm-meta-pill-opt">Optional to start</span>You need a connection only when Claude should act in a system beyond Slack, like querying BigQuery, reading Google Drive, or filing Linear tickets.<br /><br />You can add connections any time after setup (they apply immediately), but adding the systems your team expects before they onboard means their first requests succeed.</span></div>
</div>
<Tip>Claude starts delivering work before you connect anything. On Slack content alone, it can [catch a team up on a channel or thread](/docs/claude-tag/users/use-cases/catch-up), [triage a request channel](/docs/claude-tag/users/use-cases/triage-requests), [turn a discussion into a doc](/docs/claude-tag/users/use-cases/create-artifacts), and [track a project from channel history](/docs/claude-tag/users/use-cases/track-projects). Connections multiply what it can do from there; each one adds a system Claude can act in beyond Slack.</Tip>
## Your first Access bundle
An [Access bundle](/docs/claude-tag/concepts/glossary#access-bundle) is a named set of credentials, repository grants, and instructions that Claude uses in the channels the bundle covers. A connection is one service credential inside a bundle, like a Datadog API key or a warehouse service account, that Claude uses to act in that service from any channel under the bundle's [scope](/docs/claude-tag/concepts/glossary#scope).
If you're in [setup](/docs/claude-tag/admins/setup-overview), you add these connections there; skip to [Decide what to connect](#decide-what-to-connect). The steps below are for creating a bundle outside setup, on the admin page directly.
<Steps>
<Step title="Open the admin page">
Go to [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). Under **Claude Tag's access**, the **Slack** tab shows your scopes (the organization-wide **Slack** row, each workspace, and any channels under them). The **Slack** row opens as **Default Slack access**.
</Step>
<Step title="Create a bundle on a scope">
On the scope where you want the bundle to apply, click **+** next to **Access bundles** and choose **Create new bundle**. This creates the bundle and attaches it to that scope in one step; the bundle dialog opens.
</Step>
<Step title="Name the bundle">
Click the pencil next to **Untitled access bundle** to rename it (the console uses "profile" and "Access bundle" interchangeably).
</Step>
</Steps>
You can also create an unattached bundle by clicking **Create** on the **Access bundles** page in the left navigation, then attach it to scopes afterward.
Connections belong to the [agent identity](/docs/claude-tag/concepts/agent-identity), not to any person. Personal claude.ai connectors apply only in DMs.
Name a bundle after what it grants, since the name is what you'll read when deciding which bundles to bind to a channel: `data-readonly`, `github-write`, `monitoring`, `gtm-tools`. A capability name stays meaningful when the same bundle serves several teams; a team name (`devprod-team`) works when one team's full access is the unit you'll reuse.
### Why create more than one bundle
Multiple bundles let you grant access by capability and compose it per channel. For example, with separate `data-readonly`, `github-write`, and `monitoring` bundles: `#platform-eng` gets all three, `#gtm-analytics` gets only `data-readonly`, and `#incidents` gets `monitoring` plus `github-write`. Each credential is defined once, so rotating a Datadog key means editing one bundle without touching the others.
A bundle also has Domains, Plugins, and Instructions tabs alongside Credentials and Repositories. Use the bundle's Instructions for guidance that should travel with a credential; use [per-scope custom instructions](/docs/claude-tag/admins/attach-to-scope#add-custom-instructions) for guidance tied to a place.
## Decide what to connect
Six categories cover most of the work teams hand to Claude. Any service with an HTTP API can be added; start with the categories that match what your teams already do.
Read-only connections are most useful in combination: an answer that joins the ticket, the deploy, and the error rate needs all three systems connected. Connecting many systems read-only is a different decision from granting write access anywhere.
| Connect | Examples | Recommended access | What it adds |
| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------- | :------------------------------------------------------------------------------------------------------------------------------------ |
| Knowledge and docs | Google Drive, [Notion](/docs/claude-tag/admins/connections/notion), [Confluence](/docs/claude-tag/admins/connections/atlassian) | Read | Answers grounded in design docs, runbooks, and prior decisions |
| Code | GitHub, [GitLab](/docs/claude-tag/admins/connections/gitlab) | Read and write | Branches, pull requests, review, CI follow-up. GitHub is managed through the [Claude GitHub App](/docs/claude-tag/admins/configure-github) |
| Data warehouse | BigQuery, [Snowflake](/docs/claude-tag/admins/connections/snowflake), Redshift | Read | Data questions answered with charts in the thread; recurring reports |
| Monitoring | [Sentry](/docs/claude-tag/admins/connections/sentry), [Datadog](/docs/claude-tag/admins/connections/datadog), [PagerDuty](/docs/claude-tag/admins/connections/pagerduty) | Read | Logs, metrics, and errors for debugging and incident work |
| Issue tracking | [Linear](/docs/claude-tag/admins/connections/linear), [Asana](/docs/claude-tag/admins/connections/asana), [Jira](/docs/claude-tag/admins/connections/atlassian) | Read and write | File tickets and post status updates where work lives |
| Go-to-market | [HubSpot](/docs/claude-tag/admins/connections/hubspot), [Gong](/docs/claude-tag/admins/connections/gong), [Salesforce](/docs/claude-tag/admins/connections/salesforce) | Read | Pipeline and customer state for account questions |
Per-service instructions, with the credential fields and allowed-websites values, are in the [connection guides](/docs/claude-tag/admins/connections/overview).
### Create a dedicated account per service
<Warning>The credential you connect is Claude's account in that tool, not yours. Anyone in a channel under the bundle's scope can use it through Claude, so connect a dedicated identity you control rather than your personal login.</Warning>
For each tool, create that identity specifically for the agent rather than reusing a shared bot key. The pattern depends on the service.
| Service type | Recommended pattern |
| :------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Google Workspace (Drive, Calendar, Docs) | Create a virtual user like `[email protected]` and share the folders and calendars it needs. If using a GCP service-account key with domain-wide delegation, restrict the delegation to that single subject and the minimum OAuth scopes; DWD can otherwise impersonate any user in your domain. |
| SaaS with native service accounts (Datadog, Snowflake, Sentry) | Create a service account in that tool's admin, scope it to the project or read-only role, and use its API key |
| SaaS without service accounts (Linear, Asana) | Create a dedicated user seat for the agent and use a personal access token from that seat |
| Cloud APIs (AWS, GCP) | Create a dedicated IAM principal with the narrowest policy that covers the work |
A dedicated account keeps the agent's activity separately auditable in each tool's logs and lets you revoke its access without touching anyone else's. Grant read-only wherever the categories below say read; Claude can never exceed what the key allows.
If the person who administers a service isn't you, send them this:
```text wrap theme={null}
Please create a service account in [service] for our Claude agent, scoped to [read-only / the specific project], and send me the credential through [your secrets channel]. It will be used by an org-managed agent, with the credential injected at a network proxy; the agent itself never holds the key. Details: https://claude.com/docs/claude-tag/admins/add-connections
```
### Limit access to specific resources
A connection has no setting for which pages, folders, or projects Claude can reach inside a tool. The connection's reach is whatever the connected account can access in that tool. To narrow Claude to a subset, narrow the account:
* **Confluence or another wiki:** give the service account read access to only the spaces or pages Claude should see
* **Google Drive:** share only the relevant folders with the dedicated Google account; see [Google Workspace](/docs/claude-tag/admins/connections/google)
* **Project or ticket trackers:** add the service account to only the projects it needs
The host, path, and method restrictions on a connection control which API endpoints Claude can call, not which records those endpoints return. Use them alongside account-level scoping, not instead of it.
For a shared or external channel, put the narrowed connection in its own bundle and [attach that bundle only to that channel](/docs/claude-tag/admins/attach-to-scope#attach-to-a-channel), so the credential is unavailable elsewhere.
## Connect a service that isn't in the list
The services with **Connect** buttons on the Credentials tab are presets, not the full set Claude can connect to. Any app with an API can be connected: click **Connect** next to **Custom tool** at the bottom of the tab. See the [Custom connection guide](/docs/claude-tag/admins/connections/custom) for the form fields, credential types, and how to add a custom MCP server.
## Allow a host without a credential
Claude does channel work in an isolated [sandbox](/docs/claude-tag/concepts/agent-identity#channel-sessions). A network request is traffic that sandbox sends to a host, such as an API call, a `curl` fetch, or a package install. Before Claude can make one from a channel, the destination host has to be allowed by one of three settings, the allow layers:
* **A domain entry**: a hostname listed on this bundle's **Domains** tab. Requests to it pass with no credential attached; see [Add a domain](#add-a-domain).
* **A [connection](#add-a-connection)**: a credential on this bundle's **Credentials** tab. Requests matching its [allowed websites](#set-allowed-websites) pass with that credential attached.
* **The scope's [environment](/docs/claude-tag/concepts/glossary#environment)**: the compute configuration the scope's sessions run in, which carries its own network access setting, starting at the Trusted access level that covers common package registries. Requests to hosts it allows pass with no credential; see [Broad web access through the environment](#broad-web-access-through-the-environment).
A host that none of these allows stays unreachable, and when more than one bundle is attached to a scope, the entries of all of them apply. Web search is governed by none of them, because searching happens on Anthropic's servers rather than in the sandbox; see [Web search vs. network requests](#web-search-vs-network-requests).
### Add a domain
A domain entry allowlists one hostname for every channel this bundle covers. After you add it, requests from those channels' sandboxes to that host go through with no credential attached.
To get there, open the bundle from the scope that covers the channel, under **Claude Tag's access** at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag); if the scope has no bundle yet, [create one](#your-first-access-bundle) first. On the bundle's **Domains** tab, fill in the form and click **Add domain**:
* **Domain**: the hostname to allow; a wildcard is allowed as the leftmost label, like `*.example.com`, and covers subdomains at any depth but not `example.com` itself
* **Ports**: needed only when the service listens on something other than 443
You don't have to predict the full list up front. When a request is blocked, Claude says so in the thread and names the host; add that host here and retry; if it's still blocked, start a fresh thread.
Typical entries are hosts the work calls without a key, such as a docs site or a public API. Common package registries are usually already reachable through the [environment's Trusted access default](#broad-web-access-through-the-environment), and a host that needs a credential belongs in a [connection](#add-a-connection) instead. Entries appear below the form and can be removed individually.
An Admin can edit the Domains tab on an existing bundle; creating the bundle itself needs an Owner.
<Note>[Agent Proxy](/docs/claude-tag/concepts/agent-identity#agent-proxy) carries only HTTP and HTTPS. A protocol that isn't HTTP, such as SSH, can't cross the proxy, so listing a host here doesn't make it reachable over SSH.</Note>
### Broad web access through the environment
Domain entries allow hosts one at a time. For a scope whose work needs more of the web, the environment setting grants broader access. An [environment](/docs/claude-tag/concepts/glossary#environment) is the sandboxed compute configuration the scope's sessions run in, and it carries its own network access setting.
A new environment's network access level is Trusted access, which allows a [documented set of package registries and developer hosts](https://code.claude.com/docs/en/cloud-environments#default-allowed-domains). A channel can already reach hosts like `pypi.org` and `registry.npmjs.org` with no domain entry.
To give a scope broader access, create an environment with a more permissive level and pin it on the scope.
<Steps>
<Step title="Create the environment">
From the **Cloud environments** page in [admin settings](https://claude.ai/admin-settings), add an [organization-shared environment](https://code.claude.com/docs/en/cloud-environments#organization-shared-environments) and set its network access level. **Full access** allows any domain; see [Network access in the Claude Code docs](https://code.claude.com/docs/en/cloud-environments#network-access) for the other levels. This step takes an Owner or admin.
Don't create the environment at [`claude.ai/code`](https://claude.ai/code): environments you create there belong to your individual account, so they never appear in the picker.
</Step>
<Step title="Pin it on the scope">
Open the scope's **Advanced** section and use the **Environment** picker. With nothing pinned, sessions use the organization default.
</Step>
</Steps>
The environment must be scoped to the organization, not an individual account. If sessions don't pick up the one you pinned, see [the environment troubleshooting entry](/docs/claude-tag/admins/troubleshooting#channel-sessions-use-the-wrong-environment-or-can%E2%80%99t-find-one).
### Allow all hosts
Allow-all egress is off by default; ask your Anthropic account team to enable it for your organization. Once enabled, you can enter `*` alone as the domain. A `*` entry needs ports assigned; it admits any host on those ports, with no credential attached.
With `*` active:
* Requests to hosts that no connection covers go through with no credential attached.
* A `*` entry never carries a credential, and a connection's credential still travels only to its [allowed websites](#set-allowed-websites).
* Private and internal network addresses and cloud metadata endpoints remain blocked.
Without allow-all egress enabled, saving `*` fails with a generic "Couldn't add domain." error that doesn't name the cause. If the capability is later disabled, you can disable an existing `*` entry or narrow it to specific hosts, but you can't keep it active.
### Web search vs. network requests
Web search needs no domain entry, connection, or environment setting. It's [Anthropic's built-in web search tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool), and the searching happens on Anthropic's servers rather than in the channel's sandbox, so no allow layer applies.
Opening a page is not part of the search. A search returns content from the pages it matches, which Claude reads and cites; fetching a URL from the sandbox is a network request like any other, and the host needs an allow layer. Claude can answer from a page that search surfaced yet report that it can't open the same link.
If the work needs Claude to open and read pages rather than answer from search results, allow those hosts through the settings above. [Web search vs. network requests](/docs/claude-tag/concepts/agent-identity#web-search-vs-network-requests) covers the session mechanics behind the split.
## Add a connection
On the bundle's **Credentials** tab, click **Connect** next to a listed service, or next to **Custom tool** for a service not in the list.
For a custom connection, choose the credential type:
| Credential type | Use for |
| :------------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Bearer | API keys and OAuth bearer tokens. Most SaaS REST APIs. |
| Basic | HTTP Basic authentication. |
| Body parameter | A token the API expects in the request body or query string instead of a header. |
| AWS SigV4 | Signed requests to AWS APIs with an access key pair. |
| GCP access token (with Service Account Key) | Google Cloud APIs via a service-account JSON key. Google Workspace services like Drive and Calendar also use this; see [the Google guide](/docs/claude-tag/admins/connections/google). |
| GCP IAP (with Service Account Key) | Google Cloud services behind Identity-Aware Proxy. |
| OAuth 2.0 JWT bearer | Server-to-server OAuth. |
| OAuth 2.0 client credentials | Server-to-server OAuth. Salesforce uses this. |
| OAuth 2.0 authorization code (3-legged) | Sign in once as an admin; the agent acts as that account. |
| GitHub App | GitHub repositories; covered separately at [Configure GitHub access](/docs/claude-tag/admins/configure-github). |
Credentials are injected at the network boundary by Agent Proxy; the model and the sandbox are not given the key. A request to a host you haven't allowed is blocked, not sent. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
### Set allowed websites
List the hosts a connection's credential may be sent to. A wildcard works only as the leftmost label, like `*.example.com`; it covers subdomains at any depth but not `example.com` itself. You can't enter `*` alone here; a credential is always limited to specific hosts. To let Claude reach any host without a credential, see [Allow all hosts](#allow-all-hosts).
To change a connection's name or allowed websites after saving, open the **⋮** menu on that connection's row in the bundle's **Credentials** tab and choose **Edit**. The same menu has **Rotate secret** (where the credential type supports it) and **Delete**.
Check the host against your account's region before saving. Some presets fill a default host that may not match your account's region; a Datadog key, for example, only works against your account's Datadog site, like `api.datadoghq.com` or `api.datadoghq.eu`.
### Restrict by path or method
After saving, you can restrict a connection by URL path or HTTP method, like allowing `GET` but not `DELETE`, for control tighter than host-level.
### Connections vs claude.ai connectors
The connection gallery lists credential types the agent can hold, not the connectors your organization or its members have set up on claude.ai. A connection authenticates the agent, not a person; a connector on someone's personal claude.ai account doesn't appear here. For Google services, use a service-account key or the OAuth sign-in option, both of which give the agent one credential with access to the data the channel needs. Personal connectors keep working in [DMs](/docs/claude-tag/concepts/agent-identity#direct-message-channels).
## Attach plugins
A connection grants access; a plugin teaches Claude how to use it well. A plugin is a bundle of skills, reusable instructions for working with a specific tool or following a specific process, and you attach plugins to the same Access bundle or scope that carries the connection, so the credential arrives with directions for using it.
A Datadog API key, for example, makes the API reachable, and a Datadog plugin tells Claude which endpoints answer which questions. Sessions in covered channels pick up attached plugins automatically; there is nothing for channel members to install or enable.
Anthropic provides plugins for common tools, and you can add your own from a [skills repository](/docs/claude-tag/admins/skills-repo). To give Claude organization-wide skills, bundle them in a plugin.
Plugins attach in two places, and the two behave differently:
* A plugin added directly on a scope (the plugin chips on the scope's panel) is enabled there as soon as you add it.
* A bundle's **Plugins** tab lists the plugins available to your organization, each off until you toggle it on.
Registering a plugin at the organization level makes it available, not active. It takes effect only where a bundle enables it or a scope adds it directly.
Adding or removing plugins and skills applies to new threads only. A thread already running keeps the set it began with; start a fresh thread to pick up changes.
Claude can't publish a new skill version from inside a thread; that update happens in admin settings.
## Verify the connection saved
* Each connection is listed in the bundle with the host you set.
* New threads pick up new connections on their own. An existing thread isn't told about a connection added after it started, but the connection works there; ask Claude to use the service by name.
## Related resources
* [Set a spend limit](/docs/claude-tag/admins/set-spend-limit): fund usage so the connections you just added can run
* [Configure GitHub access](/docs/claude-tag/admins/configure-github): repository access, managed through the Claude GitHub App
* [How agent identity works](/docs/claude-tag/concepts/agent-identity#agent-proxy): how the credentials you just added reach Claude without entering its sandbox
claude-tag/admins/attach-to-scope First recorded · 123 lines, first recorded
# Configure per-channel access ## How scopes inherit ## Attach the bundle ### Attach to a workspace ### Attach to a channel ## Precedence when bundles overlap ### Which credential wins ### Repositories and plugins ### Custom instructions ### Instruction layers ### Add custom instructions ### Restrict who can set channel instructions ## Verify the bundle is live ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Configure per-channel access
> Choose which Slack channels and workspaces a set of Claude Tag credentials applies to. Covers inheritance, overlap rules, and adding channels after setup.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
This page covers adding access to more workspaces and channels, and how access stacks when several bundles apply to the same place. It assumes you have already [paired a workspace](/docs/claude-tag/admins/pair-workspace) and [created an Access bundle](/docs/claude-tag/admins/add-connections). You must be an Owner in your Claude organization to attach bundles.
A scope is where a bundle applies: **Default Slack access** (the organization-wide root), a workspace, or a single channel. Bundles inherit downward through those scopes, and when credentials overlap, the narrowest scope wins.
## How scopes inherit
Bundles stack downward. A channel gets whatever is attached at Default Slack access, plus its workspace, plus anything attached to the channel itself.
<img className="block dark:hidden" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/scope-inheritance.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=673f78c6c43aceb03ed9c81a2de7b0b2" alt="Nested boxes. The outermost box is the Default Slack access scope: a bundle attached here is the baseline every channel gets. Inside it, two examples. Outside the workspace box, a channel called another-team in a different workspace gets only the default bundle. Inside the workspace box, which adds an optional bundle for channels inside it, two channel boxes: a public channel called general, with no channel bundle, gets the default plus the workspace bundle; a private channel, marked with a lock, with its own channel bundle, gets all three, the default, workspace, and channel bundles." width="1000" height="320" data-path="images/claude-tag/diagrams/scope-inheritance.svg" />
<img className="hidden dark:block" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/scope-inheritance-dark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=b53a534b076e6c22f0d86a81841b00a8" alt="Nested boxes. The outermost box is the Default Slack access scope: a bundle attached here is the baseline every channel gets. Inside it, two examples. Outside the workspace box, a channel called another-team in a different workspace gets only the default bundle. Inside the workspace box, which adds an optional bundle for channels inside it, two channel boxes: a public channel called general, with no channel bundle, gets the default plus the workspace bundle; a private channel, marked with a lock, with its own channel bundle, gets all three, the default, workspace, and channel bundles." width="1000" height="320" data-path="images/claude-tag/diagrams/scope-inheritance-dark.svg" />
| Scope | What it covers | Access |
| :------------------- | :---------------------------------------- | :---------------------------------------------------------------------- |
| Default Slack access | Every Slack workspace and channel | The baseline set every channel gets |
| Workspace | All channels in one Slack workspace | Inherits Default Slack access, plus workspace-level bundles |
| Channel | A single Slack channel, public or private | Inherits Default Slack access and workspace, plus channel-level bundles |
The same stacking applies in reverse. Detaching a bundle from a channel removes only that channel's additions, and bundles attached at the workspace or Default Slack access still apply there.
Memory is also scoped, but differently: there is no organization-wide memory, public-channel entries are shared across the workspace, and a private channel reads workspace memory but writes only to its own store. See [What Claude Tag remembers](/docs/claude-tag/users/memory).
DMs run under the user's own claude.ai account, so bundles attached here apply only in channels. See [how DMs work in this model](/docs/claude-tag/concepts/agent-identity#direct-message-channels).
## Attach the bundle
Attaching binds the bundle to a workspace scope or to a single channel under it.
The binding takes full effect in new threads only. A thread already running keeps the skills, plugins, and custom instructions it started with. A connection added after a thread started still works there if you ask Claude to use the service by name, but Claude doesn't announce it, so test with a new top-level thread after attaching a bundle.
### Attach to a workspace
Each paired workspace already has a scope; bind a bundle in the scope's **Access bundles** section. On the **Access bundles** page in the left navigation, each bundle's card shows how many places it's used in. To see which scopes those are, open the bundle's **Manage** dialog and hover over the usage count in its footer. To add another workspace, [pair it](/docs/claude-tag/admins/pair-workspace) first.
### Attach to a channel
Channels Claude was added to appear on the **Slack** tab automatically, each as a scope under its workspace. To give one of these channels access beyond the workspace baseline, select its row and bind bundles in the scope's **Access bundles** section. A channel row shows the name an admin gave the scope, the channel's name in Slack, or the raw channel ID.
To find a channel, use the **Search channels** field. It matches channel names and channel IDs (pasting a channel link copied from Slack also works), and searching a workspace's name shows that workspace's channels.
A channel that doesn't appear in the list yet needs a scope created for it:
1. On [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), find the workspace on the **Slack** tab under **Claude Tag's access** and select **Add channel**.
2. Paste the channel's ID into the **Channel ID** field. Channel IDs start with `C`, or with `G` for some older private channels. Copy the ID from the channel's details in Slack.
3. Save, then bind bundles in the new scope's **Access bundles** section, the same as for a workspace.
In a channel shared across more than one workspace in your Enterprise Grid, bundles bound to the channel or its workspace don't apply. See [Channels shared across workspaces in your Enterprise Grid](/docs/claude-tag/admins/restrict-access#channels-shared-across-workspaces-in-your-enterprise-grid) for what Claude does there instead.
<Warning>A bundle attached to a public channel grants its access to anyone who joins that channel. In most Slack workspaces, anyone can join a public channel, so the channel's join policy becomes the effective access control for whatever the bundle grants. Keep elevated credentials in private-channel scopes.</Warning>
## Precedence when bundles overlap
A channel sees the **union** of every bundle bound at the channel itself, its workspace, and Default Slack access. Narrower scopes don't replace wider ones; they add to them. When two bundles in the resolved set carry rules for the same host, the rule from the narrower scope wins. Within that union, fixed rules decide which credential and which instructions apply.
### Which credential wins
When two bundles each carry a credential for the same host:
* The credential from the **narrowest scope** is used: channel beats workspace, which beats Default Slack access.
* Within the same scope, the order isn't admin-configurable. Avoid binding overlapping credentials at the same scope; if you can't predict which key acts, neither can a security review.
* There is no fallback. If the winning credential gets a `401` or `403`, Claude does not retry with the next one.
### Repositories and plugins
Repository grants and plugins from every bound bundle are combined as a union; a channel gets every repo and plugin from any bundle in its chain. The **Access summary** section, shown when you select a scope on the Slack tab, lists the resolved set.
### Custom instructions
Per-scope custom instructions are **concatenated**, Default Slack access first, then workspace, then channel. A channel's instructions add to, rather than replace, what's set above it.
### Instruction layers
Three kinds of standing instruction can apply in a channel, written by different people:
| Layer | Who writes it | Where |
| :------------------ | :-------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------- |
| Custom instructions | Owner for any scope; channel members for the channel scope, unless [restricted](#restrict-who-can-set-channel-instructions) | The scope's panel in admin settings, or the **Configure** link in any reply footer for the channel scope |
| Channel memory | Anyone in the channel | By telling Claude to remember |
| Task prompt | The requester | The message itself |
Channel members can shape how Claude responds in their channel through memory, but they can't change which credentials or repositories it has; that's bundle configuration. See [who controls what](/docs/claude-tag/admins/customize) for the full split.
Custom instructions are read ahead of the conversation and take priority in practice, but they're guidance, not an enforced guardrail. Don't rely on them to block actions; use access controls for that.
### Add custom instructions
Each scope can carry custom instructions, which are standing guidance Claude reads in every session there, like team conventions or where to file tickets. The **Custom instructions** field is on the scope's panel, shown when you select the scope on the **Slack** tab in admin settings.
Channel members reach the same field for the channel scope through the **Configure** page, linked in the footer of any Claude reply, without going through admin settings. Both entry points write the same instructions, so a change from either place is visible in the other.
The field is plain text, inserted as written; there is no include or template syntax, and `{{include:...}}` is passed through literally. To give Claude a repository's `CLAUDE.md`, [grant the repository](/docs/claude-tag/admins/configure-github#grant-repository-access) and name it in the request; its `CLAUDE.md` loads after the clone completes.
### Restrict who can set channel instructions
By default, anyone in a channel who is also a member of your Claude organization can edit that channel's instructions from the **Configure** link in Claude's reply footer. The **Channel member edits** setting in a scope's **Advanced** settings controls this.
| Option | Effect |
| :---------- | :-------------------------------------------------------------------------------------------------------- |
| **Inherit** | Follow the parent scope's setting |
| **Allow** | Members can edit channel instructions from the Configure link |
| **Block** | The Configure page is read-only for members, with a note that only admins can change channel instructions |
A chain of scopes that all inherit resolves to **Allow**. Set **Block** at the workspace or Default Slack access scope to lock channel instructions across every channel beneath it.
## Verify the bundle is live
* The bundle card's usage count includes the new scope. To see it named, open the bundle's **Manage** dialog and hover over the count in its footer.
* A test task in the pilot channel uses the bundle's connections, and the action appears in the connected service's audit log under your service account.
Repeat the attach step for any additional scopes that need elevated access, then widen per the [rollout patterns](/docs/claude-tag/admins/setup-overview#after-setup).
## Related resources
* [Getting started for users](/docs/claude-tag/users/getting-started): what your team does once the bundle is live
* [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access): narrow where it responds
claude-tag/admins/audit First recorded · 60 lines, first recorded
# Review what Claude Tag has done ## What the Audit view lists ## Trace an action to its source ## See what's scheduled in a channel ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Review what Claude Tag has done
> Claude Tag actions appear under its own service accounts in each connected tool's audit log. See what the Audit page covers, how to trace an action to its source, and where each connected tool keeps logs.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Use this page to review what Claude Tag is doing across your organization: which routines are scheduled, what memory it has saved, and where to find a record of each action it took.
<Note>You must be an Admin or Owner in your Claude organization to open the Audit page; the other trails on this page are visible to anyone with access to the underlying surface.</Note>
Claude Tag activity is auditable in four places:
* **[The Audit page](#what-the-audit-view-lists)** in admin settings, with tabs for scheduled work, memory, and (if enabled) network events
* **Memory files on each scope** (select the scope in the **Claude Tag's access** section, then choose **View memory files** from its **⋯** menu), where you can review what Claude has saved
* **[Attribution on each action](#trace-an-action-to-its-source)** Claude takes in a connected tool
* **[The audit logs of each connected service](#trace-an-action-to-its-source)**, where its actions appear under the service account you provisioned
## What the Audit view lists
The **Audit** page (left-nav label **Audit logs**) at [`claude.ai/admin-settings/claude-tag/audit`](https://claude.ai/admin-settings/claude-tag/audit) has these tabs:
| Tab | What it shows |
| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Scheduled work** | Every routine across your organization, with a **Scope** filter and a per-row **⋮** menu (View details, Pause/Resume, Delete) |
| **Memory** | A link to each scope's memory files, where you can read what Claude has saved for that workspace or channel (an Owner can also edit or delete) |
| **Network events** | An hourly JSON export of outbound calls Claude made through Agent Proxy. Git and MCP traffic are not included in this export. Select a date and hour to download. This tab only appears if your organization has network-event export enabled; contact your account team to request it. |
Each routine on the **Scheduled work** tab shows **Created by** (the member who set it up) in its **View details** dialog. There is no per-action log of every task and who asked; for that, use the trails below.
## Trace an action to its source
In channels, Claude acts as itself, so each action there carries the service-account identity:
* **In Slack**, it posts as the Claude app, and its work happens in threads anyone in the channel can read.
* **On code**, commits and pull requests show the Claude GitHub App as the author, and each one links back to the Slack thread it came from.
* **In every other connected service**, actions appear under the service account you created for the connection.
That last one is the general-purpose trail: because you provisioned the credential, the connected service's audit log shows everything Claude did there, under an account your security team already monitors.
The [See it work](/docs/claude-tag/admins/test-it) page uses this check to validate a new connection.
## See what's scheduled in a channel
Anyone in the channel can see its standing work. Ask in the channel:
```text wrap theme={null}
@Claude what triggers do you have set up in this channel?
```
Claude lists the channel's scheduled jobs and watches, and anyone there can ask it to disable one.
Routines run with the channel's credentials, so the channel listing is also the permission picture. See [proactivity](/docs/claude-tag/users/proactivity#manage-standing-work).
## Related resources
* [How agent identity works](/docs/claude-tag/concepts/agent-identity): how attribution differs in channels and DMs
* [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access): the controls when an audit turns something up
* [Security and data handling](/docs/claude-tag/concepts/security-and-data): the model behind the trails
claude-tag/admins/configure-github First recorded · 138 lines, first recorded
# Configure GitHub access ## Link your GitHub organization ## Grant repository access ## Verify GitHub access ### If Claude can't reach a repository ## How granted repositories reach a session ### What loads from a repository ### Install project dependencies ## What Claude can do with GitHub Actions ## Scheduled work uses the same connection ## GitHub Enterprise ### GitHub Enterprise Cloud with data residency ### GitHub Enterprise Server ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Configure GitHub access
> Claude Tag gives Claude its own GitHub identity, so it opens pull requests as Claude. See how to link your GitHub organization, grant repositories to a bundle, what loads when a repository is cloned into a session, how to get project dependencies installed, and what Claude can do with GitHub Actions.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Tip>Using GitLab instead of GitHub? See [Configure GitLab access](/docs/claude-tag/admins/configure-gitlab). GitLab uses a service-account token rather than an installed app.</Tip>
Claude Tag gives Claude its own GitHub identity, the Claude GitHub App, so pull requests it opens from a channel are authored by Claude rather than by a person. You only need GitHub access if a team will hand Claude code work: branches, pull requests, review, or CI follow-up.
You link GitHub once for your Claude organization, then grant repositories per Access bundle.
<Tip>If you link your GitHub organization before running [setup](/docs/claude-tag/admins/setup-overview), setup includes a step for granting repository access inline, so you don't need to return to the Repositories tab afterward.</Tip>
## Link your GitHub organization
<Note>
The person who completes the link must be both an **owner of the GitHub organization** and an **Admin in your Claude organization**. If you aren't a GitHub organization owner, use **Copy message** under **Not a GitHub account owner?** on the GitHub settings page to send the link to someone who is.
</Note>
<Steps>
<Step title="Open the GitHub settings page">
Open [`claude.ai/admin-settings/github`](https://claude.ai/admin-settings/github). This page is shared with Claude Code; one connection serves both products.
</Step>
<Step title="Connect Claude to GitHub">
Click **Connect Claude to GitHub** and complete the GitHub authorization. After authorizing, the page shows two sections: **Connected GitHub accounts** lists organizations already linked, and **Unlinked accounts** lists organizations where the Claude GitHub App is installed but not yet linked.
</Step>
<Step title="Link or install">
If your organization is under **Unlinked accounts**, click **Link** next to it. If it isn't listed at all, click **Install on another organization** and complete the install on github.com; you're returned to this page with the organization under **Connected GitHub accounts** as **Connected**.
* A disabled **Link** button means you aren't an owner of that GitHub organization
* A **Needs permissions** status means the installation has a pending request; **Review permissions** takes you to github.com to approve it
</Step>
</Steps>
## Grant repository access
The remaining steps are in the Claude Tag admin page, not GitHub's settings. Repository grants live on the Access bundle; editing a bundle's Repositories tab requires the **Owner** role in your Claude organization.
<Steps>
<Step title="Open the bundle's Repositories tab">
Open an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle) and go to its **Repositories** tab. Before any GitHub organization is linked, this tab shows a **Get started with GitHub** button that opens [`claude.ai/admin-settings/github`](https://claude.ai/admin-settings/github).
</Step>
<Step title="Select repositories">
Choose the repositories Claude can read from and open pull requests against. Access is per listed repository, or choose **Connect all** for the organization.
</Step>
</Steps>
## Verify GitHub access
* The GitHub organization shows as **Connected** under **Connected GitHub accounts** at [`claude.ai/admin-settings/github`](https://claude.ai/admin-settings/github).
* The granted repositories are listed in the bundle's **Repositories** tab.
* For the end-to-end check, open a draft PR from a test channel; see [Verify the bundle is live](/docs/claude-tag/admins/attach-to-scope#verify-the-bundle-is-live).
### If Claude can't reach a repository
When Claude replies "That environment or repo isn't configured for Claude Code", or reports that GitHub returned a 403, check the two levels in order.
| Check | Where |
| :---------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The GitHub organization that owns the repository shows **Connected** under **Connected GitHub accounts** | [`claude.ai/admin-settings/github`](https://claude.ai/admin-settings/github). An installation still waiting on a GitHub organization owner shows **Needs permissions**; **Review permissions** opens the approval on github.com. |
| The repository is listed on the bundle's **Repositories** tab, and that bundle is attached to the channel's scope | [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag) → **Access bundles** → the bundle → **Repositories**. A repository granted in one bundle isn't reachable from a channel under a different bundle. |
Repository grants apply to new threads. After changing the **Repositories** tab, start a fresh thread in the channel and name the repository in the first message.
The message "GitHub Actions writes are not permitted for this session type." is a different `403`. It says nothing about repository access; see [What Claude can do with GitHub Actions](#what-claude-can-do-with-github-actions).
## How granted repositories reach a session
Granting a repository in a bundle makes it *available* to Claude in any channel under that bundle's scope. It doesn't clone the code into a session on its own. A session starts with no repositories checked out; Claude clones one when the request names it, or when someone in the thread tells it which repository to add. Tell your team to name the repository in the first message of a code task.
### What loads from a repository
When Claude clones a granted repository into a session, its Claude Code configuration loads on the next turn after the clone completes, so project context arrives without further prompting:
* `CLAUDE.md`, `.claude/CLAUDE.md`, and `.claude/rules/*.md` load as project context
* Skills in `.claude/skills/` load, so Claude can use them in the session
* The project settings in `.claude/settings.json` load, so hooks defined there run in the session as they do under Claude Code
A repository's `.mcp.json` is never loaded, and connections come only from the Access bundle.
Repository skills apply only in sessions that have the repository. To give a skill to every channel under a scope, add it through a [skills repository](/docs/claude-tag/admins/skills-repo).
### Install project dependencies
Every session runs in an isolated sandbox with a standard set of preinstalled tools. The sandbox is the same for every repository; there is no setup script or custom image to configure. If a project needs something the standard set doesn't include, such as a specific language runtime or a database client, add the install commands to the repository's `CLAUDE.md`.
Claude follows `CLAUDE.md` as guidance when it starts work that needs it, not as an unconditional setup step. Write each install as a precondition of the work it supports, for example "install the SDK before building or running tests", so Claude runs it when a task touches that code. The sandbox is fresh for every session, so the installs repeat each time Claude works in the repository.
Prefer the standard package manager and its default registry over a vendor install script or a third-party package source. Package managers such as `apt`, `pip`, `npm`, and `dotnet` reach their default registries from the sandbox; downloads from other hosts can be blocked at the sandbox's [egress boundary](/docs/claude-tag/concepts/security-and-data#network-egress). An Owner can allow an additional host on the bundle's Domains tab; see [Allow a host without a credential](/docs/claude-tag/admins/add-connections#allow-a-host-without-a-credential).
## What Claude can do with GitHub Actions
In a channel, Claude acts on GitHub as the Claude GitHub App, and that identity carries a fixed set of GitHub Actions permissions. No admin setting changes it, and adding `api.github.com` as a [custom connection](/docs/claude-tag/admins/connections/custom) with your own token doesn't change it either; Claude's GitHub requests always act as the Claude GitHub App.
Claude can:
* Read workflow runs, jobs, logs, and artifacts, so it follows a pull request's CI and reports the result
* Re-run a workflow run or its failed jobs, and cancel a run in progress
* Trigger `push` and `pull_request` workflows by pushing a branch or opening a pull request, the same way any other author does. To let Claude start automation on demand, put the workflow behind one of these triggers instead of `workflow_dispatch`
* Edit files under `.github/workflows/` and open a pull request with the change, like any other file
Claude can't:
* Dispatch a workflow (`workflow_dispatch` or `repository_dispatch`)
* Approve a workflow run that's waiting on approval, or its pending deployments
* Delete runs, logs, or artifacts
* Enable or disable a workflow
A request for any of those is refused with a `403`. A `repository_dispatch` request returns "repository\_dispatch is not permitted for this session type." The others return "GitHub Actions writes are not permitted for this session type." Dispatching a workflow or approving a held run starts new code running with the repository's Actions secrets, so it needs a person; do it from the repository's **Actions** tab on github.com.
## Scheduled work uses the same connection
Scheduled jobs use the same GitHub connection as interactive work, with nothing extra to configure. A recurring job that can't reach its repository skips that run and retries on its next schedule; after three consecutive failed runs spanning at least an hour, it disables itself. A one-time job that can't reach its repository is disabled on the first failure; the routine's page shows why.
## GitHub Enterprise
### GitHub Enterprise Cloud with data residency
Organizations on `*.ghe.com` (Enterprise Cloud with Data Residency) are registered the same way as a GitHub Enterprise Server host below.
### GitHub Enterprise Server
GitHub Enterprise Server instances are supported when reachable from the public internet. A GHES host on a private network without a public address can't be connected.
On GHES, you create the GitHub App on your own instance instead of installing Anthropic's. The setup is shared with Claude Code; follow the [Claude Code GitHub Enterprise Server guide](https://code.claude.com/docs/en/github-enterprise-server) to create and register the app. After registering the GHE host, a host picker appears on the bundle's **Repositories** tab; select your host there to grant its repositories.
Registering a GHE host with your Claude organization isn't fully self-serve. Raise it with your account team if the guide doesn't get you all the way through.
## Related resources
* [Configure per-channel access](/docs/claude-tag/admins/attach-to-scope): bind the bundle to the workspaces and channels that need it
* [Set up routines](/docs/claude-tag/users/proactivity): the scheduled jobs that use this connection
claude-tag/admins/configure-gitlab First recorded · 76 lines, first recorded
# Configure GitLab access ## Prerequisites ## Create a dedicated GitLab account for Claude ## Grant the account access to your groups and projects ## Generate a personal access token ## Add the token to an Access bundle ## Self-managed GitLab ## Verify GitLab access ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Configure GitLab access
> Give Claude its own GitLab identity so it can read projects, manage issues, review merge requests, and check pipelines as a service account. Covers creating the account, scoping its access, generating a token, and adding it to a bundle.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Connecting GitLab lets Claude read repository contents, manage issues, review and comment on merge requests, and check pipeline status from any channel under a bundle's scope, all through the GitLab API. Unlike GitHub, there is no Claude app to install in GitLab. Instead, you give Claude its own GitLab user and add that user's personal access token to an Access bundle.
A dedicated service account keeps Claude's GitLab activity attributed to a single identity you control. You decide which groups and projects it can reach by granting that account membership the same way you would for a person, and you can revoke or rescope it at any time without touching anyone else's access.
## Prerequisites
* The **Owner** role in your Claude organization to create an Access bundle; an Admin can add credentials to a bundle that already exists.
* Permission in GitLab to create a user (or a [service account](https://docs.gitlab.com/user/profile/service_accounts/) on tiers that offer it) and to add that user to the groups or projects Claude should reach.
* An [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle) to hold the credential. Create one first if you haven't already.
## Create a dedicated GitLab account for Claude
Create a GitLab user that exists only for Claude, for example `[email protected]`. On GitLab Premium or Ultimate, a [service account](https://docs.gitlab.com/user/profile/service_accounts/) is the cleanest fit because it is clearly non-human. On other tiers, a regular user works the same way; treat it as a bot seat.
Set the account's display name and avatar to whatever you want teammates to see on Claude's comments and issue activity.
## Grant the account access to your groups and projects
Add the service account as a member of each GitLab group or project Claude should work in. Granting at the group level is usually simpler than adding it to projects one at a time, and it means new projects in that group are reachable without another grant.
The role you grant determines which API calls succeed. Grant the lowest role that covers what you want Claude to do: reading code and browsing issues and merge requests needs less than creating issues, posting review comments, or acting on pipelines. See GitLab's [permissions reference](https://docs.gitlab.com/user/permissions/) for what each role allows.
## Generate a personal access token
Create a [personal access token](https://docs.gitlab.com/user/profile/personal_access_tokens/) for the account. For a GitLab.com service account, create the token from the group's service account settings or through the API; for a regular bot user, sign in as it and create the token from its profile. The token starts with `glpat-`.
| Scope | When to grant it |
| :--------- | :------------------------------------------------------------------------------------------------------ |
| `api` | Read and write. Required for Claude to create and update issues, post comments, and act on pipelines. |
| `read_api` | Read-only. Use this instead of `api` if you want Claude to browse and answer questions but never write. |
Set an expiry that matches your rotation policy, and store the token somewhere you can retrieve it once; GitLab shows it only at creation.
<Note>Group access tokens and project access tokens also work in the same field. The service-account approach is recommended because one token covers every group you add the account to, and the identity on comments and issues is yours to name. A group or project token is scoped to that single group or project and appears under a GitLab-generated bot name.</Note>
## Add the token to an Access bundle
<Steps>
<Step title="Open the bundle's Credentials tab">
At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles**, click into the bundle, and go to **Credentials**.
</Step>
<Step title="Connect GitLab">
Click **Connect** next to **GitLab** and paste the token into **Personal access token**.
</Step>
<Step title="Attach the GitLab plugin">
If your organization's plugin marketplace includes a GitLab plugin, add it on the bundle's **Plugins** tab so Claude knows how to call the GitLab API. See [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). The connection works without the plugin, which adds ready-made workflows.
</Step>
</Steps>
The token is held by [Agent Proxy](/docs/claude-tag/concepts/agent-identity#agent-proxy) and injected on every API request to your GitLab host. The model and the session sandbox never see it.
## Self-managed GitLab
Self-managed GitLab instances are supported when reachable from the public internet. In the **Connect GitLab** form, open the **Advanced** tab and add your instance's hostname under **Allowed websites**; `gitlab.com` is preset for GitLab SaaS. An instance on a private network without a public address can't be connected.
## Verify GitLab access
* GitLab is listed under the bundle's **Credentials** tab.
* In a channel under the bundle's scope, `@Claude what can you access from this channel?` returns GitLab.
* In that same channel, ask Claude to list the open issues in one of your GitLab projects. Claude returns them without prompting for credentials.
## Related resources
* [Connect GitLab](/docs/claude-tag/admins/connections/gitlab): the credential field reference and how GitLab differs from GitHub
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential and bundle reference
* [Configure GitHub access](/docs/claude-tag/admins/configure-github): the GitHub App path, which is different
claude-tag/admins/connections/asana First recorded · 45 lines, first recorded
# Connect Asana ## Create the credential in Asana ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Asana
> Connect Asana to Claude Tag so it can file tasks and read project status. Covers the dedicated account to create, the token fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Asana lets Claude file tasks and pull project status from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the Asana plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in Asana
On every Asana plan, create the personal access token from a dedicated Asana seat for Claude, and give that seat access to only the projects and teams Claude needs. Per Asana's guidance, avoid service account tokens, which carry organization-wide access.
Asana's own guide for creating the credential is at [developers.asana.com](https://developers.asana.com/docs/personal-access-token).
## Add the connection to a bundle
In the bundle, click **Connect** next to **Asana**.
| Field | Value |
| :----------------------------- | :----------------------------------- |
| Claude's personal access token | The personal access token from Asana |
| Allowed websites | `app.asana.com` |
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Asana appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/track-projects): the issue tracking use cases
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/atlassian First recorded · 44 lines, first recorded
# Connect Jira and Confluence ## Create the credential in Atlassian ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Jira and Confluence
> Connect Atlassian Cloud to Claude Tag so it can read and update Jira issues and search Confluence pages.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Atlassian Cloud lets Claude read and search Confluence pages and read, comment on, and update Jira issues from any channel under the bundle's scope. One credential covers both products on the same Atlassian site.
This is an HTTP API connection, not an MCP server or a personal claude.ai connector. Pair it with a plugin that covers Jira and Confluence so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins).
## Create the credential in Atlassian
Create a dedicated Atlassian account for Claude (for example `[email protected]`) and add it to the Jira projects and Confluence spaces it should reach. The connection can read whatever this account can read, so a dedicated account keeps Claude's reach to exactly what you grant it.
Sign in as that account and create an API token at [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens). Atlassian shows the token once; store it somewhere you can retrieve it. Atlassian API tokens expire, with a maximum lifetime of one year, so plan to create a new token and update the connection before the old one lapses.
## Add the connection to a bundle
On the bundle's **Credentials** tab, click **Connect** next to **Jira & Confluence**.
The form asks for the dedicated account's email address and the API token from Atlassian. In the host field, replace the prefilled `*.atlassian.net` with your own site's hostname, such as `your-domain.atlassian.net`. The form rejects the wildcard because it would let the credential reach any Atlassian site, not just yours.
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
<Note>Atlassian Data Center (self-hosted) isn't covered by the preset because it authenticates with a personal access token sent as a Bearer header. Add a Data Center instance as a [custom connection](/docs/claude-tag/admins/connections/custom) with the **Bearer** credential type and your instance's hostname under **Allowed websites**. The instance must be reachable from the public internet.</Note>
## Verify the connection
In a channel under the bundle's scope, in a new thread, ask Claude to fetch one issue or page by key or URL. The call lands under the dedicated account in Atlassian's audit log.
```text wrap theme={null}
@Claude can you read PROJ-123 from Jira?
```
New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [Custom connection](/docs/claude-tag/admins/connections/custom): for a setup the preset doesn't cover, such as a self-hosted Data Center instance
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full connection model and how to scope a dedicated account
claude-tag/admins/connections/bigquery First recorded · 60 lines, first recorded
# Connect BigQuery ## Create the credential in Google Cloud ## Grant access to specific datasets ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect BigQuery
> Connect BigQuery to Claude Tag so it can run read-only queries on your datasets. BigQuery has no preset, so it is added as a custom credential with a GCP service-account key.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting BigQuery lets Claude run queries against your datasets from any channel under the bundle's scope. Add it as a custom credential with **Custom tool**; BigQuery has no preset button in the picker.
This is an HTTP API connection, not a personal claude.ai connector. Pair it with a plugin that covers BigQuery so Claude knows how to form and run queries; without one, Claude can reach the API but has to work out the request shape on its own. See [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins).
## Create the credential in Google Cloud
Create a dedicated service account for the agent in the Google Cloud project that holds your BigQuery data, then create a JSON key for it. Google's guides cover [creating a service account](https://cloud.google.com/iam/docs/service-accounts-create) and [creating a service account key](https://cloud.google.com/iam/docs/keys-create-delete).
## Grant access to specific datasets
You scope what Claude can read on the Google Cloud side, through the service account's role grants. The connection itself has no dataset setting. Grant the service account two roles:
* **BigQuery Data Viewer** (`roles/bigquery.dataViewer`) on each dataset Claude should query. Grant it on the specific datasets, not on the project, so Claude can read only those datasets.
* **BigQuery Job User** (`roles/bigquery.jobUser`) on the project, so the service account can run query jobs.
Together the two grants let Claude run read-only queries against those datasets. To widen or narrow access later, edit the dataset grants in Google Cloud; the connection needs no change.
## Add the connection to a bundle
In the bundle, click **Connect** next to **Custom tool** and choose **GCP access token (with Service Account Key)**.
| Field | Value |
| :----------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Credential type | **GCP access token (with Service Account Key)** |
| GCP service account key (JSON) | The JSON key file from Google Cloud Console |
| Scopes (optional) | `https://www.googleapis.com/auth/bigquery`. The field is labeled optional, but leave it empty and the token defaults to a broader scope. BigQuery's query endpoints don't accept a read-only scope; the dataset roles in the section above are what keep the connection read-only. |
| Allowed websites | `bigquery.googleapis.com` |
Agent Proxy exchanges the service-account key for an access token and injects it at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
BigQuery appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
Then confirm a query runs against a dataset you granted:
```text wrap theme={null}
@Claude how many rows are in <dataset>.<table>?
```
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/answer-data-questions): warehouse questions answered with charts in the thread
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/custom First recorded · 118 lines, first recorded
# Connect a service that isn't in the list ## Add a custom HTTP API ### What you need from the service ### Fill out the Custom tool form ### Credential types ### AWS SigV4 #### When AWS returns `SignatureDoesNotMatch` ### OAuth 2.0 JWT bearer #### When saving fails with "Failed to create egress credential" ## Add a custom MCP server ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect a service that isn't in the list
> Connect a tool that has no built-in preset to Claude Tag. Covers credential types, what each form field means, and how to add a custom MCP server.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
For a service that doesn't have a preset Connect button, use **Custom tool** on the bundle's Credentials tab. This works for any service with an HTTP API. The [BigQuery](/docs/claude-tag/admins/connections/bigquery) guide is a worked example.
## Add a custom HTTP API
### What you need from the service
* A service-account credential (an API key, token, or OAuth client) — not your personal login
* The API host (for example `api.example.com`)
* How the API authenticates (which header or flow it expects)
See [Create a dedicated account per service](/docs/claude-tag/admins/add-connections#create-a-dedicated-account-per-service) for the service-account patterns.
### Fill out the Custom tool form
| Field | What to enter |
| :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | A label for this connection (for example "Internal billing API") |
| **Credential type** | Pick the type that matches how the API authenticates; see [Credential types](#credential-types) |
| **Allowed websites** | The API's host (for example `api.example.com`). A wildcard is allowed as the leftmost label. You can't enter `*` alone here; a credential is always limited to specific hosts (see [Allow all hosts](/docs/claude-tag/admins/add-connections#allow-all-hosts)). The credential is sent only to hosts you list here. |
| **Path prefixes** (optional) | Restrict the credential to specific URL paths under the host. Shown only for the OAuth 2.0 authorization code type. |
| **Custom headers** | Any extra headers the API requires beyond the credential. Shown only for the Bearer credential type. |
### Credential types
| Type | Use for |
| :---------------------------------------------- | :---------------------------------------------------------------------------------------------------------- |
| **Bearer** | An API key or token sent as `Authorization: Bearer <token>`. Most SaaS REST APIs. |
| **Basic** | HTTP Basic authentication (`Authorization: Basic <base64(user:password)>`) |
| **Body parameter** | A token the API expects in the request body or query string instead of a header |
| **AWS SigV4** | AWS services and APIs that require Signature Version 4 signing |
| **GCP access token (with Service Account Key)** | Google Cloud APIs; the proxy exchanges the SA key for an access token |
| **GCP IAP (with Service Account Key)** | Google Cloud services behind Identity-Aware Proxy |
| **OAuth 2.0 JWT bearer** | APIs that accept a JWT signed with your private key in exchange for an access token (DocuSign, for example) |
| **OAuth 2.0 client credentials** | Machine-to-machine OAuth with a client ID and secret |
| **OAuth 2.0 authorization code (3-legged)** | OAuth with a user-consent step; the connection stores the resulting refresh token |
| **GitHub App** | GitHub repositories; covered separately at [Configure GitHub access](/docs/claude-tag/admins/configure-github) |
If you're unsure which type, check the service's API authentication docs for which header or flow it expects.
### AWS SigV4
Use the **AWS SigV4** credential type for AWS service APIs (S3, Lambda, Amazon Bedrock, an API Gateway endpoint with IAM authorization). Agent Proxy reads the AWS service and signing region from the hostname and signs each outbound request with the credential at the boundary, so neither the model nor the sandbox holds the keys. The host must be an `amazonaws.com` endpoint; the proxy can't sign requests to an API Gateway custom domain or to a non-AWS API that uses Signature Version 4.
| Field | Value |
| :---------------- | :---------------------------------------------------------------------------------------------------------------------- |
| Access key ID | The IAM user or role access key, for example `AKIAIOSFODNN7EXAMPLE` |
| Secret access key | The matching secret access key |
| Session token | Optional. Only needed for temporary credentials from AWS STS. |
| Allowed websites | The AWS service endpoint host, for example `s3.us-east-1.amazonaws.com` or `abc123.execute-api.us-east-1.amazonaws.com` |
Use long-lived credentials from a dedicated IAM user where you can. Temporary STS credentials work but expire on their own schedule, and the connection stops working when they do; you re-enter all three values to rotate.
Claude can call the endpoint with `curl`, an AWS SDK, or the AWS CLI. The sandbox holds no real AWS credentials, so a CLI or SDK signs the request with placeholder values; Agent Proxy strips that signature and re-signs with the stored credential before the request leaves for AWS. The one shape it can't re-sign is chunked payload signing. If Claude reports that chunked signing isn't supported through the proxy, have it set `payload_signing_enabled = false` in `~/.aws/config` and retry.
#### When AWS returns `SignatureDoesNotMatch`
A `SignatureDoesNotMatch` response from AWS means the request AWS received doesn't match the one Agent Proxy signed.
| Check | What to do |
| :---------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The access key ID and secret access key belong to the same IAM identity | Re-enter the access key ID, secret access key, and session token together. The form is write-only, so a partial update can leave them mismatched. |
| No proxy or gateway of your own sits between Anthropic and AWS | A second proxy that adds, strips, or reorders headers, or that re-signs the request, invalidates the signature Agent Proxy attached. Point **Allowed websites** at the AWS endpoint directly. |
A dropped or expired session token is a different failure: AWS rejects it with a token error such as `InvalidClientTokenId`, not `SignatureDoesNotMatch`. Rotate all three fields.
### OAuth 2.0 JWT bearer
Use the **OAuth 2.0 JWT bearer** credential type for APIs that exchange a JWT signed with your private key for an access token. The [Salesforce guide](/docs/claude-tag/admins/connections/salesforce) is a worked example.
The **Private key (PEM)** field takes a PEM-encoded RSA private key without a passphrase, the format that begins with `-----BEGIN PRIVATE KEY-----` or `-----BEGIN RSA PRIVATE KEY-----`. Identity providers such as Okta export the key as a JWK (a JSON object) by default; convert a JWK to PEM before pasting it. The form doesn't check the key's format, so a key in the wrong format fails only when you save.
#### When saving fails with "Failed to create egress credential"
Saving the form can return the error "Failed to create egress credential. Check your inputs and try again." The most likely cause is a private key that isn't PEM-encoded, for example a JWK pasted as-is into the **Private key (PEM)** field. Convert the key to PEM and save again.
Saving also fails when a PEM-encoded key isn't an RSA key or has a passphrase. Once the key is in the right format, re-check each field against the values from your service.
## Add a custom MCP server
To give Claude an MCP server (one you run, or a vendor's hosted MCP endpoint), the pattern is a plugin plus a credential:
<Steps>
<Step title="Add a plugin that declares the MCP server">
In the bundle's **Plugins** tab (or via your [skills repository](/docs/claude-tag/admins/skills-repo)), add a plugin whose `.mcp.json` points at the server URL. The plugin tells Claude the server exists and how to call it.
</Step>
<Step title="Add a credential for the server's host">
On the **Credentials** tab, click **Connect** next to **Custom tool** and add a credential for the MCP server's host (for example, a Bearer token with **Allowed websites** set to `your-mcp-host.example.com`). This lets the call leave the sandbox with auth attached.
</Step>
</Steps>
The plugin's `.mcp.json` is loaded because it's part of an attached plugin; an `.mcp.json` checked into a repository Claude clones is not loaded.
## Verify the connection
In a channel under the bundle's scope, in a new thread, ask Claude to make a small read against the API:
```text wrap theme={null}
@Claude can you reach api.example.com? Try a GET on /health.
```
Check the service's own audit log to confirm the call landed under your service account. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full connection model
* [Allow a host without a credential](/docs/claude-tag/admins/add-connections#allow-a-host-without-a-credential): for public APIs that need no auth
* [Allow all hosts](/docs/claude-tag/admins/add-connections#allow-all-hosts): the egress option that lets Claude reach any public host without a credential
claude-tag/admins/connections/datadog First recorded · 56 lines, first recorded
# Connect Datadog ## Create the credential in Datadog ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Datadog
> Connect Datadog to Claude Tag so it can query metrics, logs, and monitors. Covers the dedicated account to create, the API key fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Datadog lets Claude query metrics, logs, and monitors during debugging from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the Datadog plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in Datadog
Create an API key under a service account in Datadog. Also create an Application key under the same service account. The Application key carries the read scopes, so restrict it to read-only roles. The form doesn't require the Application key, but reading metrics, monitors, and dashboards does.
Datadog's own guide for creating the credential is at [docs.datadoghq.com](https://docs.datadoghq.com/account_management/api-app-keys/).
## Add the connection to a bundle
In the bundle, click **Connect** next to Datadog. The picker has three Datadog entries, one per site. Pick the one that matches your Datadog account's site.
| Picker entry | Site |
| :---------------- | :------------------------------------------ |
| **Datadog** | US1 (`api.datadoghq.com`), the default site |
| **Datadog (US5)** | US5 (`api.us5.datadoghq.com`) |
| **Datadog (EU)** | EU (`api.datadoghq.eu`) |
The form asks for the same fields in all three.
| Field | Value |
| :----------------------- | :------------------------------------------------------------------------------------------------------------------ |
| Claude's API key | The API key from Datadog |
| Claude's application key | The Application key from Datadog. Optional in the form; add it so Claude can read metrics, monitors, and dashboards |
| Allowed websites | Prefilled by the preset; override for other sites (see below) |
Datadog has a separate API host per site, and a key only works against its own. If your account is on a site without a picker entry, pick any Datadog entry and override Allowed websites with your site's API host: `api.us3.datadoghq.com`, `api.ap1.datadoghq.com`, or `api.ddog-gov.com`. To change the host later, open the **⋮** menu on this connection in the bundle's Credentials tab and choose **Edit**.
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Datadog appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/watch-monitors): the monitoring use cases
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/gitlab First recorded · 52 lines, first recorded
# Connect GitLab ## Add the connection ## How GitLab differs from GitHub ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect GitLab
> Connect GitLab to Claude Tag so it can read code, manage issues, comment on merge requests, and check pipelines through the GitLab API. Covers token permissions, self-managed hostnames, and how it differs from GitHub.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting GitLab lets Claude read and search projects, manage issues, comment on merge requests, and check pipeline status, all through the GitLab REST API. The connection is a single access token added to a bundle.
<Tip>This page is the credential field reference. The full setup walkthrough, including creating a dedicated GitLab service account for Claude and scoping its group access, is at [Configure GitLab access](/docs/claude-tag/admins/configure-gitlab).</Tip>
If your plugin marketplace includes a GitLab plugin, pair it with this connection so Claude knows how to call the API. See [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). The connection works without it.
## Add the connection
<Steps>
<Step title="Create the token in GitLab">
A personal access token from a [dedicated service account](/docs/claude-tag/admins/configure-gitlab#create-a-dedicated-gitlab-account-for-claude) is recommended, so one identity covers every group you add it to. Project and group access tokens also work if you only need a single project or group. Grant the `api` scope for read and write, or `read_api` for read-only. The token starts with `glpat-`.
</Step>
<Step title="Add the credential to a bundle">
On the bundle's **Credentials** tab, click **Connect** next to **GitLab** and paste the token. For self-managed GitLab, switch to the form's **Advanced** tab and add your instance's hostname under **Allowed websites**.
</Step>
</Steps>
**You'll see:** GitLab listed in the bundle's connections, and `@Claude what can you access from this channel?` returns it in a new thread under the bundle's scope. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
| Field | Value |
| :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Personal access token | The token from GitLab, starting with `glpat-`. Project and group access tokens work here too; the label is the field name, not a token-type constraint. |
| Allowed websites | `gitlab.com` (preset). For self-managed GitLab, open the **Advanced** tab and add your instance's hostname here. |
GitLab's own guide for creating tokens is at [docs.gitlab.com](https://docs.gitlab.com/api/rest/authentication/).
## How GitLab differs from GitHub
| | GitLab | GitHub |
| :-------------------------------- | :------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------- |
| Auth | A service account's personal access token | The Claude GitHub App, [installed separately](/docs/claude-tag/admins/configure-github) |
| Referencing a project in a thread | Give Claude the full project URL; it reads it through the API | Typing `owner/repo` in the message auto-attaches it |
| Self-managed | Your hostname under **Advanced → Allowed websites** | [GitHub Enterprise setup](/docs/claude-tag/admins/configure-github#github-enterprise) |
| Handing back changes | Manages issues and comments on merge requests through the API | [Draft pull requests](/docs/claude-tag/users/use-cases/work-with-github) authored by the Claude GitHub App |
The token is auto-injected on every API request to your GitLab host. The model and the sandbox are not given the key; see [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Related resources
* [Configure GitHub access](/docs/claude-tag/admins/configure-github): the GitHub App path, which is different
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/gong First recorded · 50 lines, first recorded
# Connect Gong ## Create the credential in Gong ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Gong
> Connect Gong to Claude Tag so it can pull call summaries and deal context. Covers the dedicated account to create, the token fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Gong lets Claude pull call summaries and deal context from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the Gong plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in Gong
A Gong technical admin generates the access key and secret; the key is tied to the admin who created it, so use a dedicated admin account where possible.
The credential type is HTTP Basic; both the access key and the access key secret are required.
Gong's own guide for creating the credential is at [help.gong.io](https://help.gong.io/docs/receive-access-to-the-api).
## Add the connection to a bundle
In the bundle, click **Connect** next to **Gong**.
| Field | Value |
| :------------------------- | :------------------------------ |
| Claude's access key | The access key from Gong |
| Claude's access key secret | The access key secret from Gong |
| Allowed websites | `api.gong.io` (preset) |
Gong assigns each company its own API base URL, like `us-46459.api.gong.io`. Copy yours from **Company Settings** → **Ecosystem** → **API** in Gong, then switch to the connection form's **Advanced** tab and enter it under **Allowed websites**.
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Gong appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/pull-deal-state): the go-to-market use cases
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/google First recorded · 76 lines, first recorded
# Connect Google Drive, Calendar, and Gmail ## Choose OAuth or a service account ## Add the connection with OAuth ## Add the connection with a service account ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Google Drive, Calendar, and Gmail
> Connect Google Drive, Calendar, and Gmail to Claude Tag so it can read docs, sheets, events, and email. Covers OAuth setup, the service-account option, and what each grants.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Google Drive, Calendar, and Gmail lets Claude read documents, spreadsheets, calendar events, and email from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
This is an HTTP API connection, not a personal claude.ai connector. A member's own Google connector applies only in DMs.
## Choose OAuth or a service account
The connection picker offers two routes:
| Route | When to use |
| :-------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- |
| **OAuth (Connect button)** | Fastest path. An admin signs in with a Google account that has access to the content Claude needs. |
| **GCP service-account key** | When you want a dedicated non-human identity in Google with auditable access, or need domain-wide delegation across your Workspace. |
Both routes create a credential and an allowed-websites rule path-scoped to that Google service (the Drive API path for Drive, the Calendar API path for Calendar, the Gmail API path for Gmail).
## Add the connection with OAuth
<Warning>Use a dedicated Google account for this connection (for example, `[email protected]`), not your own. The connection is shared: anyone in a channel under the bundle's scope can ask Claude to read whatever this account can see in Drive, Calendar, and Gmail. A dedicated account starts with no access until you share the specific folders and calendars Claude needs, and keeps its activity under a separate identity in Google's audit log.</Warning>
In the bundle, click **Connect** next to **Google Drive**, **Google Calendar**, or **Google Gmail**. A scope checklist appears with read-only scopes selected by default. Each scope grants a specific permission:
| Scope | What it lets Claude do |
| :------------------------- | :--------------------------------------------------- |
| `openid`, `userinfo.email` | Identify the connected account (selected by default) |
| `calendar.readonly` | Read events and calendars |
| `calendar.events.readonly` | Read events only (narrower than `calendar.readonly`) |
| `calendar` | Create, edit, and delete events |
| `drive.readonly` | Read files and folders |
| `drive.file` | Create and edit files Claude itself created |
| `gmail.readonly` | Read email |
Check write scopes only if Claude should create or edit. Click **Sign in with Google Calendar** (or **Sign in with Google Drive**, or **Sign in with Google Gmail**), approve the Google consent screen, and the credential is saved.
The connection's reach is whatever the signed-in Google account can see. Share the relevant folders and calendars with that account in Google before testing.
## Add the connection with a service account
In the bundle, click **Connect** next to **Custom tool** and choose **GCP access token (with Service Account Key)**.
| Field | Value |
| :----------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| GCP service account key (JSON) | The JSON key file from Google Cloud Console |
| Scopes (optional) | The Google API scopes to request (for example `https://www.googleapis.com/auth/drive.readonly`). The field is labeled optional, but Drive and Calendar calls fail without the matching scope listed here. |
| Subject (optional) | A user email to impersonate via domain-wide delegation. Set this for Workspace data (Drive, Calendar, Gmail, Docs). |
| Allowed websites | `*.googleapis.com` |
For Google Workspace data (Drive, Calendar, Gmail, Docs), the service account needs domain-wide delegation configured in your Google Admin console with the matching API scopes. Google's guide is at [developers.google.com/identity/protocols/oauth2/service-account](https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority).
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Google Drive, Calendar, or Gmail appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
The credential row in the bundle shows **Never used** until Claude first uses the connection. The label tracks usage, not health, so a working connection stays on **Never used** until someone exercises it. To confirm the connection works, ask Claude in the same thread to read something from the service, such as today's calendar events or a named document. The label updates after that first read.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/find-answers): grounding answers in your team's documents
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/hubspot First recorded · 45 lines, first recorded
# Connect HubSpot ## Create the credential in HubSpot ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect HubSpot
> Connect HubSpot to Claude Tag so it can read pipeline, deal, and contact data. Covers the dedicated account to create, the token fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting HubSpot lets Claude pull pipeline, deal, and contact state from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the HubSpot plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in HubSpot
Create a private app and select the read scopes you need (typically `crm.objects.contacts.read`, `crm.objects.companies.read`, `crm.objects.deals.read`). The private app acts as its own identity in HubSpot's audit log.
HubSpot's own guide for creating the credential is at [developers.hubspot.com](https://developers.hubspot.com/docs/apps/legacy-apps/private-apps/overview).
## Add the connection to a bundle
In the bundle, click **Connect** next to **HubSpot**.
| Field | Value |
| :------------------------- | :---------------------------------------------------------------------------- |
| Claude's private app token | The private app token from HubSpot |
| Allowed websites | `api.hubapi.com` (preset). To add a different host, use the **Advanced** tab. |
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
HubSpot appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/pull-deal-state): the go-to-market use cases
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/linear First recorded · 47 lines, first recorded
# Connect Linear ## Create the credential in Linear ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Linear
> Connect Linear to Claude Tag so it can file tickets and post status updates. Covers the dedicated account to create, the token fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Linear lets Claude file tickets and post status updates from a thread from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the Linear plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in Linear
Create a personal API key from a dedicated Linear seat for Claude, not your own account, so its activity shows under that seat in Linear's audit log.
Scope the key to specific Linear teams when you create it; the only place to limit which projects Claude can write to is in Linear itself. The key starts with `lin_api_`.
Linear's own guide for creating the credential is at [linear.app](https://linear.app/developers/graphql#personal-api-keys).
## Add the connection to a bundle
In the bundle, click **Connect** next to **Linear**.
| Field | Value |
| :--------------- | :---------------------- |
| Claude's API key | The API key from Linear |
| Allowed websites | `api.linear.app` |
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Linear appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/create-artifacts): the issue tracking use cases
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/notion First recorded · 45 lines, first recorded
# Connect Notion ## Create the credential in Notion ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Notion
> Connect Notion to Claude Tag so it can read and search your Notion workspace. Covers the dedicated account to create, the token fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Notion lets Claude ground answers in your Notion workspace from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the Notion plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in Notion
Create an internal integration in Notion and share the specific pages or databases Claude should read with that integration. Nothing is reachable until shared.
Notion's own guide for creating the credential is at [developers.notion.com](https://developers.notion.com/docs/create-a-notion-integration).
## Add the connection to a bundle
In the bundle, click **Connect** next to **Notion**.
| Field | Value |
| :-------------------------- | :------------------------------------------ |
| Claude's integration secret | The internal integration secret from Notion |
| Allowed websites | `api.notion.com` |
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Notion appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/find-answers): the knowledge and docs use cases
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/overview First recorded · 45 lines, first recorded
# Per-service connection guides ## When a connection fails after setup
The first capture of this source. The page was already there, and this is what it said.
# Per-service connection guides > Step-by-step setup for each tool Claude Tag can connect to. Each guide covers the dedicated account to create, the credential to enter, and the URL to allow. export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>; <BetaNote /> Each guide covers one service: how to create the credential as a dedicated identity, what to paste into the Access bundle, and the Allowed websites value. For the model behind connections (credential types, Agent Proxy, allowed websites), see [Give Claude access](/docs/claude-tag/admins/add-connections). <Warning>Always connect a dedicated account for Claude (for example, `[email protected]`), not your personal login. Anyone in a channel under the bundle's [scope](/docs/claude-tag/admins/attach-to-scope) can use the connection through Claude, so whatever this account can reach is available to every member of those channels. See [Create a dedicated account per service](/docs/claude-tag/admins/add-connections#create-a-dedicated-account-per-service).</Warning> | Service | Category | Guide | | :------------------------------ | :----------------- | :---------------------------------------------------------------------- | | Datadog | Monitoring | [Connect Datadog](/docs/claude-tag/admins/connections/datadog) | | Sentry | Monitoring | [Connect Sentry](/docs/claude-tag/admins/connections/sentry) | | PagerDuty | Monitoring | [Connect PagerDuty](/docs/claude-tag/admins/connections/pagerduty) | | Linear | Issue tracking | [Connect Linear](/docs/claude-tag/admins/connections/linear) | | Asana | Issue tracking | [Connect Asana](/docs/claude-tag/admins/connections/asana) | | Jira and Confluence | Issue tracking | [Connect Jira and Confluence](/docs/claude-tag/admins/connections/atlassian) | | Notion | Knowledge and docs | [Connect Notion](/docs/claude-tag/admins/connections/notion) | | Google (Drive, Calendar, Gmail) | Knowledge and docs | [Connect Google](/docs/claude-tag/admins/connections/google) | | HubSpot | Go-to-market | [Connect HubSpot](/docs/claude-tag/admins/connections/hubspot) | | Salesforce | Go-to-market | [Connect Salesforce](/docs/claude-tag/admins/connections/salesforce) | | Gong | Go-to-market | [Connect Gong](/docs/claude-tag/admins/connections/gong) | | GitLab | Code | [Connect GitLab](/docs/claude-tag/admins/connections/gitlab) | | BigQuery (custom) | Data warehouse | [Connect BigQuery](/docs/claude-tag/admins/connections/bigquery) | | Snowflake | Data warehouse | [Connect Snowflake](/docs/claude-tag/admins/connections/snowflake) | | Stripe | Billing | [Connect Stripe](/docs/claude-tag/admins/connections/stripe) | | Vercel | Deployments | [Connect Vercel](/docs/claude-tag/admins/connections/vercel) | GitHub is managed through the Claude GitHub App rather than a connection in this list; see [Configure GitHub access](/docs/claude-tag/admins/configure-github). Services marked (custom) have no preset button. Add them with **Custom tool** following their guide. The presets and guides cover common services, not the full set Claude can connect to. Any app with an API can be added as a custom connection or a custom MCP server. See [Connect a custom service](/docs/claude-tag/admins/connections/custom) for the credential types and form fields. ## When a connection fails after setup If Claude says it can't reach a service you connected, start with the checks at the top of [Troubleshoot Claude Tag setup](/docs/claude-tag/admins/troubleshooting). Confirm the connection is in a bundle [attached to the channel's scope](/docs/claude-tag/admins/attach-to-scope), and rerun the test in a new thread, since a session loads its connections when it starts. Two entries on the troubleshooting page cover connection failures directly: * [A connection works in one channel but not another](/docs/claude-tag/admins/troubleshooting#a-connection-works-in-one-channel-but-not-another): bundles attach per scope, so the failing channel's scope is likely missing the bundle * [I hit an authentication error and couldn't finish this turn](/docs/claude-tag/admins/troubleshooting#i-hit-an-authentication-error-and-couldn%E2%80%99t-finish-this-turn): Claude posts that message when its own request fails an authentication check. A connected service's failing credential surfaces as a tool error inside Claude's reply instead
claude-tag/admins/connections/pagerduty First recorded · 49 lines, first recorded
# Connect PagerDuty ## Create the credential in PagerDuty ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect PagerDuty
> Connect PagerDuty to Claude Tag so it can read incidents and on-call schedules. Covers the dedicated account to create, the token fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting PagerDuty lets Claude read incidents and on-call schedules during incident work from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the PagerDuty plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in PagerDuty
Generate a general-access read-only API key. A read-write key lets Claude acknowledge and resolve incidents; grant that only on a private incident-channel scope.
Creating a general-access key requires the PagerDuty Admin or Account Owner role; non-admins only see User Token keys, which also work but inherit that user's permissions.
PagerDuty's own guide for creating the credential is at [support.pagerduty.com](https://support.pagerduty.com/main/docs/api-access-keys#generate-a-general-access-rest-api-key).
## Add the connection to a bundle
In the bundle, click **Connect** next to **PagerDuty**.
| Field | Value |
| :--------------- | :------------------------- |
| Claude's API key | The api key from PagerDuty |
| Allowed websites | `api.pagerduty.com` |
PagerDuty accounts on the EU service region use `api.eu.pagerduty.com` instead.
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
PagerDuty appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/watch-monitors): the monitoring use cases
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/salesforce First recorded · 53 lines, first recorded
# Connect Salesforce ## Create the credential in Salesforce ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Salesforce
> Connect Salesforce to Claude Tag so it can read and update CRM records. Covers the connected app to create, the client credential fields, and the host to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Salesforce lets Claude read accounts, contacts, opportunities, and cases (and write, if you grant it) from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person. The connection uses the OAuth 2.0 client credentials flow.
## Create the credential in Salesforce
Create a connected app (or External Client App) with the client credentials flow enabled, and set a dedicated integration user as the app's run-as user. Salesforce's guide is [Configure a Connected App for the OAuth 2.0 Client Credentials Flow](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_client_credentials_flow.htm\&type=5).
You'll need from Salesforce:
* The app's **Consumer Key** (the client ID), from its **Settings** tab
* The app's **Consumer Secret** (the client secret)
* Your org's My Domain host (for example `yourcompany.my.salesforce.com`)
Assign the integration user a Permission Set scoped to the objects and fields Claude should reach. Read-only is the recommended starting point.
## Add the connection to a bundle
In the bundle, click **Connect** next to **Salesforce**.
| Field | Value |
| :---------------- | :--------------------------------------------------------------------------------------- |
| Client ID | The app's Consumer Key |
| Client secret | The app's Consumer Secret |
| Token URL | Your org's token endpoint, `https://yourcompany.my.salesforce.com/services/oauth2/token` |
| Scopes (optional) | Leave empty unless your app requires specific scopes |
| Allowed websites | Your org's host, for example `yourcompany.my.salesforce.com` |
The preset prefills Allowed websites with an example host that cannot resolve. Replace it with your org's host before saving, or every request fails. To change the host later, open the **⋮** menu on this connection in the bundle's Credentials tab and choose **Edit**.
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude list the five most recently modified Opportunities in Salesforce.
```
Check the integration user's login history in Salesforce Setup to confirm the call landed under that user.
## Related resources
* [Pull deal and account state](/docs/claude-tag/users/use-cases/pull-deal-state): what this connection adds
claude-tag/admins/connections/sentry First recorded · 49 lines, first recorded
# Connect Sentry ## Create the credential in Sentry ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Sentry
> Connect Sentry to Claude Tag so it can pull errors and stack traces into threads. Covers the dedicated account to create, the token fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Sentry lets Claude pull errors and stack traces into incident threads from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the Sentry plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in Sentry
Create an internal-integration token in Sentry (Settings → Developer Settings → Internal Integrations) rather than a user auth token; scope it to the projects Claude should read.
The token starts with `sntrys_`. Prefer an internal-integration token over a user auth token so access is not tied to a person.
Sentry's own guide for creating the credential is at [docs.sentry.io](https://docs.sentry.io/integrations/integration-platform/internal-integration/).
## Add the connection to a bundle
In the bundle, click **Connect** next to **Sentry**.
| Field | Value |
| :------------------ | :---------------------- |
| Claude's auth token | The api key from Sentry |
| Allowed websites | `sentry.io` |
Self-hosted Sentry uses your own hostname instead of `sentry.io`.
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Sentry appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/watch-monitors): the monitoring use cases
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/snowflake First recorded · 47 lines, first recorded
# Connect Snowflake ## Create the credential in Snowflake ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Snowflake
> Connect Snowflake to Claude Tag so it can run read-only queries on your warehouse. Covers the dedicated user to create, the access token field, and the host to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Snowflake lets Claude run queries against your warehouse from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
This is an HTTP API connection, not a personal claude.ai connector.
## Create the credential in Snowflake
Create a dedicated Snowflake user for the agent with a read-only role scoped to the databases and schemas Claude should query. In Snowsight (Snowflake's web interface), under **Governance & security** and then **Users & roles**, generate a programmatic access token for that user. Tokens expire after 15 days by default, so plan to rotate the credential.
Snowflake's guide for programmatic access tokens is at [docs.snowflake.com](https://docs.snowflake.com/en/user-guide/programmatic-access-tokens). The connection authenticates with this token; key-pair authentication is not currently supported.
## Add the connection to a bundle
In the bundle, click **Connect** next to **Snowflake**.
| Field | Value |
| :--------------------------------- | :---------------------------------------------------------------------------- |
| Claude's programmatic access token | The programmatic access token from Snowflake |
| Allowed websites | Your account's host, for example `yourorg-youraccount.snowflakecomputing.com` |
The preset prefills Allowed websites with an example host that cannot resolve. Replace it with your account's host before saving, or every request fails. To change the host later, open the **⋮** menu on this connection in the bundle's Credentials tab and choose **Edit**.
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Snowflake appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [What this connection adds](/docs/claude-tag/users/use-cases/answer-data-questions): warehouse questions answered with charts in the thread
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/stripe First recorded · 46 lines, first recorded
# Connect Stripe ## Create the credential in Stripe ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Stripe
> Connect Stripe to Claude Tag so it can answer billing and subscription questions. Covers the dedicated account to create, the key fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Stripe lets Claude answer billing and subscription questions from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the Stripe plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in Stripe
Use a restricted key with read-only resource permissions, not your account's full secret key. Consider connecting test mode first.
Stripe's own guide for creating the credential is at [docs.stripe.com](https://docs.stripe.com/keys).
## Add the connection to a bundle
In the bundle, click **Connect** next to **Stripe**.
| Field | Value |
| :------------------ | :---------------------------------------------------------------------------- |
| Claude's secret key | The secret key from Stripe |
| Allowed websites | `api.stripe.com` (preset). To add a different host, use the **Advanced** tab. |
The field labeled Claude's secret key accepts a restricted key; the label is the field name, not a key-type constraint.
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Stripe appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/connections/vercel First recorded · 44 lines, first recorded
# Connect Vercel ## Create the credential in Vercel ## Add the connection to a bundle ## Verify the connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Connect Vercel
> Connect Vercel to Claude Tag so it can check deployment status and logs. Covers the dedicated account to create, the token fields, and the URL to allow.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<Note>Connections are added inside an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle). At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open **Access bundles** in the left navigation, click into a bundle (or **Create** one), and go to its **Credentials** tab.</Note>
Connecting Vercel lets Claude check deployment status and logs from any channel under the bundle's scope. You add it as a connection inside an [Access bundle](/docs/claude-tag/admins/add-connections); the credential belongs to the agent, not to any person.
Pair this connection with the Vercel plugin from Anthropic's plugin marketplace so Claude knows how to call the API; see [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). This is an HTTP API connection, not an MCP server or a personal claude.ai connector.
## Create the credential in Vercel
Create the token from a dedicated team member seat, scoped to the team rather than your personal account.
Vercel's own guide for creating the credential is at [vercel.com](https://vercel.com/kb/guide/how-do-i-use-a-vercel-api-access-token).
## Add the connection to a bundle
In the bundle, click **Connect** next to **Vercel**.
| Field | Value |
| :-------------------- | :--------------------------- |
| Claude's access token | The access token from Vercel |
| Allowed websites | `api.vercel.com` |
The Agent Proxy injects the credential at the network boundary; the model and the sandbox are not given the key. See [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
## Verify the connection
In a channel under the bundle's scope, in a new thread:
```text wrap theme={null}
@Claude what can you access from this channel?
```
Vercel appears in the list once the connection is live. New threads pick up the connection on their own; in an existing thread, ask Claude to use the service by name.
## Related resources
* [Give Claude access](/docs/claude-tag/admins/add-connections): the full credential-type and allowed-hosts reference
claude-tag/admins/customize First recorded · 103 lines, first recorded
# Customize Claude Tag ## Settings admins control ### Channel connections are separate from personal connectors ## Change behavior from the channel ## Choose the model for a scope ### Models your organization allows ## Auto mode allow rules ## Settings no one can change ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Customize Claude Tag > Claude Tag is customized per channel and workspace (a scope), not per user. See what admins set in claude.ai, what anyone can change from the channel, and what stays fixed. export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>; <BetaNote /> Claude Tag's behavior is shaped by four layers, each set in a different place: | Layer | What it is | Who sets it | Where | | :---------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------- | | **Connections** | Credentials for the systems Claude can reach (GitHub, Drive, Datadog, your APIs) | Owner | [Access bundles](/docs/claude-tag/admins/add-connections) | | **Plugins and skills** | Instructions that teach Claude how to use a tool or follow a process. A plugin bundles one or more [skills](https://code.claude.com/docs/en/skills). | Owner | [Bundle Plugins tab](/docs/claude-tag/admins/add-connections#attach-plugins) or a [skills repository](/docs/claude-tag/admins/skills-repo) | | **Custom instructions** | Standing guidance read in every session at a scope (team conventions, output formats). Outranks channel memory. | Owner for any scope; channel members for the channel scope, from the [Configure page](/docs/claude-tag/users/good-habits#configure-claude-for-a-channel) | [Per-scope instructions](/docs/claude-tag/admins/attach-to-scope#add-custom-instructions) | | **Channel memory** | Facts Claude saves while working in a channel | Anyone in the channel | By [telling Claude](/docs/claude-tag/users/memory) | Connections and plugins decide what Claude *can do*; instructions and memory shape *how it does it*. ## Settings admins control Access and organization-wide behavior are set at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), per scope (a scope is a channel, a workspace, or your whole organization), so the same agent can work differently in different channels. Most controls below are Owner-only. | Setting | What it does | More | | :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------- | | Custom instructions | Standing guidance read in every session on a scope, like team conventions. Outranks channel memory. | [Add custom instructions](/docs/claude-tag/admins/attach-to-scope#add-custom-instructions) | | Respond automatically | Whether Claude replies to a channel's messages without an @-mention. Channel members can change it too, from Slack or the channel's Configure page. | [Turn automatic replies on or off](/docs/claude-tag/users/when-claude-responds#turn-automatic-replies-on-or-off) | | Plugins | Bundles of skills that teach Claude how to use a specific tool | [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins) | | Connections | Which systems it can reach from each channel | [Add connections](/docs/claude-tag/admins/add-connections) | | Default model | Which Claude model handles sessions in a scope | [Choose the model for a scope](#choose-the-model-for-a-scope) | | Auto mode allow rules | Actions pre-approved in a scope's sessions that Claude's permission checker would otherwise flag or stop | [Auto mode allow rules](#auto-mode-allow-rules) | | Environment | Which cloud environment a scope's sessions run in. Only [organization-shared environments](https://code.claude.com/docs/en/cloud-environments#organization-shared-environments) appear in the picker, because Claude runs channel sessions with no user account attached. | [Channel environment troubleshooting](/docs/claude-tag/admins/troubleshooting#channel-sessions-use-the-wrong-environment-or-can%E2%80%99t-find-one) | | Claude Tag version | Which generation answers (New, Legacy, or Off) in a scope | [Migrate from the earlier Claude in Slack](/docs/claude-tag/admins/restrict-access#migrate-from-the-earlier-claude-in-slack) | ### Channel connections are separate from personal connectors An Owner configures Claude's connections, plugins, and skills, and they apply per scope. They are separate from the connectors, skills, or MCP servers an individual user has set up in their own claude.ai or Claude Desktop account. A user's personal connectors are not available to Claude in a channel, and the channel's connections are not listed among that user's personal connectors in claude.ai. To give Claude access to a tool that is not in the built-in connection list, including a custom MCP server, see [add a custom connection](/docs/claude-tag/admins/connections/custom). ## Change behavior from the channel Everything in the table below is open to channel members, with no admin involved. | To change | Say something like | More | | :----------------------------- | :--------------------------------------------------------- | :------------------------------------------------------------------------- | | How Claude formats output | "remember for this channel: post reports as a table" | [Memory](/docs/claude-tag/users/memory) | | How chatty Claude is | "ask before posting anything longer than a screen" | [Memory](/docs/claude-tag/users/memory) | | When Claude follows a thread | "stay quiet in this thread unless someone tags you" | [Control when Claude Tag responds](/docs/claude-tag/users/when-claude-responds) | | What Claude does on a schedule | "every morning at 9, post a digest of open threads" | [Set up routines](/docs/claude-tag/users/proactivity) | | What Claude remembers | "what do you remember about this channel?" then correct it | [Memory](/docs/claude-tag/users/memory) | Changes in the table above are saved to channel memory; verify one stuck by asking what it remembers. Members can also tailor how Claude works in the channel from the **Configure** link in the footer of any Claude reply. The link opens a claude.ai page where anyone in the channel who is also a member of your Claude organization can edit settings for that channel, unless an admin has [restricted editing to admins](/docs/claude-tag/admins/attach-to-scope#restrict-who-can-set-channel-instructions). The **Channel instructions** field on that page holds standing guidance that outranks memory. See [configure Claude for a channel](/docs/claude-tag/users/good-habits#configure-claude-for-a-channel). ## Choose the model for a scope Each scope carries a **Default model** setting in its **Advanced** section, alongside the [environment](/docs/claude-tag/concepts/glossary#environment) and guest controls. It sets the model new channel sessions in that scope start on; the options are drawn from the models available to your organization, such as Opus and Sonnet models. A scope without its own setting inherits from its parent, and a channel's setting overrides its workspace's. The **Inherit** option shows which model the scope resolves to. To keep sessions on a model you chose, set a specific model at the organization scope rather than leaving the setting unset; every scope without an override then follows it. The setting applies to new sessions; threads already underway keep the model they started with. The footer of each Claude reply in Slack names the model that handled it, so you can confirm what a scope is running. Channel members can also change the model from Slack, with no admin involved. Asking Claude in a thread switches that thread, and asking it to make a model the channel default changes what new threads in the channel start on. See [choose the model Claude Tag uses](/docs/claude-tag/users/models). ### Models your organization allows Claude Tag's model lists come from the models your organization makes available for Claude Code, set in the Claude admin console, leaving out any that Claude Tag doesn't support. A model you see in Claude Code can be absent in Slack for that reason. The allowed list applies in two places. * **Model lists in Slack.** The models Claude offers when someone asks it to switch, and the model selector for direct messages, show only allowed models. Claude declines a request to switch to a model outside the list. * **Configured defaults.** If your organization also enforces the policy on defaults and a workspace or channel's **Default model** isn't allowed by your organization's Claude Code model policy, Claude declines to start the session and posts a notice in the thread asking the requester to contact an admin. A model excluded by your organization's plan entitlements works differently. Claude starts the session on a fallback model the plan includes, and declines only when the plan excludes every fallback. The footer of the first reply names the model that served it, so check there to see which model the session started on. A change to the allowed list applies to new sessions, like a change to the **Default model**; a thread already underway keeps its model until someone in it asks Claude to switch. ## Auto mode allow rules Sessions run in [auto mode](https://code.claude.com/docs/en/permission-modes#eliminate-prompts-with-auto-mode), where Claude's permission checker reviews each action Claude is about to take and can flag or stop it. When you add an auto mode allow rule to a scope, you pre-approve one action in that scope's sessions, so Claude runs it there without the checker stopping it. The checker keeps reviewing every other action. A rule is a plain sentence that describes work you approve in the scope, such as "Deploying to our staging cluster from a session in this channel is a normal, approved workflow." To add one: 1. On [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), open the **Slack** tab under **Claude Tag's access** and find the scope you want to change (the organization-wide **Slack** row, a workspace, or a channel). The **Slack** row opens as **Default Slack access**. 2. Open the scope's **Advanced** section and find **Auto mode allow rules**, below the [**Default model**](#choose-the-model-for-a-scope) setting. 3. Select **Add rule** and write the rule as one plain sentence. The rules list has three properties: * **Limits:** a scope holds up to 50 rules, and each rule can be up to 1,024 characters * **Inheritance:** rules you set on a workspace or on [Default Slack access](/docs/claude-tag/admins/attach-to-scope#how-scopes-inherit) (the organization-wide root) carry down to the channels beneath, the way [custom instructions](/docs/claude-tag/admins/attach-to-scope#custom-instructions) stack. A channel's own rules add to those and never replace them, so put a rule on a single channel's scope to pre-approve an action there without changing any other channel. * **Access:** you edit the list with the same admin access as the scope's other **Advanced** settings <Warning>Once you add an allow rule, Claude runs the actions it names in every channel the scope covers without anyone approving them in the moment. Keep each rule narrow: name the tool, the action, and the environment it allows, and put rules that unlock sensitive systems on the narrowest scope that needs them.</Warning> ## Settings no one can change * The Claude app's name, @-handle, and avatar in Slack are the same in every workspace; there is no rename or rebrand setting. ## Related resources * [Settings map](/docs/claude-tag/concepts/settings-map): every settings surface, including spend limits and personal connectors * [What Claude Tag remembers](/docs/claude-tag/users/memory): how channel instructions are stored, shared, and corrected * [Good habits for working with Claude Tag](/docs/claude-tag/users/good-habits): phrasings that make recurring output consistent * [How agent identity works](/docs/claude-tag/concepts/agent-identity): why access is set per channel
claude-tag/admins/for-slack-admins First recorded · 50 lines, first recorded
# What the Claude Slack app can access ## Where Claude reads and posts ## Requested scopes ## What installing does not grant ## After you install ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# What the Claude Slack app can access > What the Claude app reads and posts in Slack, the OAuth scopes it requests, and what installing it does not grant. Written for the Slack admin approving the install. export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>; <BetaNote /> You're approving the Claude app install for someone who's setting up Claude Tag. This page covers what the app can do in your Slack workspace. The rest of setup happens on their side, in the Claude console; you don't need a Claude account. ## Where Claude reads and posts Claude reads and posts only in channels a workspace member has added it to, and in direct messages. Any workspace member who opens a direct message with Claude receives its welcome message, whether or not they've linked a Claude account. Installing the app does not add it to any channel. A member can add Claude to a channel in one of two ways: * Invite it with `/invite @Claude` in the channel * Select **Add to channel** on a channel Claude suggests in a direct message. Claude's welcome message, the introduction it posts when a member first opens a direct message with it, suggests public channels this way. When a member selects **Add to channel**, Claude adds itself to that channel using its `channels:join` scope. Slack's audit log records the join as the Claude app, with no inviter shown; the member's selection is not visible in Slack's log. If you see a join in the audit log that no one can explain, a member selected one of these buttons. Claude does not join channels on its own. Reading a channel's full history requires being added there. Workspace search can surface public-channel content, the same as any app with the search scope. Slack Connect channels (shared with another company) are always excluded, regardless of configuration. ## Requested scopes The app requests bot scopes for reading and posting in channels it's a member of, reactions, files, canvases, user lookup, and public-channel search. Slack's install consent screen shows the full current list; treat that as the canonical reference, since the set can change between releases. Two scopes a Slack admin commonly asks about: * `channels:join` lets Claude add itself to a public channel when a member selects one of its suggested-channel buttons. It cannot join private channels this way. * `users:read.email` lets Claude match a Slack member to their Claude account by email, so a person who DMs Claude is recognized without a separate linking step. ## What installing does not grant Credentials for GitHub, Google Drive, a data warehouse, or anything else are provisioned separately by a Claude organization Owner and live on Anthropic's side rather than in Slack. It responds when @-mentioned, and may respond to other messages it judges warrant a reply. ## After you install Post `@Claude connect` in any channel with no other text, or send `connect` on its own in a direct message with Claude, and give the code it returns to whoever asked you to install. That code is what pairs your workspace to their Claude organization; it expires after 15 minutes. Pick a channel that belongs to just your workspace. Claude can decline to reply in [guest and shared channels](/docs/claude-tag/admins/troubleshooting#guest-and-shared-channels). ## Related resources * [Security and data handling](/docs/claude-tag/concepts/security-and-data): where credentials are stored and what leaves your workspace * [Pair your Slack workspace](/docs/claude-tag/admins/pair-workspace): what the Claude Owner does with the code you send
claude-tag/admins/migrate-from-earlier First recorded · 75 lines, first recorded
# Migrate from the earlier Claude in Slack ## Switch your workspace to Claude Tag ### If `@Claude` doesn't respond at all ## What stays the same ## How Claude Tag differs from the earlier app ## What existing users notice after the switch ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Migrate from the earlier Claude in Slack
> Claude Tag replaces the earlier per-user Claude in Slack app in place. See what changes, what stays, how the version is chosen per channel, and what existing users notice.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
If your organization already used the earlier Claude in Slack, including [Claude Code in Slack](https://code.claude.com/docs/en/slack), Claude Tag replaces it. Your existing Slack app and `@Claude` handle stay, and no data migrates. What changes is who Claude acts as and who sets it up.
## Switch your workspace to Claude Tag
<Steps>
<Step title="Connect the workspace in the Claude console">
Open [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). If your workspace isn't paired, run [setup](/docs/claude-tag/admins/setup-overview); otherwise you're already on Claude Tag. Once paired, channels and linked-user DMs answer with the New version by default; no per-channel action is needed.
</Step>
<Step title="Check for channels still on Legacy">
In the **Claude Tag's access** section, look at the **Claude Tag version** on each scope. Pairing defaults every scope to New, so this is usually empty; set any showing **Legacy** to **New**.
</Step>
<Step title="Give Claude its connections">
The New version starts with no access of its own. GitHub repositories and other connections do not carry over from individual users' linked accounts, so code requests in a switched channel have nothing to clone until you configure them. Follow the [setup overview](/docs/claude-tag/admins/setup-overview) to add connections, and [GitHub access](/docs/claude-tag/admins/configure-github) for code work specifically.
If your teams keep custom skills in a repository's `.claude/skills/` folder, those skills apply only in threads that have the repository. Grant the repository in an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle) and have users name it in the first message. To give skills to every channel under a scope, add them through a [skills repository](/docs/claude-tag/admins/skills-repo).
</Step>
<Step title="Tell your users">
Send them [Get started](/docs/claude-tag/users/getting-started). The visible change is that work now belongs to the channel; see [What existing users notice after the switch](#what-existing-users-notice-after-the-switch) below.
</Step>
</Steps>
**You'll see:** the workspace appears under **Where Claude Tag works**, and the **Claude Tag version** on each scope shows **New**.
### If `@Claude` doesn't respond at all
On Enterprise Grid, an earlier install can lose its connection and stop responding in every workspace. Don't uninstall the app. Have a Slack Org Owner or Org Admin, while signed in to one of the workspaces (not the org-level admin page), open [claude.com/claude-for-slack](https://claude.com/claude-for-slack), select **Add to Slack**, and choose **Install to entire organization**. This refreshes the connection in place. Then send `@Claude connect` again in a channel of that workspace and continue with step 1 above.
<Warning>The earlier Claude in Slack app, shown as **Legacy** in admin settings, is being deprecated; check with your account team for the cutover date. After that date, channels still set to Legacy stop responding until the scope's Claude Tag version is set to New.</Warning>
## What stays the same
* The Slack app and the `@Claude` handle. Your existing Claude in Slack settings (allowed users, verified-domain restriction) carry over. If your earlier install predates a permission Claude now uses, `@Claude connect` says so when you pair; a Slack admin clicks the install link in that reply and approves the consent screen, which installs over the existing app. Otherwise no app-side action is needed.
* Direct messages still run on the user's own claude.ai account, the same way they did before. The shift to a shared identity applies to channels.
* Users who already linked their claude.ai account keep that connection. It is what powers their DMs.
## How Claude Tag differs from the earlier app
The earlier app linked each user's own claude.ai account, so it answered as that person and used their connectors. Claude Tag has one identity for the team, provisioned by an admin who also sets what it can reach in each channel.
| | Legacy (the earlier Claude in Slack) | New (Claude Tag) |
| :------------- | :------------------------------------------ | :--------------------------------------------------------- |
| Identity | Each user links their own claude.ai account | One agent identity with org-level service credentials |
| Sessions | Spawned per request | One persistent session per thread, shared with the channel |
| Memory | None | Shared workspace memory plus private-channel memory |
| Standing work | None | Routines and channel watching |
| Who sets it up | Each user, individually | An Owner, once |
The **Claude Tag version** setting on each scope lets you pin a channel or workspace to **Off**, **Legacy**, or **New**, or **Inherit** the organization default. Use it to hold specific channels on the Legacy behavior while you finish provisioning, then switch them when ready. Access bundles only apply where the New version answers. See [the version setting](/docs/claude-tag/admins/restrict-access#migrate-from-the-earlier-claude-in-slack) for the control.
Both versions answer through the same @Claude app, so setting a scope to **Off** turns off the earlier version there too. To opt out of Claude Tag while keeping the earlier behavior, set the scope to **Legacy**, not **Off**.
## What existing users notice after the switch
In channels, the visible difference is that work belongs to the channel, not to whoever asked. Anyone can reply in a thread to steer it, and the result stays where the team can see and pick it up. Code work is authored by the Claude GitHub App rather than as the requesting user.
A user who never linked a claude.ai account can now hand Claude work in channels, by default. Whether that stays open or narrows to organization members is the admin's [access restriction](/docs/claude-tag/admins/restrict-access#members) setting.
If `@Claude` in a channel still opens pull requests under the asker's name, that channel is answering with the Legacy version; check the scope's Claude Tag version setting.
## Related resources
* [Glossary: the earlier Claude in Slack](/docs/claude-tag/concepts/glossary#the-earlier-claude-in-slack): what each term meant in the old app versus now
* [Set up Claude Tag](/docs/claude-tag/admins/setup-overview): the new admin-side setup, since per-user setup no longer applies
* [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access): keep specific channels on the old version during a phased switch
claude-tag/admins/network-requirements First recorded · 49 lines, first recorded
# Network requirements ## Add Anthropic's egress range to your allowlist ## Internet reachability ## IP allowlist vs. allowed websites ## Events and webhooks ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Network requirements
> Claude Tag reaches your services from a published egress range, over HTTP and HTTPS only. See the IP block to allowlist and how the allowlist relates to the allowed-websites setting on a connection.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
If a service you want to connect (a data warehouse, an internal API, a GitHub organization with an IP allow list) restricts access by source IP, add Anthropic's egress range to its allowlist. Hand this page to the team that manages it.
## Add Anthropic's egress range to your allowlist
Requests from Claude to your services originate from Anthropic's network. To let them through, add Anthropic's published egress range to the service's allowlist:
```text wrap theme={null}
160.79.104.0/21
```
The authoritative list is [Anthropic's published IP addresses](https://platform.claude.com/docs/en/api/ip-addresses); check it when you create the rule.
The range is shared across Anthropic services, and dedicated per-organization egress addresses aren't available, so the allowlist entry admits Anthropic's infrastructure as a whole. Your credential's [allowed websites](/docs/claude-tag/admins/add-connections#set-allowed-websites) are what scope which of *your* systems Claude can call.
Allowlist changes on enterprise systems can take days to take effect, which is why the [setup overview](/docs/claude-tag/admins/setup-overview#before-you-start) sends you here before you start setup.
## Internet reachability
<Warning>A connected service must accept traffic from the internet (restricted by IP allowlist if you like). A service reachable only inside your private network can't be connected; private networking such as PrivateLink or VPC peering is not supported.</Warning>
Every request from a channel's sandbox to your service passes through [Agent Proxy](/docs/claude-tag/concepts/agent-identity#agent-proxy), which carries HTTP and HTTPS only. A service reachable only over another protocol, such as SSH or a database's native wire protocol, can't be connected; put an HTTP API in front of it instead.
## IP allowlist vs. allowed websites
The IP allowlist on your service and the [allowed websites](/docs/claude-tag/admins/add-connections#set-allowed-websites) on a connection are opposite sides of the same boundary:
| | IP allowlist | Allowed websites |
| :-------------------- | :----------------------------------- | :-------------------------------------- |
| **Who configures it** | Your team, on your service | You, on the connection in Claude |
| **What it decides** | Which networks may reach the service | Which hosts a credential may be sent to |
## Events and webhooks
Events from connected services, like GitHub activity, are delivered directly to Anthropic, so there is no inbound listener to configure on your side.
## Related resources
* [Add connections](/docs/claude-tag/admins/add-connections#set-allowed-websites): the allowed-websites setting (the other direction: what Claude is allowed to reach)
* [Allow a host without a credential](/docs/claude-tag/admins/add-connections#allow-a-host-without-a-credential): how hosts become reachable from a channel, including [allow-all egress](/docs/claude-tag/admins/add-connections#allow-all-hosts)
* [How agent identity works](/docs/claude-tag/concepts/agent-identity): how credentials are injected at the network boundary
* [Setup overview](/docs/claude-tag/admins/setup-overview): back to the console flow once the allowlist is in place
claude-tag/admins/pair-workspace First recorded · 106 lines, first recorded
# Pair your Slack workspace ## Install and pair ## Send the install request to your Slack admin ### If `@Claude` doesn't respond at all ### If `@Claude connect` says the installation is out of date ### If Claude says Claude in Slack is not available for your organization ### If the console says "already connected to a different organization" ### If the console says "claim code is invalid, expired, or already used" ### If DMs never respond on Enterprise Grid ## After pairing: where Claude is enabled ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Pair your Slack workspace
> Connect your Slack workspace to your Claude organization. See what to send your Slack admin, where to paste the pairing code, and whether to enable the entire workspace or specific channels first.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<div className="tm-stepbar">
<a className="tm-stepbar-seg tm-current" href="/docs/docs/claude-tag/admins/pair-workspace">1 · Pair workspace</a>
<a className="tm-stepbar-seg" href="/docs/docs/claude-tag/admins/add-connections">2 · Give access</a>
<a className="tm-stepbar-seg" href="/docs/docs/claude-tag/admins/set-spend-limit">3 · Spend limit</a>
<a className="tm-stepbar-seg" href="/docs/docs/claude-tag/admins/test-it">4 · See it work</a>
</div>
<div className="tm-stepmeta">
<div className="tm-stepmeta-row"><span className="tm-stepmeta-label">Role you need</span><span>Owner in your Claude organization, plus a Slack workspace admin to install the app and generate the pairing code. These can be the same person or two people.</span></div>
<div className="tm-stepmeta-row"><span className="tm-stepmeta-label">Before this step</span><span>The <a href="/docs/docs/claude-tag/admins/setup-overview#before-you-start">prerequisites</a>: confirm your role and decide where you'll pilot</span></div>
<div className="tm-stepmeta-row"><span className="tm-stepmeta-label">Do I need this?</span><span><span className="tm-meta-pill tm-meta-pill-req">Required</span>Nothing else in setup works until a workspace is paired.</span></div>
</div>
## Install and pair
Pairing has three parts: install the app in Slack, get a code from Slack, and paste it in the Claude console.
<Steps>
<Step title="Install the Claude app in Slack">
Open [claude.com/claude-for-slack](https://claude.com/claude-for-slack), click **Add to Slack**, and approve the permissions Slack shows. Skip if the app is already installed.
</Step>
<Step title="Run @Claude connect in Slack">
Send `@Claude connect` in any channel, with no other text, as a new top-level message or in a thread where Claude isn't already working. Claude replies with a pairing code valid for 15 minutes. In a thread where Claude is already working, it treats the message as a normal request instead.
Pick a channel that belongs to just your workspace. Claude can decline to reply in [guest and shared channels](/docs/claude-tag/admins/troubleshooting#guest-and-shared-channels).
In a DM with Claude, send `connect` on its own. Sending `link` works in place of `connect` in both cases.
Only a Slack workspace admin (or Grid org admin) can run this command. If that's not you, [send them the install request](#send-the-install-request-to-your-slack-admin) and have them return the code.
If your install is missing a permission, the reply names it (and may still issue a code with a warning); see [the section below](#if-@claude-connect-says-the-installation-is-out-of-date).
</Step>
<Step title="In the console: complete the pairing step">
At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), setup opens as a full page until your first workspace is paired; click **Start setup** to reach **Pair your Slack workspace**. Paste the code, choose where Claude can reply (**Entire workspace (recommended)** or **Specific channel**), and click **Pair workspace**. To pair a workspace after your first, select **+ Connect** next to **Where Claude Tag works** instead, as described in [Manage workspaces](/docs/claude-tag/admins/workspaces#pair-another-workspace).
</Step>
</Steps>
Setup confirms the pairing and moves on to choosing Claude's tools, so there's nothing to check at this point; continue with [Give Claude access](/docs/claude-tag/admins/add-connections). After setup finishes, the Slack row under **Where Claude Tag works** shows your workspace as connected, and a [scope](/docs/claude-tag/concepts/glossary#scope) for it (the entry where you'll bind tool access) appears on the **Slack** tab under **Claude Tag's access**.
## Send the install request to your Slack admin
Steps 1–2 above need a Slack workspace admin; step 3 needs an Owner in your Claude organization. If those are two people, send the Slack admin this and have them return the code:
```text wrap theme={null}
Please install the Claude app (https://claude.com/claude-for-slack) in [workspace]. When that's done, let me know a time that works for the next part: you post "@Claude connect" in any channel with no other text and send me the code it returns. Pick a channel that belongs to just [workspace]. The code expires 15 minutes after Claude posts it, so I'll redeem it right away. What it can access: https://claude.com/docs/claude-tag/admins/for-slack-admins
```
### If `@Claude` doesn't respond at all
On Enterprise Grid, an earlier install can lose its connection and stop responding in every workspace. Don't uninstall the app. Have a Slack Org Owner or Org Admin, while signed in to one of the workspaces (not the org-level admin page), open [claude.com/claude-for-slack](https://claude.com/claude-for-slack), select **Add to Slack**, and choose **Install to entire organization**. This refreshes the connection in place. Then send `@Claude connect` again in a channel of that workspace.
### If `@Claude connect` says the installation is out of date
Your Slack install predates a permission the app now requests. The workspace keeps its old grant until a Slack admin approves the update. Replies name the missing permissions until then. The reply links both remedies; either one clears the error.
* **Approve the updated permissions.** A Slack workspace admin opens Slack's installed-apps page, `https://app.slack.com/apps-manage/<team-id>/integrations/installed`, finds the Claude app, and approves its requested permissions. The **approves its updated permissions** link in the reply lands on that page directly. On Enterprise Grid with an org-wide install, a Slack org admin uses `https://app.slack.com/manage/<grid-id>/integrations/installed` instead.
* **Reinstall the app.** A Slack workspace admin clicks the **reinstalls the Claude app** link in the reply and approves the consent screen Slack shows. Opening [claude.com/claude-for-slack](https://claude.com/claude-for-slack) and clicking **Add to Slack** again does the same thing. This installs over the existing app with the current permissions; do not uninstall first.
Then run `@Claude connect` again. Slack's **Manage apps** page lists the scopes the app requests, not the scopes your workspace has granted. Seeing a permission listed there does not by itself mean it is approved. The grant happens when an admin approves the update or completes the consent screen.
### If Claude says Claude in Slack is not available for your organization
The reply "Claude in Slack is not available for your organization" means your Slack workspace is paired to a Claude organization with a restricted compliance configuration, such as Zero Data Retention (ZDR). Claude Tag retains channel memory and session transcripts, so it can't run under that configuration.
Check which Claude organization the workspace is paired to. If your company has more than one, for example a trial org alongside the main one, the workspace may be paired to the wrong one. An Owner in that organization can [revoke the pairing](/docs/claude-tag/admins/workspaces#revoke-a-pairing) so you can pair the workspace to the right one here.
If the pairing already points to the intended organization, no admin setting lifts the restriction; contact your account team.
If the reply instead says Claude Tag has been turned off for your Claude organization, the cause is the **Enable Claude Tag for your organization** toggle, and an Owner can turn it back on. See [Claude Tag is turned off for your organization](/docs/claude-tag/admins/troubleshooting#claude-tag-is-turned-off-for-your-organization).
### If the console says "already connected to a different organization"
A Slack workspace can pair with only one Claude organization at a time, and this one is already paired elsewhere. An Owner in the Claude organization that currently holds the pairing must [disconnect it](/docs/claude-tag/admins/workspaces#revoke-a-pairing) from their **Connected workspaces** list before your code can be redeemed here. If your company has more than one Claude organization, check the others; the existing pairing is often in a test or trial org.
### If the console says "claim code is invalid, expired, or already used"
Pairing codes are single-use and expire 15 minutes after they're issued. Ask the Slack admin to send `@Claude connect` again and paste the fresh code; reinstalling the app is not required. On Enterprise Grid, a Grid org admin's reply includes a Grid-wide code (starting with `enterprise_`) alongside the workspace code (starting with `workspace_`).
### If DMs never respond on Enterprise Grid
On Enterprise Grid, direct messages with Claude follow each user's home workspace, not the workspace you paired. When a user is homed in a grid workspace the pairing doesn't cover, their DMs answer with a redirect to setup instructions even after their account connects, while channels in the paired workspace work normally.
The fix is to pair the whole grid rather than one workspace. Claude's reply to a Grid Org Owner or Org Admin's `@Claude connect` includes two codes; redeem the one starting with `enterprise_` (not the `workspace_` one) in the pairing step to cover DMs for users in every workspace of the grid.
## After pairing: where Claude is enabled
Once a workspace is paired, where Claude responds depends on what you chose when pairing (entire workspace or specific channels), the **Enable Claude Tag for your organization** toggle, and your [access restriction](/docs/claude-tag/admins/restrict-access#members) setting.
* **What Claude can reach** in each channel depends on which Access bundles you bind; see [Configure per-channel access](/docs/claude-tag/admins/attach-to-scope).
* **Nothing runs until usage is funded** on Team plans; see [Set a spend limit](/docs/claude-tag/admins/set-spend-limit).
* **DMs work separately** from channels and run on each user's own claude.ai account. On Enterprise Grid, DMs follow each user's home workspace; see [If DMs never respond on Enterprise Grid](#if-dms-never-respond-on-enterprise-grid).
## Related resources
* [Give Claude access](/docs/claude-tag/admins/add-connections): create an Access bundle and add connections
* [What the Claude Slack app can access](/docs/claude-tag/admins/for-slack-admins): the page to send a Slack admin who's approving the install
claude-tag/admins/restrict-access First recorded · 185 lines, first recorded
# Restrict where Claude Tag operates ## Control who can invoke Claude Tag ### Restrict who can use Claude #### Restrict by role on Enterprise ## Control where Claude Tag operates ### Quiet or remove Claude Tag ### Limit Claude Tag to specific channels ### Restrict guest channels ### Externally shared channels ### Channels shared across workspaces in your Enterprise Grid ### Migrate from the earlier Claude in Slack ### Allow or disable direct messages ### Set spend limits ## Permissions by role ## Controls that aren't available ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Restrict where Claude Tag operates
> Claude Tag responds only where it has been added and addressed. See who can invoke it, guest and externally shared channel limits, the per-scope version setting, how to limit it to chosen channels, and how to quiet or remove it.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
In channels, Claude Tag responds only where it's been added and addressed, and the controls on this page narrow that further. DMs are a separate surface that runs on the user's own account; see [how DMs differ from channels](/docs/claude-tag/concepts/agent-identity#direct-message-channels).
<Note>Most controls on this page require the Owner role in your Claude organization; the [permissions table](#permissions-by-role) below lists which actions an Admin or a channel member can take.</Note>
## Control who can invoke Claude Tag
In channels where the app has been added, an @-mention guarantees a response; Claude may also respond to a message that doesn't mention it when it judges a reply is warranted, and once a thread is active it follows replies in that thread. By default, anyone in such a channel can address it. A single toggle narrows that to people in your Claude organization.
<a id="members" />
### Restrict who can use Claude
Open **Manage** on the Slack entry under **Where Claude Tag works** at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). The dialog shows a toggle that controls who in your Slack workspace can use Claude at all; its label depends on your plan. You must be an Owner of your Claude organization to change it.
| Plan | Toggle | Off (default) | On |
| :--------- | :----------------------------------------- | :------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------- |
| Enterprise | **Restrict in your organization via RBAC** | Anyone in the connected Slack workspace can use Claude, even without a Claude account | Only members whose role grants the **Claude Tag in Slack** capability can use Claude |
| Team | **Restrict to your organization** | Anyone in the connected Slack workspace can use Claude, even without a Claude account | Only Slack users with a Claude account in your organization can use Claude |
The toggle applies to channels and DMs alike.
<Info>
You may see the earlier three-option **Members** dropdown instead of the toggle. The dialog keeps the dropdown while your organization's stored choice matches neither toggle state. That happens for an Enterprise organization that previously chose **Open to any organization member** (now marked deprecated), and for a Team organization still restricted by role from an earlier Enterprise plan. Switch to one of the toggle's two states. The dropdown is then replaced by the toggle, and the deprecated option is no longer offered.
</Info>
#### Restrict by role on Enterprise
Role restriction requires an Enterprise plan. Team plans don't have role-level control; turning on **Restrict to your organization** is the only restriction available there.
Restricting by role spans three console pages.
1. On [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), turn on **Restrict in your organization via RBAC**.
2. On [`claude.ai/admin-settings/groups`](https://claude.ai/admin-settings/groups), create groups and add the relevant members.
3. On [`claude.ai/admin-settings/roles`](https://claude.ai/admin-settings/roles), create a custom role with the **Claude Tag in Slack** capability turned on or off, and choose which groups hold the role in the role editor.
Three rules govern how role restrictions resolve.
* **The toggle gates the capability.** The **Claude Tag in Slack** capability on a role has no effect until **Restrict in your organization via RBAC** is on. While the toggle is off, every member can use Claude regardless of what their role grants.
* **Built-in roles always grant access.** Every built-in role, including User, Owner, and Primary owner, grants **Claude Tag in Slack** automatically, so the restriction only blocks members on a custom role that doesn't grant it.
* **Any grant wins.** A member in more than one group keeps access if any of their roles grants it.
A member whose roles don't grant the capability is excluded everywhere Claude works, in three ways:
* **@-mentions and DMs get a private notice.** Claude doesn't act on the request. The member sees a notice only they can see, saying their role doesn't allow Claude Tag and to ask their admin for access.
* **Automatic replies skip them.** In channels where Claude responds without being tagged, a restricted member's messages never trigger a response.
* **Their thread replies aren't read.** In a thread an allowed member started, a restricted member's replies don't reach Claude as content. Claude sees that a message arrived, but the message body is withheld.
<Warning>On a Slack Enterprise Grid whose workspaces are paired to different Claude organizations, one organization's access settings govern the entire grid, so your restrictions may not be enforced in your own workspaces.</Warning>
## Control where Claude Tag operates
The restriction toggle decides who can use Claude. The controls in this section decide where it works at all, from one channel up to a workspace, and which generation answers in each scope (a scope is a channel, a workspace, or your whole organization).
### Quiet or remove Claude Tag
Six ways to stop Claude Tag from responding, ordered from quietest to most complete:
1. **Ask it to stay quiet.** Saying "stay quiet in this thread unless tagged" stops Claude following an active thread.
2. **Remove it from the channel.** Run `/remove @Claude`. It can no longer read or post there.
3. **Set the scope's Claude Tag version to Off.** Claude stops responding in that scope even if someone invites it back; an @-mention gets a disabled notice instead of a reply. The control is on the scope's panel at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), and only an Owner can change it.
4. **Detach the scope.** The channel loses its elevated access and falls back to inherited baselines.
5. **Delete the bundle.** This revokes its credentials everywhere it was attached (the credentials are removed; memory, routines, and transcripts are not). Running sessions may keep a revoked credential for a short window before the change propagates.
6. **Uninstall the app.** This removes Claude from the workspace entirely.
Steps 1–4 and 6 do not delete any data. Step 5 (deleting a bundle) removes the credentials in that bundle; memory, routines, and session transcripts are unaffected by any of these steps. Removing Claude from a channel stops it responding there; the channel's memory and routines remain on record, and re-adding it restores them. Credentials are stored in Access bundles on the claude.ai side and persist independently of the Slack app installation. To delete data, use the dedicated controls at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag) rather than removal alone.
### Limit Claude Tag to specific channels
To let Claude respond only in channels you choose, for example during a pilot confined to one channel, turn the [version setting](/docs/claude-tag/admins/workspaces#set-the-version-for-a-scope) **Off** everywhere and switch the chosen channels back to **New**. Both changes happen in the **Claude Tag's access** section at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). DMs, guest channels, and shared channels need more than the version setting; each gets its own treatment after the steps.
<Note>**Off** silences the earlier Claude in Slack too. If you're in the middle of migrating from the earlier app, decide which scopes stay on **Legacy** before you start; the earlier app keeps answering in those channels.</Note>
<Steps>
<Step title="Turn Claude Tag off everywhere">
Set the **Claude Tag version** on [**Default Slack access**](/docs/claude-tag/admins/attach-to-scope) to **Off**. Then set any workspace or channel scope whose version is something other than **Inherit** to **Off** or **Inherit** too, leaving alone the scopes you're keeping on **Legacy**.
</Step>
<Step title="Switch the chosen channels back on">
Set each chosen channel's version to **New**. A channel's own setting wins over the **Off** above it, so Claude responds in the chosen channels and nowhere else. Channels Claude was added to already appear in the **Claude Tag's access** section, and the version control is on each channel scope's panel; use **Search channels** to find each one. For a channel that isn't listed, create a scope with **Add channel** as described in [Attach to a channel](/docs/claude-tag/admins/attach-to-scope#attach-to-a-channel).
</Step>
</Steps>
If someone invites the app into another channel afterward, Claude stays silent there. Mentioning `@Claude` in that channel gets a notice that Claude is disabled in the channel, not a reply.
DMs, guest channels, and shared channels sit outside the version setting:
* **DMs.** The version setting doesn't cover them. To close those off too, turn off [Allow direct messages](#allow-or-disable-direct-messages).
* **Guest channels.** By default Claude is off in any channel that includes a Slack guest. If a chosen channel has guests, also set [Allow Claude to respond to guests](#restrict-guest-channels) to **Allow** on its scope.
* **Shared channels.** A [channel shared across workspaces in your Enterprise Grid](#channels-shared-across-workspaces-in-your-enterprise-grid) takes its settings from **Default Slack access** only, and Claude [doesn't operate in Slack Connect channels](#externally-shared-channels) at all; neither can serve as a chosen channel.
To control who can use Claude in the allowed channels, turn on the [restriction toggle](#restrict-who-can-use-claude); to cap what a channel spends, [set a per-channel spend limit](#set-spend-limits).
### Restrict guest channels
By default, Claude is disabled in any channel that includes a Slack guest. To allow it there, set **Allow Claude to respond to guests** to **Allow** for the scope covering the channel; **Restrict** (the default) keeps it off wherever a guest is present. The setting is at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, in the scope's collapsed **Advanced** section.
**Allow** applies to every guest channel the scope covers, and guests in those channels can see Claude's replies and interact with it. To open one channel rather than a whole workspace, set it on the channel's own scope.
**Allow** controls whether Claude replies, not what it can search. Workspace search is unavailable in any channel that includes a guest, even when the setting is **Allow**. Search results could include content from channels the guests can't see, the same reason Claude doesn't search private channels. To run a search that covers the workspace, ask from a channel without guests.
### Externally shared channels
Claude doesn't operate in Slack Connect channels, the ones shared with another company. It's off in those channels regardless of scope or bundle, and this isn't configurable.
### Channels shared across workspaces in your Enterprise Grid
What happens in a channel shared across more than one workspace inside your Enterprise Grid depends on whether every workspace in it is connected to the same Claude organization.
When the workspaces all belong to your one Claude organization, Claude replies in the channel, but only with the access and settings on your organization's [Default Slack access](/docs/claude-tag/admins/attach-to-scope) scope. Bundles, instructions, and memory set on a workspace or on that channel don't reach it. Claude posts a notice in the thread explaining this, about once a month per channel at most rather than on every reply. Where guest access is at its default **Restrict**, the [guest check](#restrict-guest-channels) still runs first and can refuse the reply.
When the workspaces belong to different Claude organizations, each with its own settings and plan, Claude won't reply and posts a refusal message instead.
There is no per-channel override for either case.
### Migrate from the earlier Claude in Slack
If your organization used the earlier Claude in Slack app, you choose which generation answers `@Claude` per scope. The control is the **Claude Tag version** setting on each workspace or channel scope at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), with the choices **Off**, **Legacy**, **New**, and **Inherit**, plus the **Claude Tag version** row on the **Default Slack access** scope above them.
Both generations answer through the same @Claude app, so **Off** turns off both. To opt out of Claude Tag but keep the earlier app answering in a scope, choose **Legacy**.
Access bundles only apply where the New version answers. The [glossary](/docs/claude-tag/concepts/glossary#the-earlier-claude-in-slack) covers how the two differ.
### Allow or disable direct messages
The **Allow direct messages** toggle controls whether members can message Claude directly. When it's off, Claude is reachable only in channels. The default is on, and you must be an Owner of your Claude organization to change it.
On [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), the toggle appears in one of two places: directly on the Claude Tag settings page, or in the **Manage** dialog on the Slack entry under **Where Claude Tag works**, where the toggle is labeled **Allow direct messages with Claude**. If your organization still uses the earlier Claude in Slack settings page at [`claude.ai/admin-settings/claude-in-slack`](https://claude.ai/admin-settings/claude-in-slack), the toggle appears there too. It's the same setting in each place, so change it wherever it appears for your organization.
### Set spend limits
Spend limits and usage analytics live at [`claude.ai/admin-settings/usage/claude-tag`](https://claude.ai/admin-settings/usage/claude-tag), a different page than the main Claude Tag settings.
A spend limit is a cap on how much of your organization's usage balance Claude Tag can draw each billing period. Setting a limit doesn't fund the balance; on a Team plan, [fund the usage balance first](/docs/claude-tag/admins/set-spend-limit) or Claude won't respond in channels regardless of the limit.
* **Organization-wide limit.** Caps total Claude Tag spend across every channel.
* **Default spend limit.** A default limit applied to each channel that doesn't have its own.
* **Per-channel limits.** Set on any channel from its row in the per-channel spend table, in addition to the organization limit. A channel doesn't need its own scope to take a limit.
* **Usage analytics.** Per-channel spend breakdown on the same page.
Work that would exceed a limit is declined rather than silently truncated. A user blocked by a limit can request more usage from their admin in Slack, and the admin notification names whether the usage balance or the limit caused the block.
## Permissions by role
Creating bundles, binding them to scopes, and pairing workspaces need an Owner; an Admin can edit a bundle's Credentials and Domains tabs but not its other tabs. Everything else happens inside the channel and is open to its members. The table lists each action and who can take it.
| Action | Owner | Admin | Channel member |
| :--------------------------------------------------------- | :------------------ | :------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------- |
| Pair a workspace | Yes | No | No |
| Create, rename, delete, or bind an Access bundle | Yes | No (view only) | No |
| Edit a bundle's Repositories, Plugins, or Instructions tab | Yes | No (view only) | No |
| Edit a bundle's Credentials or Domains tab | Yes | Yes | No |
| Write channel memory | Yes, in the channel | Yes, in the channel | Yes |
| Set channel instructions from the Configure link | Yes | Yes | Yes, unless the scope's [Channel member edits](/docs/claude-tag/admins/attach-to-scope#restrict-who-can-set-channel-instructions) setting blocks it |
| Create, list, or disable a scheduled job in the channel | Yes, in the channel | Yes, in the channel | Yes |
| Remove Claude from a channel | Yes | Yes | Yes, with `/remove`, unless your Slack admin restricts it |
Scheduled jobs run with the channel's credentials, so a member creating one can't reach anything the channel itself can't.
## Controls that aren't available
These are controls an admin might look for that Claude Tag doesn't have.
* **Third-party deployment.** Sessions run on Anthropic's first-party infrastructure; Claude Tag isn't available through third-party deployments.
* **Renaming or rebranding the app.** The Claude app's name, @-handle, and avatar in Slack are fixed; there is no per-workspace rename setting.
* **A pre-invite channel blocklist.** Once the app is installed in a workspace, anyone can `/invite @Claude` into a public channel; there's no list that prevents the invite itself. To keep Claude out of a channel after the fact, [set that scope's Claude Tag version to Off](#quiet-or-remove-claude-tag). To confine Claude to chosen channels instead, see [Limit Claude Tag to specific channels](#limit-claude-tag-to-specific-channels).
* **Per-user spend caps on channel work.** Spend limits apply at the organization and channel level. There's no way to cap what one member can spend in channels; DM usage bills to that member's own seat and follows the seat's usual limits.
* **Per-channel responder allowlist.** The restriction toggle governs who can invoke Claude across the workspace; you can't narrow it to a list of people for one channel only.
* **An open-internet switch in Claude Tag settings.** A channel sandbox reaches only allowed hosts. To let Claude reach a public site or API, an Owner or Admin adds that hostname on a [bundle's Domains tab](/docs/claude-tag/admins/add-connections#allow-a-host-without-a-credential); for broad web access, they pin an [environment](/docs/claude-tag/concepts/glossary#environment) whose network access level is Full access on the scope. [Allow-all egress](/docs/claude-tag/admins/add-connections#allow-all-hosts), a `*` entry on the Domains tab, is off by default and enabled per organization by Anthropic.
* **A web search toggle for channels.** No setting turns web search off for channel sessions; the web search capability setting in claude.ai admin settings governs claude.ai chat, not channels. Web search runs on Anthropic's servers rather than from the channel sandbox, so Domains entries and egress settings don't govern it, and a search opens no new path out of the sandbox; search requests travel to Anthropic the same way the session's model traffic already does. See [Web search vs. network requests](/docs/claude-tag/concepts/agent-identity#web-search-vs-network-requests).
* **Read-scope confinement.** Claude can search public channels by keyword the same way any Slack user can; it can't read a channel's full history unless it's been added there. There's no setting to disable workspace search, and no setting to enable it in [channels that include guests](#restrict-guest-channels), where search is unavailable.
* **Session length enforcement.** Your organization's Slack session-length policy is not enforced on this surface.
## Related resources
* [Configure per-channel access](/docs/claude-tag/admins/attach-to-scope): change the scopes these controls apply to
* [How agent identity works](/docs/claude-tag/concepts/agent-identity): the model these controls operate on
* [Security and data handling](/docs/claude-tag/concepts/security-and-data): what these controls don't cover (data flow, retention, where credentials are stored)
claude-tag/admins/set-spend-limit First recorded · 80 lines, first recorded
# Set a spend limit ## Whether this step is required depends on your plan ## Set the spend limit ## What happens when the spend limit is reached ### Rate limits versus the spend limit ## Per-channel limits ## Attribute costs by channel ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Set a spend limit
> Claude Tag draws from your organization's usage balance, not individual seats. See whether you need to fund usage, how to set the spend limit, and what happens when it's reached.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<div className="tm-stepbar">
<a className="tm-stepbar-seg tm-done" href="/docs/docs/claude-tag/admins/pair-workspace">1 · Pair workspace</a>
<a className="tm-stepbar-seg tm-done" href="/docs/docs/claude-tag/admins/add-connections">2 · Give access</a>
<a className="tm-stepbar-seg tm-current" href="/docs/docs/claude-tag/admins/set-spend-limit">3 · Spend limit</a>
<a className="tm-stepbar-seg" href="/docs/docs/claude-tag/admins/test-it">4 · See it work</a>
</div>
Work Claude does in channels bills to your **organization's usage balance**, not to individual seats. The **spend limit** is a cap you set on how much of that balance Claude Tag can use each billing period.
| Work | Bills to | Capped by |
| :--------------- | :-------------------------------- | :-------------------------------------------------------------------------------------------------- |
| Channel work | Your organization's usage balance | The spend limit, plus any [per-channel limits](/docs/claude-tag/admins/restrict-access#set-spend-limits) |
| A DM with Claude | The sender's own seat | The seat's usual limits, not the spend limit |
## Whether this step is required depends on your plan
| Your plan | What you need to do here |
| :------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Team** | **Required, before anything runs.** A Team plan has no usage balance until it's funded, and Claude won't respond in channels until it is. A [launch usage credit](https://support.claude.com/en/articles/15575654-claude-tag-launch-promo-for-claude-team-and-enterprise) counts as a funded balance, so check for one before buying credits. Then set a spend limit. |
| **Enterprise (invoiced)** | **Recommended.** Usage bills to your invoice with no upper bound until you set a spend limit. Set one to cap exposure during the pilot. |
## Set the spend limit
If your organization bills through a reseller, this page is not available and these steps don't apply; your organization's usage is funded through the reseller instead.
<Steps>
<Step title="Open the usage page">
Go to [`claude.ai/admin-settings/usage/claude-tag`](https://claude.ai/admin-settings/usage/claude-tag).
</Step>
<Step title="Enter an amount">
Enter an amount in your organization's billing currency. The spend limit resets at the start of each billing period and applies across every paired workspace. You can change it any time.
</Step>
</Steps>
There's no published per-task cost guidance. For a pilot, set a spend limit you're comfortable with for the first billing period, then watch the per-channel usage breakdown on the same page and adjust.
## What happens when the spend limit is reached
When usage reaches the spend limit, Claude stops and tells the requester in the thread that it couldn't finish. The requester can ask an admin to raise the limit.
The spend limit counts usage at list price. If your organization has a negotiated discount, that discount applies at invoice time, not to the cap.
### Rate limits versus the spend limit
The spend limit caps how much your organization is charged. It doesn't change how fast Claude can work. Claude Tag also applies its own throughput limits on how quickly threads can be started and messages delivered, and an organization with many busy channels can hit one while the spend limit still has plenty of room.
When that happens, Claude tells the requester in the thread that it hit a rate limit and names a short wait, usually a few seconds. Re-send the message after the wait. Raising the spend limit doesn't clear a rate limit, and a rate-limited request doesn't spend anything.
| Claude says | Limit reached | What to do |
| :--------------------------------------------------------------------- | :--------------- | :------------------------------------------------------------------------------------------------------------------- |
| The spend limit is reached | Spend limit | Raise it on the usage page above |
| It hit the session rate limit, or is rate limited delivering a message | Throughput limit | Wait the few seconds the reply names, then re-send. If your organization hits this often, contact your account team. |
## Per-channel limits
Per-channel limits and the per-channel spend breakdown are on the same usage page. See [Set spend limits](/docs/claude-tag/admins/restrict-access#set-spend-limits) for the full set of controls.
## Attribute costs by channel
Channel work can't be attributed to individual users. It bills to your organization's usage balance, not to any user's seat, and often has no single requesting user (several people contribute to one thread, and scheduled jobs run without anyone asking). The channel is the unit you can attribute.
The usage page at [`claude.ai/admin-settings/usage/claude-tag`](https://claude.ai/admin-settings/usage/claude-tag) shows spend broken down by channel.
To attribute spend to teams or departments for showback or chargeback reporting, structure channels so each maps to one team or department, and give those channels [their own scopes](/docs/claude-tag/admins/attach-to-scope). The per-channel breakdown then reads as your per-team report, and per-channel spend limits act as team-level budgets.
DMs are separate. A DM bills to the sender's own seat, not to the organization's usage balance.
## Related resources
* [See it work](/docs/claude-tag/admins/test-it): run a first task in the pilot channel
* [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access#set-spend-limits): per-channel limits and the usage page in full
claude-tag/admins/setup-overview First recorded · 198 lines, first recorded
# Set up Claude Tag ## Before you start ## Setup steps ### Pair your Slack workspace ### Choose Claude's first tools ### Connect GitHub ### Create accounts for the tools you chose ### Launch Claude Tag ## Change a setting after setup ## Test that setup worked ## After setup ## Common setup issues ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Set up Claude Tag
> Set up Claude Tag for your organization: pair your Slack workspace, give Claude access to your tools, set a spending limit, and launch. See prerequisites and each step in detail.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Claude Tag is Claude working in your team's Slack channels, with its own accounts in your tools.
Open [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). The page opens on setup until your first workspace is paired. It shows a step list, an FAQ, and a **Start setup** button (**Resume setup** if you started earlier without finishing). If you see **View setup guide** and **Go to chat** buttons instead, your signed-in account can't run setup; start at [Common setup issues](#common-setup-issues). Setup walks you through each step:
* **[Pair your Slack workspace](#pair-your-slack-workspace)**: install the Slack app and link it with a pairing code
* **[Choose Claude's first tools](#choose-claude%E2%80%99s-first-tools)**: pick two apps Claude will work in
* **[Connect GitHub](#connect-github)**: install the Claude GitHub App, or grant repositories if it's already linked
* **[Create accounts for Claude's other tools](#create-accounts-for-the-tools-you-chose)**: give Claude its own account in each tool you picked and connect the credentials
* **[Launch Claude Tag](#launch-claude-tag)**: set a spending limit and turn on Claude Tag
The rest of this page covers [what to have ready before you start](#before-you-start), [each step in detail](#setup-steps), and [common setup issues](#common-setup-issues).
<Note>If your team already uses the earlier Claude in Slack, the same steps apply and your existing app stays; see [Migrate from the earlier app](/docs/claude-tag/admins/migrate-from-earlier) for what changes.</Note>
## Before you start
| Prerequisite | Why you need it | If you don't have it |
| :------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A **Team or Enterprise plan** on claude.ai | Claude Tag is available on Team and Enterprise plans, on Anthropic's first-party service. It isn't available on individual plans (Free, Pro, or Max), or for third-party deployments. | Start a Team or Enterprise plan at [claude.com/pricing](https://claude.com/pricing) |
| A Claude organization **without Zero Data Retention (ZDR)** | Claude Tag stores channel memory and session transcripts, which ZDR doesn't permit. | Claude Tag isn't available to ZDR organizations |
| **Routines** enabled for your Claude organization | Claude Tag requires Routines to be enabled for your organization. Until it is, Claude answers every mention and DM with a reply that it's unavailable and does no work. | An admin enables Routines at [`claude.ai/admin-settings/claude-code`](https://claude.ai/admin-settings/claude-code) |
| **Owner** role in the Claude organization you're setting up | Pairing a workspace and creating Access bundles are Owner-only writes; an Admin can view settings but not complete setup. Roles are per organization, so being an Owner elsewhere doesn't carry over. | Ask an Owner to run setup, or have one promote you at [`claude.ai/admin-settings/members`](https://claude.ai/admin-settings/members) |
| A **Slack workspace admin** | Running `@Claude connect` requires a Slack workspace admin; installing the app usually does too (most workspaces require admin approval for new apps) | If that's someone else, [send them the install request](/docs/claude-tag/admins/pair-workspace#send-the-install-request-to-your-slack-admin) early (app approval can take time), and plan to be online together when you [pair your Slack workspace](#pair-your-slack-workspace); pairing codes expire 15 minutes after they're issued |
| **Usage credits** (Team plans) | Channel work draws from your organization's usage balance; on a Team plan nothing runs until credits are loaded | Check whether your organization has a [launch usage credit](https://support.claude.com/en/articles/15575654-claude-tag-launch-promo-for-claude-team-and-enterprise) before buying; otherwise, buy credits at [`claude.ai/admin-settings/usage`](https://claude.ai/admin-settings/usage) |
| *(Optional)* The **Claude GitHub App** linked to your Claude organization | Linking GitHub before you start turns setup's GitHub step into repository selection, so you can grant repositories there instead of installing the app mid-setup | [Link your GitHub organization](/docs/claude-tag/admins/configure-github#link-your-github-organization) first, or grant repository access after setup |
| *(Optional)* A **channel to test in** | You'll invite Claude to a channel to [test](#test-that-setup-worked) that setup worked | Create a private Slack channel for the pilot, or pick any existing one |
If any of your services restrict traffic by IP, file the [network requirements](/docs/claude-tag/admins/network-requirements) request with your network team early; in many organizations, IP allowlist changes take days to approve.
## Setup steps
All steps run on one page. Everything you set is saved automatically, so you can leave and resume setup later. Each section below shows what you'll see and what to do.
### Pair your Slack workspace
A Slack workspace is your team's space in Slack, at an address like `your-team.slack.com`; it contains all your channels. Pairing links one workspace to your Claude organization so `@Claude` can run in its channels and usage bills to your organization.
This step shows four numbered substeps. The code is created in Slack and redeemed back on this setup page:
<Steps>
<Step title="Add the Claude app to Slack">
Click **Add the Claude app** to open the Slack Marketplace listing, then click **Add to Slack** there and approve the permissions.
</Step>
<Step title="Send `@Claude connect` as a new channel message">
Copy the message shown and send it in any channel of the workspace you just installed in, with no other text, as a new top-level message or in a thread where Claude isn't already working. Claude replies with a pairing code valid for 15 minutes.
Pick a channel that belongs to just that workspace. Claude can decline to reply in [guest and shared channels](/docs/claude-tag/admins/troubleshooting#guest-and-shared-channels).
Only a Slack workspace admin (or Grid org admin) can run `@Claude connect`; anyone else gets a message naming who to ask. If that's not you, [send them the install request](/docs/claude-tag/admins/pair-workspace#send-the-install-request-to-your-slack-admin) and have them return the code.
</Step>
<Step title="Paste the pairing code">
Back on the setup page, paste the code into the input field (the placeholder reads `workspace_…`).
</Step>
<Step title="Choose where Claude runs">
Under **Choose where Claude can reply when tagged**, select **Entire workspace (recommended)** or **Specific channel** (which asks for channel IDs).
</Step>
</Steps>
Click **Pair workspace**. A confirmation screen shows the pairing worked; select **Next: Choose Claude's tools**.
See [Pair your Slack workspace](/docs/claude-tag/admins/pair-workspace) for the Slack-admin handoff template, what to do if `@Claude connect` fails, and pairing on Enterprise Grid.
### Choose Claude's first tools
Claude works in your tools with its own accounts, so everything it does is recorded under its own name. On this step you pick those tools; connecting them happens in a [later step](#create-accounts-for-the-tools-you-chose).
GitHub isn't in the list. You connect it in the [next step](#connect-github). The list suggests widely used tools; check the ones your team works in, or use **Search all tools** for a service that isn't shown. Pick two to unlock **Next: Connect GitHub**. You can add more at any time.
You can skip connecting the tools you pick and finish that after setup. Without any connected tools, Claude still works in Slack conversations and can use web search and a [default set of network hosts](/docs/claude-tag/admins/add-connections#allow-a-host-without-a-credential); it can't act in a tool until that tool is connected.
See [Give Claude access](/docs/claude-tag/admins/add-connections) for which services to connect first, and the [per-service connection guides](/docs/claude-tag/admins/connections/overview) for credential fields per tool.
### Connect GitHub
GitHub is managed through the Claude GitHub App rather than a credential, so it has its own step. What the step shows depends on whether the app is already linked to your Claude organization.
* **Not linked yet**: the step walks through installing the Claude GitHub App, with a message you can copy for the GitHub organization owner if that isn't you.
* **Already linked**: the step is titled **Choose your GitHub repos** and lists each installation, so you can grant every repository or only specific ones.
These grants apply to every channel Claude is in. You can [add repositories to specific channels later](/docs/claude-tag/admins/attach-to-scope), or skip this step and [configure GitHub access](/docs/claude-tag/admins/configure-github) after setup instead.
### Create accounts for the tools you chose
Claude needs its own account in each tool you picked, so you can always see what it did and limit what it reaches. [How agent identity works](/docs/claude-tag/concepts/agent-identity) explains this model.
<Steps>
<Step title="Set up an email for Claude">
Create an address like `[email protected]` with your email provider. Some tools support service accounts (tool-managed identities that don't need an email) instead.
</Step>
<Step title="Invite Claude to each tool">
In each tool you picked, create an account for that address, the same way you would for a new team member.
</Step>
<Step title="Connect each tool with Claude's credentials">
Each tool you picked is listed. Click **Connect** and enter the credential for the account you created (not your personal login).
</Step>
</Steps>
To finish this step later, select **Skip** and confirm past the warning that Claude won't be able to act in the unconnected tools.
See [Give Claude access](/docs/claude-tag/admins/add-connections) for how to create the accounts and what access to give them.
### Launch Claude Tag
Channel work draws from your organization's usage balance, not from individual seats; the spend limit you set here caps how much of that balance Claude Tag can use each billing period. (DMs run on the user's own claude.ai account and aren't capped by this limit.)
<Steps>
<Step title="Set monthly spend limits">
Choose from `$500`, `$1,000`, `$2,500` (the default), `$5,000`, **Unlimited**, or **Custom** (a US-dollar amount up to `$1,000,000`).
</Step>
<Step title="Let members know they can now tag Claude">
Choose whether Claude sends a DM to everyone in your Slack workspace after launch.
</Step>
<Step title="Click Launch Claude Tag">
Claude Tag turns on, and a confirmation screen summarizes what's connected. Claude is now reachable in the workspace you paired.
</Step>
</Steps>
To leave setup without turning Claude Tag on, select **Finish later**; everything you've set is saved, and the admin page shows a resume card that brings you back to where you left off.
If your organization buys usage credits by card in US dollars and has none loaded, a **Buy usage credits** step appears before launch instead of the spend limit picker; load credits, or select **Skip** to continue without. Invoiced organizations and those billing in other currencies get the spend limit picker regardless of balance.
See [Set a spend limit](/docs/claude-tag/admins/set-spend-limit) for what counts toward the cap, per-channel limits, and what users see when it's reached.
## Change a setting after setup
Everything you set during setup can be changed afterward on the [Claude Tag admin page](https://claude.ai/admin-settings/claude-tag).
| To change | Go to |
| :------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Pair another workspace, or disconnect one | The Slack row's **⋮** menu under **Where Claude Tag works** (**Disconnect** is under **Manage**); see [Manage workspaces](/docs/claude-tag/admins/workspaces) |
| The Access bundle's name, connections, domains, repos, plugins, or instructions | **Access bundles** in the left navigation, or any scope's panel on the **Slack** tab; see [Give Claude access](/docs/claude-tag/admins/add-connections) |
| The spending limit | [`claude.ai/admin-settings/usage/claude-tag`](https://claude.ai/admin-settings/usage/claude-tag); see [Set a spend limit](/docs/claude-tag/admins/set-spend-limit) |
| Whether Claude Tag is enabled at all | The **Enable Claude Tag for your organization** toggle at the top of the admin page |
## Test that setup worked
In Slack, in your pilot channel, run `/invite @Claude` and then `@Claude summarize this channel`.
An *is thinking…* status under your message means the app is installed and listening. A reply means the workspace is paired and the channel is on the new version. This task doesn't touch any connection, so it isolates pairing from credential issues.
The [See it work](/docs/claude-tag/admins/test-it) page has more prompts that run with no connections, and a per-connection test that proves each credential works.
## After setup
After your test passes, you can DM Claude in Slack with setup questions. These guides cover what's not part of initial setup:
| Guide | Do this when |
| :-------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Give Claude access](/docs/claude-tag/admins/add-connections) | You skipped connections during setup, or a team needs another tool connected |
| [Allow a host without a credential](/docs/claude-tag/admins/add-connections#allow-a-host-without-a-credential) | Claude reports a blocked host, or a channel needs to reach a site or API that doesn't take a credential |
| [Configure per-channel access](/docs/claude-tag/admins/attach-to-scope) | One channel needs more (or different) access than the default. Keep elevated credentials in private-channel scopes; the org baseline stays minimal. |
| [Configure GitHub access](/docs/claude-tag/admins/configure-github) | You didn't grant repository access during setup, or you need to add more repositories |
| [Restrict where Claude operates](/docs/claude-tag/admins/restrict-access) | Governance review: guest channels, member access, DM policy |
| [Customize](/docs/claude-tag/admins/customize) | Standing instructions, plugins, and what channel members can change |
There are two common ways to roll out from here:
| Pattern | What you do | What channel members experience |
| :----------------------- | :------------------------------------------------------------- | :--------------------------------------------------------------------------------------------- |
| Pilot first | One bundle on one workspace or channel; widen after validating | Claude appears in a few channels first, with capability growing as scopes are attached |
| Single bundle everywhere | One broad bundle at organization defaults | Every channel gets the same capability on day one. Fits orgs that already grant tools broadly. |
## Common setup issues
| You expected | But got | Do this |
| :----------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| The setup page at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag) | A page titled **Set up Claude Tag** with **View setup guide** and **Go to chat** buttons | Your signed-in account can't run setup, and **View setup guide** leads back to this guide. On a personal account (Free, Pro, or Max), [start a Team or Enterprise plan](https://claude.com/pricing) first. In a Team or Enterprise organization, ask an Owner to run setup. When the page shows a workspace switcher, your account also belongs to another Team or Enterprise organization; switch to it and retry. |
| A pairing code from `@Claude connect` | “Only Slack workspace admins (or Enterprise Grid org admins) can link this workspace to a Claude organization…” | The person who sent `@Claude connect` isn't a Slack workspace admin (or Grid org admin). [Send the request](/docs/claude-tag/admins/pair-workspace#send-the-install-request-to-your-slack-admin) to someone who is. |
| A pairing code | “…installation is out of date” | The app was updated with permissions your workspace hasn't approved yet. A Slack admin approves the update or reinstalls the app, then sends `@Claude connect` again. See [both remedies](/docs/claude-tag/admins/pair-workspace#if-@claude-connect-says-the-installation-is-out-of-date). |
| The Slack row under **Where Claude Tag works** to show your workspace as connected | It still shows **Not connected** | The code may have expired (codes last 15 minutes) or come from a different workspace. Send `@Claude connect` again for a fresh code. |
| A pairing code | A message about guests, or about the channel being shared across workspaces | Send `@Claude connect` again in a channel with no guests that belongs to a single workspace. Match the exact message in [Guest and shared channels](/docs/claude-tag/admins/troubleshooting#guest-and-shared-channels) for the fix that fits it. |
| A connected tool to work in your test | “I can't reach…” | Claude isn't told about a connection added after the thread started. Ask it to use the service by name, or start a fresh thread. |
| The **Where Claude Tag works** section with a **+ Connect** button | Only the legacy Claude in Slack toggles | Your organization isn't enabled for Claude Tag. Contact your account team. |
| Claude to respond in Slack | "Claude Tag has been turned off for your Claude organization…" | The **Enable Claude Tag for your organization** toggle is off. An Owner turns it on at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). See [the troubleshooting entry](/docs/claude-tag/admins/troubleshooting#claude-tag-is-turned-off-for-your-organization). |
| Claude to respond in Slack | "Claude Tag is unavailable because Routines aren't enabled for your organization…" | Routines isn't enabled for your Claude organization, which Claude Tag requires. An admin enables Routines at [`claude.ai/admin-settings/claude-code`](https://claude.ai/admin-settings/claude-code), then anyone can mention `@Claude` again. See [the troubleshooting entry](/docs/claude-tag/admins/troubleshooting#claude-tag-is-unavailable-because-routines-are-not-enabled). |
| Claude to respond in Slack | "Claude in Slack is not available for your organization" or "Claude isn't available for organizations with restricted compliance settings." | The paired Claude organization has a restricted compliance configuration, such as Zero Data Retention (ZDR), that Claude Tag can't run under. No setting lifts this; contact your account team. See [the troubleshooting entry](/docs/claude-tag/admins/troubleshooting#restricted-compliance-settings-block-claude-tag). |
| The **Slack** tab to list your scopes | "Couldn't load Slack scopes. Reload the page to try again." | A page-load fetch failed; reload. Your configuration is intact. |
| A reply in your test channel | "Couldn't check this channel just now" | The pre-reply guest check briefly failed. Mention `@Claude` again. |
| A reply in your test channel | "Something went wrong starting a session" | Retry first. If it persists, see [the session-start entries](/docs/claude-tag/admins/troubleshooting#something-went-wrong-starting-a-session). |
## Related resources
* [Network requirements](/docs/claude-tag/admins/network-requirements): what your services must allowlist so Claude can reach them
claude-tag/admins/skills-repo First recorded · 81 lines, first recorded
# Set up a skills repository Claude can update ## Set up the skills repository ## How updates propagate ## Prompt Claude to propose updates ## Why a repository instead of uploading skills ## What belongs in the repository ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Set up a skills repository Claude can update
> Put your org's Claude Tag skills in a git repository with auto-sync, grant Claude write access, and Claude can open pull requests to improve its own skills from what it learns in channels.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
A **skill** is a set of instructions that teaches Claude how to use a specific tool or follow a specific process (for example, which Datadog endpoints answer which questions, or your org's incident-response runbook). Claude Tag uses the same [skills format as Claude Code](https://code.claude.com/docs/en/skills). A **plugin** bundles one or more skills together.
You can upload skills one at a time in the console, but putting them in a git repository means Claude can open pull requests to improve them from what it learns working in your channels. You review the PR; once merged, every channel picks up the update.
## Set up the skills repository
<Steps>
<Step title="Create the repository">
A new GitHub repository in your organization, with one folder per plugin. Each plugin bundles one or more skills.
</Step>
<Step title="Register the repository as a plugin marketplace">
On the **Plugins** page at [`claude.ai/admin-settings/plugins`](https://claude.ai/admin-settings/plugins), click **Add plugins** and choose **Sync from GitHub**. Select the repository, leave **Sync automatically** on (the default), and click **Create**.
</Step>
<Step title="Grant Claude write access to the repository">
Open an [Access bundle](/docs/claude-tag/admins/add-connections#your-first-access-bundle), go to its **Repositories** tab, and add the repository. The Claude GitHub App must already be linked to your GitHub organization; see [Configure GitHub access](/docs/claude-tag/admins/configure-github).
</Step>
<Step title="Attach the plugins to a scope">
In the same bundle's **Plugins** tab, toggle on the plugins from your new marketplace; each is off until you enable it. See [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins).
</Step>
</Steps>
**You'll see:** the repository appears in the bundle's Repositories list, and the marketplace's plugins appear in the bundle's Plugins tab, each labeled with the marketplace name.
## How updates propagate
Once the repository is set up, Claude can propose changes and they reach channels automatically after you merge:
| Stage | What happens |
| :------------------------ | :----------------------------------------------------------------------------------------------------------------------------------- |
| Claude works in a channel | Using the skills currently attached to that scope |
| Claude proposes an update | Opens a pull request against the skills repository, under the Claude GitHub App identity, linked back to the thread that prompted it |
| You review and merge | The PR is yours to approve, edit, or close, like any contributor's |
| The marketplace syncs | On push to the default branch, the updated plugin syncs to your organization automatically |
| New threads pick it up | The next thread in any covered channel uses the updated skill |
Every skill change reaches channels only after a human approves the merge; Claude opens the PR, you merge it.
## Prompt Claude to propose updates
Claude won't open skill PRs unprompted. Ask in the channel when something it learned should stick:
```text wrap theme={null}
@Claude that worked. Open a PR to the skills repo so the Datadog skill includes that query pattern.
```
Or set a routine that sweeps a channel's corrections into proposed updates:
```text wrap theme={null}
@Claude every Friday, review what you got wrong in this channel this week and open one PR to the skills repo with the fixes.
```
## Why a repository instead of uploading skills
You can also upload individual skills in the console without a repository. The repository pattern is worth the setup because Claude can propose changes to it, every change goes through version control and code review, and you can attach the same skills to multiple bundles without uploading them again.
## What belongs in the repository
| Put in the skills repo | Put in channel memory instead |
| :------------------------------------------------------------ | :------------------------------------- |
| How to call a specific API correctly | This channel's preferred output format |
| A runbook that any team would reuse | A one-off decision this channel made |
| Tool-specific gotchas (auth headers, pagination, rate limits) | Who owns what in this team |
Skills in the repository reach every channel under the scope.
## Related resources
* [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins): how plugins and skills load into a scope
* [Configure GitHub access](/docs/claude-tag/admins/configure-github): granting Claude write access to a repository
* [What Claude Tag remembers](/docs/claude-tag/users/memory): when channel memory is the right place instead
claude-tag/admins/test-it First recorded · 106 lines, first recorded
# See Claude Tag work ## Run tasks that need no connections ## Test the connections you added ## If a test fails ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# See Claude Tag work
> Run Claude Tag's first tasks in a pilot channel before any connection exists. See copy-paste prompts that run on Slack content alone, per-connection checks, and what to do if a step fails.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
<div className="tm-stepbar">
<a className="tm-stepbar-seg tm-done" href="/docs/docs/claude-tag/admins/pair-workspace">1 · Pair workspace</a>
<a className="tm-stepbar-seg tm-done" href="/docs/docs/claude-tag/admins/add-connections">2 · Give access</a>
<a className="tm-stepbar-seg tm-done" href="/docs/docs/claude-tag/admins/set-spend-limit">3 · Spend limit</a>
<a className="tm-stepbar-seg tm-current" href="/docs/docs/claude-tag/admins/test-it">4 · See it work</a>
</div>
<div className="tm-stepmeta">
<div className="tm-stepmeta-row"><span className="tm-stepmeta-label">Role you need</span><span>Anyone in the pilot channel can run the prompts; you'll want Owner access handy to fix anything they surface</span></div>
<div className="tm-stepmeta-row"><span className="tm-stepmeta-label">Before this step</span><span>Workspace paired and a <a href="/docs/docs/claude-tag/admins/set-spend-limit">spend limit</a> set</span></div>
<div className="tm-stepmeta-row"><span className="tm-stepmeta-label">Do I need this?</span><span><span className="tm-meta-pill tm-meta-pill-req">Required</span>The only way to know the setup holds together before rolling out to more channels.</span></div>
</div>
Claude starts taking work the moment the workspace is paired, with or without connections. This step has two parts: tasks that run on the channel's own content, then a check for each connection you added.
## Run tasks that need no connections
Add Claude to the pilot channel:
```text wrap theme={null}
/invite @Claude
```
Then paste the recap task. It uses only the channel's history, so it confirms the app install, the scope, and the session machinery before any connection is in play.
```text wrap theme={null}
@Claude summarize what this channel decided this week and list any open questions
```
**Passed when:** an "is thinking…" line appears under the message, Claude posts its work in the thread, and delivers a summary.
The recap proves the setup; the prompts below preview the work your channels can hand Claude before anything is connected. Each links to a use case page with the full setup.
Roll up the channel's open requests, the one-off version of [Triage requests](/docs/claude-tag/users/use-cases/triage-requests):
```text wrap theme={null}
@Claude post a summary of this week's requests in this channel: how many, top themes, and anything still unrouted
```
Turn a settled discussion into a document, from [Turn threads into docs and tickets](/docs/claude-tag/users/use-cases/create-artifacts):
```text wrap theme={null}
@Claude turn this thread into a one-page decision doc: what we decided, the options we rejected, and why.
```
Ask for a personalized menu of next tasks, from the [prompt library](/docs/claude-tag/users/prompt-library):
```text wrap theme={null}
@Claude learn what you can about my role from this workspace, then tell me three tasks you could take off my plate this week.
```
## Test the connections you added
If you skipped connections during setup, you're done; come back to this section after you [add a connection](/docs/claude-tag/admins/add-connections). For each connection, run a task in a new thread.
<Steps>
<Step title="Ask what the channel can reach">
```text wrap theme={null}
@Claude what can you access from this channel?
```
Claude replies with the systems available there.
</Step>
<Step title="Ask for data from the connection">
Pick one connection and ask for something a read-only credential can do, like the latest items from an issue tracker or a single row count from a warehouse.
```text wrap theme={null}
@Claude pull the five most recent items from our issue tracker and post them here
```
For a GitHub repository grant, ask about pull request state:
```text wrap theme={null}
@Claude list the open pull requests in your-org/your-repo and who each one is waiting on
```
</Step>
<Step title="Check the service's own audit log">
Confirm the action appears in that service's audit log under the service account you provisioned. That entry proves the credential chain end to end and is the trail your security team reads later.
</Step>
</Steps>
**Passed when:** the connection responds, and the action shows in that service's audit log under your service account.
## If a test fails
Most first-task failures trace to one of three causes, in order of likelihood:
* **No response at all**: the channel isn't covered by any scope you've configured. Check the workspace appears under **Claude Tag's access** on the **Slack** tab in admin settings.
* **Claude responds but can't reach a service you connected**: Claude isn't told about a connection added after the thread started. Ask it to use the service by name, or start a fresh thread, before investigating anything else.
* **An error message**: the message text names what's missing (a connection, [a host on the allowlist](/docs/claude-tag/admins/add-connections#add-a-domain), or a permission). Fix that piece and try again.
## Related resources
* [Getting started for users](/docs/claude-tag/users/getting-started): what to send the first people in
* [Use case library](/docs/claude-tag/users/use-cases): tasks to hand the pilot channel, with the prompts to paste
* [Prompt library](/docs/claude-tag/users/prompt-library): every prompt on one page, each with why it works
claude-tag/admins/troubleshooting First recorded · 610 lines, first recorded
# Troubleshoot Claude Tag setup ## Slack app permissions ### This workspace's Claude app installation is out of date ### Unapproved permissions requested ### Only Slack workspace admins or Grid org admins can link this workspace ### Missing the required Slack permission (users:read) ### The audit log shows Claude joining channels no one invited it to ## Guest and shared channels ### Claude doesn't respond in channels that include guests ### Couldn't check this channel just now ### This channel is shared across multiple workspaces ### This channel is shared among several Claude workspaces ### This channel is shared across several Slack workspaces ### Claude isn't available in channels shared across your Enterprise Grid ### This channel is now shared across multiple workspaces ## Console errors ### Couldn't load Slack scopes ### The page shows your plan as Free ## Nothing responds ### Claude went silent in one thread, but responds elsewhere ### Claude is silent everywhere on Enterprise Grid ### This workspace isn't set up for Claude Tag yet ### Claude Tag is turned off for your organization ### Claude Tag is unavailable because Routines are not enabled ### Restricted compliance settings block Claude Tag ### Claude is disabled in this channel ## Access and connections ### Claude says a host isn't allowed or it can't reach the internet ### A connection works in one channel but not another ### GitHub doesn't work in this channel ### I hit an authentication error and couldn't finish this turn ### Your Claude account is connected, but it doesn't have access in this organization ## Session start errors ### Still waiting for available capacity ### Session failed to start: the session container never connected ### Something went wrong starting a session ### Channel sessions use the wrong environment, or can't find one ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Troubleshoot Claude Tag setup > Error messages from Claude Tag setup and what fixes each. Covers permission mismatches, GitHub access gaps, session start failures, and account errors. export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>; <BetaNote /> This page covers errors you might hit setting up and administering Claude Tag: Slack app permissions, guest and shared channels, console errors, channels and threads where nothing responds, access and connections, and session starts. Each entry has the same three parts: what you see, what it means, and how to resolve it. <Note>For problems people can resolve on their own in a channel, like a missing reply or a thread that lost its work, see [Troubleshoot Claude Tag in channels and DMs](/docs/claude-tag/users/troubleshooting).</Note> If someone reports that Claude can't reach a service you connected, check two things before anything else: * The connection is in a [bundle attached to that channel's scope](/docs/claude-tag/admins/attach-to-scope). * The test ran in a new thread; an existing thread isn't told about a connection added after it started, though the connection works there if the request names the service. ## Slack app permissions Most errors in this section appear when Claude needs a Slack permission that wasn't part of the app when your workspace approved it. For those, the fix is a Slack workspace admin re-approving the Claude app from [Claude for Slack](https://claude.com/claude-for-slack), which grants the current permission set. Nothing else changes, and existing settings carry over. ### This workspace's Claude app installation is out of date **What you see** Claude replies to `@Claude connect`: > This workspace's Claude app installation is out of date — it hasn't granted the \[permission name] permission(s). I can't create a link code until a Slack admin reinstalls the Claude app or approves its updated permissions. Once that's done, ask me to link again. Two phrases in the message are links: * **reinstalls the Claude app** opens the reinstall flow. The fix below starts from this link. * **approves its updated permissions** opens Slack's Manage apps page for the workspace. On Enterprise Grid the message names "this Slack organization's Claude app installation" and asks a Slack organization admin to reinstall the org-wide app. The org-wide reinstall works from inside one of the Grid's workspaces with **Install to entire organization**, following the steps in [Claude is silent everywhere on Enterprise Grid](#claude-is-silent-everywhere-on-enterprise-grid). Sometimes the reply issues a code anyway, with a footnote that the install "is out of date". The reinstall steps below clear the footnote too. **What it means** Claude needs a Slack permission that wasn't part of the app when your workspace approved it, so the app was never granted it. Claude can't issue a link code until the updated permission set is approved. **How to resolve** A Slack workspace admin runs these three steps: 1. Click the **reinstalls the Claude app** link in the reply, or open [Claude for Slack](https://claude.com/claude-for-slack) and click **Add to Slack**. Don't uninstall first; this installs over the existing app, so your settings carry over. 2. Approve the consent screen Slack shows; it lists each permission being added. If Slack shows **Unapproved permissions requested** instead of completing, see [Unapproved permissions requested](#unapproved-permissions-requested). 3. Run `@Claude connect` again. If the reinstall worked, the reply contains a pairing code (the link code the original message said it couldn't create) instead of this message. Send that pairing code to whoever runs Claude setup in the console; it expires after 15 minutes. Slack's **Manage apps** page lists the permissions the app requests, not the permissions your workspace has granted, so seeing the missing permission listed there doesn't mean it's approved. The grant happens on the consent screen. For the app's permissions in one place, see [What the Claude Slack app can access](/docs/claude-tag/admins/for-slack-admins). ### Unapproved permissions requested **What you see** **Unapproved permissions requested** is a message from Slack, not a Claude reply. It appears in either of two places: * On the consent screen after **Add to Slack**, including for a workspace admin who approved the app before * As the pending status on the Claude entry under **Settings & administration** → **Manage apps** → **App requests**, in workspaces that require admin approval for apps **What it means** The permissions the Claude app requests have changed since your workspace approved it, and Slack requires a fresh approval for the additions. The consent screen lists each permission being added, so you can review exactly what you're granting before approving; approval applies only to the Claude app already installed in your workspace. **How to resolve** A Slack workspace admin approves the Claude app's updated permissions in either place: * In Slack, go to **Settings & administration** → **Manage apps** → **App requests** and approve the Claude request. * Or open [Claude for Slack](https://claude.com/claude-for-slack), click **Add to Slack**, and approve the consent screen. Both paths grant the same permissions, and neither requires uninstalling first. If the approval worked, `@Claude connect` returns a pairing code without mentioning the installation again. ### Only Slack workspace admins or Grid org admins can link this workspace **What you see** Claude replies to `@Claude connect`: > Only Slack workspace admins (or Enterprise Grid org admins) can link this workspace to a Claude organization. Please ask a workspace admin to mention me with `@Claude connect`. **What it means** Slack reports that the person who ran `@Claude connect` doesn't hold the workspace admin role, so no pairing code was issued. This reply is itself the signal, and there's nothing else to check. The Claude Owner role doesn't satisfy the check; it's the Slack-side role that matters. **How to resolve** Have a Slack workspace admin run `@Claude connect` instead. On Enterprise Grid, a Grid organization admin works too. If the fix worked, their reply contains a pairing code. ### Missing the required Slack permission (users:read) **What you see** Claude replies in the channel: > Claude can't check this channel for guests because it's missing the required Slack permission (users:read). A workspace admin needs to reinstall Claude to grant it. If the failure happens while Claude is posting a message rather than replying, there's no fixed message; Claude describes the problem in its own words, and the underlying error it relays reads "message not delivered: Claude can't check this channel for guests because the Slack app is missing a permission (users:read); a workspace admin must reinstall Claude to grant it." **What it means** **Allow Claude to respond to guests** is set to **Restrict** for this channel's [scope](/docs/claude-tag/concepts/glossary#scope), so Claude checks the channel for guests before replying, and this install predates the `users:read` permission that check needs. **How to resolve** Re-approve the app from [Claude for Slack](https://claude.com/claude-for-slack). Don't uninstall first; the re-approval installs over the existing app. If the fix worked, a mention in the affected channel gets a reply instead of the permission message. ### The audit log shows Claude joining channels no one invited it to **What you see** Slack's audit log shows Claude joining a channel with no inviter recorded, and no one in the workspace remembers adding it. **What it means** A member selected **Add to channel** on a channel Claude suggested in a direct message. Claude's welcome message, the introduction it posts when a member first opens a direct message with it, suggests a few public channels, each with an **Add to channel** button. Selecting one directs Claude to add itself to that channel. Claude performs that join with its own `channels:join` permission, so Slack's audit log records the join as the Claude app and shows no inviter; the member's selection is not visible in Slack's log. Claude never joins a channel unprompted. [What the Claude Slack app can access](/docs/claude-tag/admins/for-slack-admins) covers how members add it. **How to resolve** Nothing is misconfigured, and no setting changed. If Claude shouldn't be in the channel, remove it with `/remove @Claude`, or [set the scope's Claude Tag version to Off](/docs/claude-tag/admins/restrict-access#quiet-or-remove-claude-tag) so it stops responding there even if it's added again. If you want every join in the audit log attributed to a person, ask members to add Claude with `/invite @Claude` rather than the buttons; Slack records an invite as the inviting member's action. ## Guest and shared channels Claude checks a channel for guests and for sharing across workspaces before it replies there. The messages those checks post look alike, but most are refusals and one is a notice on a reply Claude goes on to give. Match the exact message text before changing anything; each message has a different cause and a different fix. A channel created at the Enterprise Grid organization level rather than inside a single workspace counts as shared across workspaces even when it appears in only one workspace's sidebar, so a channel can hit the shared-channel messages below despite looking like an ordinary single-workspace channel. ### Claude doesn't respond in channels that include guests **What you see** Claude replies in the channel: > Claude doesn't respond in channels that include guests. You can remove the guests from this channel (Channel details -> Members -> filter by "guests"), or a claude.ai organization owner can allow it here. In the message, "here" is a link to the guest setting described below. The role it names is a claude.ai organization owner, not a Slack admin. **What it means** The channel includes at least one Slack guest account, and **Allow Claude to respond to guests** is set to **Restrict** for this channel's scope. **Restrict** is the default. **How to resolve** Either fix works: * Remove the guests from the channel, or move the conversation to a channel with no guests; this changes no settings, so no other channel is affected. * Or set **Allow Claude to respond to guests** to **Allow** for the scope covering this channel. The setting is at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, in the scope's collapsed **Advanced** section. **Allow** applies to every guest channel that scope covers, and guests there can see Claude's replies and interact with it. To limit it to one channel, set it on the channel's own scope. See [restrict guest channels](/docs/claude-tag/admins/restrict-access#restrict-guest-channels) for the full exposure picture. **Allow** restores replies, not workspace search. Claude can't search the workspace from a channel that includes guests, even when the setting is **Allow**. Removing the guests restores search as well. If the fix worked, a mention in the channel gets a reply. ### Couldn't check this channel just now **What you see** Claude replies in the channel: > Couldn't check this channel just now. Please try again in a moment. **What it means** Claude couldn't complete its check for guests in this channel; either the guest-policy lookup or the Slack membership check briefly failed, so Claude declined this reply rather than risk posting where a guest might see it. This isn't a configuration error. **How to resolve** 1. Mention Claude again; the retry usually clears it. 2. If one channel hits this repeatedly, the membership check may be failing on an unusually large channel. Setting **Allow Claude to respond to guests** to **Allow** on the channel's scope removes the guest check for every channel that scope covers, which usually stops the message from recurring; weigh [what Allow exposes](#claude-doesn%E2%80%99t-respond-in-channels-that-include-guests) first. ### This channel is shared across multiple workspaces **What you see** Claude replies in the channel: > This channel is shared across multiple workspaces, and Claude can't verify whether it includes guests, so Claude can't respond here. The same check also refuses requests made from another conversation, such as asking Claude to post a message in the channel, with a message ending "shared across multiple workspaces and Claude can't verify whether it includes guests". **What it means** This message comes from the guest check, not from workspace sharing. **Allow Claude to respond to guests** is set to **Restrict** for this channel's scope, and the channel's membership can't be verified, most often because the channel is shared across an Enterprise Grid organization, so Claude declines. **How to resolve** Use a channel that belongs to a single workspace. Setting the scope's guest setting to **Allow** removes the guest check that posts this message, but a Grid-shared channel still doesn't behave like a single-workspace one. When its workspaces connect to different Claude organizations, Claude posts the refusal in [This channel is shared among several Claude workspaces](#this-channel-is-shared-among-several-claude-workspaces) instead of replying. When they all share your one Claude organization, Claude replies with only your organization's default access and settings, described in [This channel is shared across several Slack workspaces](#this-channel-is-shared-across-several-slack-workspaces). ### This channel is shared among several Claude workspaces **What you see** Claude replies in the channel: > This channel is shared among several Claude workspaces, so Claude cannot respond here. The reply appears only when someone mentions Claude directly, or addresses it in a thread it already joined. Other messages in the channel get no reply at all. **What it means** The channel is shared across more than one Slack workspace in your Enterprise Grid, and those workspaces are paired to different Claude organizations. No single organization's settings cover the channel, so Claude declines regardless of the guest policy or any scope setting. Claude also declines when it can't confirm that the workspaces share one Claude organization. Two similar messages come from different situations. [This channel is shared across multiple workspaces](#this-channel-is-shared-across-multiple-workspaces) is the guest case, and [This channel is shared across several Slack workspaces](#this-channel-is-shared-across-several-slack-workspaces) is the case where every workspace belongs to your one Claude organization, so Claude replies. **How to resolve** Move the conversation to a channel that belongs to a single workspace, or to a DM. ### This channel is shared across several Slack workspaces **What you see** Claude posts a notice in the thread, then answers the request: > This channel is shared across several Slack workspaces, so Claude is using only your organization's default Slack access and settings here — not any workspace- or channel-specific repos, instructions, or memory you've configured. **What it means** The channel is shared across more than one Slack workspace, and every one of those workspaces belongs to your Claude organization. Claude works there, but only with the access and settings on your [**Default Slack access**](/docs/claude-tag/admins/attach-to-scope) scope. Bundles, instructions, and memory attached to a workspace or to this channel don't apply. The notice posts at most about once a month per channel, so replies in this channel run under the same defaults even when no notice accompanies them. **How to resolve** Nothing is broken. To use a channel's own repositories, connections, or instructions, work in a channel that belongs to a single workspace, or add what the channel needs to the **Default Slack access** scope. In a single-workspace channel, requests use that channel's own configuration and the notice doesn't appear. ### Claude isn't available in channels shared across your Enterprise Grid **What you see** You ask Claude to do something that involves a channel shared across your Enterprise Grid, and the refusal names the request it declined and ends: > Claude isn't available in channels shared across your Enterprise Grid **What it means** The request needed Claude to act in a channel that's shared across more than one workspace in your Enterprise Grid. The message appears in whichever conversation you made the request; the entries above cover the replies Claude posts in the shared channel itself. This refusal covers both sharing cases. Even when the shared channel's workspaces all belong to your one Claude organization and Claude answers direct mentions there, Claude still declines requests made from another conversation. **How to resolve** Point the request at a channel that belongs to a single workspace, or move the conversation to one. ### This channel is now shared across multiple workspaces **What you see** Claude posts in the thread: > This channel is now shared across multiple workspaces, so this thread's earlier session can't continue here. Please @-mention me in a new thread. **What it means** The channel became shared after this thread's session started, so the session is still bound to one workspace's configuration and can't continue in front of every workspace that now sees the channel. **How to resolve** Mention Claude in a new thread; new threads start under the channel's current sharing. ## Console errors ### Couldn't load Slack scopes **What you see** A banner at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, reads: > Couldn't load Slack scopes. Reload the page to try again. **What it means** The request that loads your scope list from Claude's backend failed; it isn't a Slack permissions problem, and your configuration is intact. The page shows the error instead of an empty list so that a failed load doesn't look like an unconfigured workspace. **How to resolve** 1. Reload the page. If the reload worked, the scope list renders. That's the usual outcome. 2. If the banner persists across reloads, check [`status.anthropic.com`](https://status.anthropic.com) for an active incident and try again in a few minutes. 3. If it continues with no incident posted, contact [Anthropic support](https://support.claude.com) with the time it occurred. ### The page shows your plan as Free **What you see** You open the admin console expecting your organization's settings and land on your personal account settings instead, showing the **Free plan** and no Claude Tag section anywhere. **What it means** You're signed into a personal claude.ai account, which is a separate workspace from your organization. claude.ai sends a personal account to its own settings page rather than to the admin console, so the **Free** you see is your personal account's plan, not a broken admin page. **How to resolve** Use the workspace switcher in claude.ai to switch to your organization, then reopen [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). If the switch worked, the page shows your organization's plan and the Claude Tag settings. ## Nothing responds
Cut at 300 lines. The page has the rest.
claude-tag/admins/workspaces First recorded · 67 lines, first recorded
# Manage workspaces and versions ## Pair another workspace ### Pair an Enterprise Grid ## Set the version for a scope ## Revoke a pairing ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Manage workspaces and versions
> Connect more Slack workspaces or an Enterprise Grid to Claude Tag, choose which Claude version each channel uses, and disconnect a workspace.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
This page covers managing Slack workspace pairings after initial setup: adding more workspaces, choosing which Claude Tag version each one runs, and disconnecting one.
A workspace pairing links one Slack workspace (or Enterprise Grid) to your Claude organization so `@Claude` can run there. Your first pairing was created during [setup](/docs/claude-tag/admins/setup-overview). To add more, you must be an Owner in your Claude organization, and a Workspace Admin (or Grid Org Admin) in the Slack workspace you're adding.
## Pair another workspace
You can connect multiple Slack workspaces to one Claude organization. After the first pairing, the page no longer opens on setup, and the Slack row appears under **Where Claude Tag works**.
The reverse doesn't hold. A Slack workspace or Enterprise Grid pairs with one Claude organization at a time.
To move a pairing to a different Claude organization, an Owner in the organization that currently holds it must [disconnect it](#revoke-a-pairing) first. Until then, the console refuses the new pairing as [already connected to a different organization](/docs/claude-tag/admins/pair-workspace#if-the-console-says-“already-connected-to-a-different-organization”). Once the pairing moves, changes the previous organization's admins make in their settings no longer reach that workspace.
If your company has more than one Claude organization (a subsidiary with its own, for example), agree on which one holds the pairing before connecting.
<Steps>
<Step title="Open the pairing dialog">
At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), under **Where Claude Tag works**, either select **+ Connect** at the top right, or open the **⋮** menu on the Slack row and select **+ Add workspace**.
</Step>
<Step title="Get a pairing code from Slack">
In any channel of the new workspace, send `@Claude connect` with no other text, as a new top-level message or in a thread where Claude isn't already working, then paste the code Claude sends you into the dialog.
Pick a channel that belongs to just the new workspace. Claude can decline to reply in [guest and shared channels](/docs/claude-tag/admins/troubleshooting#guest-and-shared-channels).
</Step>
</Steps>
<Note>If your organization used the earlier Claude in Slack app, the dialog header reads **Switch to Claude Tag** instead of **Set up Claude Tag for your workspace**. The steps are the same, and the new workspace is added alongside your existing one, not in place of it.</Note>
**You'll see:** the new workspace in the Slack row's connected list and as a scope in the **Claude Tag's access** section.
### Pair an Enterprise Grid
When a Grid Org Owner or Org Admin sends `@Claude connect`, the reply includes two codes. The `workspace_` code pairs only the workspace it was sent from. The `enterprise_` code pairs every workspace in the grid at once; redeem it when Claude should work across the grid.
The choice matters for direct messages. On Enterprise Grid, DMs follow each user's home workspace rather than the workspace you paired, so pairing a single workspace leaves DMs unanswered for users homed in the grid's other workspaces. The `enterprise_` code covers them all.
## Set the version for a scope
Every scope routes to one of four versions. In the **Claude Tag's access** section of admin settings, select the scope and use the **Claude Tag version** control. Channels Claude was added to appear in the section automatically, and the **Search channels** field finds a channel's scope by name or ID.
| Label | Effect |
| :---------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **New** | Claude Tag. Access bundles, skills, and custom instructions apply |
| **Legacy** | The earlier per-user Claude in Slack. Bundles and skills do not apply. Being deprecated; see [Migrate from the earlier app](/docs/claude-tag/admins/migrate-from-earlier) |
| **Off** | Neither version responds to channel mentions in this scope. Direct messages are unaffected |
| **Inherit** | Use the parent scope's value. Not shown at **Default Slack access** |
Both versions answer through the same @Claude app, so **Off** turns off the Legacy version too. To opt out of Claude Tag while keeping the earlier behavior, set the scope to **Legacy**, not **Off**.
Per-scope version changes (workspace and channel) are reversible; see [Migrate from the earlier app](/docs/claude-tag/admins/migrate-from-earlier).
## Revoke a pairing
In the **Connected workspaces** list, select **Disconnect** on the workspace's row. Disconnecting revokes the pairing so `@Claude` no longer runs in that workspace, but the workspace's scope and any bundles bound to it remain in the **Slack** tab; remove the scope separately if you want it gone. Claude stops responding in that workspace immediately. Its scopes remain in the Claude Tag's access section, so credentials and instructions are preserved, until you remove them.
## Related resources
* [Migrate from the earlier app](/docs/claude-tag/admins/migrate-from-earlier): the upgrade path and what changes for existing users
* [Pair your Slack workspace](/docs/claude-tag/admins/pair-workspace): the first pairing, with the Slack-admin handoff
claude-tag/concepts/agent-identity First recorded · 141 lines, first recorded
# How agent identity works ## Channel sessions ### Agent Proxy ### Web search vs. network requests ### Agent access ## Direct message channels ### Claude Tag versus Claude Code in Slack ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# How agent identity works
> Claude Tag acts under its own service accounts in Slack channels, not as you. See how channel access is bounded, how credentials reach it, and why DMs differ.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Claude Tag's identity depends on where you message it.
In Slack channels, Claude acts with its own service accounts, rather than as a specific user. An organization Owner [provisions this identity during setup](/docs/claude-tag/admins/setup-overview), so it arrives with its own account in each system it works in: the Claude app in Slack, the Claude GitHub App on GitHub, and a service account in every other connected tool. Actions it takes are attributed to those accounts; for example, posts come from the Claude app and pull requests show the Claude GitHub App as the author.
In direct messages (DMs) between a user and `@Claude`, the provisioned identity does not apply. DMs are one-to-one only; group DMs aren't supported. A DM has no channel to scope it to, so a DM session runs on [the individual's own claude.ai account](#direct-message-channels) instead, with their personal connectors. GitHub is the exception in attribution: a pull request opened from a DM is authored by the Claude GitHub App, the same as in channels, though the session can only work with repositories connected on that user's own account. Owners can disable DMs organization-wide; see [Allow or disable direct messages](/docs/claude-tag/admins/restrict-access#allow-or-disable-direct-messages).
<Note>
How Claude behaves in channels (its standing instructions, plugins, and channel memory) is configured separately from its identity; see [custom instructions](/docs/claude-tag/admins/attach-to-scope#add-custom-instructions), [plugins](/docs/claude-tag/admins/add-connections#attach-plugins), and [memory](/docs/claude-tag/users/memory) for more information.
</Note>
## Channel sessions
When Claude works on a channel task, three systems are involved:
* The ask happens in your Slack workspace, when a user tags Claude to do something or a scheduled task starts.
* The work Claude does runs in a sandbox on Anthropic's infrastructure, with nothing installed in your network.
* The agent's credentials for any additional connections, such as GitHub or a data warehouse, reach those systems to pull the required information. An organization Owner sets up those credentials as part of [provisioning the identity](/docs/claude-tag/admins/setup-overview#setup-steps).
The diagram below traces one request through this process.
<img className="block dark:hidden" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/request-path.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=e8776cf0edd1f3ec912b9b044c9cc838" alt="Diagram showing the request path across three zones. A task mentioned in your Slack workspace runs in a session sandbox on Anthropic's infrastructure, one sandbox per thread, holding no credentials. Outbound requests pass to Agent Proxy, which injects the credential drawn from the credential store; a request matching no rule is blocked. Credentialed requests reach your systems, like GitHub, a data warehouse, monitoring, or any HTTP API. A dashed return path shows results posting back in the thread, as Claude." width="1000" height="440" data-path="images/claude-tag/diagrams/request-path.svg" />
<img className="hidden dark:block" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/request-path-dark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=a2ed5f3270989c3ed3d9b9a78a72bff0" alt="Diagram showing the request path across three zones. A task mentioned in your Slack workspace runs in a session sandbox on Anthropic's infrastructure, one sandbox per thread, holding no credentials. Outbound requests pass to Agent Proxy, which injects the credential drawn from the credential store; a request matching no rule is blocked. Credentialed requests reach your systems, like GitHub, a data warehouse, monitoring, or any HTTP API. A dashed return path shows results posting back in the thread, as Claude." width="1000" height="440" data-path="images/claude-tag/diagrams/request-path-dark.svg" />
<Steps>
<Step title="Tag Claude in a channel">
A user asks Claude to chart last week's signups or fix a deploy test. The request starts a new session.
</Step>
<Step title="The session sandbox starts">
Claude does the work in an isolated environment Anthropic builds for this thread, reading files, writing documents, and running code. The credentials you provision are not placed in the sandbox; they stay in the credential store and are injected at the proxy.
</Step>
<Step title="The request crosses Agent Proxy">
When the work needs something outside the sandbox, like calling the GitHub API or querying a warehouse, the request crosses Agent Proxy, the network boundary between the sandbox and everything else. Agent Proxy checks it against the rules an admin configured, and decides whether it proceeds and what credential, if any, travels with it.
</Step>
<Step title="Agent Proxy attaches a credential">
A matching credential comes from the credential store, where an admin's [connections](/docs/claude-tag/admins/add-connections) are kept. Once saved, a credential is never displayed again; Agent Proxy retrieves it only at the moment of injection and attaches it to the request at the boundary, so the model and the sandbox itself are not given the key.
</Step>
<Step title="The result posts back, as Claude">
The credentialed request reaches your system, like GitHub or the warehouse, and the result returns to the thread.
</Step>
</Steps>
### Agent Proxy
For each outbound request from the sandbox, Agent Proxy checks the destination against three allow layers. A request goes through if any one of them allows it; a host that none of them allows is blocked.
| When the destination | Result |
| :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- |
| Matches a connection's rule, its [allowed websites](/docs/claude-tag/admins/add-connections#set-allowed-websites) | The proxy attaches that connection's credential and forwards the request. The credential stays at the proxy; the model and sandbox are not given it. |
| Is on the [bundle](/docs/claude-tag/concepts/glossary#access-bundle)'s [Domains list](/docs/claude-tag/admins/add-connections#allow-a-host-without-a-credential) but matches no connection | The proxy forwards the request without a credential. |
| Is allowed by the network access setting of the [environment](/docs/claude-tag/concepts/glossary#environment) the [scope](/docs/claude-tag/concepts/glossary#scope)'s sessions run on | The proxy forwards the request without a credential. |
| Matches none of these | The proxy blocks the request. |
A new environment's network access level defaults to Trusted access, so a fresh setup can reach a documented set of package registries and developer hosts before an admin has configured anything. The [cloud environments documentation](https://code.claude.com/docs/en/cloud-environments#default-allowed-domains) lists the covered hosts. To narrow that default, pin an environment with a stricter level, such as No access.
The same rules apply to code Claude runs in the sandbox, like `curl` or a `fetch` call: a request is blocked unless its host is allowed by one of the layers above.
Agent Proxy carries HTTP and HTTPS only. A protocol that isn't HTTP, such as SSH or a database's native wire protocol, can't cross the proxy even to an allowed host.
Nothing is installed inside your network. Your systems see only requests authenticated with the credentials Agent Proxy attached. For the endpoints and addresses your network team may need to allowlist, see [Network requirements](/docs/claude-tag/admins/network-requirements).
### Web search vs. network requests
Claude can search the web from a channel without any Domains entry. Web search is [Anthropic's built-in web search tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool), which runs on Anthropic's servers, not code running in the channel's sandbox.
The sandbox sends nothing new for a search. Search requests travel to Anthropic the same way the session's model traffic already does, and the searching happens server-side. The [Agent Proxy](#agent-proxy) rules don't apply to web search; fetching a page or calling a service from the sandbox is an outbound network request and follows them.
Searching and opening a page are different actions. A search returns content from the pages it matches, which Claude reads and cites, so it can answer from a page that search surfaced. Opening a URL, whether one you pasted or one a search returned, is a fetch from the sandbox, and the host needs an allow layer. That is why Claude can quote a page it found through search and still report that it can't open the same link.
The web search capability setting in your organization's claude.ai admin settings governs claude.ai chat; it doesn't govern Claude Tag sessions, in channels or DMs. If Claude reports that it can't reach a host from a channel, the fix is a [domain entry](/docs/claude-tag/admins/add-connections#add-a-domain) or the scope's [environment](/docs/claude-tag/concepts/glossary#environment), not that setting.
### Agent access
What Claude can reach in a channel comes from the [Access bundles](/docs/claude-tag/admins/add-connections) an admin attached to that channel's scope. Anyone in the channel gets the same capability, and the same request can do more in `#platform-eng` than in a general channel.
This design has four consequences.
* **Configure once.** Everyone in the scope can use it immediately.
* **Predictability.** What Claude can do never changes based on who asked.
* **Personal connectors apply in DMs.** A shared channel uses only the service-account connections an admin attached, not connectors on anyone's claude.ai account.
* **Clean audit.** Actions in connected tools show up under a service account your security team already knows how to reason about.
That service-account identity is also how Claude appears wherever it acts. In Slack, it posts as the Claude app. On GitHub, commits and pull requests show the Claude GitHub App, and pull requests link back to the Slack thread they came from. In every other connected service, actions appear under the service account an admin provisioned, in that service's audit log.
## Direct message channels
A DM with Claude works differently from a channel. There is no scope to attach an identity to, so a DM session runs with your own claude.ai account instead, the same way a Claude Code session on the web does, using your own connectors and credentials, with results attributed to you (pull requests excepted; the Claude GitHub App authors those from DMs too). The diagram contrasts with the channel path above; the sandbox is the same engine, but everything around it is yours.
<img className="block dark:hidden" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/dm-identity.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=d4089034f46e4a760f9fac9d36a689cc" alt="Diagram showing how a DM session reaches your systems. A message to Claude in a direct message runs in a session sandbox on Anthropic's infrastructure, the same engine as a channel session, but it runs with your identity. From there it reaches your systems through your own connectors and accounts, like GitHub or Drive, using your own credentials. A dashed return path shows results posting back in the DM, as Claude." width="1000" height="270" data-path="images/claude-tag/diagrams/dm-identity.svg" />
<img className="hidden dark:block" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/dm-identity-dark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=a3ca3c8aa926704742402882f4345b1b" alt="Diagram showing how a DM session reaches your systems. A message to Claude in a direct message runs in a session sandbox on Anthropic's infrastructure, the same engine as a channel session, but it runs with your identity. From there it reaches your systems through your own connectors and accounts, like GitHub or Drive, using your own credentials. A dashed return path shows results posting back in the DM, as Claude." width="1000" height="270" data-path="images/claude-tag/diagrams/dm-identity-dark.svg" />
The table lines up the two paths on the four dimensions that differ.
| | In a channel | In a DM |
| :---------- | :--------------------------------------------- | :------------------------------------------------------------------- |
| Acts as | Its own service accounts | You |
| Access | The channel's Access bundles | Your personal connectors |
| Attribution | The agent's accounts, in each tool's audit log | Your name, except pull requests, which the Claude GitHub App authors |
| Billing | The organization | Your seat |
Three of those differences are worth spelling out.
* **Connectors.** The [connectors on your account](/docs/connectors/overview) are available, including MCP servers you've added.
* **Billing.** Usage bills to your seat rather than the organization's service key.
* **Channel-side configuration.** It doesn't follow you in; the agent's connections and repository grants don't apply in DMs.
DM work runs under your credentials, so most of it is attributed to you and can reach only what your own accounts can. Pull requests are the exception: Claude authors them as the Claude GitHub App from DMs too, so a repository's history shows the same author either way, while the repositories it can reach are still only the ones connected on your own account.
Use channels for shared work and DMs for personal tasks, or for data you'd rather access under your own authenticated identity than a shared channel credential.
### Claude Tag versus Claude Code in Slack
A DM with Claude Tag runs under your own account, which is also how [Claude Code in Slack](https://code.claude.com/docs/en/slack) works, routing a coding @-mention to a Claude Code session on the web under the requester's own account. The two can look identical. The table shows how to tell them apart.
| | Claude Tag in a channel | Claude Code in Slack |
| :------------- | :----------------------------------------------------- | :------------------------------------------------------------------------------ |
| **Runs under** | The agent identity an admin provisioned | Your own Claude account, linked in the Claude app |
| **GitHub** | The Claude GitHub App; pull requests belong to the app | Your GitHub connection on claude.ai/code; pull requests open under your account |
| **Access** | The Access bundles an admin attached to the channel | Your personal connectors |
| **Billing** | The organization | Your seat |
If `@Claude` in your workspace opens pull requests as you, you're seeing Claude Code in Slack, not a Claude Tag session.
## Related resources
* [Security and data handling](/docs/claude-tag/concepts/security-and-data): where credentials are stored, what leaves your tenant, and what runs unattended
* [Give Claude access](/docs/claude-tag/admins/add-connections): provision the access this page describes
* [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access): narrow where this agent identity is allowed to act
claude-tag/concepts/for-claude-code-users First recorded · 89 lines, first recorded
# Claude Tag for Claude Code users ## What happens when a session starts ### How hooks run in the sandbox ## Local settings versus admin settings ### Admin counterparts for local settings ## How Slack threads map to sessions ## Whose credentials a session uses ### In a channel ### In a direct message ## Steer a session in the thread ### Keep instructions in channel memory ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Claude Tag for Claude Code users
> Which parts of a Claude Code setup carry into Claude Tag, which move to admin settings, and how Slack threads map to sessions.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Claude Tag runs the same engine as Claude Code. When you tag `@Claude` in Slack with a task, a session starts in a sandbox that Anthropic hosts and your organization configures, not on your machine. That sandbox is the same managed compute behind [Claude Code on the web](https://code.claude.com/docs/en/web-quickstart), described in [Compute and the sandbox](/docs/claude-tag/concepts/security-and-data#compute-and-the-sandbox).
If you use Claude Code on the web, a session works the way a web session does, from a fresh clone of your repository rather than from files on your machine. The configuration you checked into that repository, such as `CLAUDE.md`, hooks, and skills, applies in the session as it does in a web session.
If you run Claude Code in your terminal, the settings on your own machine don't reach a session, because the session runs in the sandbox and can't read your machine. For most of those settings, an admin sets a channel-wide counterpart instead, and a few have no counterpart at all. This page shows what happens when a session starts, which admin settings replace your local ones, and how Slack threads map to sessions.
## What happens when a session starts
A session begins with a fresh sandbox and no repository checked out. Your repository's Claude Code configuration takes effect only after Claude clones the repository, which happens when your message names a repository that an admin has [granted to the channel](/docs/claude-tag/admins/configure-github#grant-repository-access).
| Step | What applies |
| :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| You tag `@Claude` with a task | Your message is the task, and Claude starts work in a sandbox with no repository |
| Your message names a granted repository | Claude clones it into the sandbox |
| The clone completes | `CLAUDE.md`, `.claude/CLAUDE.md`, `.claude/rules/*.md`, and the skills in `.claude/skills/` [load into the session](/docs/claude-tag/admins/configure-github#what-loads-from-a-repository) |
| Claude works on the task | Hooks defined in the repository's `.claude/settings.json` run as they do under Claude Code |
### How hooks run in the sandbox
Hooks run inside the sandbox, and every session runs on the same standard sandbox image, no matter which repository it clones. If a hook calls a command that the image doesn't include, add an install step for it to the repository's `CLAUDE.md`, as described in [Install project dependencies](/docs/claude-tag/admins/configure-github#install-project-dependencies).
## Local settings versus admin settings
A session reads configuration from your repository, not from your machine. The `CLAUDE.md`, hooks, and skills you checked into the repository load when Claude clones it, as described in [What happens when a session starts](#what-happens-when-a-session-starts).
The settings on your machine never load into a session, because a session runs in the sandbox and can't read your machine. That includes your `~/.claude` directory, your personal `settings.json`, your shell environment, and the MCP servers you configured locally. They still apply when you run Claude Code in your terminal.
### Admin counterparts for local settings
The table shows what takes the place of each setting from your machine. Where a counterpart exists, an admin sets it for the whole channel.
| Claude Code setting on your machine | In Claude Tag |
| :--------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/model` | An admin sets the [default model per channel](/docs/claude-tag/admins/customize#choose-the-model-for-a-scope), and you can [switch models in a thread](/docs/claude-tag/users/models) |
| Effort level | Not configurable. Sessions run at the model's default effort. |
| MCP servers in `.mcp.json` | Not loaded, even when `.mcp.json` is checked into the repository. A session reaches external services only through the [connections an admin set for the channel](/docs/claude-tag/admins/add-connections), and each connection holds that service's credentials. |
| Secrets and API keys in your environment | An admin provisions them as channel connections. The raw key never enters the sandbox. It is [added to requests at the network layer](/docs/claude-tag/concepts/agent-identity#agent-proxy). |
| Environment variables and a personal `settings.json` | No counterpart. Every session runs on the same standard sandbox image, so there is no per-person environment to customize. Put non-secret setup in `CLAUDE.md` as [install steps](/docs/claude-tag/admins/configure-github#install-project-dependencies), and ask an admin to add secrets as connections. |
| A setup script for your workspace | No counterpart. Use `CLAUDE.md` install steps instead. |
| Permission prompts | Sessions run in auto mode, where Claude's permission checker reviews each action and can stop it. An admin pre-approves routine actions with [auto mode allow rules](/docs/claude-tag/admins/customize#auto-mode-allow-rules) instead of you approving in the moment. |
To change what a session can reach, ask an admin to [add a connection](/docs/claude-tag/admins/add-connections). The change applies to every session in the channel.
## How Slack threads map to sessions
You start a session by tagging `@Claude` in a thread with a task, and that session gets its own sandbox. Each reply in the same thread continues the session, so there is no `--continue` or `/resume` to run, and a session stays attached to the thread it started in. See [the lifecycle of a request](/docs/claude-tag/concepts/how-it-works#lifecycle-of-a-request) for what happens between replies.
Each thread is its own session with its own sandbox, so run parallel tasks in separate threads the way you would in separate terminal tabs. The sandbox is released after a quiet period, but the conversation stays in the thread, and a later reply continues the session. See [what survives between replies](/docs/claude-tag/concepts/how-it-works#what-survives-between-replies).
## Whose credentials a session uses
Claude Code acts with your credentials. What a session acts with depends on whether you tag Claude in a channel or in a direct message.
### In a channel
In a channel, Claude acts with credentials of its own, service accounts that [an admin provisions](/docs/claude-tag/concepts/agent-identity#channel-sessions). A pull request comes from the Claude GitHub App rather than from you, and a query against a connected service runs with the channel's credentials no matter who asked. Access is set per channel, not per person.
### In a direct message
A [direct message](/docs/claude-tag/concepts/agent-identity#direct-message-channels) runs on your own claude.ai account, with the connectors you added to that account rather than the connections an admin set for the channel, so a DM is the closest match to a Claude Code session on your own credentials.
## Steer a session in the thread
Where you would interrupt Claude Code and edit a file or reprompt, [reply in the thread](/docs/claude-tag/concepts/how-it-works#reply-in-the-thread-to-steer). Corrections and added constraints land as messages, and Claude folds them into the running task.
### Keep instructions in channel memory
For instructions that should persist beyond one thread, use channel memory, the instructions Claude keeps for one channel and reads in every session there. Keep repository conventions in `CLAUDE.md`. Put channel conventions in memory by telling Claude to remember them:
```text theme={null}
@Claude remember for this channel: reports go out as tables
```
See [What Claude remembers](/docs/claude-tag/users/memory) for how memory is scoped and how to correct it.
## Related resources
* [How Claude Tag works](/docs/claude-tag/concepts/how-it-works): the session model this page maps your setup onto
* [How agent identity works](/docs/claude-tag/concepts/agent-identity): why a channel uses the agent's access and a DM uses yours
* [Claude Tag settings map](/docs/claude-tag/concepts/settings-map): where each setting your organization owns is set
* [Configure GitHub access](/docs/claude-tag/admins/configure-github): what loads from a repository and how installs work in the sandbox
claude-tag/concepts/glossary First recorded · 78 lines, first recorded
# Glossary ## Access bundle ## Agent identity ## Agent Proxy ## Channel memory ## The earlier Claude in Slack ## Connection ## Connector ## Environment ## Plugin ## Routine ## Rule ## Scope ## Session ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Glossary > Claude Tag terms defined in one place. See agent identity, Access bundle, connection, scope, Agent Proxy, routine, channel memory, environment, and session. export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>; <BetaNote /> ## Access bundle A named set of connections, [domain entries](/docs/claude-tag/admins/add-connections#add-a-domain), repository access, and rules that an Owner creates for Claude to use. Bundles attach to scopes, and one bundle can serve many scopes. See [Give Claude access](/docs/claude-tag/admins/add-connections). ## Agent identity The service accounts Claude acts with: the Claude app in Slack, the Claude GitHub App on code, and the credentials an admin provisions for every other tool. See [How agent identity works](/docs/claude-tag/concepts/agent-identity). ## Agent Proxy The network layer that injects credentials into Claude's outbound requests. The model and the sandbox are not given the key; Agent Proxy adds the credential at the network boundary when a request matches the rules an admin set. See [How agent identity works](/docs/claude-tag/concepts/agent-identity#agent-proxy). ## Channel memory Facts Claude retains while working in a channel, including facts you told it to remember and notes it writes itself. Entries from public channels are shared across the workspace; entries from private channels are saved to that channel's own store. See [What Claude Tag remembers](/docs/claude-tag/users/memory). ## The earlier Claude in Slack Claude Tag is the second generation of the Claude app in Slack: | | Legacy (the earlier Claude in Slack) | New (Claude Tag) | | :------------- | :------------------------------------------ | :---------------------------------------------------- | | Identity | Each user links their own claude.ai account | One agent identity with org-level service credentials | | Sessions | Spawned per request | One persistent session per thread, shared | | Memory | None | Shared workspace memory plus private-channel memory | | Proactive work | None | Routines and channel watching | Your admin chooses which generation answers `@Claude` in a given channel, so two channels in the same workspace can work differently. See [Migrate from the earlier Claude in Slack](/docs/claude-tag/admins/restrict-access#migrate-from-the-earlier-claude-in-slack). ## Connection A credential for one external service that Claude uses on the channel's behalf, like a Datadog API key or a GitHub App installation. Connections belong to the agent identity, not to any user, and are grouped into [Access bundles](#access-bundle) by an admin. A connection is not a connector. A connector belongs to your personal claude.ai account. Claude cannot use your connectors in channels; it uses the channel's connections. The one exception is a DM, where it uses your own account instead; see [how DMs work in this model](/docs/claude-tag/concepts/agent-identity#direct-message-channels). ## Connector A tool you add to your own claude.ai account, like Gmail, Google Drive, or a custom MCP server, listed under [Customize > Connectors](https://claude.ai/customize/connectors). Connectors are personal; in Slack they apply only in DMs. For the agent-side equivalent that works in channels, see [Connection](#connection). ## Environment The sandboxed compute configuration a session runs in, including its network access setting. Environments used here must be scoped to the organization, not to an individual account, because channel sessions run with no user account attached. ## Plugin A bundle of skills an Owner attaches to an Access bundle or scope, teaching Claude how to use a specific tool or follow a specific process. Anthropic provides plugins for common tools; you can add your own. See [Attach plugins](/docs/claude-tag/admins/add-connections#attach-plugins). ## Routine A scheduled or run-once task Claude runs on its own, such as a daily digest or a channel watch. Anyone in a channel can ask Claude to set one up, list what's scheduled, or disable one. Routines run with the channel's connections, not the creator's. Claude Code also has a feature named routines. Those run under an individual user's account; Claude Tag routines run under the agent identity. ## Rule The match conditions Agent Proxy checks against each outbound request. A connection pairs one credential with the rule that decides when to inject it, and a request that matches the rule gets the credential attached at the boundary. A request that nothing allows (no rule, no domain entry, no [environment](#environment) network access setting) is blocked. See [Agent Proxy](/docs/claude-tag/concepts/agent-identity#agent-proxy). ## Scope One of three levels Claude's settings can target: Default Slack access (the organization-wide root), one Slack workspace, or one channel (public or private). Scopes inherit downward, so a channel gets its workspace's settings plus any of its own. An Owner attaches [Access bundles](#access-bundle) and instructions at a scope. See [Attach the bundle to a scope](/docs/claude-tag/admins/attach-to-scope). ## Session The unit of work behind one conversation. Each Slack thread binds to one persistent session, and anyone in the channel can continue it by replying in the thread. A channel where Claude works at the top level, outside threads, also carries one session for the channel itself, separate from every thread's. See [How Claude Tag works](/docs/claude-tag/concepts/how-it-works) and [Restart a stuck or wrong-context session](/docs/claude-tag/users/commands#restart-a-stuck-or-wrong-context-session). ## Related resources * [How Claude Tag works](/docs/claude-tag/concepts/how-it-works): the scope, channel, and thread model in action * [How agent identity works](/docs/claude-tag/concepts/agent-identity): how connection, scope, and Agent Proxy fit together when Claude runs a task * [Set up Claude Tag](/docs/claude-tag/admins/setup-overview): where bundles, scopes, and connections get created in the console
claude-tag/concepts/how-it-works First recorded · 263 lines, first recorded
# How Claude Tag works ## Walk through a Claude Tag session ### Start a session ### Track Claude's progress ### Reply in the thread to steer ## Team channels and personal DMs ## How Claude Tag differs from Cowork and Claude Code ## Key concepts ## Lifecycle of a request ### What Claude posts back ### How the checklist updates ### Channel access #### How to identify access ### One-off and scheduled tasks ## Session context and memory ### Conversation context ### What survives between replies ### Channel and workspace memory ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# How Claude Tag works
> Each Claude Tag thread in Slack runs a working session in a sandbox. See how progress shows in the thread, how to steer mid-task, what survives between turns, and how memory is scoped.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Claude Tag is Claude, working inside your team's Slack channels. An organization Owner gives it its own accounts to the tools your team uses, so it arrives already able to act, and anyone in a channel can tag it into a problem without setting anything up.
When someone tags Claude in with a task, a working session starts for that thread. Claude works through the task and posts the result back into the conversation. It runs in an ephemeral cloud sandbox that Anthropic hosts, not on your local machine or inside your network.
This page covers:
* [Walk through a session](#walk-through-a-claude-tag-session): an annotated example thread showing one task end to end
* [Starting a session](#start-a-session), [tracking progress](#track-claude%E2%80%99s-progress), and [steering mid-thread](#reply-in-the-thread-to-steer): what to type, what to watch, and who can redirect
* [Team channels and personal DMs](#team-channels-and-personal-dms): which surface to use, and how access differs between them
* [Key concepts](#key-concepts): agent identity, scheduling, and memory defined
* [Lifecycle of a request](#lifecycle-of-a-request): the five-step loop, [the checklist](#how-the-checklist-updates), [per-channel access](#channel-access), and [scheduled tasks](#one-off-and-scheduled-tasks)
* [Session context and memory](#session-context-and-memory): what Claude reads, what survives idle, and what carries across channels
## Walk through a Claude Tag session
The thread below is one task end to end in Slack: Jordan tags @Claude into `#launch-week` with a question, a colleague steers mid-thread, and the answer lands in the channel.
<div className="tm-slack">
<div className="tm-slack-head">
<span className="tm-slack-chan"># launch-week</span>
<span className="tm-slack-members">19 members</span>
</div>
<div className="tm-slack-body">
<div className="tm-msg">
<span className="tm-avatar tm-avatar-user" aria-hidden="true">J</span>
<div className="tm-msg-col">
<div className="tm-msg-meta"><span className="tm-msg-name">Jordan</span><span className="tm-msg-time">9:02 AM</span></div>
<p><span className="tm-mention">@Claude</span> where are we on launch prep? Pull together what's still open from this channel.</p>
</div>
</div>
<div className="tm-msg">
<span className="tm-avatar tm-avatar-claude">
<img src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/logo/clay-spark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=032101c39ca3b1af9f72fc4af8e60d12" alt="" noZoom width="94" height="94" data-path="images/claude-tag/logo/clay-spark.svg" />
</span>
<div className="tm-msg-col">
<div className="tm-msg-meta"><span className="tm-msg-name">Claude</span><span className="tm-msg-app">APP</span><span className="tm-msg-time">9:02 AM</span></div>
<p>On it. I'll go through this channel's open threads and the launch plan.</p>
<div className="tm-tasklist">
<span className="tm-task-done"><span className="tm-sr">Done: </span>Read 14 open threads</span>
<span className="tm-task-done"><span className="tm-sr">Done: </span>Cross-checked the launch plan in Drive</span>
<span className="tm-task-done"><span className="tm-sr">Done: </span>Listed who each item is waiting on</span>
<span className="tm-task-done"><span className="tm-sr">Done: </span>Drafted the status summary</span>
</div>
</div>
</div>
<div className="tm-msg">
<span className="tm-avatar tm-avatar-user tm-avatar-b" aria-hidden="true">S</span>
<div className="tm-msg-col">
<div className="tm-msg-meta"><span className="tm-msg-name">Sam</span><span className="tm-msg-time">9:06 AM</span></div>
<p>fold in the vendor quotes from last week's thread too</p>
</div>
</div>
<div className="tm-msg">
<span className="tm-avatar tm-avatar-claude">
<img src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/logo/clay-spark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=032101c39ca3b1af9f72fc4af8e60d12" alt="" noZoom width="94" height="94" data-path="images/claude-tag/logo/clay-spark.svg" />
</span>
<div className="tm-msg-col">
<div className="tm-msg-meta"><span className="tm-msg-name">Claude</span><span className="tm-msg-app">APP</span><span className="tm-msg-time">9:08 AM</span></div>
<p>Done. Full status below: eight items closed, three open. The venue contract is the oldest, waiting on legal since the 2nd.</p>
</div>
</div>
</div>
</div>
Each of the five moments in that thread shows a piece of how Claude Tag works:
1. **Jordan handed Claude a problem, not a prompt.** Typing `@Claude` in a message that asks for something is what starts a working session.
2. **Claude acknowledged, then went quiet.** The "is thinking…" line and the checklist are the progress surface; the silence between 9:02 and 9:06 was the work happening. [How the checklist updates](#how-the-checklist-updates)
3. **Sam steered Claude without `@`-mentioning it again.** Once a session is active in a thread, it belongs to everyone there. [Reply in the thread to steer](#reply-in-the-thread-to-steer)
4. **The work ran somewhere real, with the channel's tools.** Reading fourteen threads happened in a sandbox built for this thread, and the launch plan came through this channel's Drive connection. What a session can reach is set per channel. [Channel access](#channel-access)
5. **The result is in the thread.** The whole channel can see it, use it, and build on it. [What survives between replies](#what-survives-between-replies)
The rest of this page takes each piece apart.
### Start a session
To start a session, type `@Claude` in a Slack message and say what you need in that same message (a question to answer, a task to run, a problem to dig into). Jordan's "`@Claude` where are we on launch prep?" is the whole move. Anyone in the channel can do it.
### Track Claude's progress
Once your message sends, an "is thinking…" line at the bottom of the thread means Claude picked it up. What happens next depends on the size of the ask. Questions and one-off requests get a direct reply. A longer task, like Jordan's, gets a checklist instead. [How the checklist updates](#how-the-checklist-updates) covers how it works and how to read one while it runs.
While a session runs, check in by replying in the same thread. Asking "how's it going?" in the thread is enough; it reads new replies as it works.
Each delivery ends with an "Open session in Claude" link showing the full record of the work, including every tool call. To open it, you need a Claude account in your organization; without one, the link shows a not-found page. If the thread is in a private channel, you also need to be a member of that channel. The page is read-only; follow-ups go in the Slack thread.
### Reply in the thread to steer
Anyone in the channel can steer a running session by replying in its thread, not just the person who started it. That is what Sam did in the walkthrough. Without re-mentioning `@Claude` or starting over, he replied in Jordan's thread, and the session folded his instruction into work already in progress. Add context, redirect the approach, or pick up the result later; a colleague's thread is yours to continue.
Editing or deleting an earlier message doesn't steer the session the way a reply does:
* **Editing a message**: Claude receives a note each time you edit, showing what the message said before the edit and what it says now. It reads the note but doesn't act on it, so it won't reply, redo finished work, or treat words you added as a new request.
* **Deleting a reply**: Claude gets no notification and keeps the version it already read.
* **Deleting the thread's first message**: if the thread already has replies, Claude keeps working and the session stays open. If you delete it before anyone has replied, the session closes. Anything Claude already pushed or posted persists, per [what survives between replies](#what-survives-between-replies), and you start a new thread to pick the task back up.
* **Correcting course**: Claude acts on replies, not on edits or deletions. Say the change in a new reply; the reply is also how you walk back a message it already read.
## Team channels and personal DMs
Where you message Claude determines whose tools and accounts it uses. In a channel, it acts with the connections an organization admin set for that channel, and the work is attributed to its own accounts. In a DM, the same engine runs with your own claude.ai connectors, and the work is attributed to you, except pull requests, which the Claude GitHub App authors from DMs as well.
| Working in… | Access | Attribution | Best for |
| :---------- | :----------------------------------------- | :----------------------- | :--------------------------------- |
| A channel | The channel's connections, set by an admin | The agent's own accounts | Shared work the team should see |
| A DM | Your own claude.ai connectors | You | Personal tasks using your own data |
The Access column is about external systems. A channel session reaches what the channel was granted, and a DM session reaches what your own account is connected to.
Everything below describes channel sessions, where most of the model lives. For the DM side, see [direct message channels](/docs/claude-tag/concepts/agent-identity#direct-message-channels), and for choosing between the two, see [pick the right surface](/docs/claude-tag/users/good-habits#pick-the-right-surface).
## How Claude Tag differs from Cowork and Claude Code
Anthropic offers several ways to work with Claude on real tasks; they reach the same kinds of systems but through different mechanisms.
| | Claude Tag | Cowork | Claude Code |
| :---------------- | :---------------------------------------------------------------- | :------------------------------------ | :------------------------------------------- |
| Where | Slack channels | claude.ai chat | Your terminal or IDE |
| Whose access | The team's: service-account credentials an admin sets per channel | Yours: your personal OAuth connectors | Yours: your local credentials and filesystem |
| Who sees the work | Everyone in the channel | Just you | Just you |
| Best for | Shared work the team should see and steer | Personal research and drafting | Hands-on coding in your own checkout |
The short version: **team work → Claude Tag; personal work → Cowork or Claude Code.** Claude Tag's connections authenticate the agent itself with service accounts, not any person. Personal connectors apply in a Claude Tag DM, which runs on your own claude.ai account, the same way Cowork does.
## Key concepts
Three ideas recur across this page and the rest of these docs.
* **Agent identity**: in channels, Claude acts under its own service accounts that an admin provisions, not as the person who asked. What it can reach is set per channel, so everyone in a channel works with the same access. See [How agent identity works](/docs/claude-tag/concepts/agent-identity).
* **Scheduling and long-running work**: a task can run on a schedule, trigger on a repository event, or keep going across many turns in one thread. The same channel access applies whether a person or a schedule started it. See [Set up routines](/docs/claude-tag/users/proactivity).
* **Memory**: what Claude learns in public channels is saved as workspace memory that any channel can use; private channels keep their own. See [What Claude remembers](/docs/claude-tag/users/memory).
## Lifecycle of a request
Every session, in any channel, follows the same five-step loop.
1. **The session starts.** Someone tags `@Claude` with a task, or a [scheduled routine](/docs/claude-tag/users/proactivity) runs.
2. **A sandbox builds.** Anthropic builds an isolated working environment for this thread.
3. **The working loop runs.** Claude works through the task with the channel's access, editing its checklist in place.
4. **The result lands in the thread.** An answer, a doc, a chart, or a pull request.
5. **A quiet period follows.** The sandbox is released while the thread persists; a new reply rebuilds it and starts the loop again.
<img className="block dark:hidden" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/session-loop.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=436dd451c4ab3ab0f0b072f85051e844" alt="Flow diagram of one session in five numbered steps. Step 1, tag Claude in with an @Claude message carrying a task. Steps 2 and 3 happen inside the sandbox. Step 2, a sandbox builds, one per thread; step 3, the working loop runs through the task's steps using the channel's access. Step 4, Claude posts the result in the thread as an answer, a doc, a chart, or a pull request. Step 5, a dashed quiet period follows, where the sandbox is released while the thread persists. A dashed return arrow from the quiet period back up into the sandbox shows that a new reply rebuilds it and the loop continues." width="1000" height="400" data-path="images/claude-tag/diagrams/session-loop.svg" />
<img className="hidden dark:block" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/session-loop-dark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=616c51832cbb9bc57fe6da5346c6ac85" alt="Flow diagram of one session in five numbered steps. Step 1, tag Claude in with an @Claude message carrying a task. Steps 2 and 3 happen inside the sandbox. Step 2, a sandbox builds, one per thread; step 3, the working loop runs through the task's steps using the channel's access. Step 4, Claude posts the result in the thread as an answer, a doc, a chart, or a pull request. Step 5, a dashed quiet period follows, where the sandbox is released while the thread persists. A dashed return arrow from the quiet period back up into the sandbox shows that a new reply rebuilds it and the loop continues." width="1000" height="400" data-path="images/claude-tag/diagrams/session-loop-dark.svg" />
Steps 1 and 2 are [starting a session](#start-a-session): a message tags Claude in, and a sandbox builds for that thread. Step 3, the working loop, is [the checklist](#how-the-checklist-updates) below. Steps 4 and 5, the result and the quiet period that follows, are covered in [What survives between replies](#what-survives-between-replies).
Every session runs in an ephemeral sandbox Anthropic hosts, a real working environment where it can read documents, run code, build charts, and open pull requests. Claude clones your repositories into the sandbox, edits them there, and pushes changes back to your Git host as a branch or pull request. The sandbox runs the same engine that powers Claude Code on the web, Anthropic's agent for writing and running code, which is why the results are working artifacts rather than chat.
Two threads in the same channel are two separate sessions with separate sandboxes; sessions don't share state directly.
Even with nothing connected, every session starts from the same baseline.
* It reads its own thread and the channel's history, including pinned items
* It searches the workspace's content
* It writes and runs code inside the sandbox, which is how a chart comes out of a posted CSV, or a doc out of a long thread, with nothing wired up
### What Claude posts back
Claude posts each session's result in the thread you asked in, choosing the form that fits the work.
| Form | What it is | When you see it |
| :------------------ | :------------------------------------------------------ | :--------------------------------- |
| A reply | An answer, list, or summary as a Slack message | Questions and short results |
| A file or chart | Attached to the thread the way anyone shares a file | Data, images, generated documents |
| A page kept current | Any of the above, edited in place over time | Digests, indexes, standing reports |
| A hosted page | A web page published on claude.ai, linked in the thread | Dashboards, prototypes, reports |
A hosted page stays available after the session ends, and Claude updates it when you ask in the thread. Anyone with access to the channel can open it; [artifact visibility](/docs/claude-tag/concepts/security-and-data#artifact-visibility) covers the access model. These are the same artifacts [Claude Code publishes](https://code.claude.com/docs/en/artifacts), with channel-based access in place of owner-controlled sharing.
For code work, the result is usually a draft pull request opened under the Claude GitHub App, with the link posted in the thread.
### How the checklist updates
For a longer task, Claude's first reply is a checklist, a live task list that it edits in place as it goes. Slack does not send notifications when a message is edited, so the thread can look frozen while the list is still moving.
A quiet thread usually means Claude is mid-task, not stuck. Open the thread. Checklist items checked off since you last looked mean the work is moving. In the walkthrough, nothing new arrived in anyone's notifications between 9:02 and 9:06, while the checklist ticked through fourteen threads of reading. If the work hits a wall, Claude usually says so in a reply rather than going silent. When a thread stays silent well past what the task should need, treat it as a stuck session; see [Claude reacted or started thinking, then never replied](/docs/claude-tag/users/troubleshooting#claude-reacted-or-started-thinking-then-never-replied).
### Channel access
Connections extend a session's reach into your own systems. An organization admin attaches access to a scope (the organization, a workspace, or a single channel), so the same request can do more in one channel than in another, and everyone in a given channel works with the same capability.
A thread locks in its skills, plugins, and custom instructions when it starts, and a running thread keeps that set. Connections and domain rules are enforced on each request, so one an admin adds mid-thread works in a running thread. Claude doesn't announce a new connection in an existing thread; ask it to use the service by name. A new thread picks up every kind of change, so after a configuration change, start a new top-level thread.
#### How to identify access
Because access is set per channel rather than per person, the way to find out what a session can reach is to ask it, not to guess from your own permissions.
* **Ask what Claude can reach.** In any channel, `@Claude what can you access from this channel?` lists its current reach.
* **If Claude cannot reach something, the channel was not granted access.** Another channel may have the access, and an organization Owner can add it. [How agent identity works](/docs/claude-tag/concepts/agent-identity) covers the model.
* **Personal connectors apply only in DMs.** A connection an admin attaches to a channel is separate from a connector on your personal claude.ai account; anything on your own account works in your DMs, not here.
### One-off and scheduled tasks
A session starts the same way whether a person triggers it or a schedule does. A mention starts a session for that one task, and the sandbox is released once it finishes. A routine runs the same loop on a schedule, a channel watch, or a repository event, with the channel's connections, so a recurring digest or watcher gets the same access a typed request would. See [set up routines](/docs/claude-tag/users/proactivity).
## Session context and memory
Every session runs the same lifecycle; what varies by place and thread is [what it can see](#conversation-context), [what survives idle](#what-survives-between-replies), and [what it remembers](#channel-and-workspace-memory).
### Conversation context
A session reads its own thread and its channel. Mentioning `@Claude` partway into an existing thread gives it up to 50 messages from the start of the thread (the root plus the oldest replies, with other bots' replies filtered out). In long threads, the most recent messages before your mention can fall outside that window, so restate anything critical.
Claude works in channels it has been added to, but workspace search can still find messages by keyword from public channels it's not a member of (the same search any Slack user has). Workspace search is unavailable in [channels that include guests](/docs/claude-tag/admins/restrict-access#restrict-guest-channels). Finding something is broader than being able to act somewhere; to have it participate in a channel directly, invite it with `/invite @Claude`.
### What survives between replies
The thread is durable; the sandbox is not. When a session is idle, its sandbox is released, and it is rebuilt when the next message arrives.
<img className="block dark:hidden" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/session-lifecycle.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=9a56231787b03f179e8d552d887778fc" alt="Timeline with two lanes. The Slack thread lane is one continuous bar that persists from the moment a task starts. The sandbox lane below it is segmented, built when the task starts, released while the thread goes quiet, and rebuilt fresh when someone replies." width="1000" height="270" data-path="images/claude-tag/diagrams/session-lifecycle.svg" />
<img className="hidden dark:block" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/session-lifecycle-dark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=0693a90b98baa729dcacfd35261f6494" alt="Timeline with two lanes. The Slack thread lane is one continuous bar that persists from the moment a task starts. The sandbox lane below it is segmented, built when the task starts, released while the thread goes quiet, and rebuilt fresh when someone replies." width="1000" height="270" data-path="images/claude-tag/diagrams/session-lifecycle-dark.svg" />
| | Survives idle periods |
| :------------------------------------- | :---------------------------------- |
| The conversation and its context | Yes |
| Channel memory | Yes |
| Work pushed, posted, or opened as a PR | Yes, in the external system |
| Files that exist only in the sandbox | No. Claude recreates them if asked. |
For long tasks, ask it to push branches and post drafts as it goes, so deliverables are saved somewhere durable while the work is still running. See [Good habits](/docs/claude-tag/users/good-habits#give-every-task-a-definition-of-done).
### Channel and workspace memory
Memory follows places the same way access does, and it accumulates for the team rather than for any individual.
Memory from public channels is shared across the workspace, so a decision recorded while working in #launch-week is available when someone asks in #gtm-west. When Claude cites something from a channel you have never used it in, it is reading workspace memory, not a record about you.
Private channels read workspace memory while working, and what they save is written to that channel's own store rather than the workspace store.
To see what it holds, ask `@Claude what do you remember about this channel?`. Anyone in the channel can correct or remove entries. [What Claude Tag remembers](/docs/claude-tag/users/memory) covers reading, correcting, and adding to memory.
The whole model so far fits in one picture, with access set at the scope, memory shared from public channels, work in progress per thread, and DMs outside all of it.
<img className="block dark:hidden" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/three-levels.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=511231c5561da4ade26f91cd395488fa" alt="Diagram showing three nested levels. A scope container holds two channels, #platform-eng and #gtm-west, and each channel holds its own threads, like 'fix checkout latency' or 'pull deal state'. The private channel is marked with a lock. Callouts mark what lives at each level (identity and access at the scope; memory, shared from public channels across the workspace while private channels keep their own; and work in progress at the thread). A DM with Claude sits below, outside every scope, and runs on your own account." width="1000" height="648" data-path="images/claude-tag/diagrams/three-levels.svg" />
<img className="hidden dark:block" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/three-levels-dark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=e593920bd85a97c285a56f7b9d3e5019" alt="Diagram showing three nested levels. A scope container holds two channels, #platform-eng and #gtm-west, and each channel holds its own threads, like 'fix checkout latency' or 'pull deal state'. The private channel is marked with a lock. Callouts mark what lives at each level (identity and access at the scope; memory, shared from public channels across the workspace while private channels keep their own; and work in progress at the thread). A DM with Claude sits below, outside every scope, and runs on your own account." width="1000" height="648" data-path="images/claude-tag/diagrams/three-levels-dark.svg" />
DMs are outside this picture; they run on your own account, as covered in [Team channels and personal DMs](#team-channels-and-personal-dms) above. Owners can disable DMs organization-wide; see [Allow or disable direct messages](/docs/claude-tag/admins/restrict-access#allow-or-disable-direct-messages).
## Related resources
* [Getting started](/docs/claude-tag/users/getting-started): hand Claude your first task
* [How agent identity works](/docs/claude-tag/concepts/agent-identity): why an admin sets access per channel, and how credentials stay out of the sandbox
* [Good habits](/docs/claude-tag/users/good-habits): write tasks that survive the sandbox lifecycle
claude-tag/concepts/security-and-data First recorded · 108 lines, first recorded
# Security and data handling ## How a request travels ### Compute and the sandbox ### Credential storage ### Network egress ### Service accounts ### Isolate credentials between channels ## Artifact visibility ## Member access ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Security and data handling > Claude Tag runs in an isolated sandbox where outbound traffic is default-deny and reaches only allowed hosts. Covers sandbox isolation, credential storage, network egress, service accounts, isolating credentials between channels and what one channel can reach, who can open a published artifact, and which members can invoke Claude. export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>; <BetaNote /> In channels, Claude acts under its own service accounts that an Owner provisions. By default it can read and post in Slack channels it's been added to and search public channels by keyword; it has no access to your external systems until an Owner adds connections. Each connection is scoped to specific channels and workspaces, and the actions Claude takes in connected tools are attributable to its own service accounts. Every channel request, whether a person typed it or a schedule triggered it, follows the same path: it runs in a sandbox Anthropic hosts, leaves that sandbox only through Agent Proxy, and reaches your systems under the agent's own accounts. DMs run on the user's own claude.ai account instead and are covered separately on [How agent identity works](/docs/claude-tag/concepts/agent-identity#direct-message-channels). ## How a request travels Each Slack thread runs in its own sandbox, and every outbound call from that sandbox passes through the same checkpoints. <img className="block dark:hidden" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/request-path.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=e8776cf0edd1f3ec912b9b044c9cc838" alt="Diagram showing the request path across three zones. A task mentioned in your Slack workspace runs in a session sandbox on Anthropic's infrastructure, one sandbox per thread, holding no credentials. Outbound requests pass to Agent Proxy, which injects the credential drawn from the credential store; a request matching no rule is blocked. Credentialed requests reach your systems, like GitHub, a data warehouse, monitoring, or any HTTP API. A dashed return path shows results posting back in the thread, as Claude." width="1000" height="440" data-path="images/claude-tag/diagrams/request-path.svg" /> <img className="hidden dark:block" src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/diagrams/request-path-dark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=a2ed5f3270989c3ed3d9b9a78a72bff0" alt="Diagram showing the request path across three zones. A task mentioned in your Slack workspace runs in a session sandbox on Anthropic's infrastructure, one sandbox per thread, holding no credentials. Outbound requests pass to Agent Proxy, which injects the credential drawn from the credential store; a request matching no rule is blocked. Credentialed requests reach your systems, like GitHub, a data warehouse, monitoring, or any HTTP API. A dashed return path shows results posting back in the thread, as Claude." width="1000" height="440" data-path="images/claude-tag/diagrams/request-path-dark.svg" /> | Checkpoint | The guarantee | | :----------- | :------------------------------------------------------------------------------------------------------------- | | The sandbox | Runs on Anthropic's infrastructure and holds no credentials | | Agent Proxy | Injects credentials from the credential store at request time, and blocks traffic to unlisted hosts by default | | Your systems | See the agent's own accounts, so its actions there are attributable | ### Compute and the sandbox Sessions run in sandboxes Anthropic hosts, the same managed compute behind [Claude Code on the web](https://code.claude.com/docs/en/web-quickstart). Each Slack thread gets its own sandbox. When a thread goes quiet, its sandbox is released; replying in the thread builds a fresh one. What persists across that release and rebuild: * **Persists:** The thread, its visible work, and anything pushed to a branch, opened as a pull request, or posted into Slack. * **Does not persist:** Files that existed only inside the sandbox. To keep generated files, ask Claude to push them to a branch or post them in the thread. Claude Tag retains channel memory and session transcripts. Because of that retention, Claude Tag isn't available to organizations with Zero Data Retention (ZDR) enabled. ### Credential storage Credentials you provision are kept in a separate credential store, not in the proxy itself. When an outbound request matches a rule, [Agent Proxy](/docs/claude-tag/concepts/agent-identity#agent-proxy), the network layer between the sandbox and any external host, retrieves the credential from that store and injects it at the boundary, so the model and the sandbox are not given the key. This means: * **A saved credential is not displayed again.** The setup screens are write-only. * **The credential travels only to the hosts you named** when you added the connection. * **You can narrow the credential further**, to one host, one path prefix, or read-only methods, in [Add connections](/docs/claude-tag/admins/add-connections). ### Network egress Outbound traffic from a channel session's sandbox is default-deny. Requests go only to hosts an allow layer covers, and the layers are a [connection's Allowed websites](/docs/claude-tag/admins/connections/custom#fill-out-the-custom-tool-form), the [bundle's Domains tab](/docs/claude-tag/admins/add-connections#allow-a-host-without-a-credential), and the network access setting of the [environment](/docs/claude-tag/concepts/glossary#environment) the scope's sessions run on. A new environment's default level, Trusted access, already covers a [documented set of package registries and developer hosts](https://code.claude.com/docs/en/cloud-environments#default-allowed-domains). Every request gets one of three outcomes: * **Matches a credential rule.** The credential is attached at the boundary and the request proceeds. * **Matches only an allowlist.** The host is on the Domains tab or allowed by the environment's network access setting; the request is sent without credentials. * **Matches nothing.** The request is blocked outright; the host is unreachable rather than merely unauthenticated. <img className="block dark:hidden" src="https://mintcdn.com/claude-ai/Tf9m3OvmKAZp3uXC/images/claude-tag/diagrams/proxy-decision.svg?fit=max&auto=format&n=Tf9m3OvmKAZp3uXC&q=85&s=a4aecacf4e23944d5a2ecaacf6cf95a1" alt="Flow diagram across two zones. Inside Anthropic's infrastructure, a session sandbox that holds no credentials sends every outbound request to Agent Proxy, which matches it against admin rules. Three outcomes branch toward your systems: on a rule match, the credential is attached at the boundary and the request proceeds; on an allowlist-only match, from the bundle's Domains list or the environment's network access setting, the request is sent without credentials; on no match, the request is blocked entirely (the default-deny outcome) and the host is unreachable." width="1000" height="400" data-path="images/claude-tag/diagrams/proxy-decision.svg" /> <img className="hidden dark:block" src="https://mintcdn.com/claude-ai/Tf9m3OvmKAZp3uXC/images/claude-tag/diagrams/proxy-decision-dark.svg?fit=max&auto=format&n=Tf9m3OvmKAZp3uXC&q=85&s=d2ad1dd61b859e9f2aebfceedbc247c3" alt="Flow diagram across two zones. Inside Anthropic's infrastructure, a session sandbox that holds no credentials sends every outbound request to Agent Proxy, which matches it against admin rules. Three outcomes branch toward your systems: on a rule match, the credential is attached at the boundary and the request proceeds; on an allowlist-only match, from the bundle's Domains list or the environment's network access setting, the request is sent without credentials; on no match, the request is blocked entirely (the default-deny outcome) and the host is unreachable." width="1000" height="400" data-path="images/claude-tag/diagrams/proxy-decision-dark.svg" /> Because requests to any other host are blocked, data can only leave the sandbox to hosts an allow layer covers. An admin sets the Allowed websites list on each connection and the Domains tab on each bundle. An admin sets the environment's network access level, which defaults to Trusted access, from the **Cloud environments** page in [admin settings](https://claude.ai/admin-settings). See [Set allowed websites](/docs/claude-tag/admins/add-connections#set-allowed-websites) and [Allow a host without a credential](/docs/claude-tag/admins/add-connections#allow-a-host-without-a-credential). Organizations can opt in to allow-all egress, where a `*` entry on a bundle's Domains tab admits requests to any host on the ports that entry lists, still without credentials. Private and internal network addresses and cloud metadata endpoints remain blocked. Allow-all egress is off by default and enabled per organization by Anthropic; see [Allow all hosts](/docs/claude-tag/admins/add-connections#allow-all-hosts). ### Service accounts In channels, Claude acts under service credentials of its own, not under the account of the person who tagged it. The Slack surface is the Claude app, code work goes through the Claude GitHub App, and every other connected tool uses a service account an Owner provisions in an Access bundle. See [How agent identity works](/docs/claude-tag/concepts/agent-identity) for the full model. A connection belongs to that agent identity and is shared by everyone the bundle's scope covers. Anyone in a channel under that scope can ask Claude to act with the credential, so whatever the connected account can read or write is available to every member of those channels. Connect a dedicated identity you control for each service, such as a `[email protected]` seat or a native service account, rather than a personal login. A dedicated account keeps the agent's actions separately auditable in each tool's logs and lets you revoke its access without affecting a person; see [Create a dedicated account per service](/docs/claude-tag/admins/add-connections#create-a-dedicated-account-per-service). DMs with `@Claude` run on the user's own claude.ai account instead, with that user's personal connectors, and work there is attributed to them, except pull requests, which the Claude GitHub App authors from DMs as well. Personal connectors apply only in DMs, never in channels. Owners can disable DMs organization-wide; see [Allow or disable direct messages](/docs/claude-tag/admins/restrict-access#allow-or-disable-direct-messages). ### Isolate credentials between channels A channel session can use only the [Access bundles](/docs/claude-tag/admins/add-connections) attached in one of three places: * **The channel itself.** A bundle you attach here applies in that channel only. * **The channel's workspace.** A bundle you attach here applies in every channel of that workspace. * **[Default Slack access](/docs/claude-tag/admins/attach-to-scope#how-scopes-inherit).** The organization-wide root; a bundle you attach here applies in every channel of every paired workspace. A bundle attached anywhere else in your organization is invisible to the session, and no request from the session's sandbox can carry a credential from a bundle outside those three scopes. For example, if you attach a bundle holding finance credentials to one private channel, sessions in every other channel run as if that credential doesn't exist. If you attach the same bundle to a workspace or to Default Slack access instead, every channel beneath it gets that access, so isolation comes from where you attach the bundle, not from the bundle itself. Confine a credential to one channel in three steps: 1. Attach its bundle to that channel and nowhere broader. 2. Keep the channel private. A bundle on a public channel [grants its access to anyone who joins](/docs/claude-tag/admins/attach-to-scope#attach-to-a-channel). 3. Check the channel's **Access summary** on the [Slack tab in admin settings](/docs/claude-tag/admins/attach-to-scope). It shows the access the channel actually gets, including what it inherits from the workspace and Default Slack access. Claude [doesn't operate in externally shared channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels), so a channel shared with another company never has a session to isolate. Isolating a credential doesn't isolate what Claude knows. What it learns in a public channel becomes [workspace memory](/docs/claude-tag/users/memory) that sessions in the workspace's other channels can read, and it can [search public channels by keyword](/docs/claude-tag/admins/restrict-access#controls-that-aren%E2%80%99t-available) without being added to them, the same way any workspace member can. ## Artifact visibility A session can publish an artifact, a web page hosted on claude.ai with the link posted in the thread, and the page stays available after the sandbox is released. Anyone with access to the source Slack channel can open it, which in a public channel covers everyone in the workspace. Someone who opens the link without that access sees a request-access prompt rather than the page. There is no share setting for anyone to change, and updates go through Claude in the thread. Artifacts you publish from your own Claude Code sessions work differently: they belong to you, and you control who can open them, with sharing options that depend on your plan and organization settings. See the [Claude Code artifacts documentation](https://code.claude.com/docs/en/artifacts). ## Member access By default, anyone in a connected Slack workspace can invoke Claude in channels, with or without a Claude account. An Owner can turn on a restriction toggle to narrow that: on Team plans it limits Claude to people with a Claude account in your organization, and on Enterprise plans it limits Claude to members whose role grants the **Claude Tag in Slack** capability. See [Restrict who can use Claude](/docs/claude-tag/admins/restrict-access#members). The toggle governs DMs as well as channels. ## Related resources * [How agent identity works](/docs/claude-tag/concepts/agent-identity): the identity model in full, including DM attribution * [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access): the controls that exist and the ones that don't * [Audit Claude Tag activity](/docs/claude-tag/admins/audit): the trails for tracing what it did
claude-tag/concepts/settings-map First recorded · 56 lines, first recorded
# Claude Tag settings map ## The Claude Tag admin page ## Spend limits and usage ## The Configure page ## Personal connectors on claude.ai ## Claude Tag versus Claude Managed Agents ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Claude Tag settings map > Claude Tag settings map: the admin page for access and behavior, the usage page for spend limits, the in-Slack Configure link for channel instructions, and personal connectors for DMs. Claude Managed Agents is configured separately on the Claude Platform. export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>; <BetaNote /> Claude Tag's settings live on claude.ai, split across a few pages that each own a different kind of setting. Which page you need depends on what you're changing. The table maps each surface to what it controls. | Surface | Who changes it | What it controls | | :--------------------------------------------------------------------------------------------- | :------------------------------------------------- | :------------------------------------------------------------------------------------------------------- | | [Claude Tag admin page](https://claude.ai/admin-settings/claude-tag) | An Owner in your Claude organization | Access, behavior, and restrictions for channels, per [scope](/docs/claude-tag/concepts/glossary#scope) | | [Usage page](https://claude.ai/admin-settings/usage/claude-tag) | An admin | Spend limits and per-channel usage analytics | | The **Configure** link in any Claude reply footer | Channel members, unless an admin restricts editing | One channel's instructions and whether Claude replies there without an @-mention | | [Customize > Connectors](https://claude.ai/customize/connectors) on your own claude.ai account | You | Which of your personal tools apply in [DMs](/docs/claude-tag/concepts/agent-identity#direct-message-channels) | Channel memory and routines aren't in the table because you change them by talking to Claude in the channel; see [what anyone can change from the channel](/docs/claude-tag/admins/customize#change-behavior-from-the-channel). ## The Claude Tag admin page Everything an Owner configures for channels lives at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). Settings there apply per scope (a channel, a workspace, or the whole organization). A scope without its own setting inherits from its parent, and a channel's setting overrides its workspace's, so two channels can run with different connections, models, and instructions. Most controls are Owner-only; the [permissions table](/docs/claude-tag/admins/restrict-access#permissions-by-role) lists each action and who can take it. * **Access bundles**: the connections, domain entries, repository grants, and plugins Claude uses in the channels a bundle covers. See [Give Claude access](/docs/claude-tag/admins/add-connections). * **Custom instructions**: standing guidance Claude reads in every session on a scope. See [Add custom instructions](/docs/claude-tag/admins/attach-to-scope#add-custom-instructions). * **Default model**: the model new sessions in a scope start on. The picker shows the models your organization allows for Claude Code, leaving out any that Claude Tag doesn't support, so it can be missing models you see in Claude Code itself. See [Choose the model for a scope](/docs/claude-tag/admins/customize#choose-the-model-for-a-scope). * **Auto mode allow rules**: plain sentences that pre-approve actions Claude's permission checker would otherwise flag or stop in a scope's sessions. See [Auto mode allow rules](/docs/claude-tag/admins/customize#auto-mode-allow-rules). * **Workspace pairing and restrictions**: which Slack workspaces are paired, whether DMs are allowed, guest-channel behavior, who can invoke Claude, and which generation of the app answers in each scope. See [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access). ## Spend limits and usage Spend limits and usage analytics live at [`claude.ai/admin-settings/usage/claude-tag`](https://claude.ai/admin-settings/usage/claude-tag), a different page than the Claude Tag admin page. It holds the organization-wide spend limit, the default spend limit for channels, per-channel limits, and the per-channel spend breakdown. If your organization bills through a reseller, this page is not available. See [Set a spend limit](/docs/claude-tag/admins/set-spend-limit) for funding the usage balance and what users see when a limit is reached. ## The Configure page Every Claude reply in Slack ends with a footer, and its **Configure** link opens a claude.ai page for that channel. Anyone in the channel who is also a member of your Claude organization can edit the **Channel instructions** field there, unless an admin has [restricted editing to admins](/docs/claude-tag/admins/attach-to-scope#restrict-who-can-set-channel-instructions). The page's **Respond automatically** toggle controls whether Claude replies in the channel without an @-mention; see [Turn automatic replies on or off](/docs/claude-tag/users/when-claude-responds#turn-automatic-replies-on-or-off). The page also shows the channel's **Connections**, which admins set, so members can see the list but not change it. The Configure page and the **Custom instructions** field on the scope's panel in admin settings write the same instructions, so a change from either place is visible in the other. See [Configure Claude for a channel](/docs/claude-tag/users/good-habits#configure-claude-for-a-channel). ## Personal connectors on claude.ai Connectors you add to your own claude.ai account, under **Customize > Connectors**, apply only in DMs with Claude, because [a DM runs on your own account](/docs/claude-tag/concepts/agent-identity#direct-message-channels). A channel uses only the connections an admin attached to it, and personal connectors never apply there. Slack has no connector settings of its own. See [connectors on claude.ai](/docs/connectors/overview) for setting one up, and [the troubleshooting entry](/docs/claude-tag/users/troubleshooting#a-connector-works-on-claude-ai-but-not-in-slack) if a connector you use on claude.ai is missing in Slack. ## Claude Tag versus Claude Managed Agents [Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/overview) is a separate product for developers, a pre-built agent harness that runs in managed infrastructure. You configure it on the Claude Platform through the Managed Agents API, and access requires a Claude API key. An agent there is defined by its model, system prompt, tools, MCP servers, and skills. Environments choose where its sessions run (a cloud sandbox, or a self-hosted sandbox on your own infrastructure), and scheduled deployments run it on a cron schedule. The two products don't share settings. Nothing on the Claude Tag admin page configures a Managed Agent, and an agent defined on the Claude Platform doesn't change how Claude behaves in Slack. ## Related resources * [Customize Claude Tag](/docs/claude-tag/admins/customize): the layers that shape Claude's behavior in a channel and who sets each one * [How agent identity works](/docs/claude-tag/concepts/agent-identity): why channels and DMs use different access * [Set up Claude Tag](/docs/claude-tag/admins/setup-overview): where each setting is first created during setup
claude-tag/overview First recorded · 220 lines, first recorded
# Work with Claude Tag ## Plans that include Claude Tag ## Where Claude Tag runs ## Billing and spend limits ## Put Claude Tag to work ## Set Claude Tag up once for everyone ## Where to start with Claude Tag
The first capture of this source. The page was already there, and this is what it said.
# Work with Claude Tag
> Claude Tag puts Claude in your Slack channels with admin-governed access. See what to hand it, how setup works, and where to start as an admin or end user.
<div className="tm-hero">
<div className="tm-hero-copy">
<span className="tm-pill">Public Beta</span>
<p className="tm-hero-title">Tag <span className="tm-hero-at">@Claude</span> in. Get results back in the thread.</p>
<p className="tm-hero-lede">Anyone in a channel can tag Claude into a problem and hand it work: reproduce a bug and open a pull request, turn a decision thread into a doc, assemble the state of a project. It posts a checklist in the thread as it goes, and the whole exchange stays visible to the channel.</p>
<div className="tm-hero-ctas">
<a className="tm-btn tm-btn-dark" href="/docs/docs/claude-tag/admins/setup-overview">I'm setting it up →</a>
<a className="tm-btn tm-btn-light" href="#put-claude-tag-to-work">Use it in your channel ↓</a>
</div>
</div>
<div className="tm-slack">
<div className="tm-slack-head">
<span className="tm-slack-chan"># platform-eng</span>
<span className="tm-slack-members">38 members</span>
</div>
<div className="tm-slack-body">
<div className="tm-msg">
<span className="tm-avatar tm-avatar-user" aria-hidden="true">D</span>
<div className="tm-msg-col">
<div className="tm-msg-meta"><span className="tm-msg-name">Dana</span><span className="tm-msg-time">2:14 PM</span></div>
<p>checkout has felt slow all morning — anyone else seeing it?</p>
</div>
</div>
<div className="tm-msg">
<span className="tm-avatar tm-avatar-user tm-avatar-b" aria-hidden="true">L</span>
<div className="tm-msg-col">
<div className="tm-msg-meta"><span className="tm-msg-name">Leo</span><span className="tm-msg-time">2:15 PM</span></div>
<p>same. <span className="tm-mention">@Claude</span> can you investigate? Compare latency against this morning's deploy and find what's causing it.</p>
</div>
</div>
<div className="tm-msg">
<span className="tm-avatar tm-avatar-claude">
<img src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/logo/clay-spark.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=032101c39ca3b1af9f72fc4af8e60d12" alt="" noZoom width="94" height="94" data-path="images/claude-tag/logo/clay-spark.svg" />
</span>
<div className="tm-msg-col">
<div className="tm-msg-meta"><span className="tm-msg-name">Claude</span><span className="tm-msg-app">APP</span><span className="tm-msg-time">2:15 PM</span></div>
<p>On it. I'll compare latency before and after the deploy, track down the cause, and report back here.</p>
<div className="tm-tasklist">
<span className="tm-task-done"><span className="tm-sr">Done: </span>Pulled p99 latency from Datadog</span>
<span className="tm-task-done"><span className="tm-sr">Done: </span>Diffed deploy 4f2c1 against main</span>
<span className="tm-task-done"><span className="tm-sr">Done: </span>Reproduced the slow query locally</span>
<span className="tm-task-doing"><span className="tm-sr">In progress: </span>Opening a pull request with the fix…</span>
</div>
</div>
</div>
</div>
</div>
</div>
## Plans that include Claude Tag
Claude Tag is available on Team and Enterprise plans, on Anthropic's first-party service. It isn't available on individual plans (Free, Pro, or Max), or for third-party deployments. To use it, your organization pairs its Slack workspace with its Claude organization; see [the setup overview](/docs/claude-tag/admins/setup-overview) for the full prerequisites.
If you're choosing between Claude products for Slack-shaped work, [how Claude Tag differs from Cowork and Claude Code](/docs/claude-tag/concepts/how-it-works#how-claude-tag-differs-from-cowork-and-claude-code) compares them directly: team work in shared channels is Claude Tag; personal work on your own files is Cowork or Claude Code.
## Where Claude Tag runs
Claude Tag works in Slack. You interact with it by writing in a Slack channel, thread, or direct message, and it replies there. Mention `@Claude` in a channel to guarantee it picks the message up.
When Claude works on a task, it runs in an ephemeral sandbox hosted by Anthropic, not on your computer or inside your network. The sandbox is created when a conversation starts, holds any code or files Claude is working with, and is discarded when the conversation goes idle. See [how Claude Tag works](/docs/claude-tag/concepts/how-it-works) for the full lifecycle.
You extend what Claude can reach, like your repositories, ticketing systems, data warehouses, and custom tools, through [connections](/docs/claude-tag/admins/add-connections), [plugins, and skills](/docs/claude-tag/admins/customize). An Owner configures these per scope (a channel, a workspace, or the whole organization), separately from any connectors an individual user has set up in their own claude.ai account.
<div className="tm-route-grid">
<div className="tm-card">
<a className="tm-band tm-band-admins" href="/docs/docs/claude-tag/admins/setup-overview">
<span className="tm-band-text">
<span className="tm-band-label">For administrators</span>
<span className="tm-band-title">Provision the identity</span>
</span>
<img src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/illustrations/Hand-Key.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=1b7a9675728f971bc7a4663c7f1ea599" alt="" noZoom width="1000" height="1000" data-path="images/claude-tag/illustrations/Hand-Key.svg" />
</a>
<div className="tm-qrows">
<a className="tm-qrow" href="/docs/docs/claude-tag/admins/setup-overview">
<span className="tm-qrow-text">
<span className="tm-qrow-q">Where do I start?</span>
<span className="tm-qrow-sub">The four setup steps, what to have ready, and what to test first</span>
</span>
</a>
<a className="tm-qrow" href="/docs/docs/claude-tag/concepts/agent-identity">
<span className="tm-qrow-text">
<span className="tm-qrow-q">What can Claude Tag access?</span>
<span className="tm-qrow-sub">How admins set access per channel, and where credentials are stored</span>
</span>
</a>
<a className="tm-qrow" href="/docs/docs/claude-tag/admins/add-connections">
<span className="tm-qrow-text">
<span className="tm-qrow-q">How do I connect each service?</span>
<span className="tm-qrow-sub">Credential types, allowed hosts, and what each connection lets Claude reach</span>
</span>
</a>
</div>
</div>
<div className="tm-card">
<a className="tm-band tm-band-users" href="#put-claude-tag-to-work">
<span className="tm-band-text">
<span className="tm-band-label">For end users</span>
<span className="tm-band-title">Put Claude Tag to work</span>
</span>
<img src="https://mintcdn.com/claude-ai/5JFKyLlO7sHMMf5J/images/claude-tag/illustrations/Hand-NodePair.svg?fit=max&auto=format&n=5JFKyLlO7sHMMf5J&q=85&s=c64df4c6d27a6da752aa32c9e0622781" alt="" noZoom width="1000" height="1000" data-path="images/claude-tag/illustrations/Hand-NodePair.svg" />
</a>
<div className="tm-qrows">
<a className="tm-qrow" href="/docs/docs/claude-tag/users/getting-started">
<span className="tm-qrow-text">
<span className="tm-qrow-q">How do I hand Claude Tag a task?</span>
<span className="tm-qrow-sub">Mention Claude in any channel it's in, with nothing to install</span>
</span>
</a>
<a className="tm-qrow" href="/docs/docs/claude-tag/users/use-cases">
<span className="tm-qrow-text">
<span className="tm-qrow-q">What is Claude Tag good at?</span>
<span className="tm-qrow-sub">Use cases for coding, data, incidents, and GTM</span>
</span>
</a>
<a className="tm-qrow" href="/docs/docs/claude-tag/users/good-habits">
<span className="tm-qrow-text">
<span className="tm-qrow-q">How do I get good results?</span>
<span className="tm-qrow-sub">Good habits for scoping and reviewing work</span>
</span>
</a>
<a className="tm-qrow" href="/docs/docs/claude-tag/users/memory">
<span className="tm-qrow-text">
<span className="tm-qrow-q">What does Claude Tag remember?</span>
<span className="tm-qrow-sub">Channel memory, what's shared across the workspace, and who can see what</span>
</span>
</a>
<a className="tm-qrow" href="/docs/docs/claude-tag/users/proactivity">
<span className="tm-qrow-text">
<span className="tm-qrow-q">Can Claude Tag run tasks on a schedule?</span>
<span className="tm-qrow-sub">Scheduled jobs, channel watching, and triggers</span>
</span>
</a>
</div>
</div>
</div>
## Billing and spend limits
Adding Claude to Slack doesn't add a per-seat charge. Channel and thread work is billed by usage instead: it draws from a **usage balance**, an amount in your organization's billing currency that an Owner funds. A [spend limit](/docs/claude-tag/admins/set-spend-limit) caps how much of that balance Claude Tag can use each billing period.
Direct messages don't draw from this balance. A DM runs on the sender's own claude.ai account and follows that seat's usual usage limits, so the organization spend limit doesn't apply to it.
To learn what your team's usage costs, run a pilot with a spend limit set and watch the per-channel breakdown on the [usage page in your admin settings](https://claude.ai/admin-settings/usage/claude-tag). Your organization may already have a [launch usage credit](https://support.claude.com/en/articles/15575654-claude-tag-launch-promo-for-claude-team-and-enterprise) to run that pilot against before it funds the balance itself.
[Set a spend limit](/docs/claude-tag/admins/set-spend-limit) covers how to fund the balance on each plan, set the limit, and what happens when usage reaches it.
<div className="tm-eyebrow"><span className="tm-swatch tm-swatch-users" />For end users</div>
## Put Claude Tag to work
If Claude Tag is in your channel, you can use it now. (If it isn't there yet, an Owner in your Claude organization runs setup: see [Set up Claude Tag](/docs/claude-tag/admins/setup-overview).) Anyone in the channel can hand it work, and channel work bills to the organization, not to you.
What it can reach depends on the channel you're in, not on who you are. The fastest way to find out is to ask it: `@Claude what can you access from this channel?` Or, if you're signed in to your Claude organization, click **Configure** in the footer of any Claude reply to see the channel's connections.
The one exception is a DM, where it runs on your own claude.ai account instead of the channel's setup. Owners can disable DMs organization-wide; see [Allow or disable direct messages](/docs/claude-tag/admins/restrict-access#allow-or-disable-direct-messages).
Begin with [Get started](/docs/claude-tag/users/getting-started), which covers your first message, what you see while it works, and how to shape its behavior in your channel.
<div className="tm-eyebrow"><span className="tm-swatch tm-swatch-admins" />For administrators</div>
## Set Claude Tag up once for everyone
Installing the Claude app in Slack is a prerequisite, not the setup. Setup is provisioning an identity. Claude Tag starts with no access to your external systems; you choose its credentials and repositories (an [Access bundle](/docs/claude-tag/concepts/glossary#access-bundle)), and which workspaces and channels they apply to.
You configure this once, at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), and everyone in those places can use Claude Tag immediately, with no per-user setup. You must be an Owner in your Claude organization to run setup.
[Set up Claude Tag](/docs/claude-tag/admins/setup-overview) walks the four provisioning steps, from creating the identity to attaching it to your first channel.
<div className="tm-strip">
<div className="tm-strip-head">
<p className="tm-strip-title">Security review</p>
<a className="tm-strip-all" href="/docs/docs/claude-tag/concepts/security-and-data">Security and data handling</a>
</div>
<p>The security model, what admins can and can't restrict, audit trails, and network requirements.</p>
</div>
## Where to start with Claude Tag
<CardGroup cols={2}>
<Card title="Set up Claude Tag" icon="gear" href="/docs/claude-tag/admins/setup-overview" horizontal arrow>
Admins: provision the identity and connect your first channel
</Card>
<Card title="Hand Claude Tag your first task" icon="paper-plane" href="/docs/claude-tag/users/getting-started" horizontal arrow>
It's already in your channel: send your first message
</Card>
<Card title="How Claude Tag works" icon="diagram-project" href="/docs/claude-tag/concepts/how-it-works" horizontal arrow>
The session model, what it can read, and how memory follows places
</Card>
<Card title="Use case library" icon="list" href="/docs/claude-tag/users/use-cases" horizontal arrow>
Prompts to paste, by team and connection
</Card>
</CardGroup>
claude-tag/users/commands First recorded · 114 lines, first recorded
# Commands Claude Tag understands ## See the commands available to you ## Restart a stuck or wrong-context session ## Mute or unmute a thread ## Send feedback ## List the routines in a channel ## Continue a thread in another channel ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Commands Claude Tag understands
> A few exact, bang-prefixed words after an @-mention run a fixed action instead of starting a normal turn: see the command list, restart a stuck or wrong-context session, mute or unmute a thread, send feedback, list a channel's routines, and continue a thread's conversation in another channel.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
A command is `@Claude` followed immediately by one of a few exact words starting with `!`. Claude matches the message against that word and runs a fixed action instead of starting a normal turn. `!help`, `!restart`, `!mute`, and `!unmute` must stand alone: adding extra words, as in `!restart` with words tacked on, makes the message an ordinary prompt instead. `!feedback`, `!routines`, and `!fork` accept text after the command, covered below.
## See the commands available to you
```text wrap theme={null}
@Claude !help
```
Claude replies with the commands it understands in your workspace. The list can differ by workspace, since a command can be enabled for some workspaces and not others.
## Restart a stuck or wrong-context session
```text wrap theme={null}
@Claude !restart
```
Use this when a session is stuck, or when it's carrying context you don't want the next reply to build on. Claude archives the current session and starts a fresh one in its place.
Every thread Claude takes part in runs a session of its own, holding that one conversation. Some channels have one more session on top of the per-thread ones. That session belongs to the channel itself, and it's the session Claude works from at the channel's top level, outside any thread. When Claude [replies to a top-level message no one mentioned it in](/docs/claude-tag/users/when-claude-responds), the channel's session is the one replying.
Where you run `!restart` picks which session gets replaced:
* **In a thread**, `!restart` replaces that thread's session. The fresh session rereads the thread, so it keeps what's in the messages and drops everything else the old one was carrying.
* **At a channel's top level**, `!restart` replaces the channel's session. The fresh session picks up from where the old one left off.
Claude confirms once the replacement session is ready. If the restart can't complete, Claude tells you and you can run `!restart` again.
You need the same access to run `!restart` that you'd need to message the session directly; someone who can only observe a thread can't restart it.
## Mute or unmute a thread
```text wrap theme={null}
@Claude !mute
```
Run `!mute` in a thread Claude is part of, and Claude stops replying there. Muting is per thread by design. Other threads, the channel's top level, [routine](/docs/claude-tag/users/proactivity) posts, and service notices are unaffected.
There's no channel-level mute. If you run `!mute` at a channel's top level, Claude posts this hint:
```text wrap theme={null}
:mute: Muting works per thread — reply `@Claude !mute` (or `!unmute`) inside the thread you mean.
```
To quiet unprompted replies across a whole channel, turn the channel's [**Respond automatically** setting](/docs/claude-tag/users/when-claude-responds#turn-automatic-replies-on-or-off) off.
Unmute the same way:
```text wrap theme={null}
@Claude !unmute
```
A muted thread also unmutes on any direct `@Claude` mention, so you don't need `!unmute` before asking something new.
You need the same access to mute or unmute a thread that you'd need to message Claude there.
## Send feedback
```text wrap theme={null}
@Claude !feedback
```
Opens a form in Slack for sending feedback on Claude Tag to the team that builds it, along with a note on what the report includes. Add words after `!feedback` and Claude carries them into the form as a starting draft, which you can still edit before submitting:
```text wrap theme={null}
@Claude !feedback the channel summary skipped the pinned thread
```
## List the routines in a channel
```text wrap theme={null}
@Claude !routines
```
Claude replies in the thread with the [routines](/docs/claude-tag/users/proactivity) set up in the channel: the scheduled jobs, watched channels, and other standing work it runs there. The list covers only that channel's routines.
* **For the current channel**, run `!routines` in that channel.
* **For another channel**, add the channel mention or its ID, as in `@Claude !routines #other-channel`. You need to be a member of that channel, and it must belong to your organization. Claude sends the list in a reply only you can see, so that channel's routines aren't posted for everyone in the channel where you asked.
If the single word after `!routines` isn't a channel mention or ID, Claude replies with how to use the command. Adding two or more words makes the message an ordinary prompt that starts a normal turn instead.
## Continue a thread in another channel
```text wrap theme={null}
@Claude !fork #channel <prompt>
```
Run `!fork` from inside a thread Claude is part of, and Claude continues that conversation in a new thread in the channel you name. Use it when a discussion outgrows its home channel: a bug thread that turns out to belong in the owning team's channel, or a side question that deserves its own audience.
The fork starts a new thread in Slack and links the two threads together:
* **In the channel you name**, Claude posts a new top-level message that links back to the original thread and carries your prompt, then continues in the replies under it. The new conversation starts with the original thread as background, so nobody has to re-explain.
* **Back in the original thread**, Claude replies with a link to the new thread, so anyone following along can see where the conversation continued.
The prompt is required, and it kicks off the new thread: Claude starts working on it there right away.
Pick the channel from Slack's `#` autocomplete so it arrives as a channel mention. The channel must be public, and both you and Claude must be members of it; invite Claude with `/invite @Claude` first if it isn't there yet. On Enterprise Grid, a public channel in another workspace of your grid also works when that workspace is paired to the same Claude organization, but a channel shared across workspaces doesn't.
`!fork` works from threads in public channels only. Threads in private channels, DMs, and group DMs can't be forked, since forking would carry the conversation to a different audience.
If the fork can't be set up, Claude replies with a note only you can see, and nothing is posted in either channel.
## Related resources
* [Set up routines](/docs/claude-tag/users/proactivity): the standing work `!routines` lists, and how to create, edit, or disable it
* [Control when Claude Tag responds](/docs/claude-tag/users/when-claude-responds): what makes Claude reply without any command or mention at all
* [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access): the admin controls that decide who can message Claude at all, including its commands
claude-tag/users/getting-started First recorded · 117 lines, first recorded
# Get started ## When to tag Claude in a channel versus a DM ## Add Claude to a channel ## Check that Claude is working ### What you see when Claude first joins a channel ## Hand Claude a task ## What Claude can see ### Which messages Claude reads ## Give Claude standing instructions ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Get started
> Claude Tag works in your Slack channels. See how to check it's on, send your first message, what it can read, and why DMs work differently.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Claude Tag is Claude working in your Slack workspace. You hand it work by writing a message where Claude is, and Claude carries it out in that thread. An `@Claude` mention guarantees a response in a channel, but it isn't required everywhere. DMs and threads Claude is already in reach it without one. There's nothing for you to install or configure; if `@Claude` is in your channel, you can use it (unless your admin has [restricted who can invoke Claude](/docs/claude-tag/admins/restrict-access#members)).
## When to tag Claude in a channel versus a DM
Where you tag Claude decides whose tools it uses and who sees the result.
* **Channel** for shared team work. The work happens in the open, so anything Claude does in the thread, including its checklist and results, is visible to everyone in the channel, and anyone can reply to steer the work. An admin sets what Claude can reach in each channel, and everyone who asks there gets the same access. By default you don't need a Claude account to tag Claude in a channel; the work bills to the organization. An admin can [restrict who can invoke Claude](/docs/claude-tag/admins/restrict-access#members).
* Example: `@Claude where are we on the launch checklist? Pull what's still open from this channel and #design-review.`
* **DM** for personal tasks. A DM runs on your own claude.ai account with [your own connectors](/docs/connectors/overview). Every DM message reaches Claude without an @-mention. You can also DM Claude questions about getting started, like how to word a task or what to try first. DMs are one-to-one only; group DMs aren't supported.
* Example: `Pull my afternoon meetings from my calendar and draft a one-line prep note for each.`
See [team channels and personal DMs](/docs/claude-tag/concepts/how-it-works#team-channels-and-personal-dms) for the full comparison.
If your workspace previously used the earlier Claude in Slack app, see [how Claude Tag differs](/docs/claude-tag/admins/migrate-from-earlier) for what has changed.
## Add Claude to a channel
Claude only works in channels it's been added to. To add it, anyone in the channel can run:
```text wrap theme={null}
/invite @Claude
```
Run the command in the channel's message box. Slack rejects `/invite` sent from inside a thread.
Or mention `@Claude` in a message; Slack will prompt you to add it.
## Check that Claude is working
Mention `@Claude` in any channel where it's been added. In the Slack message box, send:
```text wrap theme={null}
@Claude what can you access from this channel?
```
A reply means it's running there, and the answer tells you what it can reach.
### What you see when Claude first joins a channel
When a person first invites Claude to a channel, it posts a short intro on its own: it reads the channel's history and suggests a few tasks it could pick up. The intro doesn't post when a bot adds Claude, in org-shared channels, or in channels that already have memory.
Each reply ends with a footer showing an **Open session in Claude** link (the full record of that task), a **Configure** link (opens a page where you can [tailor how Claude works in this channel](/docs/claude-tag/users/good-habits#configure-claude-for-a-channel)), and which model handled the reply. You can [choose a different model](/docs/claude-tag/users/models) yourself, and admins [set the default model for each channel](/docs/claude-tag/admins/customize#choose-the-model-for-a-scope).
| If you see | It means | Do this |
| :------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Typing `@Claude` doesn't show **Claude** with an **APP** badge in the suggestion list | The Claude app isn't installed in your workspace | Ask your Slack admin to install the Claude app, and send them [the installation guide](/docs/claude-tag/admins/pair-workspace#install-and-pair) |
| The mention sends but Claude doesn't reply | Setup isn't finished for this channel | Ask your Claude organization admin to enable Claude Tag for this channel, and send them [the setup guide](/docs/claude-tag/admins/setup-overview) with the channel name |
| Claude replies "I couldn't find a Claude Code environment for your account" | Your own claude.ai account has no cloud environment yet; this appears in DMs, which run on your account rather than the organization's | Sign in at [claude.ai/code](https://claude.ai/code) once, then try again |
## Hand Claude a task
Every interaction has the same shape. You mention `@Claude` with a task, Claude works on it in the thread, and Claude posts the result there.
```text wrap theme={null}
@Claude learn what you can about my role from this workspace, then tell me three tasks you could take off my plate this week.
```
An "is thinking…" line appears at the bottom of the thread when Claude picks the task up, and it replies with results; a multi-step task also gets a checklist it updates as it works. A quiet thread after the "is thinking…" line means Claude is working, not stuck; long tasks can take a minute or more before the first reply.
Once Claude is in a thread, you don't need to @-mention it again; it reads every reply in that thread.
Read Claude's work before you use it, in proportion to what's at stake. A summary you can skim; something going to a customer or changing a system gets a careful read. If a result needs checking, ask it to show its work in the same thread.
The work runs on Anthropic's servers, so it continues after you close Slack.
Replies in the thread reach Claude without re-mentioning. If the thread looks idle, Claude is usually still working; see [how to read its progress](/docs/claude-tag/concepts/how-it-works#track-claude%E2%80%99s-progress).
## What Claude can see
After you've handed Claude a task, the first question is what it has to work with. The short version: it reads the thread you tagged it in, it can search your workspace's public channels, and anything beyond Slack depends on what your admin connected.
| What you give Claude | Can Claude read it? |
| :----------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Messages in this thread | Yes. Mentioning it mid-thread also gives it the thread's earlier messages |
| An image or screenshot you attach | Yes |
| Other public channels in your workspace | By searching only, the same way a person searches Slack; Claude can find a message by keyword but can't read a channel's full history unless it's been added there |
| Private channels and DMs | Only from inside them. Adding Claude to a private channel lets it work there, but the channel stays unreadable from any other channel or DM. |
| A link you paste, like a Google Doc or a webpage | Only if your admin allowed that site for this channel. If not, Claude tells you it can't reach it. For files in your personal Drive or Google account, DM Claude instead; [a DM uses your own connectors](/docs/claude-tag/concepts/agent-identity#direct-message-channels) |
| A Slack canvas | No |
| A message you edited after sending | Yes. Each edit sends Claude a note showing the text before and after the edit. Claude reads the note but doesn't act on it, so say a correction in a new reply. Deleting a message doesn't notify Claude |
The fastest way to find out for your channel is to ask: `@Claude can you read the doc I just linked?` gets you a yes or a "that site isn't allowed here."
<Note>Slack doesn't expose personal account settings (your sidebar, notification preferences, channel membership, or DMs between you and other people) to apps. If you want help organizing channels, paste or screenshot the list and Claude can propose a scheme you apply yourself.</Note>
### Which messages Claude reads
* An @-mention guarantees a response. Claude may also respond to a message that doesn't mention it when it judges a reply is warranted; include the mention to guarantee one. It receives the thread's root message and earlier replies for context when you mention it mid-thread; for details on the window, refer to [what Claude sees when you mention it](/docs/claude-tag/concepts/how-it-works#conversation-context).
* Once mentioned in a thread, Claude follows the rest of that thread and may reply without another mention.
* While working on a task, Claude can search the workspace's public channels by keyword, the same way a person searches Slack. It can't read a channel's full history unless it's been added there.
To quiet Claude in a thread or remove it from a channel, see [Control when Claude Tag responds](/docs/claude-tag/users/when-claude-responds).
## Give Claude standing instructions
Set instructions for a channel by telling Claude there, the way you'd ask anyone on the team:
```text wrap theme={null}
@Claude remember for this channel: keep replies short, and always include a link to the source.
```
The instruction saves to channel memory and applies to everyone's threads. Public-channel memory is also [shared across your workspace](/docs/claude-tag/users/memory). Verify with "what do you remember about this channel?"
## Related resources
* [Use case library](/docs/claude-tag/users/use-cases): every shape of work, each with the prompts to paste
* [Good habits](/docs/claude-tag/users/good-habits): how to write tasks that finish
* [Set up routines](/docs/claude-tag/users/proactivity): once a task works, have Claude run it on its own schedule
* [Commands](/docs/claude-tag/users/commands): exact words starting with `!` that run a fixed action, like `!restart` for a stuck session
claude-tag/users/good-habits First recorded · 188 lines, first recorded
# Good habits for working with Claude Tag ## Work in the open ## Write tasks that close ### Name the outcome, not the activity ### How much detail to give ### Give every task a definition of done ### Say which decisions come back to you ### Specify the output format for anything recurring ### Steer Claude Tag explicitly ## Work in the right place ### Start a new thread for a new task ### Pick the right surface ### Teach Claude something that sticks ### Configure Claude for a channel ## Keep thread count and review rate matched ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Good habits for working with Claude Tag
> Name the outcome, give every task a definition of done, and pick the right channel. See how to write tasks Claude can finish and how to keep many threads reviewable.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Tasks should have a verifiable end state. Claude runs each one in its own thread, and a thread closes when someone can confirm the work is done. A task without that end state produces an open-ended report, and the thread stays open while you decide what to do with it.
The habits here are for anyone who tags Claude in from Slack.
## Work in the open
Claude is most useful when the work is somewhere the team can see, steer, and build on. A few mindsets make that the default rather than something you remember to do.
* **Work in public.** Assume everyone in the channel can read the thread, including its checklist and results. Anything your team writes down, like decisions, conventions, and postmortems, is context Claude can use. Knowledge that lives in DMs or was only said aloud is invisible to it. Put anything personal in a DM instead.
* **Share control.** Replying in a thread someone else started is how work moves. Redirect the approach, add what the requester didn't know, or pick up the result and run with it.
* **Grant broad access.** A channel with more connections (the tools an admin linked for this channel, like GitHub or Drive) produces more useful results, because Claude can join more sources together. The connections are scoped to the agent's identity, so granting them to a channel does not expose anyone's personal data.
* **Give Claude the destination, not the route.** State the outcome you want and let Claude work out the steps; the [definition of done](#give-every-task-a-definition-of-done) below makes that concrete.
* **Tolerate the mess.** A first draft posted in the thread is more useful than a polished one in a DM. The thread is the workspace, not the deliverable.
## Write tasks that close
The phrasing of a task determines whether it has a verifiable end state, what form the result takes, and how Claude responds while working on it.
### Name the outcome, not the activity
A task like "post the project status and tag me when it's up" has an end state Claude can verify; "look at this" does not, and invites an open-ended report. Put the verifiable outcome in the first sentence of the task.
### How much detail to give
Claude [reads the thread you tag it in, can search the workspace's public channels, and works with the channel's connections](/docs/claude-tag/users/getting-started#what-claude-can-see). If the background for your task is already in a thread, channel, or connected tool, link to it and state the outcome you want in one sentence. You don't need to restate the background.
```text wrap theme={null}
@Claude take over the bug in the thread linked above. Fix it and open a draft PR.
```
When a mistake would be costly to undo, give Claude more detail. Write the detail as constraints: name the rules the change must respect, the checks that count as verification, and what the work must not touch.
```text wrap theme={null}
@Claude migrate the export config to the new schema. Hard rules: no behavior change, don't touch the billing module, and every old config key keeps working as an alias. Done means the full test suite passes, not only the export tests.
```
<Warning>Constraints in a task steer Claude but don't restrict Claude from performing a specific action. Anything you type to Claude goes into its working context, where it can be forgotten or overridden. If there are actions Claude must not take, enforce them outside the conversation, with controls like repository permissions, branch protection rules, and required checks.</Warning>
### Give every task a definition of done
Starting a thread costs one sentence. Closing it costs your attention, because you read the output, decide whether it's right, and reply.
Without a stated end condition, Claude can't declare the thread finished and you can't stop checking it. The end condition you write determines who can close the thread, and the table matches each kind of condition to who closes it.
| End condition | Who closes it | Example |
| :----------------------------- | :----------------- | :---------------------------------------------------- |
| An objective check passes | Claude, on its own | "Done when CI is green" |
| You approve a prepared result | You, one click | "Draft the status memo and post it here for approval" |
| You choose between options | You, one word | "Research approaches A and B and recommend one" |
| No verifiable condition exists | No one | Reframe it as a question instead of a task |
Two refinements make the table work in practice:
* **The condition must be observable by Claude.** "Done when CI is green" requires access to CI. If the proof lives in a system the channel isn't connected to, change the condition to one you close yourself.
* **Spell out everything the condition includes.** "Babysit this PR until it merges" can produce a merge the moment approvals arrive, before open review comments are addressed. If the full condition is approvals present, comments resolved, and your final go-ahead, write all three into the task.
For tasks Claude closes itself, ask it to attach proof, such as the source link, the chart, the test output, or the diff. You read the proof, not the transcript.
For long-running work, make getting the deliverable somewhere durable part of the definition. Post the file to the thread, push the branch, or open the draft pull request as it goes. See [what survives between replies](/docs/claude-tag/concepts/how-it-works#what-survives-between-replies).
Calibrate over time. Check everything it produces in a new channel at first, and widen what it closes on its own as its output holds up under review.
### Say which decisions come back to you
Tell Claude which decisions it can make on its own and which ones it must bring to you before acting. If you don't, Claude judges each case itself. It may make a change you wanted to see first, or stop to ask so often that it spends most of the task waiting for your replies.
```text wrap theme={null}
@Claude update the retry logic the way this thread decided. Handle test failures and lint yourself. Come back to me before changing any public interface, and for anything you're not sure is in scope.
```
<Warning>These instructions steer Claude but don't restrict Claude from deciding on its own. A decision that must come back to you needs an enforced control too, such as branch protection for merges.</Warning>
Once you've seen and verified Claude's output over several tasks, you can let it make more decisions without checking in, the same way you widen [what it closes on its own](#give-every-task-a-definition-of-done).
### Specify the output format for anything recurring
A monitor or digest that posts on a schedule posts to the channel repeatedly, so spell out the shape you want each post to take. Say how long each item should be, give it the status legend to use, and tell it what to leave out, so the channel can read every post at a glance.
```text wrap theme={null}
@Claude every 6 hours, check #alerts and post one line per item: 🔴 needs a person, 🟡 watch, 🟢 fine. Skip 🟢 unless something changed.
```
Once a post matches the format you want, you can also point at it directly: "use the format from your 9am post going forward."
### Steer Claude Tag explicitly
Claude adapts to instructions, but it won't guess that you want it to. Tell it how to behave in this channel and ask it to remember. That works in both directions, whether you want more structure or less noise:
```text wrap theme={null}
@Claude remember for this channel: always format reports as a table, and ask before posting anything longer than a screen.
```
```text wrap theme={null}
@Claude remember for this channel: keep replies to three sentences unless someone asks for detail.
```
Verify what stuck by asking what it remembers about the channel. See [What Claude Tag remembers](/docs/claude-tag/users/memory).
## Work in the right place
Where you start a thread determines what Claude can reach, who else can pick the work up, and which standing conventions apply.
### Start a new thread for a new task
Each thread runs its own session, and the session carries the whole conversation into every reply. Keep follow-ups on the same task in the same thread, where Claude already has the context.
Start a new thread for each new task. The fresh session begins with full room for the work, picks up any configuration changes made since the old thread began, and keeps each piece of work reviewable on its own. A thread that accumulates many tasks eventually [grows past what one session can hold](/docs/claude-tag/users/troubleshooting#this-conversation-is-too-long-for-me-to-process).
### Pick the right surface
Channel access belongs to the channel, and DM access belongs to you. A channel can also be yours alone. Create one with just you and Claude in it, and it works the same way a team channel does. The table compares the three surfaces.
| | A team channel | Your own channel | A DM |
| :---------------- | :----------------------------------------- | :---------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------- |
| Access | The channel's connections, set by an admin | The channel's connections, set by an admin | Your own claude.ai connectors |
| Memory | Channel memory the team builds | Channel memory you build | Outside channel and workspace memory |
| Who sees the work | Everyone in the channel | You, plus anyone you invite | You |
| Billing | The organization | The organization | Your seat |
| Best for | Shared work the team should see and steer | Your own questions, digests, and follow-ups, kept where a teammate can pick them up | Personal tasks on your own connections, or data that shouldn't run through a shared channel connection |
[Routines](/docs/claude-tag/users/proactivity) belong to a channel too. You set standing work up in the channel where it should post, and it runs with that channel's connections. [Work from your own channel](/docs/claude-tag/users/use-cases/your-own-channel) shows what a channel of your own is good for.
A DM can still answer questions about a public channel when the answer should stay private. Name the channel in the DM, as in `summarize the last week of #product-feedback`. Claude's Slack search covers public channels in this workspace from a DM the same as from a channel, so the DM advantage is privacy of the answer, not broader reach. Workspace search is unavailable in [channels that include guests](/docs/claude-tag/admins/restrict-access#restrict-guest-channels), so ask from a DM or from a channel without guests.
Reading a public channel's full history, rather than what search finds, needs Claude to be a member of that channel. If it says it can't read a public channel, `/invite @Claude` from inside that channel adds it.
A private channel is readable only from inside it. Inviting Claude lets it work in that channel, but Claude can't read the private channel's messages from any other channel or DM. To ask about a private channel, ask in that channel.
Channels in a different workspace and Slack Connect channels stay out of reach.
When more than one surface would work, prefer a channel. Work that happens there compounds, because Claude can draw on it in later threads and teammates can find it, redirect it, or build on it.
If Claude says it can't reach something in a channel, the channel likely wasn't granted that access. See [How agent identity works](/docs/claude-tag/concepts/agent-identity).
### Teach Claude something that sticks
When Claude gets something wrong, or learns something worth keeping, where you put the fix decides who else benefits and whether you can do it yourself.
| You want Claude to know | Put it in | Who can write it | Reaches |
| :---------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------- |
| How this channel should behave: format, tone, when to respond | [**Channel memory**](/docs/claude-tag/users/memory) (say it and ask Claude to remember) | Anyone in the channel | This channel (or workspace, from a public channel) |
| Conventions and setup for one repository: file layout, PR labels, dependencies to install | **`CLAUDE.md`** at the repo root ([loaded when the repo is](/docs/claude-tag/admins/configure-github#what-loads-from-a-repository)) | Anyone with repo write | Any session that works in that repo, from any channel |
| Standing rules for this channel that outrank memory | The [**Configure** page](#configure-claude-for-a-channel), in the **Channel instructions** field | Channel members, unless an admin has [restricted it](/docs/claude-tag/admins/attach-to-scope#restrict-who-can-set-channel-instructions) | This channel |
| How to use a tool correctly, or follow a specific process, org-wide | [**A skill**](/docs/claude-tag/admins/skills-repo) in your org's plugin marketplace | An organization Owner adds it; anyone can ask Claude to open a PR proposing the change | Every channel under the scope it's attached to |
| Standing rules across many channels | [**Custom instructions**](/docs/claude-tag/admins/attach-to-scope#add-custom-instructions) on a workspace or organization scope | An organization Owner, in the console | Every session in that scope |
The first three are yours to write. Skills and wider-scope custom instructions are attached by an Owner, but you can still ask Claude to draft a skill change as a pull request for an admin to review:
```text wrap theme={null}
@Claude that worked. Open a PR to the skills repo so this query pattern is part of the Datadog skill.
```
See [the admin guide to a skills repository](/docs/claude-tag/admins/skills-repo) for what that setup gives you.
A `CLAUDE.md` carries setup as well as conventions. Sessions run in a sandbox with a standard set of preinstalled tools. If the repository needs more, such as a language runtime or a database client, put the install commands in `CLAUDE.md`, and Claude [runs them when its work needs them](/docs/claude-tag/admins/configure-github#install-project-dependencies).
A `CLAUDE.md` is guidance; a required status check is a gate. If a pull request must carry a label or pass a check, make that a repository rule rather than a memory note or a skill.
### Configure Claude for a channel
The **Configure** link in the footer of any Claude reply opens a page where you tailor how Claude behaves in that channel. The page is on claude.ai, so you need to be signed in to your Claude organization to edit it, and an admin can [restrict editing](/docs/claude-tag/admins/attach-to-scope#restrict-who-can-set-channel-instructions) so the page is read-only for members.
The **Respond automatically** toggle on that page controls whether Claude replies in the channel without an @-mention. See [Turn automatic replies on or off](/docs/claude-tag/users/when-claude-responds#turn-automatic-replies-on-or-off) for what the setting does and the other places you can change it.
Use the **Channel instructions** field on that page to write standing guidance Claude reads in every new session in the channel: the channel's purpose, its conventions, the tone replies should take, and anything Claude should do or avoid there. Channel instructions outrank channel memory and sit alongside any instructions an admin has set for the workspace or organization. Save the field and the change applies to new sessions started in the channel.
The page also shows **Connections**, the services Claude can reach from this channel. Your organization's admins set that list, so you can see it on this page but not change it.
## Keep thread count and review rate matched
Claude runs as many threads as you start. Your capacity to review them doesn't scale the same way, because every thread that needs your judgment routes through you serially. Three conventions keep the queue manageable:
* **One channel per project.** Threads and the project's working context stay in one place, and a glance at the channel shows the project's state.
* **Batch your reviews.** Several threads in one sitting costs less than the same number spread across the day, because each return is a context reload.
* **Mark closed threads.** React ✅ to anything you consider done, and tell your digest routine to skip them.
## Related resources
* [Use case library](/docs/claude-tag/users/use-cases): the full setups these habits make reliable
* [What Claude Tag remembers](/docs/claude-tag/users/memory): make corrections stick
claude-tag/users/memory First recorded · 68 lines, first recorded
# What Claude Tag remembers ## Workspace memory ## Manage what Claude Tag remembers ### Make an instruction stick ### Check and correct what Claude Tag remembers ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# What Claude Tag remembers
> Claude Tag memory belongs to the channel, not to you. See how public channels share workspace memory, why private channels stay isolated, and how to check or correct it.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Claude keeps memory by channel. Memory from public channels is shared across the workspace. What it learns working in a private channel is saved to that channel's own store, and nothing it learns in a channel is attached to you individually.
Memory accumulates three ways:
* **You tell Claude.** Say "remember for this channel: reports go out as tables" and it saves the instruction.
* **Claude saves facts on its own.** While working it keeps notes like decisions the channel made.
* **Claude can read past sessions.** Ask it to look back and it lists earlier sessions in the channel and reads their transcripts; it can't full-text search across them, so name a timeframe or topic.
## Workspace memory
Memory generated in public channels is shared across the workspace automatically. A decision recorded in #data-eng is available when you ask in #analytics. You can still point it at a specific channel, like "check what #data-eng knows about this."
Reading and saving follow different rules depending on where Claude is working:
| Where Claude is working | Reads from | Saves to |
| :---------------------- | :------------------------------------------------------- | :------------------------------------------------------------------------ |
| Public channel | Workspace memory | This channel's notes or workspace-shared, both inside the workspace store |
| Private channel | That channel's memory, plus workspace memory (read-only) | That channel's own store |
DMs and other workspaces stay separate.
If a private channel is later made public, its accumulated memory does not move with it: new sessions there read and write the workspace store, and the memory it saved while private is no longer read by new sessions.
## Manage what Claude Tag remembers
Anyone in the channel can save, read, and correct memory by talking to Claude directly in the channel.
### Make an instruction stick
Memory is a curated note, not a transcript. To make something permanent, say so explicitly:
```text wrap theme={null}
@Claude remember for this channel: changes go to acme/data-pipeline, never acme/website, and run the lint check before opening any pull request.
```
Keep saved instructions short. Long entries crowd out everything else; memory works best holding stable facts, not a running log of events.
For longer playbooks, put them in a repository Claude can read. The documents that onboard a person to your team work as context the same way. Link the runbook, style guide, or review checklist in the channel, or store them where it can read them, instead of re-describing their contents in memory.
### Check and correct what Claude Tag remembers
Ask Claude in the channel to list everything it has saved to memory.
```text wrap theme={null}
@Claude what do you remember about this channel?
```
If something is wrong or stale, tell it to update or forget the entry. Anyone in the channel can read and change channel memory.
Two habits keep memory useful over time:
* **After correcting an entry, have Claude record the fix.** "Update your memory for this channel so this doesn't happen again" turns a one-time fix into a standing one.
* **Prune what your work has outgrown.** Entries written weeks ago can describe a repository, owner, or convention that no longer exists; review the memory list when the channel's work shifts.
An Admin in your Claude organization can view a scope's memory files at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), under the scope's options menu; only an Owner can edit or delete them.
## Related resources
* [How Claude Tag works](/docs/claude-tag/concepts/how-it-works): the scope, channel, and thread model behind memory
* [Good habits](/docs/claude-tag/users/good-habits): habits that keep memory accurate
claude-tag/users/models First recorded · 58 lines, first recorded
# Choose the model Claude Tag uses ## Switch the model in a thread ## Set a default model for the channel ## Choose the model for your direct messages ## Which models you can use ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Choose the model Claude Tag uses
> Ask Claude to switch models in a Slack thread, set a channel's default model, or pick the model for your direct messages. See which models you can use and how to confirm which one replied.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Every Claude Tag reply in Slack comes from one Claude model, and you choose which one by asking Claude for it in plain language, the same way you hand it any other task. The footer of each reply names the model that handled it, so you can confirm a switch took effect.
Which models you can ask for depends on your organization; see [which models you can use](#which-models-you-can-use).
## Switch the model in a thread
Tell Claude which model you want, in your own words, in the thread.
```text wrap theme={null}
@Claude switch to Claude Opus 4.8 for the rest of this thread.
```
To confirm the switch, check the reply footers. The reply that acknowledges the switch still names the previous model, because Claude writes it before the switch takes effect; the new model appears in the footer of the reply after it. Asking in a thread changes the model for that thread only. To change what new threads in the channel start on, set a [default model for the channel](#set-a-default-model-for-the-channel) instead.
The same request works in a direct message, where it applies to that conversation only.
## Set a default model for the channel
To change what new threads in a channel start on, ask for the channel, not just the thread.
```text wrap theme={null}
@Claude use Sonnet for this thread, and make it the default model for this channel.
```
Claude sets the channel's default model, which applies to new threads in that channel. Threads already underway keep the model they started with until someone in them asks Claude to switch.
Admins set the same default from claude.ai, per workspace or channel; see [choose the model for a scope](/docs/claude-tag/admins/customize#choose-the-model-for-a-scope).
## Choose the model for your direct messages
Open the Claude app's **Home** tab in Slack. When model selection is enabled for your organization, the tab includes a model selector for direct messages. New direct message conversations you start with Claude use the model you pick there. The selector offers only the models your organization allows.
The selector doesn't change a conversation already underway. To change one of those, ask Claude to switch in that conversation.
## Which models you can use
Anthropic manages the list of models on offer, and your organization's settings narrow it. The options include Opus and Sonnet models, drawn from what's available to your organization. Every list you see in Slack, the direct message selector and the models Claude offers to switch to, is already filtered to that set.
To see the current list, ask in the thread.
```text wrap theme={null}
@Claude what models can I use here?
```
If you ask for a model that isn't on the list, Claude tells you it isn't available, and the thread stays on the model it was already using.
## Related resources
* [Get started](/docs/claude-tag/users/getting-started): what else the reply footer links to
* [Customize Claude Tag](/docs/claude-tag/admins/customize#choose-the-model-for-a-scope): how admins set a default model per workspace or channel, and how the organization's model policy applies
claude-tag/users/proactivity First recorded · 115 lines, first recorded
# Set up routines ## Set up standing work ### Scheduled jobs ### Watch channels ### Follow a pull request ## Routine recipes ### Daily standup summary ### Weekly channel digest ### Watch a pull request until it merges ### Alert investigation when a monitor fires ### Automatic triage for new requests ## Manage standing work ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Set up routines
> Claude Tag runs routines you set up from the channel. See scheduled jobs, channel watching, pull request subscriptions, paste-ready routine recipes, and how to list or pause standing work.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
You can give Claude standing work from any channel it's in. This standing work is called a routine: a job that runs on a schedule, such as watching a channel, following a pull request, or posting status updates. You set a routine up in the channel where it should run, and it uses that channel's connections with the same permissions as a typed request.
## Set up standing work
### Scheduled jobs
Describe the schedule you want and the work Claude should do in one message:
```text wrap theme={null}
@Claude every weekday at 9am, read the open threads in this channel, check the tickets and pull requests linked in them, and post a one-line status per item. Skip anything with a ✅ reaction.
```
Name the output format in the job so recurring posts stay scannable.
### Watch channels
Ask Claude to watch named channels and post here when something matches a topic:
```text wrap theme={null}
@Claude watch #product-announce, #eng-announce, and #design-announce. Once a day, post here if anything is relevant to user education. Skip days with nothing.
```
Naming both the channels and the topic is what keeps a watch useful. The watch can cover this channel too ("keep an eye on this channel and post a morning summary").
### Follow a pull request
Claude can subscribe to a single pull request and react when it updates.
```text wrap theme={null}
@Claude subscribe to PR #482 in acme/data-pipeline. When CI finishes or a review lands, post here, and tag me if anything failed.
```
## Routine recipes
Each recipe below sets up a complete routine with one message. Adapt the channel names, repositories, and times to your own, and name the timezone so the schedule fires when you expect.
### Daily standup summary
Claude posts a morning rollup of open threads and anything waiting on someone, before the team starts the day.
```text wrap theme={null}
@Claude every weekday at 9am Pacific, post a summary of open threads in this channel and anything that looks like it's waiting on someone.
```
"Waiting on someone" makes the rollup surface actions, not just a recap; [Catch up](/docs/claude-tag/users/use-cases/catch-up) has the one-off version.
### Weekly channel digest
Claude posts one recap at the end of each week, so the channel has a single place to see what happened.
```text wrap theme={null}
@Claude every Friday at 3pm Eastern, post a digest of this week in this channel: what got decided, what's still open, and anything waiting on someone.
```
For an intake channel, the [Triage requests](/docs/claude-tag/users/use-cases/triage-requests) version of this rollup also sweeps posts that never tagged Claude.
### Watch a pull request until it merges
Claude subscribes to a single pull request and posts as it moves through CI, review, and merge.
```text wrap theme={null}
@Claude subscribe to PR #482 in acme/data-pipeline. Post here when CI finishes, a review lands, or it merges, and tag me if anything failed.
```
[Follow a pull request](#follow-a-pull-request) explains what the subscription reacts to.
### Alert investigation when a monitor fires
Claude checks the alerting dashboard on a schedule and posts a first pass at diagnosis for anything new, so the investigation is underway before anyone asks. This recipe needs a monitoring connection such as Datadog or PagerDuty; [Watch monitors and alerts](/docs/claude-tag/users/use-cases/watch-monitors) has the full setup.
```text wrap theme={null}
@Claude every two hours, check the alerting dashboard against its last state. For anything new, post when it started, what changed around then, and what to look at first.
```
The routine posts only when something changed, not on every check.
### Automatic triage for new requests
Claude answers, deduplicates, and routes requests as they arrive. This recipe is a standing role rather than a schedule; "remember for this channel" saves it to [channel memory](/docs/claude-tag/users/memory), so it applies to everyone's threads.
```text wrap theme={null}
@Claude remember for this channel: when someone tags you on a request, check whether it duplicates something already reported, answer it directly if the answer exists, and otherwise route it to the right owner with a one-line summary.
```
Pair it with a weekly rollup so untagged posts are still swept; [Triage requests](/docs/claude-tag/users/use-cases/triage-requests) has both messages.
## Manage standing work
Anyone in the channel can list, edit, or disable its standing work:
* **List.** Ask "what routines do you have set up in this channel?", or send [`@Claude !routines`](/docs/claude-tag/users/commands#list-the-routines-in-a-channel). Add a channel mention or its ID, as in `@Claude !routines #other-channel`, to list another channel's routines; pick the channel from Slack's autocomplete so it lands as a real mention, since a typed name on its own isn't accepted.
* **Edit.** Describe the change and it updates the job
* **Disable.** Name the job to stop, as in "disable the Friday rollup"
Standing work is visible to the channel: jobs post into the channel they belong to. Routines keep running if their creator leaves the organization, but stop firing if the creator is removed from the channel.
A few boundaries apply:
* A job runs with the channel's connections, the same as an interactive request.
* Schedules default to UTC. When you say "every weekday at 9am," include the timezone (for example "9am Pacific") so Claude converts correctly; without one it may guess. Ask "what triggers do you have set up?" to confirm the time it actually scheduled.
* A scheduled job that touches a github.com repository uses the same GitHub connection your admin set up for interactive work. See [Configure GitHub access](/docs/claude-tag/admins/configure-github#scheduled-work-uses-the-same-connection).
## Related resources
* [Use case library](/docs/claude-tag/users/use-cases): every entry has a proactive form to copy
* [Prompt library](/docs/claude-tag/users/prompt-library#manage-routines): prompts to create, audit, and stop routines
* [Good habits](/docs/claude-tag/users/good-habits): write schedules that keep working
claude-tag/users/prompt-library First recorded · 161 lines, first recorded
# Prompt library ## First messages in a new channel ## Forward a message as a task ## Shape how the channel works ## Check and correct memory ## Manage routines ## Steer work mid-thread ## Task starters, by shape ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Prompt library
> Copy-paste prompts for Claude Tag in Slack, each with why it works. See first messages, forwarded-message handoffs, channel rules, memory checks, routines, and mid-thread steering.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
These prompts are ready to copy, paste, and adapt: swap in your own channel names, services, and repositories. Each comes with the reason it works, so you can keep the mechanism when you change the words.
## First messages in a new channel
Ask what Claude can access from this channel:
```text wrap theme={null}
@Claude what can you access from this channel?
```
**Why it works**: what Claude can do differs per channel, and without this grounding Claude may suggest tasks it can't do here.
Get a personalized starting point:
```text wrap theme={null}
@Claude learn what you can about my role from this workspace, then tell me three tasks you could take off my plate this week.
```
**Why it works**: it's a discovery task with a bounded output. By asking for three tasks, you get a list you can judge in ten seconds and reuse as a menu of next tasks.
Start with a low-stakes task:
```text wrap theme={null}
@Claude catch me up on this channel since Monday.
```
**Why it works**: you bound the task with "since Monday", and you can grade the result yourself because you were there.
## Forward a message as a task
To turn an existing Slack message into a task, for example a bug report or a request someone posted, forward it to a channel Claude is in. In the message you attach when forwarding, name the deliverable and say what Claude should do if it isn't possible. Claude reads the forwarded message, so you don't need to retype its contents.
```text wrap theme={null}
@Claude investigate this. If it's something we can fix, open a draft PR; if not, post who owns it and why it's theirs.
```
**Why it works**: by giving Claude both branches, you get a useful result whether or not a fix is possible.
To hand over a discussion too long to forward, paste the thread's link instead:
```text wrap theme={null}
@Claude read the thread linked below and take over the fix it describes. Post your plan here before changing anything.
```
**Why it works**: Claude works in the thread where you pasted the link, not in the thread you linked, so it uses this channel's connections and this channel can see the result. By asking Claude to post its plan first, you can redirect it before it starts. To read a linked thread in a public channel, Claude must be a member of that channel, and it can read a private channel's threads [only from inside that channel](/docs/claude-tag/users/good-habits#pick-the-right-surface). If Claude says it can't read the link, `/invite @Claude` in the linked public channel, or forward the messages instead.
## Shape how the channel works
Use the prompts below to set channel-wide behavior that applies to every thread, not just yours.
```text wrap theme={null}
@Claude remember for this channel: keep replies short, and always include a link to the source.
```
**Why it works**: you're explicitly telling Claude to save the rule. Claude usually doesn't keep preferences you mention in passing.
```text wrap theme={null}
@Claude stay quiet in this channel unless tagged.
```
**Why it works**: you're stating standing channel behavior, so Claude applies it beyond the current conversation.
```text wrap theme={null}
@Claude remember for this channel: treat every top-level post as a task and pick it up without waiting for a mention.
```
**Why it works**: Claude already [picks up untagged posts when it judges a reply is warranted](/docs/claude-tag/users/when-claude-responds), and it weighs this channel-memory rule in that judgment, so teammates don't have to remember to tag Claude on posts with a concrete ask. If you don't specify a need, or if a teammate has already claimed the task, Claude may not respond to the message. In [a channel where Claude has quieted itself](/docs/claude-tag/users/when-claude-responds#when-claude-quiets-itself), mention `@Claude` to turn unprompted pickup back on.
## Check and correct memory
```text wrap theme={null}
@Claude what do you remember about this channel?
```
**Why it works**: memory is a curated note and Claude decides what's worth keeping, so you have to ask to know what stuck.
```text wrap theme={null}
@Claude that's outdated — forget the entry about the old project name.
```
**Why it works**: you name the specific entry, so Claude doesn't have to guess what's stale the way it does with "clean up your memory".
```text wrap theme={null}
@Claude update your memory for this channel so this doesn't happen again.
```
**Why it works**: when you correct Claude in a thread, you fix that thread only. With this message, Claude saves the correction and applies it in everyone's future threads.
## Manage routines
Create, audit, and stop the scheduled jobs Claude runs in this channel. For paste-ready schedules by scenario, like a daily standup summary or a weekly digest, see [Routine recipes](/docs/claude-tag/users/proactivity#routine-recipes).
```text wrap theme={null}
@Claude every Friday at 3pm, post a summary of this week's requests: how many, top themes, and anything still unrouted.
```
**Why it works**: you name the schedule and the post's contents, so every week Claude posts the same shape and you can compare to last week. By asking for anything still unrouted, you get a sweep for dropped requests, not just a recap.
```text wrap theme={null}
@Claude what routines do you have set up in this channel?
```
**Why it works**: schedules are channel state, and someone else may have set them up. Check what exists before you create a duplicate digest.
```text wrap theme={null}
@Claude disable the daily digest job.
```
**Why it works**: you name which job. Any channel member can disable a scheduled job; you don't need to find an admin to stop a noisy routine.
## Steer work mid-thread
Reply in the same thread; once Claude is working there, you don't need to @-mention it again.
```text wrap theme={null}
Status check — what's done and what's left?
```
**Why it works**: you're replying into the session that's running the task, with full context. If you ask in a new thread instead, Claude starts a second session that knows nothing about the first.
```text wrap theme={null}
Change of plan: target the staging config instead, and post the diff here before applying anything.
```
**Why it works**: when you redirect in the thread, Claude keeps everything the session has already learned. By asking for the diff first, you and the channel can review the change before Claude applies it.
```text wrap theme={null}
Post the draft to the thread, or commit and push what you have, then keep going.
```
**Why it works**: the thread is durable but [the isolated workspace behind it isn't](/docs/claude-tag/concepts/how-it-works#what-survives-between-replies). Anything Claude posts to the thread or pushes to a branch survives idle recycling; files that exist only in that workspace don't.
## Task starters, by shape
Each entry in the use case library gets one starter here; the linked page has the full setup and the reasoning behind its prompts.
| To do this | Paste this |
| :-------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Triage requests](/docs/claude-tag/users/use-cases/triage-requests) | "remember for this channel: when someone tags you on a request, check whether it duplicates something already reported, answer it directly if the answer exists, and otherwise route it to the right owner with a one-line summary. Track recurring themes." |
| [Catch up](/docs/claude-tag/users/use-cases/catch-up) | "what got decided in this thread, and what's still open?" |
| [Create an artifact](/docs/claude-tag/users/use-cases/create-artifacts) | "turn this thread into a one-page decision doc" |
| [Track a project](/docs/claude-tag/users/use-cases/track-projects) | "where are we on the migration? What's blocked and on whom?" |
| [Answer a data question](/docs/claude-tag/users/use-cases/answer-data-questions) | "show signup growth by week, and explain the dips discussed above" |
| [Find an answer in the docs](/docs/claude-tag/users/use-cases/find-answers) | "what's our policy on data retention, and which doc says so?" |
| [Pull deal state](/docs/claude-tag/users/use-cases/pull-deal-state) | "what's the state of the Acme renewal?" |
| [Watch monitors](/docs/claude-tag/users/use-cases/watch-monitors) | "every morning at 7, check the dashboards and post one line per service" |
| [Fix a bug](/docs/claude-tag/users/use-cases/fix-bugs) | "in acme/data-pipeline, reproduce the bug in this thread, fix it, and open a draft PR" |
## Related resources
* [Use case library](/docs/claude-tag/users/use-cases): the full setup behind each starter
* [Good habits](/docs/claude-tag/users/good-habits): the habits these prompts are built from
* [Getting started](/docs/claude-tag/users/getting-started): the basics, if you haven't sent a first message yet
claude-tag/users/troubleshooting First recorded · 595 lines, first recorded
# Troubleshoot Claude Tag in channels and DMs ## No response or silence ### Mentioning @Claude does nothing at all ### Claude replies to me but not to a teammate ### Claude reacted or started thinking, then never replied ### Claude says my session is queued or failed to start ### Claude didn't react to a message I edited ### Claude never responds in a channel shared with another company ### Couldn't check this channel just now ### Claude doesn't respond in channels that include guests ## Too many or wrong responses ### Claude gave me a confident but wrong answer ### Claude replies to every message in a thread ### I want to take back something I sent ### This conversation is too long for me to process ## Claude stopped mid-task ### I hit repeated API server errors and stopped after retrying ### I hit API rate limits and stopped after retrying ### This request needs usage credits that aren't available ### Claude couldn't clone a repository for this session ### I lost the connection to this session's container mid-turn ### Something went wrong and I couldn't finish this turn ## Lost or stale work ### Claude lost work it created earlier ### My old thread stopped working, but new threads are fine ### Claude picked the wrong repository ### Claude forgot instructions I gave it before ## Access and connections ### A connection my admin added isn't showing up ### Claude says it can't access a channel it read before ### Claude says it can't reach a tool or service ### A connector works on claude.ai but not in Slack ### Claude says it has no internet access or can't open a link ### Claude can't connect over SSH ### You've reached a Claude Tag spend limit ## DMs aren't working ### I get an environment error in a DM ### Your Claude account is connected, but it doesn't have access in this organization ### Your Claude admin has disabled sending direct messages to Claude ### Group DMs aren't supported ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Troubleshoot Claude Tag in channels and DMs
> Fixes for common Claude Tag problems in Slack. See no reply after a reaction, queued or failed sessions, lost work, missing connections, blocked links and websites, and DM or account errors.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
When something goes wrong mid-conversation, the cause is usually one of a small set. Each entry below has the same three parts: what you see, what it means, and how to resolve it. For setup and credential errors, see the [admin troubleshooting page](/docs/claude-tag/admins/troubleshooting).
Many fixes end with something to send your admin. On this page that means whoever manages your organization's Claude account at claude.ai, and it's often not the same person as your Slack administrator. If you don't know who that is, ask whoever set Claude up in your workspace.
## No response or silence
### Mentioning @Claude does nothing at all
**What you see**
`@Claude` gets no reaction and no reply.
**What it means**
Total silence has several possible causes, from the app not being installed to the channel being turned off, and the checks below separate them.
**How to resolve**
Work through these in order. Each step says what success looks like and where to go if it fails.
1. **Is the Claude app installed in this workspace?** Start typing `@Claude` in any channel. **Works**: Slack autocompletes to a Claude app with an app badge; if more than one Claude app appears, check with your admin which one to use. **Fails**: nothing autocompletes, or only a person named Claude appears. The app isn't installed; this needs your admin (send them the [setup overview](/docs/claude-tag/admins/setup-overview)).
2. **Is Claude in this channel?** Type `/invite @Claude` in the channel's message box, not in a thread reply. Slack rejects `/invite` inside threads ("/invite is not supported in threads. Sorry!"). **Works**: Slack posts "Claude was added to #channel" (or "is already in this channel"). Mention it again. **Fails**: Slack says you can't add apps to this channel (a Slack Connect or guest-restricted channel); try an internal channel instead.
3. **Is Claude Tag turned on for this channel?** Mention it again now that it's invited. **Works**: it reacts and replies. **Fails**: it replies "Claude is disabled in this channel" (the channel is set to **Off**), or it replies but behaves like the earlier Claude in Slack, with no channel memory and pull requests opening under your name rather than Claude's (the channel is set to **Legacy**). Either way this needs your admin (send them [Migrate from the earlier Claude in Slack](/docs/claude-tag/admins/restrict-access#migrate-from-the-earlier-claude-in-slack)).
If `@Claude` still gets no reaction and no reply after all three, send your admin [the admin entries for a silent workspace](/docs/claude-tag/admins/troubleshooting#nothing-responds). If the silence covers every channel across an Enterprise Grid, the fix needs a Slack organization admin rather than your Claude admin, so send the link to them.
### Claude replies to me but not to a teammate
**What you see**
Claude answers your mentions in a channel, and a teammate's mentions in the same channel get silence or a refusal.
**What it means**
Mentioning Claude in a channel doesn't require the sender to have a Claude account or seat, so by default anyone in the workspace can use it. Your organization can restrict that with the [member access setting](/docs/claude-tag/admins/restrict-access#members), in which case members outside the restriction are declined.
**How to resolve**
Have the teammate mention `@Claude` themselves and report the exact text of any reply; the reply is the diagnosis.
* No reaction and no reply at all: unusual when it works for you in the same channel; send your admin the exact channel and person.
* A message about guests: see [the guest entry below](#claude-doesn%E2%80%99t-respond-in-channels-that-include-guests).
* A message about permissions or access: your organization restricts who can use Claude; send your admin [the member access setting](/docs/claude-tag/admins/restrict-access#members).
### Claude reacted or started thinking, then never replied
**What you see**
Claude added a reaction to your message, or an "is thinking…" line appeared under it, but no reply arrived.
**What it means**
A reaction or an "is thinking…" line without a reply usually means Claude is still working, not that your message was dropped.
**How to resolve**
1. @-mention Claude in the same thread to ask for a status check.
2. If it has replied before in the thread, open the session from the link in its last message to watch live progress. Long tasks often show steady movement there while the Slack thread looks idle.
3. If the silence has stretched well past what the task should need, send [`@Claude !restart`](/docs/claude-tag/users/commands#restart-a-stuck-or-wrong-context-session) in the thread; it archives the session and starts a fresh one that still reads the thread. Starting a new thread and restating the request also works.
<Warning>Restarting abandons whatever the session was midway through, and there's no way to resume it. A silent session may still be working through a long task, so treat `!restart` as a last resort.</Warning>
### Claude says my session is queued or failed to start
**What you see**
Claude posts in the thread:
> Still waiting for available capacity — your request is queued and will start automatically. Replies in this thread are picked up automatically.
Or, if the session never started:
> Session failed to start: the session container never connected — please try again
**What it means**
The first message means compute capacity is temporarily busy; the session starts on its own once capacity frees up. The second means the session didn't start at all, which is transient.
**How to resolve**
* For the capacity message, wait a few minutes; no action is needed. To add context while waiting, @-mention Claude in the same thread rather than starting a new one. A new thread only queues a second session behind the first.
* For the failed-start message, mention Claude in the same thread to retry. If the retry worked, the session starts and Claude begins the task.
### Claude didn't react to a message I edited
**What you see**
You edited a sent message to add `@Claude`, and nothing happened.
**What it means**
Editing a sent message to add a mention doesn't trigger a response; Claude only picks up mentions from new messages.
**How to resolve**
Send a new message with the mention included.
### Claude never responds in a channel shared with another company
**What you see**
Mentions in a channel shared with another company get no reaction and no reply, ever.
**What it means**
Claude doesn't operate in Slack Connect channels, the ones shared with another company. This holds regardless of admin settings; mentions there are dropped without a reply. See [externally shared channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels).
A channel shared across workspaces inside your Enterprise Grid isn't silent; what happens there depends on how those workspaces connect to Claude. When every workspace in the channel belongs to your one Claude organization, Claude answers, but with only your organization's default access and settings, so a repository or an instruction set up for that channel doesn't apply. A notice in the thread points this out from time to time. When the workspaces are connected to different Claude organizations, you see "This channel is shared among several Claude workspaces, so Claude cannot respond here" instead of an answer.
Where guest access is restricted, you may first see "This channel is shared across multiple workspaces, and Claude can't verify whether it includes guests, so Claude can't respond here." If you ask Claude from another conversation to act in one of these channels, such as posting a message there, you see a reply that ends "Claude isn't available in channels shared across your Enterprise Grid".
Each of these messages means the channel spans more than one workspace. The [admin entries on these messages](/docs/claude-tag/admins/troubleshooting#this-channel-is-shared-across-multiple-workspaces) explain what causes each one and what an admin can change.
**How to resolve**
Move the conversation to an internal channel that belongs to a single workspace, or to a DM, and mention Claude there.
### Couldn't check this channel just now
**What you see**
Claude replies in the channel:
> Couldn't check this channel just now. Please try again in a moment.
**What it means**
When your organization restricts Claude in channels that include guests (the default), Claude checks each channel for guests before replying. That check briefly failed, so Claude declined this reply rather than guess.
**How to resolve**
Mention Claude again; the check usually passes on retry. If the same channel hits this repeatedly, send your admin [the admin entry on this message](/docs/claude-tag/admins/troubleshooting#couldn%E2%80%99t-check-this-channel-just-now).
### Claude doesn't respond in channels that include guests
**What you see**
Claude replies in the channel:
> Claude doesn't respond in channels that include guests. You can remove the guests from this channel (Channel details -> Members -> filter by "guests"), or a claude.ai organization owner can allow it here.
**What it means**
The channel includes at least one Slack guest account, and your organization restricts Claude in channels that include guests (the default).
**How to resolve**
Any of these fixes works:
* Remove the guests from the channel. In Slack, open **Channel details** → **Members** and filter by "guests"; guests show a **guest** badge on their Slack profile.
* Move the conversation to a channel with no guests.
* Ask a claude.ai organization owner to allow Claude to respond in channels that include guests, and send them [the guest access setting](/docs/claude-tag/admins/restrict-access#restrict-guest-channels). If you don't know who your organization's owners are, ask whoever set Claude up in your workspace.
The guest access setting restores replies, not workspace search. Claude can't search the workspace from a channel that includes guests, even when it's allowed to respond there. Removing the guests or moving the conversation to a channel with no guests restores search as well.
If the fix worked, a mention in the channel gets a reply.
## Too many or wrong responses
### Claude gave me a confident but wrong answer
**What you see**
Claude answered with certainty, and the answer is wrong or incomplete.
**What it means**
Claude can be wrong, including when it sounds certain. The most common wrong answer in Slack is an incomplete one, where Claude queried one source or one date range and reported the result as if it were the whole picture.
**How to resolve**
Before you share or act on a result, check the source links it posted, and ask it to show its work ("which channels did you search?" or "show me the query you ran"). If the answer is wrong, say so in the same thread with the correct answer; correcting it there is also how you steer the next attempt.
For numbers and facts that matter, the [definition-of-done habit](/docs/claude-tag/users/good-habits#give-every-task-a-definition-of-done) helps. Make "include the source for every figure" or "show me the query" part of the ask.
### Claude replies to every message in a thread
**What you see**
Claude answers messages in the thread that weren't addressed to it.
**What it means**
Once Claude is mentioned in a thread, it follows the whole conversation there and may reply to messages that weren't addressed to it.
**How to resolve**
Reply in the thread with an instruction such as "only respond when I @-mention you"; Claude follows that instruction for the rest of the thread.
### I want to take back something I sent
**What you see**
You edited or deleted a message, and Claude still acts on the original.
**What it means**
Claude has already read the original. An edit reaches it as a new update in the thread, so it may or may not act on the change, and it never undoes work already in progress. A deleted reply doesn't reach Claude at all.
**How to resolve**
Say so in a new reply ("ignore that, do X instead"), or start a fresh thread for a clean session.
### This conversation is too long for me to process
**What you see**
Claude posts in the thread:
> This conversation is too long for me to process and I couldn't finish this turn — please start a new thread to continue.
In a DM it ends with "Click *New Chat* in the top right to start a fresh session" instead.
**What it means**
The thread has grown past what one session can hold, and it stays too long forever; retrying there can't work.
**How to resolve**
Start a new thread. You can paste a summary of where the previous one left off.
## Claude stopped mid-task
The messages in this section mean a session started and then stopped partway through. In most cases the work isn't lost, and the same thread picks up where it stopped. Each entry says whether anything needs redoing.
### I hit repeated API server errors and stopped after retrying
**What you see**
Claude posts in the thread:
> I hit repeated API server errors and stopped after retrying. Mention me to continue.
The related messages "I hit repeated 529 Overloaded errors (the API is at capacity) and stopped after retrying. Mention me to continue." and "The API request timed out and I stopped after retrying. Mention me to continue." behave the same way.
**What it means**
The API serving the session returned repeated errors, so Claude stopped rather than keep retrying. The work isn't lost.
**How to resolve**
Mention Claude in the same thread; it picks up where it stopped.
### I hit API rate limits and stopped after retrying
**What you see**
Claude posts in the thread:
> I hit API rate limits and stopped after retrying. Wait a moment, then mention me to continue.
**What it means**
The Claude API rate-limited your organization's traffic partway through the turn. The work isn't lost. Rate limits are about momentary request rate, not accumulated usage: a single task makes many API requests in short bursts, so this can appear on an organization's very first request. It isn't the channel spend limit, and it doesn't mean anything is misconfigured.
**How to resolve**
Wait a moment, then mention Claude in the same thread; it picks up where it stopped. If it recurs constantly across channels, the organization's sustained traffic is above its rate limits; an admin can stagger heavy use or contact their account team about limits.
If your message mentions a spend limit instead, that's a different problem; see [You've reached a Claude Tag spend limit](#you%E2%80%99ve-reached-a-claude-tag-spend-limit).
### This request needs usage credits that aren't available
**What you see**
Claude posts in the thread:
> This request needs usage credits that aren't available and I couldn't finish this turn. Enable or purchase usage credits in claude.ai, then mention me to retry.
**What it means**
Your organization's usage credit balance can't cover the request, so the turn stopped. The session is still there.
**How to resolve**
An admin enables or purchases usage credits in claude.ai for your organization. Once that's done, mention Claude in the same thread to retry (adding credits doesn't restart the work on its own). The retry continues with the thread's conversation and context. [What survives between replies](/docs/claude-tag/concepts/how-it-works#what-survives-between-replies) covers what else carries over.
### Claude couldn't clone a repository for this session
**What you see**
Claude posts in the thread:
> Claude couldn't clone a repository for this session. Mention Claude in this thread to retry.
**What it means**
The clone failed when the session started. A one-off failure is transient; the same repository failing every time usually means it isn't granted for this channel.
**How to resolve**
Mention Claude in the same thread to retry. If the same repository fails every time, send your admin [the GitHub access entry](/docs/claude-tag/admins/troubleshooting#github-doesn%E2%80%99t-work-in-this-channel).
Cut at 300 lines. The page has the rest.
claude-tag/users/use-cases First recorded · 50 lines, first recorded
# Use case library ## All use cases ## Use cases by connection ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Use case library > Shapes of work teams hand Claude Tag in Slack, each with prompts to paste. See triage, catch-up, docs and tickets, project tracking, data, deals, monitoring, and bug fixes. export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>; <BetaNote /> Each use case below links to a page with prompts to paste, what it needs connected, and how to set it up to [run on a schedule or watch the channel](/docs/claude-tag/users/proactivity) instead of asking each time. <Note>If `@Claude` doesn't autocomplete in your workspace, your admin hasn't enabled Claude Tag. Send them the [setup guide](/docs/claude-tag/admins/setup-overview).</Note> ## All use cases | Use case | Who it's for | What Claude does | Connections needed | | :----------------------------------------------------------------------------------- | :------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------ | | [Catch up](/docs/claude-tag/users/use-cases/catch-up) | Anyone | Summarizes a thread, a channel, or what's waiting on you | Nothing | | [Work from your own channel](/docs/claude-tag/users/use-cases/your-own-channel) | Anyone | Answers scratch questions, digests channels you don't follow, and chases what you said you'd do | Nothing (issue tracker or GitHub optional) | | [Triage requests](/docs/claude-tag/users/use-cases/triage-requests) | Support, ops, IT, any intake channel | Answers what it can, flags duplicates, routes the rest, rolls up themes | Nothing (issue tracker optional for filing) | | [Turn threads into docs and tickets](/docs/claude-tag/users/use-cases/create-artifacts) | Anyone | Produces a decision doc, status memo, ticket, send-ready reply, or hosted web page from a discussion | Nothing (Drive or issue tracker optional) | | [Track projects and chase approvals](/docs/claude-tag/users/use-cases/track-projects) | PMs, leads, anyone running a project channel | Posts standing status digests; follows up on stalled sign-offs | Nothing (issue tracker optional) | | [Find answers in your docs](/docs/claude-tag/users/use-cases/find-answers) | Anyone | Looks up policies, runbooks, prior decisions; replies with the source | Google Drive, Notion, or Confluence | | [Review documents against a checklist](/docs/claude-tag/users/use-cases/review-documents) | Ops, compliance, anyone reviewing against criteria | Checks documents in a connected tool against a checklist or policy; posts findings per item | Google Drive, Notion, or Confluence | | [Answer data questions](/docs/claude-tag/users/use-cases/answer-data-questions) | Analysts, data-adjacent teams | Runs warehouse queries, returns charts; or charts from Slack history alone | BigQuery, Snowflake, or Redshift (charts from Slack need none) | | [Fix bugs](/docs/claude-tag/users/use-cases/fix-bugs) | Engineering | Reproduces the bug, opens a draft PR, follows CI to green | GitHub (Datadog, Sentry optional) | | [Work with GitHub](/docs/claude-tag/users/use-cases/work-with-github) | Engineering, anyone with repository questions | Answers repository questions in-thread, watches pull requests for you, turns postponed chores into draft PRs | GitHub | | [Watch monitors and alerts](/docs/claude-tag/users/use-cases/watch-monitors) | On-call, SRE | Checks dashboards on a schedule; investigates alerts before anyone asks | Datadog, Sentry, or PagerDuty | | [Pull deal and account state](/docs/claude-tag/users/use-cases/pull-deal-state) | Sales, customer success | Answers account questions in-thread; pre-call briefs; weekly pipeline digest | Salesforce, HubSpot, or Gong | | [Claude Tag for marketing teams](/docs/claude-tag/users/use-cases/marketing-team) | Marketing | Answers policy questions from team docs, drafts from campaign threads, checks lead state, posts a weekly metrics digest | HubSpot or Salesforce, plus Google Drive or Notion; BigQuery or Snowflake for the metrics digest (varies by recipe) | ## Use cases by connection A connection is a tool an admin linked for the channel. Each one adds a category of work; ask `@Claude what can you access from this channel?` to see which your channel has. | Connection | Examples | What it adds | | :----------------- | :------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------- | | Knowledge and docs | Google Drive, Notion, Confluence | [Find answers in your docs](/docs/claude-tag/users/use-cases/find-answers) | | Issue tracking | Linear, Jira, Asana | [Turn threads into tickets](/docs/claude-tag/users/use-cases/create-artifacts), [track projects](/docs/claude-tag/users/use-cases/track-projects) | | Data warehouse | BigQuery, Snowflake | [Answer data questions](/docs/claude-tag/users/use-cases/answer-data-questions) with charts | | Go-to-market | Salesforce, HubSpot, Gong | [Pull deal and account state](/docs/claude-tag/users/use-cases/pull-deal-state) | | Monitoring | Datadog, Sentry, PagerDuty | [Watch monitors and alerts](/docs/claude-tag/users/use-cases/watch-monitors) | | Code | GitHub | [Fix bugs](/docs/claude-tag/users/use-cases/fix-bugs), open pull requests, follow CI | If a connection your work needs is missing, an admin can [add it](/docs/claude-tag/admins/add-connections). ## Related resources * [Prompt library](/docs/claude-tag/users/prompt-library): the prompts from every entry, plus the operational ones, on one page * [Good habits](/docs/claude-tag/users/good-habits): make any of these reliable * [Set up routines](/docs/claude-tag/users/proactivity): turn any entry into a scheduled job
claude-tag/users/use-cases/answer-data-questions First recorded · 63 lines, first recorded
# Answer data questions ## How data-question prompts work ## Check the channel's connections ## Prompts to paste ### Chart a metric on demand ### Schedule a recurring metrics report ### Chart from Slack alone ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Answer data questions
> Claude Tag answers data questions in the Slack thread. See warehouse queries with charts, scheduled metric reports, and charts built from channel history alone.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How data-question prompts work
This page is for teams who answer questions from a data warehouse (the database where your analytics tables live, like BigQuery or Snowflake). These prompts turn a question asked in Slack into a query and a chart.
Each prompt below is a Slack message. You paste it in the channel where the metrics get discussed, Claude queries the warehouse or reads the channel history and posts progress in that thread, and the result lands there too. The result is a chart with a short answer, returned once or on a schedule depending on the prompt.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :------------- | :------------------ | :------------------------------------------- |
| Data warehouse | BigQuery, Snowflake | Required. Runs the queries behind each chart |
## Prompts to paste
### Chart a metric on demand
The thread is debating something a number would settle. Ask in the channel where the metrics get discussed.
```text wrap theme={null}
@Claude show signup growth by week for the last quarter, and explain the two dips people were debating above.
```
### Schedule a recurring metrics report
When the team checks the same numbers every morning, schedule the post. One message sets up the recurring report.
```text wrap theme={null}
@Claude every morning at 8, post yesterday's key metrics as a chart with a two-line summary of anything unusual.
```
Naming the format, here a chart plus two lines, keeps a recurring post scannable instead of letting it grow each day. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
### Chart from Slack alone
Charts don't require a connection, because channel history is data. It can chart request volume in a triage channel, or how long requests waited for a first reply.
```text wrap theme={null}
@Claude chart the volume of requests in this channel by week, and how long each waited for a first reply.
```
Anyone in the thread can ask for a different cut of the same data.
## Related resources
<CardGroup cols={2}>
<Card title="Watch monitors and alerts" href="/docs/claude-tag/users/use-cases/watch-monitors" horizontal arrow>
When the question is about systems, not metrics
</Card>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
Recurring reports
</Card>
</CardGroup>
claude-tag/users/use-cases/catch-up First recorded · 57 lines, first recorded
# Catch up ## How catch-up prompts work ## Check the channel's connections ## Prompts to paste ### Get a one-off recap ### Schedule a daily recap ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Catch up
> Claude Tag summarizes Slack threads and channels on demand. See one-off recaps, a scheduled morning rollup of open threads, and what's waiting on you.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How catch-up prompts work
Each prompt below is a Slack message. You paste it in any channel Claude is in, Claude reads the channel or thread history and posts progress in that thread, and the recap lands there too. The result is always a summary of what was said, returned once or every morning depending on the prompt.
## Check the channel's connections
This use case needs no connections; it works on Slack history alone. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
## Prompts to paste
### Get a one-off recap
A thread ran to forty replies overnight, or you skipped a channel for a week. Ask for the catch-up you need.
```text wrap theme={null}
@Claude catch me up on this channel since Monday.
```
```text wrap theme={null}
@Claude what got decided in this thread, and what's still open?
```
```text wrap theme={null}
@Claude summarize what I missed last week, grouped by topic.
```
Each of these bounds the work with a time window, one thread, or a grouping, so the summary comes back in a shape you can check.
### Schedule a daily recap
If the first stretch of every morning goes to re-reading channels, schedule the recap instead. One message sets up a rollup that posts before you start the day.
```text wrap theme={null}
@Claude every weekday at 9am, post a summary of open threads in this channel and anything that looks like it's waiting on someone.
```
"Waiting on someone" makes the rollup surface actions, not just a recap of yesterday. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
## Related resources
<CardGroup cols={2}>
<Card title="Turn threads into docs and tickets" href="/docs/claude-tag/users/use-cases/create-artifacts" horizontal arrow>
When the catch-up should become an artifact
</Card>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
Scheduling and triggers
</Card>
</CardGroup>
claude-tag/users/use-cases/create-artifacts First recorded · 72 lines, first recorded
# Turn threads into docs and tickets ## How artifact prompts work ## Check the channel's connections ## Prompts to paste ### Draft from one thread ### Ask for a hosted page ### Keep a capture channel ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Turn threads into docs and tickets
> Claude Tag turns a Slack discussion into the artifact you name. See replies you can send, decision docs, status memos, filed tickets, hosted web pages, and a capture-channel pattern.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How artifact prompts work
An artifact here is a generated document, page, chart, or file Claude posts or links in the thread for the team to use, as opposed to a chat reply.
Each prompt below is a Slack message. You paste it in the thread or channel you want turned into something, Claude reads the discussion and posts progress in that thread, and the draft lands there too. What the draft is depends on the prompt, and each one below names the artifact it returns, like a decision doc, a customer reply, a filed ticket, a planning outline, or a hosted web page.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :------------- | :------------------ | :------------------------------------- |
| None | — | Works on Slack content alone |
| Issue tracking | Linear, Jira, Asana | Optional. Files tickets from the draft |
## Prompts to paste
### Draft from one thread
The thread settled the question, and what's missing is the doc, the customer reply, or the ticket. Name the artifact in the thread where the discussion happened.
```text wrap theme={null}
@Claude turn this thread into a one-page decision doc: what we decided, the options we rejected, and why.
```
```text wrap theme={null}
@Claude draft a reply I can send to the customer based on this discussion. Keep it under 150 words.
```
```text wrap theme={null}
@Claude file this thread as a ticket, assign it to the owner we discussed above, and post the link here.
```
Name the format and the length; "a doc" gets you a guess, "a one-pager with a decision section" gets you the artifact.
### Ask for a hosted page
When the deliverable is a page people open, like a dashboard or a status page, ask for one. Claude publishes it as a web page hosted on claude.ai, posts the link in the thread, and updates it when you ask in the same thread.
```text wrap theme={null}
@Claude build a status page from the open items in this channel and post the link here.
```
Anyone with access to this channel can open the page; [artifact visibility](/docs/claude-tag/concepts/security-and-data#artifact-visibility) covers the access model.
### Keep a capture channel
Planning inputs arrive over a month, not in one sitting. Forward messages and ideas to one channel as you find them, then ask for a synthesis when you need the artifact.
```text wrap theme={null}
@Claude go through everything posted in this channel this month and synthesize it into an outline for the planning doc.
```
## Related resources
<CardGroup cols={2}>
<Card title="Catch up" href="/docs/claude-tag/users/use-cases/catch-up" horizontal arrow>
When you need the summary, not the artifact
</Card>
<Card title="Good habits" href="/docs/claude-tag/users/good-habits" horizontal arrow>
How to specify outputs that come back right
</Card>
</CardGroup>
claude-tag/users/use-cases/find-answers First recorded · 71 lines, first recorded
# Find answers in your docs ## How answer-finding prompts work ## Check the channel's connections ## Prompts to paste ### Look up a policy ### Check a named document ### Find the latest version ### Answer from the channel alone ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Find answers in your docs
> Claude Tag finds answers in connected docs and replies in the thread. See policy lookups, runbook checks, prior decisions, and answers from the Slack channel alone.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How answer-finding prompts work
Each prompt below is a Slack message. You paste it in the channel where the question came up, Claude searches the connected docs or the channel history and posts progress in that thread, and the answer lands there too. The result is always an answer with the source it came from, so you can open what it read.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :----------------- | :------------------------------- | :-------------------------------------------------------------------------------------------------------------- |
| Knowledge and docs | Google Drive, Notion, Confluence | Required to search those sources; channel-history-only answers need none. Searches the docs the answers live in |
## Prompts to paste
### Look up a policy
A customer asks about data retention and you need the policy, not a recollection. Ask where the question comes up.
```text wrap theme={null}
@Claude what's our policy on data retention, and which doc says so?
```
Asking for the doc keeps the answer checkable, since you can open what it read.
### Check a named document
Launch is close and you need to know whether the plan covers the EU rollout, without re-reading it. Point it at the document and the question.
```text wrap theme={null}
@Claude does the launch plan cover the EU rollout? Quote the relevant section if it's there.
```
"Quote the relevant section" turns a yes/no into evidence.
### Find the latest version
The pricing deck gets recreated every quarter, and the link you saved is two versions old. Ask for the current one.
```text wrap theme={null}
@Claude find the latest pricing deck and post where it lives.
```
### Answer from the channel alone
Without any connection, Claude can still answer from the channel's own history.
```text wrap theme={null}
@Claude what did this channel decide about the retention policy, and when?
```
Answers come from this channel's history and [memory](/docs/claude-tag/users/memory).
## Related resources
<CardGroup cols={2}>
<Card title="Catch up" href="/docs/claude-tag/users/use-cases/catch-up" horizontal arrow>
The same mechanism pointed at "what did I miss"
</Card>
<Card title="What Claude Tag remembers" href="/docs/claude-tag/users/memory" horizontal arrow>
How channel knowledge accumulates
</Card>
</CardGroup>
claude-tag/users/use-cases/fix-bugs First recorded · 79 lines, first recorded
# Fix bugs ## How bug-fix prompts work ## Check the channel's connections ## Prompts to paste ### Fix a reported bug ### Watch a bug channel ### Diagnose a failure without a fix ### See a pull request through CI ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Fix bugs
> Claude Tag takes a bug report from Slack to a draft pull request. See reproducing the issue, watching a bug channel, root-cause digs, and following CI to green.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How bug-fix prompts work
This page is for engineering teams. A pull request is a proposed code change opened for review; Claude opens them under its own GitHub identity, so they appear in your review queue like any other pull request.
Each prompt below is a Slack message. You paste it in the channel or thread where the bug lives, Claude works on it in an isolated workspace Anthropic hosts and posts progress in that thread, and the result lands there too. What the result is depends on the prompt, and each one below says what it returns, like a draft pull request, a root-cause writeup, or a standing watch that triages new reports as they arrive. Anything it opens on GitHub is authored by the Claude GitHub App.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :--------- | :------- | :----------------------------------------------------- |
| Code | GitHub | Required. Reads the repo and opens draft pull requests |
## Prompts to paste
### Fix a reported bug
A bug report arrives with reproduction steps and nobody free to take it. This gets you a draft pull request with the fix, linked back to the thread. Name the repository in the prompt so it's cloned before work starts.
```text wrap theme={null}
@Claude in acme/data-pipeline, reproduce the bug in this thread, fix it, and open a draft PR. Done means CI is green and the PR links back here.
```
The done definition, CI green and the PR linking back, gives the session a finish line it can check itself against.
The pull request appears under the Claude GitHub App and links back to the Slack thread it came from. See [how agent identity works](/docs/claude-tag/concepts/agent-identity#agent-access).
### Watch a bug channel
Reports arrive faster than the team triages them. The standing form watches the channel and opens drafts for anything reproducible.
```text wrap theme={null}
@Claude when a bug report lands in this channel, try to reproduce it. If you can, open a draft PR and tag the area owner; if you can't, reply with what you tried.
```
With the if/can't branch, every report gets a reply, either a draft or a list of what was tried. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
### Diagnose a failure without a fix
Not every failure needs a pull request. Ask for the diagnosis alone, and the decision about what to do with it stays with the team.
```text wrap theme={null}
@Claude why is this failing? Trace it to a cause and post what you find — diagnosis only, no fix.
```
Naming the deliverable, a cause rather than a patch, keeps the session from jumping ahead to code changes nobody asked for.
### See a pull request through CI
Once a pull request exists, one Claude opened or one a person did, Claude can watch it instead of you refreshing the page. It subscribes to that pull request and posts when CI status changes.
```text wrap theme={null}
@Claude watch PR #482 in acme/data-pipeline. When CI finishes, post the result here, and tag me if anything failed.
```
"Tag me if anything failed" is the filter. Green runs land quietly in the thread, and only a failure interrupts you.
For repository conventions that should hold across every session that touches the code, like where files go or what a pull request must include, see [Make repo conventions stick](/docs/claude-tag/users/good-habits#teach-claude-something-that-sticks).
## Related resources
<CardGroup cols={2}>
<Card title="Watch monitors and alerts" href="/docs/claude-tag/users/use-cases/watch-monitors" horizontal arrow>
Catching the problem before the bug report
</Card>
<Card title="Good habits" href="/docs/claude-tag/users/good-habits" horizontal arrow>
Definitions of done for code tasks
</Card>
</CardGroup>
claude-tag/users/use-cases/marketing-team First recorded · 116 lines, first recorded
# Claude Tag for marketing teams ## How marketing prompts work ## Check the channel's connections ## Prompts to paste ### Answer policy questions in an intake channel ### Recap a campaign channel and draft from it ### Check lead and campaign state in the CRM ### Schedule a weekly campaign metrics digest ### Save brand voice rules to channel memory ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Claude Tag for marketing teams
> Claude Tag recipes for marketing teams in Slack. See policy answers in an intake channel, campaign channel recaps and send-ready drafts, lead and campaign state from the CRM, a weekly metrics digest, and brand voice rules saved to channel memory.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How marketing prompts work
This page is for marketing teams. The recipes below run in the channels where marketing work already happens, like an intake channel where other teams post requests, a campaign channel during a launch, and the channel where lead numbers get discussed.
Each prompt below is a Slack message. You paste it in the channel where that work lives, Claude posts progress in that thread, and the result lands there too. What you get depends on the prompt, and each recipe names it, like an answer with the doc it came from, a channel recap, a send-ready draft, a list of CRM records, or a scheduled digest.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing. Each recipe below names the connection it uses.
| Connection | Examples | Why it matters here |
| :----------------- | :------------------------------- | :----------------------------------------------------------------------- |
| None | — | Recaps, drafts, and brand voice rules work on Slack content alone |
| Knowledge and docs | Google Drive, Notion, Confluence | Answers policy and process questions from the docs where they're written |
| Go-to-market | HubSpot, Salesforce | Reads CRM records, like contacts, leads, and deals |
| Data warehouse | BigQuery, Snowflake | Runs the queries behind the metrics digest |
## Prompts to paste
### Answer policy questions in an intake channel
Other teams bring marketing their process questions, like whether the company can sponsor an event, who approves a use of the logo, and who owns customer stories. When the answers are written in the team's connected docs, Claude can answer each request in the thread where it was asked.
```text wrap theme={null}
@Claude a vendor asked us to sponsor their conference. What's our sponsorship policy, and which doc says so?
```
Asking for the doc keeps the answer checkable, since you can open what it read.
To answer requests as they arrive instead of prompting each time, give the channel a standing role:
```text wrap theme={null}
@Claude remember for this channel: when someone tags you on a request, answer it from the brand guidelines and the marketing process docs, name the doc you used, and route anything the docs don't cover to the right owner with a one-line summary.
```
"Remember for this channel" saves the role to [channel memory](/docs/claude-tag/users/memory), so it applies to everyone's threads, not just yours. [Triage requests](/docs/claude-tag/users/use-cases/triage-requests) adds a weekly rollup that also sweeps posts that never tagged Claude.
Some questions have no doc to cite, and a person on the team answers in the thread. When that answer will come up again, tell Claude to save it:
```text wrap theme={null}
@Claude remember for this channel: conference sponsorships are capped at $5,000, and the events lead approves each one.
```
The next person who asks gets the answer from channel memory instead of waiting for the team. When the policy changes, ask `@Claude what do you remember about this channel?` and tell it to update the entry.
### Recap a campaign channel and draft from it
During a launch, a campaign channel fills with decisions, status updates, and copy changes faster than anyone can read them all. Ask for a recap bounded by a time window, and when a thread settles what an announcement should say, ask for the draft in that thread.
```text wrap theme={null}
@Claude catch me up on this channel since Monday: what got decided, what's still open, and anything waiting on marketing.
```
The time window bounds the recap, so it comes back in a shape you can check.
```text wrap theme={null}
@Claude turn this thread into an announcement draft I can send to the customer list. Keep it under 200 words and match the messaging doc linked above.
```
Name the format, the length, and the source the draft should match. The same prompt shape produces a decision doc or a status memo; [Turn threads into docs and tickets](/docs/claude-tag/users/use-cases/create-artifacts) lists the variants.
### Check lead and campaign state in the CRM
A lead is a prospect record in a CRM like HubSpot or Salesforce, created when someone responds to a campaign. When the channel is debating whether a campaign's leads are moving, ask the question against those records.
```text wrap theme={null}
@Claude which leads from last month's webinar campaign still have no owner, and how long has each been waiting?
```
Asking how long each has waited tells you which lead to chase first.
```text wrap theme={null}
@Claude compare the leads the June campaign created against the ones that reached a queue, and post which ones stalled and at what stage.
```
The reply lists the stalled records and the stage where each stopped. The [HubSpot connection](/docs/claude-tag/admins/connections/hubspot) is created with read scopes, so prompts in this channel pull records and don't change them. For account questions, pre-call briefs, and a pipeline digest, see [Pull deal and account state](/docs/claude-tag/users/use-cases/pull-deal-state).
### Schedule a weekly campaign metrics digest
When the team checks the same campaign numbers at the start of every week, schedule the post instead of asking each time. One message sets up the recurring report, and it needs a data warehouse connection to run the queries.
```text wrap theme={null}
@Claude every Monday at 9am Eastern, post last week's campaign metrics as a chart: signups by campaign, week-over-week change, and a two-line note on anything unusual.
```
Naming the timezone matters, since schedules default to UTC. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
### Save brand voice rules to channel memory
Claude follows the tone and terminology rules saved to a channel's memory, so a rule saved once applies to every later draft in that channel.
```text wrap theme={null}
@Claude remember for this channel: headlines use sentence case, "sign up" is the verb and "signup" is the noun, and the product is never called a platform.
```
Keep saved entries short, since long entries crowd out everything else. For a full style guide, link the document in the channel or store it in a connected tool Claude can read, instead of re-describing its contents in memory. [What Claude Tag remembers](/docs/claude-tag/users/memory) covers how to check and correct what's saved.
## Related resources
<CardGroup cols={2}>
<Card title="Pull deal and account state" href="/docs/claude-tag/users/use-cases/pull-deal-state" horizontal arrow>
The full set of go-to-market prompts
</Card>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
How the scheduled digest runs, and more recipes
</Card>
</CardGroup>
claude-tag/users/use-cases/pull-deal-state First recorded · 71 lines, first recorded
# Pull deal and account state ## How deal-state prompts work ## Check the channel's connections ## Prompts to paste ### Check one account's state ### Find stalled deals ### Get a pre-call brief ### Schedule a weekly digest ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Pull deal and account state
> Claude Tag pulls account and deal state into the Slack channel. See in-thread account answers, pre-call briefs, and a scheduled weekly pipeline digest.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How deal-state prompts work
This page is for sales and customer-success teams. A deal (also called an opportunity) is a sales prospect tracked in a CRM like Salesforce or HubSpot; an account is a customer record. These prompts pull that state into the Slack channel where the team discusses it.
Each prompt below is a Slack message. You paste it in the account or deal channel, Claude pulls from the connected CRM and the channel discussion and posts progress in that thread, and the result is posted in that thread. What you get depends on the prompt, and each one below names it, like one account's state, a pre-call brief, or a scheduled pipeline digest.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :----------- | :------------------------ | :--------------------------------------- |
| Go-to-market | Salesforce, HubSpot, Gong | Required. Pulls account and deal records |
## Prompts to paste
### Check one account's state
The reply lists last activity, open items, and who owns the next step for the named account.
```text wrap theme={null}
@Claude what's the state of the Acme renewal? Last activity, open items, and who owns the next step.
```
### Find stalled deals
The reply lists deals stuck at the named stage and how long each has been there.
```text wrap theme={null}
@Claude which deals are stuck in stage 3, and how long has each been there?
```
"How long has each been there" is the actionable half. Aging tells you which deal to work first.
### Get a pre-call brief
The brief pairs what's in the system with what was discussed in the channel.
```text wrap theme={null}
@Claude brief me on Initech before my 2pm: account history, recent activity, and anything discussed in this channel lately.
```
### Schedule a weekly digest
One message sets up a standing digest posted to the team channel every Monday.
```text wrap theme={null}
@Claude every Monday at 9am, post a pipeline digest: deals that moved stage last week, deals stalled more than two weeks, and renewals due in the next 30 days.
```
The three lines cover what moved, what's stuck, and what's coming due, so the digest reads the same way every Monday. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
## Related resources
<CardGroup cols={2}>
<Card title="Answer data questions" href="/docs/claude-tag/users/use-cases/answer-data-questions" horizontal arrow>
When the question is metrics, not accounts
</Card>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
Scheduled digests
</Card>
</CardGroup>
claude-tag/users/use-cases/review-documents First recorded · 89 lines, first recorded
# Review documents against a checklist ## How document-review prompts work ## Check the channel's connections ## Prompts to paste ### Review one document against a checklist ### Review a batch against a policy ### Work through a filing list ### Compare with the last review ### Schedule a recurring review ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Review documents against a checklist
> Claude Tag reviews documents in a connected tool against a checklist or policy and posts findings in the thread. See single-document checks, batch reviews, filing lists, comparisons with past reviews, and a scheduled weekly sweep.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How document-review prompts work
Each prompt below is a Slack message. You paste it in the channel where the review belongs, Claude reads the documents and the criteria from the connected tool and posts progress in that thread, and the findings land there too. The criteria can be whatever your team already uses, like a checklist, a policy document, or a filing list.
Read the findings before you act on them, in proportion to what's at stake. If a finding needs checking, ask Claude to show its work in the same thread.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :----------------- | :------------------------------- | :----------------------------------------------------------------------------------------------------------------------- |
| Knowledge and docs | Google Drive, Notion, Confluence | Required. Claude reads the documents under review, and the checklist or policy they're checked against, from these tools |
Claude can reach only what the connected account can see in that tool. If a document is missing from a review, ask an admin to [share it with the connected account](/docs/claude-tag/admins/add-connections#limit-access-to-specific-resources).
## Prompts to paste
### Review one document against a checklist
A draft is ready to go out, and it has to pass the team's checklist first. Name the document and the checklist in the channel where the review is happening.
```text wrap theme={null}
@Claude review the launch announcement doc against the review checklist, and post one finding per item: met, not met, or unclear, plus the section you based each call on.
```
Asking for the section keeps each finding checkable, since you can open what it read.
### Review a batch against a policy
A quarter's worth of vendor documents landed in one folder, and each needs the same check. Name the folder and the policy.
```text wrap theme={null}
@Claude go through each document in the vendor-docs folder and check it against the data-handling policy. Post a table with one row per document: what it covers, what's missing, and anything unclear.
```
One row per document bounds the work, so the review comes back in a shape you can check.
### Work through a filing list
Your team keeps a list of filings to check, and each item needs a verdict by the end of the week. Point Claude at the list and where the filings live.
```text wrap theme={null}
@Claude work through this week's filing list in the shared folder. For each item, find the matching filing, check it against the list's criteria, and post its status and what's missing.
```
Naming both the list and the folder scopes the search to the documents that matter.
### Compare with the last review
A revised draft is in, and you need to know whether it fixes what the last review flagged.
```text wrap theme={null}
@Claude review the updated vendor agreement against the checklist, then compare with what the review in this channel found last month and post what changed.
```
Naming the timeframe matters, since Claude looks back by listing this channel's earlier sessions and reading them.
### Schedule a recurring review
New documents arrive every week, and the same check applies to each. Schedule the review instead of asking each time.
```text wrap theme={null}
@Claude every Monday at 9am Pacific, check the shared folder for documents added in the past week, review each against the review checklist, and post the findings here.
```
Including the timezone matters, since schedules default to UTC. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
Keep the checklist as a document Claude can read, in the connected tool or linked in the channel, rather than re-describing its contents in [channel memory](/docs/claude-tag/users/memory).
## Related resources
<CardGroup cols={2}>
<Card title="Find answers in your docs" href="/docs/claude-tag/users/use-cases/find-answers" horizontal arrow>
The same connections pointed at a single question
</Card>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
How the recurring review runs on a schedule
</Card>
</CardGroup>
claude-tag/users/use-cases/track-projects First recorded · 68 lines, first recorded
# Track projects and chase approvals ## How project-tracking prompts work ## Check the channel's connections ## Prompts to paste ### Get a one-time status update ### Schedule a daily project digest ### Chase an approval ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Track projects and chase approvals
> Claude Tag posts project digests no one has to compile. See standing status updates and follow-ups on contracts, design reviews, and pull requests until they close.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How project-tracking prompts work
This page is for anyone running a project from a Slack channel: pulling status, chasing approvals, and posting digests so the team doesn't have to ask.
Each prompt below is a Slack message. You paste it in the project channel, Claude reads channel history and any connected trackers and posts progress and the result in that thread. What you get depends on the prompt, and each one below names it, like a one-time status digest, a scheduled daily digest, or a follow-up that runs until an approval lands.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :------------- | :------------------ | :------------------------------------------------------------------------------------------ |
| Issue tracking | Linear, Jira, Asana | Optional. Adds tracker state to digests; without it, digests draw from channel history only |
| Code | GitHub | Optional. Checks PR and review state |
## Prompts to paste
### Get a one-time status update
The reply pulls status spread across days of channel scroll into one digest. Ask in the project channel.
```text wrap theme={null}
@Claude where are we on the migration? What's blocked and on whom?
```
The digest comes back in the thread with what moved, what's blocked, and on whom, built from channel history plus any connected trackers.
### Schedule a daily project digest
One message sets up a digest that posts every weekday.
```text wrap theme={null}
@Claude every weekday at 5pm, post a project digest: what moved today, what's blocked, and what hasn't been touched in three days.
```
Name the format in the prompt, like the three sections here, so every digest comes back in the same readable shape. "Hasn't been touched in three days" is a number, so stalled work surfaces itself instead of depending on someone's sense of what counts as stale. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
### Chase an approval
A contract sits with legal, a design review has no comments, a pull request waits on a reviewer. Claude can follow any of them until they close. It nudges when the review stalls and posts when the state changes.
```text wrap theme={null}
@Claude every weekday, check the design review discussed in this thread. If it's gone two weekdays with no reviewer reply, nudge them here; when an approval lands, post that it's done. Done means approved, not just commented on.
```
Define what "done" includes; see [the babysit caution](/docs/claude-tag/users/good-habits#give-every-task-a-definition-of-done).
Code approvals need the code connection. Scheduled follow-ups on repositories use that same GitHub connection, with nothing extra to set up.
## Related resources
<CardGroup cols={2}>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
Schedules and event triggers
</Card>
<Card title="Good habits" href="/docs/claude-tag/users/good-habits" horizontal arrow>
Definitions of done that close threads
</Card>
</CardGroup>
claude-tag/users/use-cases/triage-requests First recorded · 58 lines, first recorded
# Triage requests ## How triage prompts work ## Check the channel's connections ## Prompts to paste ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Triage requests
> Claude Tag triages a Slack request channel with two setup messages. See in-thread answers, duplicate flags, owner routing, weekly theme rollups, and optional ticket filing.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How triage prompts work
This page is for any team with an intake channel, like #ask-it, #design-requests, or #legal-help, where people post questions and someone has to route or answer each one.
The two prompts below are Slack messages you paste in the request channel, in order. Together they set up a standing role: when someone tags `@Claude` on their request, it replies in-thread, answering what it can, flagging duplicates, and routing the rest. The weekly rollup lands as a top-level post in the same channel and sweeps anything that wasn't tagged.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :------------- | :----------- | :-------------------------------------- |
| None | — | Works on Slack content alone |
| Issue tracking | Linear, Jira | Optional. Files routed items as tickets |
## Prompts to paste
Add Claude to the channel with `/invite @Claude` if it isn't there, then two messages set it up.
<Steps>
<Step title="Give the channel a standing role">
```text wrap theme={null}
@Claude remember for this channel: when someone tags you on a request, check whether it duplicates something already reported, answer it directly if the answer exists, and otherwise route it to the right owner with a one-line summary. Track recurring themes.
```
"Remember for this channel" saves the role to [channel memory](/docs/claude-tag/users/memory), so it applies to everyone's threads, not just yours. Tell requesters to include `@Claude` when they post; pin the convention or add it to the channel topic.
</Step>
<Step title="Add a weekly rollup so nothing is missed">
```text wrap theme={null}
@Claude every Friday at 3pm, post a summary of this week's requests: how many, top themes, and anything still unrouted, including posts that didn't tag you.
```
"Including posts that didn't tag you" turns the recap into a sweep, so requests that arrived without a mention are still caught. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
</Step>
</Steps>
Answers draw on what the channel has already settled, meaning its [memory](/docs/claude-tag/users/memory) and its own past threads, and routing gets more accurate as corrections land in channel memory.
## Related resources
<CardGroup cols={2}>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
How the weekly rollup runs on a schedule
</Card>
<Card title="What Claude Tag remembers" href="/docs/claude-tag/users/memory" horizontal arrow>
How the standing role persists and improves
</Card>
</CardGroup>
claude-tag/users/use-cases/watch-monitors First recorded · 63 lines, first recorded
# Watch monitors and alerts ## How monitor-watch prompts work ## Check the channel's connections ## Prompts to paste ### Schedule a recurring dashboard check ### Investigate a single alert ### Start the diagnosis before anyone asks ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Watch monitors and alerts
> Claude Tag watches dashboards and alert channels so you see one line per issue. See scheduled checks, alert investigation before anyone asks, and the prompts to set both up.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How monitor-watch prompts work
This page is for operations and on-call teams. A monitor is an automated check in a tool like Datadog or PagerDuty that fires an alert when a metric crosses a threshold. These prompts have Claude check those dashboards or investigate alerts as they arrive.
Each prompt below is a Slack message. You paste it in the channel that receives the alerts, Claude checks the connected dashboards or investigates the alert and posts progress in that thread, and the findings land there too. What comes back depends on the prompt, and each one below names it, like a scheduled one-line-per-service check, a single alert's diagnosis, or a standing watch that posts only changes.
## Check the channel's connections
Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :--------- | :------------------------- | :----------------------------------------- |
| Monitoring | Datadog, Sentry, PagerDuty | Required. Reads dashboards and alert state |
## Prompts to paste
### Schedule a recurring dashboard check
One message sets up a standing check that posts every morning, one line per service.
```text wrap theme={null}
@Claude every morning at 7, check the service dashboards and post one line per service: green, or what's off and since when.
```
Name the output format in the schedule, like "one line per service" above, so every post reads the same way. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
### Investigate a single alert
Reply in the thread the alert landed in for a first pass at diagnosis. The prompt names what diagnosis means here and where to put the result.
```text wrap theme={null}
@Claude investigate this alert: when it started, what changed around then, and what you'd look at first. Post findings here.
```
"When it started, what changed around then" points the work at diagnosis, and "post findings here" keeps the trail in the thread for whoever picks it up.
### Start the diagnosis before anyone asks
Set this up as a routine to get both: a scheduled check against the last known state, and an investigation kicked off for any change. The routine posts only when something changed, not on every check.
```text wrap theme={null}
@Claude every two hours, check the alerting dashboard against its last state. For anything new, post when it started, what changed around then, and what to look at first.
```
## Related resources
<CardGroup cols={2}>
<Card title="Fix bugs" href="/docs/claude-tag/users/use-cases/fix-bugs" horizontal arrow>
When the investigation should end in a pull request
</Card>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
Schedules and event triggers
</Card>
</CardGroup>
claude-tag/users/use-cases/work-with-github First recorded · 121 lines, first recorded
# Work with your GitHub repositories ## How GitHub prompts work ## Check the channel's connections ## Prompts to paste ### Answer a repository question without interrupting the author ### Stop refreshing a pull request ### Hand off the change you keep postponing ### Triage a suspected bug where the report arrives ### Hand off a change and follow its pull request in one message ### Act on review comments and CI failures ## Repository instructions in CLAUDE.md ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Work with your GitHub repositories
> Claude Tag works with your GitHub repositories from Slack: answer questions in-thread, subscribe to pull requests, and hand back chores as draft pull requests.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
## How GitHub prompts work
This page is for engineers and anyone else with questions a repository can answer. Claude works with the GitHub repositories an admin granted for the channel. It reads the code to answer questions, watches pull requests you name, and hands back changes as draft pull requests.
Each prompt below is a Slack message. Paste it in the channel or thread where the question lives. Claude clones the repository into an isolated workspace Anthropic hosts, posts progress in that thread, and delivers the result there too.
Name the repository in the first message. A session starts with no repositories checked out and clones one when the request names it. Anything Claude opens on GitHub is authored by the Claude GitHub App, so it appears in your review queue like any other pull request.
<Note>An admin [grants a repository to the channels that need it](/docs/claude-tag/admins/attach-to-scope), and questions about the code work only in those channels. By default anyone in those channels can ask, and an admin can [restrict who can use Claude](/docs/claude-tag/admins/restrict-access#control-who-can-invoke-claude-tag).</Note>
## Check the channel's connections
Check that the channel has the connection below. Ask `@Claude what can you access from this channel?` and the reply also lists which repositories the channel can reach. An admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.
| Connection | Examples | Why it matters here |
| :--------- | :------- | :----------------------------------------------------------------- |
| Code | GitHub | Required. Reads granted repositories and opens draft pull requests |
The same workflows apply to other source control systems. For GitLab, an admin [connects it with an access token](/docs/claude-tag/admins/connections/gitlab) instead of the GitHub App, and Claude clones its repositories the same way.
If Claude replies that a repository isn't configured, the repository wasn't granted for this channel. An admin can [verify GitHub access](/docs/claude-tag/admins/configure-github#verify-github-access). After the grant changes, start a fresh thread and name the repository in the first message.
## Prompts to paste
### Answer a repository question without interrupting the author
A question about how the code behaves arrives in the channel, and the person who wrote it is away. Claude clones the repository, reads the code, and posts the answer in the thread.
```text wrap theme={null}
@Claude in acme/data-pipeline, how does the export retry logic decide when to give up? Name the files involved.
```
Asking for the files involved attaches proof to the answer, so anyone in the thread can open them and check.
Investigation questions work the same way: when a behavior last changed, in which commit, and who to ask about it.
```text wrap theme={null}
@Claude in acme/data-pipeline, did the export retry behavior change recently? Find the commit that changed it, when it landed, and who wrote it.
```
The clone carries the repository's full commit history, so history questions get answered from the same checkout as code questions. If the repository keeps a `CODEOWNERS` file, questions about who owns a path read from it too.
### Stop refreshing a pull request
Your work is blocked on a pull request a teammate opened, and the only way to know it moved is to keep checking the page. Claude subscribes to the pull request and posts in the thread when it updates, whether Claude opened it or a person did.
```text wrap theme={null}
@Claude subscribe to PR #519 in acme/data-pipeline, the schema migration. When CI finishes or a review arrives, post here, and tag me if anything failed.
```
Claude reads the pull request's workflow runs and logs, so the post says whether checks passed or failed. To list or cancel a subscription later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work). Because the prompt asks for a tag only on failure, passing runs post to the thread without notifying you.
### Hand off the change you keep postponing
Small, well-understood changes sit on the list for weeks because they never become urgent. Docs drift from the code, a config key keeps its old name, a dependency stays a version behind. Describe one in a message, and it comes back as a draft pull request linked to the thread.
```text wrap theme={null}
@Claude in acme/data-pipeline, the CSV export docs still describe the old date format. Update them to match the code and open a draft PR. Done means CI is green and the PR links back here.
```
Writing a [definition of done](/docs/claude-tag/users/good-habits#give-every-task-a-definition-of-done) into the task lets the session check its own work. The change comes back as a draft pull request in your review queue, opened under Claude's own GitHub identity.
### Triage a suspected bug where the report arrives
A report arrives in the feedback channel, and nobody knows yet whether it's a bug. Claude investigates the repository and either explains the behavior or opens a draft fix.
```text wrap theme={null}
@Claude a user reports that exports drop rows with empty dates. In acme/data-pipeline, is that a bug or intended behavior? If it's a bug, open a draft PR with a fix; if it's intended, explain here what the code does.
```
For the full arc from a bug report to green CI, including a standing watch that triages a bug channel, see [Fix bugs](/docs/claude-tag/users/use-cases/fix-bugs). Because the prompt asks for either a fix or an explanation, the thread gets an answer even when the behavior turns out to be intended.
### Hand off a change and follow its pull request in one message
You can combine the earlier recipes in a single message. The prompt below hands off a change, sets the definition of done, and asks Claude to subscribe to the pull request it opens.
```text wrap theme={null}
@Claude in acme/data-pipeline, the deprecation warnings in the export module still reference the removed legacy-dates option. Remove the stale warnings and open a draft PR. Done means CI is green and the PR links back here. Then subscribe to your own PR, and when CI finishes or a review arrives, post here and tag me if anything failed.
```
Claude opens the draft and then follows it the way it follows any pull request, because subscriptions work the same whether Claude opened the pull request or a person did. CI results and review activity arrive as posts in the thread, so you open GitHub only to review the finished change.
### Act on review comments and CI failures
Claude can watch a pull request and address CI failures, review comments, and change requests as they come in, until the pull request is ready to merge. You approve and merge.
```text wrap theme={null}
@Claude watch your PR #562 in acme/data-pipeline. When CI fails, fix it and push. When a review comment arrives, address it and push. Post here after each push saying what changed and why. Done means CI is green and every comment is addressed. I do the approving and merging.
```
<Warning>If you don't want Claude to approve or merge pull requests, turn on branch protection rules that restrict who can merge. These rules apply to Claude too. Also write "I do the approving and merging" into the task, as the example does. The task wording states your intent, but it's an instruction Claude can lose track of, not a control. The branch protection rule is what enforces it.</Warning>
Ask for a post after each push so you can follow the pull request from the thread instead of opening GitHub.
## Repository instructions in CLAUDE.md
If your repository has conventions Claude should follow, such as file layout, pull request labels, or dependencies to install, add them to a `CLAUDE.md` file at the repository root. When Claude clones the repository into a session, its `CLAUDE.md`, `.claude/CLAUDE.md`, and `.claude/rules/*.md` files load on the next turn, so the guidance arrives without further prompting. Skills in the repository's `.claude/skills/` folder also load, so Claude can use them in sessions that have the repository. Anyone with repository write access can edit these files, and they reach every session that works in that repository, from any channel.
Each session runs in an isolated sandbox with a standard set of preinstalled tools. Two threads are two sessions with two separate sandboxes. If the repository needs a tool that the standard set doesn't include, such as a language runtime or a database client, add the install commands to `CLAUDE.md`, and Claude [runs them when its work needs them](/docs/claude-tag/admins/configure-github#install-project-dependencies).
<Note>A `CLAUDE.md` is guidance rather than a gate. If a pull request must carry a label or pass a check, make that a repository rule. For where `CLAUDE.md` sits among channel memory, channel instructions, and skills, see [Teach Claude something that sticks](/docs/claude-tag/users/good-habits#teach-claude-something-that-sticks).</Note>
## Related resources
<CardGroup cols={2}>
<Card title="Fix bugs" href="/docs/claude-tag/users/use-cases/fix-bugs" horizontal arrow>
The full arc from a bug report to a draft pull request and green CI
</Card>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
Pull request subscriptions and other standing work
</Card>
</CardGroup>
claude-tag/users/use-cases/your-own-channel First recorded · 111 lines, first recorded
# Work from your own channel ## Your own channel versus a DM ## Set up the channel ## Prompts to paste ### Ask scratch questions ### Get a digest of channels you don't follow ### Track your week ### Hand a thread to a teammate ### Chase your open follow-ups ## Cover your time away ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Work from your own channel
> Create a Slack channel for you and Claude Tag alone and run your work from it. See scratch questions, digests of channels you don't follow, a weekly status digest, follow-ups chased until they close, and a handoff that covers your time away.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
A channel with just you and Claude in it works the same way any other channel does. This page is for anyone who wants a place for work that doesn't belong in any specific team's channel, like half-formed questions, personal digests, and the things you said you'd do.
## Your own channel versus a DM
A DM is the other place to work alone with Claude, and the two surfaces run on different accounts. A DM session runs with your own claude.ai connectors, the work is attributed to you (pull requests excepted; the Claude GitHub App authors those), and usage bills to your seat. What Claude does there sits outside channel and workspace memory.
Your own channel runs with the connections an admin set for it, usage bills to the organization, and what Claude learns there accumulates as [channel memory](/docs/claude-tag/users/memory) that later threads build on. [Routines](/docs/claude-tag/users/proactivity) can post there on a schedule. When scratch work turns into a team task, the thread is ready to [hand to a teammate](#hand-a-thread-to-a-teammate).
Pick a DM for personal tasks on your own connections, or for data that shouldn't run through a shared channel connection. Pick your own channel for standing work, and for anything you might later hand off or show someone. [Pick the right surface](/docs/claude-tag/users/good-habits#pick-the-right-surface) compares both against a team channel.
## Set up the channel
1. Create a Slack channel and add Claude with `/invite @Claude`. Make the channel public unless the work needs to be private, since [memory](/docs/claude-tag/users/memory) from a public channel is shared across the workspace and teammates can find and join the work. A private channel works too, and keeps its memory in its own store.
2. Ask `@Claude what can you access from this channel?`. None of the prompts below require a connection, and an admin can [add a connection](/docs/claude-tag/admins/add-connections) your work needs, like the issue tracker or GitHub.
3. Tell Claude how the channel should behave and ask it to remember, as in `@Claude remember for this channel: keep replies short, and format digests as tables`. Later sessions in the channel start from what you saved.
## Prompts to paste
Each prompt below is a Slack message. You paste it in your channel, Claude works with the channel's history and connections, and the result lands in that thread.
### Ask scratch questions
A question is half-formed, or the answer only matters to you. Ask it here instead of in a team channel.
```text wrap theme={null}
@Claude summarize the last week of #product-feedback and pull out anything about the export flow.
```
Naming a public channel works from here, since Claude's Slack search covers public channels in this workspace. For a channel's full history rather than what search finds, Claude needs to be a member of that channel too. The answers stay in your channel, where later sessions read them.
### Get a digest of channels you don't follow
Some channels matter to your work a few times a month, not daily. Have Claude watch them and post here when something is relevant.
```text wrap theme={null}
@Claude watch #product-announce, #eng-announce, and #design-announce. Once a day, post here anything relevant to the billing migration. Skip days with nothing.
```
Naming both the channels and the topic keeps the watch useful, and skipping empty days keeps this channel readable. Instead of skimming three announcement channels yourself, you read at most one post a day here.
### Track your week
Open threads pile up here the way they do in any project channel. A scheduled digest posts a weekly summary of where they all stand.
```text wrap theme={null}
@Claude every Friday at 3pm Pacific, post a digest of this channel: what closed this week, what's still open, and what hasn't moved in five days. Skip anything with a ✅ reaction.
```
Give the digest a concrete threshold, like five days without movement, and stalled work shows up without you asking for it. React ✅ to anything you consider done, and the digest drops it. Include the timezone, since schedules default to UTC. To list, edit, or cancel scheduled work later, see [manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
### Hand a thread to a teammate
Scratch work sometimes turns into a team task. Suppose a thread in this channel started as a half-formed question about the export flow, grew into a reproducible bug, and the fix now belongs to your teammate Marta. That thread is ready to share as it stands, because anyone in the channel can steer a session by replying in it. Invite Marta to the channel (for a public channel, sharing the thread link works too) and ask for a handoff summary in the thread.
```text wrap theme={null}
@Claude summarize this thread for Marta: what's been tried, what's decided, and what's still open.
```
The summary gives Marta the state of the work in one message, with the full history above it. From there the thread is hers to continue, without re-mentioning @Claude or starting over.
### Chase your open follow-ups
Claude can track the work you've committed to but might have forgotten about. When you agree to do something in another channel, forward that message to this channel, or post a short note here describing the commitment. When the work is somewhere Claude can check through this channel's connections, like a pull request review you owe, include the link.
Then schedule a weekly sweep.
```text wrap theme={null}
@Claude every Monday at 9am Pacific, read this channel and post one line per thing I said I'd do that isn't done yet, with how long it's been open. Check anything linked before calling it done. Keep listing each item until I mark it with a ✅.
```
Monday's post lists each commitment in this channel that isn't done yet. React ✅ when you finish one and it drops off the list, and everything else comes back the next Monday.
## Cover your time away
Your channel can cover for you while you're out. Before you leave, post one handoff message here and pin it. Say who's covering, where each piece of work stands, what to point people at, and what holds until you're back. Then tell Claude to answer from it and to pause the channel's standing work.
```text wrap theme={null}
@Claude I'm out next week and Marta is covering. Where things stand: the billing migration is waiting on legal, the dashboard rebuild is paused until the design review closes, and the onboarding runbook is pinned in this channel. Leave the pricing config alone until I'm back. While I'm out, when anyone asks here, answer from this message and the channel's history. Pause this channel's scheduled posts until I say I'm back.
```
While you're out, a teammate who needs to know where a piece of work stands, or who owns it, tags `@Claude` in your channel and gets the answer from the pinned handoff message, the channel's history, and [channel memory](/docs/claude-tag/users/memory). If you set a Slack status or an out-of-office reply, point people to this channel in it.
The pause covers this channel's own routines, like the Friday digest and the Monday sweep this page sets up, so scheduled posts stop piling up unread. Anyone in the channel can [list, edit, or disable its standing work](/docs/claude-tag/users/proactivity#manage-standing-work), so a teammate can turn a routine back on early if the coverage needs it.
On your first morning back, ask Claude to catch you up.
```text wrap theme={null}
@Claude I'm back. Turn this channel's scheduled posts back on, and post one list of what needs me first, in priority order, built from what happened here while I was away.
```
The reply is one list of everything that happened here while you were away, ordered by what needs your attention first.
## Related resources
<CardGroup cols={2}>
<Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
List, edit, or disable the standing work this page sets up
</Card>
<Card title="Good habits" href="/docs/claude-tag/users/good-habits" horizontal arrow>
Pick the right surface and write tasks that close
</Card>
</CardGroup>
claude-tag/users/when-claude-responds First recorded · 104 lines, first recorded
# Control when Claude Tag responds ## What triggers a response ## Turn automatic replies on or off ## The name on a reply ## Make a channel quieter ### Quiet one conversation ### Quiet the whole channel ### Remove Claude Tag from the channel ## When Claude quiets itself ## Messages that never get a reply ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Control when Claude Tag responds
> Claude Tag replies to DMs, threads it's already in, and channel messages it judges warrant a reply, all without an @-mention. See what triggers a response, how to tell an unprompted reply from a task reply, how to turn automatic replies on or off with the Respond automatically setting, how to quiet a thread or channel, when Claude quiets itself, how to remove Claude from a channel, and which messages never get a reply.
export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
<BetaNote />
Claude replies without an @-mention in DMs, in any thread it's already part of, and to channel messages it judges warrant a reply. It's an ambient presence in the channel, and the @-mention is how you guarantee a response, not a requirement for one. Claude also [turns unprompted replies off on its own](#when-claude-quiets-itself) in a channel whose messages stop giving it anything to respond to. Any channel member can quiet Claude further, give it [standing work that posts on a schedule](/docs/claude-tag/users/proactivity), or remove it from the channel.
## What triggers a response
Where you send the message decides whether you need the mention.
| Where you write | Replies without an @-mention? |
| :---------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A DM with Claude | Always. Every message is addressed to Claude already |
| A thread Claude is already in | Yes, unless you've [quieted the thread](#quiet-one-conversation). Once Claude has joined, every reply there reaches it without another mention |
| A channel, top-level | Sometimes, when it can answer a question or pick up a task. Include `@Claude` to guarantee a reply, or [turn unprompted replies off](#quiet-the-whole-channel) |
All of this is adjustable. You can [quiet a single thread](#quiet-one-conversation), [turn automatic replies off across a channel](#turn-automatic-replies-on-or-off), or tell Claude which kinds of messages to respond to.
For work that should happen without anyone typing a message, use a [routine](/docs/claude-tag/users/proactivity): scheduled posts, channel watches, and pull-request subscriptions run on their own trigger and post into the channel.
## Turn automatic replies on or off
The **Respond automatically** setting controls whether Claude replies to a channel's messages without an @-mention. Each channel has its own. When it's on, Claude may reply to a message it judges warrants one, as [What triggers a response](#what-triggers-a-response) describes. When it's off, Claude replies in that channel only when someone @-mentions it.
All three places below change the same setting, so a change you make in one appears in the others.
| Where | How |
| :-------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| In Slack | Ask Claude in the channel, for example "@Claude only respond in this channel when someone @-mentions you" or "@Claude respond to messages here even when nobody mentions you." Claude confirms the change. |
| The channel's Configure page | Open the **Configure** link in the footer of any Claude reply and switch the **Respond automatically** toggle. See [Configure Claude for a channel](/docs/claude-tag/users/good-habits#configure-claude-for-a-channel). |
| The Claude Tag admin page (admins only) | At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, open the channel's scope and switch **Respond automatically** in its **Advanced** settings. |
The setting covers the channel's messages, not DMs. To quiet a single thread instead of the whole channel, [ask Claude in that thread](#quiet-one-conversation). Work that runs on a schedule or an event rather than in response to a message is a [routine](/docs/claude-tag/users/proactivity), which has its own controls.
## The name on a reply
Claude doesn't post every reply under the same display name. The name shows which kind of work produced the reply, in two forms:
* **Claude**, the name alone: the reply comes from Claude's ambient presence in the channel, including unprompted replies
* **Claude** followed by a short description of the task in square brackets: the reply comes from a [working session](/docs/claude-tag/concepts/how-it-works) handling that task in its thread. The description changes with every task, so a channel might show something like `Claude [reviewing the launch checklist]`, `Claude [debugging a failing deploy]`, or `Claude [summarizing customer feedback]`.
## Make a channel quieter
If Claude is replying to messages that weren't meant for it, turn that down from inside the channel.
### Quiet one conversation
Tell Claude in the thread to respond only when mentioned.
```text wrap theme={null}
@Claude only respond when I @-mention you
```
Claude stops following that thread, and the rest of the channel is unaffected. This is the fix when one busy thread is the noise. The [`!mute` command](/docs/claude-tag/users/commands#mute-or-unmute-a-thread) goes further and silences the thread entirely; any direct `@Claude` mention turns it back on.
### Quiet the whole channel
Turn the channel's [**Respond automatically**](#turn-automatic-replies-on-or-off) setting off, so Claude replies there only when @-mentioned. From Slack, ask Claude directly.
```text wrap theme={null}
@Claude only respond in this channel when someone @-mentions you directly.
```
Claude confirms the change, which is channel-wide, not just for you. You can make the same change with the toggle on the channel's Configure page, and an admin can make it from the Claude Tag admin page.
Threads Claude already joined keep forwarding replies, so quiet those individually with the in-thread line above. The [`!mute` command](/docs/claude-tag/users/commands#mute-or-unmute-a-thread) quiets one thread at a time and does nothing at a channel's top level.
### Remove Claude Tag from the channel
When quieting isn't enough, end Claude's presence in the channel.
```text wrap theme={null}
/remove @Claude
```
Claude can no longer read or post in that channel. Any member can run this unless your Slack admin restricts the command. Admins have further options, through full removal from the workspace, on [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access).
## When Claude quiets itself
When a channel's messages stop giving Claude anything to respond to, with no questions it can answer and no tasks it can pick up, Claude turns unprompted replies off there on its own. Mentioning `@Claude` turns unprompted replies back on.
A channel whose [**Respond automatically**](#turn-automatic-replies-on-or-off) setting is off stays that way until someone changes the setting.
## Messages that never get a reply
A few cases produce silence even when the message includes a mention:
* **Editing a message to add the mention.** An edit doesn't trigger a response. Delete the message and send a new one with `@Claude` included.
* **Channels with guest accounts.** By default, Claude is off in channels that include guests; your admin can turn it on per scope. Ask whoever runs your Claude plan, or send them [the guest access setting](/docs/claude-tag/admins/restrict-access#restrict-guest-channels).
* **Channels shared across workspaces connected to different Claude organizations.** Every workspace where Claude runs is connected to a Claude organization, the account a company sets up for Claude. When a channel is shared across workspaces connected to different Claude organizations, Claude won't reply there and posts a refusal message instead. You can't tell from Slack how a workspace is connected; the refusal message itself is the signal. Use a channel that belongs to one workspace, or send Claude a DM.
* **Slack Connect channels.** Channels shared with another company are always off.
When the workspaces sharing a channel all belong to one Claude organization, Claude replies there, but with only your organization's default access and settings. The repositories, instructions, and memory set up for that channel or its workspaces don't apply, and Claude posts a notice in the thread explaining this from time to time. The guest check above still applies first where guest access is restricted.
To confirm a channel's setting, check the **Respond automatically** toggle on its [Configure page](/docs/claude-tag/users/good-habits#configure-claude-for-a-channel). To confirm an instruction Claude saved, ask `@Claude what do you remember about responding in this channel?`, and see [What Claude Tag remembers](/docs/claude-tag/users/memory) for where instructions are stored and how to change them.
## Related resources
* [Customize Claude Tag](/docs/claude-tag/admins/customize): the settings only an admin can change, if channel memory isn't enough
* [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access): the admin-side controls, from guest channels to full removal
connectors/building/after-publishing First recorded · 29 lines, first recorded
# Manage your listing after publishing ## Update your MCP server ## Update your plugin ## Update your listing ## Slugs are permanent ## Delist your connector
The first capture of this source. The page was already there, and this is what it said.
# Manage your listing after publishing
> Update your MCP server, plugin, and directory listing after publication
## Update your MCP server
An MCP server is a live API. To add, change, or remove tools, deploy the change to your server—no resubmission to Anthropic is required, and there is no scheduled re-review. Claude picks up the new tool surface on the next connection.
## Update your plugin
Plugin updates are pushed via your GitHub repo. CI mirrors changes to the public marketplace and runs automated screening on each update.
## Update your listing
Edit your description, categories, icon, and other listing metadata from the submissions dashboard at [Organization settings > Directory](https://claude.ai/admin-settings/directory/submissions) in Claude.ai. See [Managing your listing](/docs/connectors/building/managing-your-listing) for what you can edit directly and which changes require review.
## Slugs are permanent
Your directory slug is fixed after publication. It determines your connector's permanent listing URL:
```text theme={null}
https://claude.ai/directory/connectors/SLUG
```
Share this URL from your own documentation or a "Connect to Claude" button to send users directly to your listing. Display names can change via the dashboard; the URL slug cannot.
## Delist your connector
To voluntarily remove your connector from the directory, email `[email protected]`.
connectors/building/authentication First recorded · 137 lines, first recorded
# Authentication for connectors ## Supported authentication types ## Anthropic-held client credentials ## DCR and CIMD details ## Cross-host authorization servers ## Callback URLs ## Token refresh ## Enterprise authentication ## Custom connectors ## Endpoint latency ## Network reference
The first capture of this source. The page was already there, and this is what it said.
# Authentication for connectors
> OAuth and authentication options for MCP servers in Claude
Authentication is the most common source of partner questions. Claude's auth support differs in a few places from the generic MCP specification, so read this page even if you're already familiar with MCP auth.
## Supported authentication types
Claude supports the following authentication types for remote MCP servers. The same infrastructure backs Claude.ai, Claude Desktop, Claude mobile, Claude Code, and Cowork.
| Type | Description | Availability |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| `oauth_dcr` | OAuth 2.0 with Dynamic Client Registration ([RFC 7591](https://www.rfc-editor.org/rfc/rfc7591)) | Supported out of the box |
| `oauth_cimd` | OAuth 2.0 with [Client ID Metadata Document](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents) | Supported out of the box |
| `oauth_anthropic_creds` | OAuth 2.0 with Anthropic-held client credentials | Contact `[email protected]` |
| `custom_connection` | Custom URL or credentials supplied at connection time (for example, Snowflake-style) | Contact `[email protected]` |
| `static_headers` | Fixed credential (API key or bearer token) entered by an organization administrator as a request header when adding the connector | Beta |
| `none` | No authentication (authless server) | Supported. An optional partial-auth mode is experimental. |
Static bearer tokens and API keys are supported in beta through request headers (`static_headers`). An organization administrator enters the credential once when adding the connector, and Claude sends it on every request. The credential is shared by the organization rather than pasted per user. See [Authenticating with request headers](/docs/connectors/custom/remote-mcp#authenticating-with-request-headers) for what administrators see and how to document the expected header for them.
Tokens or API keys passed in the connector URL (for example, `?token=`, `?apiKey=`, or `?userToken=` query parameters) are **not recommended**. A credential in a URL is a security vulnerability: URLs are routinely recorded in server logs, proxies, and browsing history, so a query-string credential is easy to leak. The MCP authorization specification explicitly [prohibits access tokens in the URI query string](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-requirements). Use OAuth or [request headers](/docs/connectors/custom/remote-mcp#authenticating-with-request-headers) instead.
## Anthropic-held client credentials
A pure machine-to-machine `client_credentials` grant—where a server-to-server token is issued with no user in the loop—is **not supported**. Every connection requires user consent.
`oauth_anthropic_creds` is the consent-gated alternative. The flow works like this:
1. You create an OAuth `client_id` and `client_secret` in your own authorization server and send them to Anthropic.
2. Anthropic stores those credentials securely and associates them with your directory entry.
3. When a user connects your server, they go through a standard OAuth consent screen.
4. After consent, Anthropic uses the stored client credentials to complete the token exchange on the user's behalf.
This gives you a stable, registered OAuth client without requiring DCR or CIMD on your end, while keeping the user-consent step. Anthropic stores your credentials securely and uses them only for token exchange on behalf of consenting users; they are shared across the hosted Claude surfaces (Claude.ai web, Desktop, mobile, and Cowork). Claude Code runs its own OAuth flow on the user's machine and identifies itself with its own [Client ID Metadata Document](#callback-urls), so it does not use Anthropic-held credentials. Claude Managed Agents uses a separate credential set.
Anthropic-held credentials are bound to the authorization server that issued them. If you migrate to a new authorization server, email `[email protected]` with the new `client_id` and `client_secret` before cutting over. CIMD-based connectors don't have this constraint — a CIMD `client_id` is a self-hosted URL, so it works against any authorization server that fetches it.
To use this flow, email `[email protected]` with your `client_id` and secret.
## DCR and CIMD details
If your authorization server does **not** expose a `registration_endpoint` (i.e., does not support DCR), you have several options:
* Expose a `registration_endpoint`
* Support CIMD instead. Claude selects CIMD only when your authorization server metadata advertises **both** `"client_id_metadata_document_supported": true` **and** `"none"` in `token_endpoint_auth_methods_supported` — the second is required because Claude's CIMD client authenticates as a public client at your token endpoint. If either is missing, Claude falls back to DCR. See [lazy authentication](/docs/connectors/building/lazy-authentication#identify-the-client-with-cimd) for a worked CIMD example.
* Switch to `oauth_anthropic_creds`
For servers expecting high traffic from the directory, prefer **CIMD or `oauth_anthropic_creds` over DCR**. DCR causes Claude to register a new client on every fresh connection, which can result in very large numbers of registered clients on your authorization server. CIMD and Anthropic-held credentials avoid the registration call entirely.
Claude includes a [PKCE](https://datatracker.ietf.org/doc/html/rfc7636) `code_challenge` with `code_challenge_method=S256` on every authorization request, regardless of which registration mechanism it uses. Your authorization server must support S256 PKCE, and the [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-code-protection) requires it to advertise `"code_challenge_methods_supported": ["S256"]` in its metadata so spec-compliant clients can verify support before starting the flow.
To control which scopes Claude requests, include a `scope` parameter in the `WWW-Authenticate` header on your `401` response. If you don't, Claude requests the scopes your protected resource metadata advertises in `scopes_supported`. Claude also appends `offline_access` when your authorization server metadata lists it in `scopes_supported`, to obtain a refresh token. See [lazy authentication](/docs/connectors/building/lazy-authentication#return-401-not-a-tool-error) for the canonical `401` shape.
## Cross-host authorization servers
A cross-host authorization server doesn't need anything special on its own. The `authorization_servers` field in your [protected resource metadata](https://www.rfc-editor.org/rfc/rfc9728) tells Claude where the authorization server is, and Claude resolves it regardless of which host it points at. The thing to get right is making sure Claude can find the protected resource metadata in the first place.
**Always return a `401` with a `WWW-Authenticate` header** whose `resource_metadata` parameter points at your protected resource metadata document — the same handshake described in [Return 401, not a tool error](/docs/connectors/building/lazy-authentication#return-401-not-a-tool-error):
```http theme={null}
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"
```
The `401` status is required — Claude does not honor a `WWW-Authenticate` header on a `200` response — and the `resource_metadata` URL doesn't have to be on the MCP server's origin; it can be any HTTPS location that serves the JSON document. That's what makes this the most reliable path for hosting platforms that can't serve `/.well-known/*` at the root, such as Supabase Edge Functions, Cloudflare Workers without a `/.well-known/*` route, and Lambda function URLs that only route a path prefix.
If your `401` doesn't include a `resource_metadata` pointer, Claude can still infer the metadata location by probing your MCP server's origin: `/.well-known/oauth-protected-resource/<your-mcp-path>` first, then `/.well-known/oauth-protected-resource`. Treat this as a fallback — it only works when your platform serves `/.well-known/*` paths, and it adds round-trips to every connection.
Whichever way Claude finds the document:
* The protected resource metadata document's `resource` field must match your MCP server URL exactly as the user enters it in Claude, including any path component.
* The metadata's `authorization_servers` field must list your authorization server's issuer URL. If you list more than one, Claude uses the first entry and does not fall back to later entries — list your primary issuer first.
* Your authorization server must serve its own discovery metadata — [RFC 8414](https://www.rfc-editor.org/rfc/rfc8414) authorization server metadata or [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html) — at its `/.well-known/` paths, and that host must also be reachable from Anthropic's [published egress range](https://platform.claude.com/docs/en/api/ip-addresses). Discovery requests to the authorization server come from the same IP range as requests to your MCP server, so a WAF in front of your identity provider can break the flow even when your MCP server is reachable.
<Note>
If your authorization server is Microsoft Entra ID, you must also register the MCP server URL as an Application ID URI on your Entra app registration, or the token request fails with `AADSTS9010010`. See [the troubleshooting entry](/docs/connectors/building/troubleshooting#microsoft-entra-id-rejects-the-resource-value) for the fix.
</Note>
If you control both hosts, an alternative is to serve the MCP endpoint and the authorization server behind a single custom domain that can route both `/.well-known/*` and your MCP path.
<Tip>
A common symptom of a discovery failure is that your MCP server receives the initial request but your authorization server sees no traffic at all. That happens when neither path works: there's no `WWW-Authenticate: Bearer resource_metadata=…` header on your `401`, and the well-known paths on your MCP server's origin return `404`. With no metadata to read, Claude never learns where your authorization server is, and the connection fails with "Couldn't reach the MCP server." See [troubleshooting](/docs/connectors/building/troubleshooting) for the full diagnostic flow.
</Tip>
## Callback URLs
For the hosted Claude surfaces (Claude.ai web, Desktop, mobile, and Cowork), register the following redirect URI:
```
https://claude.ai/api/mcp/auth_callback
```
**Claude Code** is a native client and uses an RFC 8252 loopback redirect on an ephemeral port — for example:
```
http://localhost:3118/callback
```
The port varies per session. Claude Code declares `http://localhost/callback` and `http://127.0.0.1/callback` in its [Client ID Metadata Document](https://claude.ai/oauth/claude-code-client-metadata), so your authorization server must accept both with the port component ignored. [RFC 8252 section 7.3](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) requires this for the IP-literal form (`127.0.0.1`); apply the same port-agnostic match to `localhost` so Claude Code works, even though RFC 8252 section 8.3 discourages `localhost`. See [lazy authentication](/docs/connectors/building/lazy-authentication) for implementation details.
A Client ID Metadata Document can't prevent loopback impersonation on its own — any local process can bind a port and claim to be the legitimate client. The [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#localhost-redirect-uri-risks) requires authorization servers to display the redirect URI hostname clearly on the consent screen and recommends an extra warning when the only registered redirect URIs are loopback addresses.
## Token refresh
Claude refreshes tokens **reactively on a 401 response**, with a proactive refresh up to five minutes before the stored expiry. To avoid refresh failures:
* Return RFC 6749-compliant error codes (`invalid_grant`, not `invalid_request` or a custom code) when a refresh token is no longer valid
* Rotate refresh tokens for public-client connections. DCR and CIMD register Claude as a public client, and the [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-theft) adopts OAuth 2.1's requirement to rotate or sender-constrain refresh tokens for public clients. If you rotate, return the new refresh token in the same response that invalidates the old one.
Your `/token` endpoint must accept `Content-Type: application/x-www-form-urlencoded` per [RFC 6749 section 4.1.3](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3). Claude sends both the initial token exchange and refresh requests with this content type. Some web frameworks default to JSON-only body parsing—if your endpoint returns `415 Unsupported Media Type`, register a form-urlencoded body parser. Dynamic client registration (`/register`) uses `application/json` per [RFC 7591 section 3.1](https://www.rfc-editor.org/rfc/rfc7591#section-3.1), so don't assume the same parser works for both.
## Enterprise authentication
<Note>
Organizations using SSO can also connect their users to your server without an interactive OAuth consent step, using an identity assertion signed by their identity provider. See [Enterprise Managed Auth](./enterprise-managed-auth) for what your authorization server needs to support.
</Note>
Directory connectors use a **single shared OAuth application per connector**. There is no per-org OAuth client for directory connectors — enterprise customers connect to the same OAuth app as everyone else, and access is scoped by the user's own permissions on your service. Custom connectors are different: an admin can supply their own OAuth client credentials when adding the connector, which scopes the OAuth client to that organization. See [custom connectors](#custom-connectors).
## Custom connectors
When a user adds a custom connector by URL, the OAuth Client Secret field is **optional**. Supply it only if your authorization server requires confidential-client authentication.
Supplying your own pre-registered client ID (and secret, if your server requires one) as static client credentials is a good option when you want a stable OAuth client per organization: it avoids dynamic client registration entirely, and the credentials are scoped to the organization that entered them.
For servers that authenticate with a fixed API key or token rather than OAuth, request header authentication (`static_headers`) is available in beta. See [Supported authentication types](#supported-authentication-types) above and [Authenticating with request headers](/docs/connectors/custom/remote-mcp#authenticating-with-request-headers) for what administrators see.
## Endpoint latency
Claude waits up to **10 seconds** for a response from your OAuth discovery, registration, and token endpoints, and up to **30 seconds** for refresh token requests. If no response arrives within that window the flow is treated as a failure, even if your server eventually completes the request. Aim well under these limits; a token endpoint that takes several seconds to respond will produce intermittent connection failures for users.
If your token endpoint depends on slow downstream calls, return the HTTP response headers and body without buffering behind upstream work, and check that any reverse proxy, API gateway, or WAF in front of the endpoint isn't holding the response.
## Network reference
Anthropic's outbound traffic to your server originates from `160.79.104.0/21`. See the [IP address reference](https://platform.claude.com/docs/en/api/ip-addresses) if you need to allowlist Anthropic for conditional access or firewall rules.
connectors/building/directory-vs-custom First recorded · 79 lines, first recorded
# Directory connectors vs custom connectors ## Share an install link ### Directory connectors ### Custom connectors ## Suggested Connectors ## Use both: directory plus elevated custom ## Per-tenant URLs ## What the directory is not
The first capture of this source. The page was already there, and this is what it said.
# Directory connectors vs custom connectors
> Understand the difference between directory-listed and custom connectors
Directory connectors and custom connectors run on the **same MCP infrastructure**. The runtime, transport, authentication, and tool-calling code paths are identical. The difference is review, discoverability, and distribution.
| | Directory connector | Custom connector |
| ------------------------------------------------------------------------------ | -------------------------------------------- | ---------------------------------------------------------- |
| **Runtime** | Same | Same |
| **Anthropic review** | Yes | No |
| **In-product discovery** | Browse, search, Suggested Connectors | None |
| **Distribution** | [Directory link](#share-an-install-link) | [Install link](#share-an-install-link) or manual URL entry |
| **Anthropic-held client credentials** | Available | Not available |
| **[External link](/docs/connectors/building/mcp-apps/external-links) confirmation** | Can allowlist destinations to skip the modal | Always shows the modal |
| **Appears as** | Named card with logo | "Custom" |
For what directory and custom connectors look like to a Claude user, including the Verified and Community labels, see [connector verification](/docs/connectors/verification).
## Share an install link
Both directory and custom connectors have a URL you can share from your own documentation, a "Connect to Claude" button, or an onboarding email.
### Directory connectors
After publication, your connector has a permanent listing URL based on its slug:
```text theme={null}
https://claude.ai/directory/connectors/SLUG
```
For example, `https://claude.ai/directory/connectors/dovetail` opens the Dovetail listing with its description, screenshots, and a **Connect** button. You receive your slug when your submission is approved, and it [cannot change afterward](/docs/connectors/building/after-publishing#slugs-are-permanent).
### Custom connectors
For a connector that is not in the directory, link to the **Add custom connector** dialog with the name and URL prefilled:
```text theme={null}
https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=NAME&connectorUrl=ENCODED_URL
```
| Parameter | Description |
| --------------- | ----------------------------------------------------------------------------------------------------------- |
| `modal` | Must be `add-custom-connector`. |
| `connectorName` | Display name shown to the user. |
| `connectorUrl` | Your MCP server URL, [percent-encoded](https://developer.mozilla.org/en-US/docs/Glossary/Percent-encoding). |
For example, an install link for a server at `https://mcp.example.com/` looks like this:
```text theme={null}
https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=Example&connectorUrl=https%3A%2F%2Fmcp.example.com%2F
```
When a user follows the link, claude.ai opens the dialog with the name and URL prefilled and shows a notice that the values came from an external link. The user reviews the values and confirms before anything is added. If the user is signed out, they are prompted to sign in first and then land on the prefilled dialog.
<Note>
Install links only prefill the form. They do not bypass review by the user, and they do not grant your server any permissions the user has not confirmed.
</Note>
Organization administrators can use the same parameters on the admin path to prefill the org-wide connector dialog:
```text theme={null}
https://claude.ai/admin-settings/connectors?modal=add-custom-connector&connectorName=NAME&connectorUrl=ENCODED_URL
```
## Suggested Connectors
Directory connectors are eligible for **Suggested Connectors**—Claude can recommend your connector in-chat when it's relevant to the user's task. Custom connectors are never suggested. Every directory entry is automatically eligible; there is no separate opt-in.
## Use both: directory plus elevated custom
A supported pattern is to list a connector in the directory with safe, broadly-applicable defaults, **and** provide enterprise customers a separate URL to add as a custom connector with elevated permissions or tenant-specific configuration. Document both paths in your own product docs.
## Per-tenant URLs
If your server URL varies per tenant (for example, `{tenant}.mcp.example.com`), this is typically handled either as separate per-tenant directory entries or via the [`custom_connection`](/docs/connectors/building/authentication#supported-authentication-types) authentication type, where users supply their tenant-specific URL at connection time. `custom_connection` is enabled per partner—email `[email protected]` to request it. The directory does not currently template a single entry across tenant subdomains.
## What the directory is not
The Anthropic Directory is independent of the open [MCP Registry](https://registry.modelcontextprotocol.io) and the `modelcontextprotocol/servers` GitHub repository. Publishing to those does **not** surface your server in Claude. Submit through the [directory submission form](/docs/connectors/building/submission) to appear in Claude products.
connectors/building/enterprise-managed-auth First recorded · 168 lines, first recorded
# Enterprise Managed Auth for connectors ## How it works ## With lazy authentication ## Prerequisites ## Authorization server requirements ## Access token lifetime ## Testing your implementation ### Testing with the cross-app access playground ## Related resources
The first capture of this source. The page was already there, and this is what it said.
# Enterprise Managed Auth for connectors
> Accept identity assertions from enterprise SSO so users connect to your MCP server without a separate OAuth consent step.
<Note>
Enterprise Managed Auth is in beta and is available on Claude Team and Enterprise plans. Organizations can [join the waitlist](https://claude.com/form/ema-waitlist) to request access. MCP server developers and identity provider vendors can [register interest](https://docs.google.com/forms/d/e/1FAIpQLSf1goHGNDVFK7rncYuh6wnRpWSy7eGOcgL1i8uw3oyKFO9UUA/viewform) in supporting this flow.
</Note>
Enterprise Managed Auth (EMA) lets a user connect to your MCP server silently, using the single sign-on session they already have with their organization. Instead of showing each user an OAuth consent screen, Claude presents your authorization server with an **identity assertion**: a signed JSON Web Token (JWT), issued by the customer's identity provider, that vouches for the user's identity.
Your authorization server validates the assertion and returns an access token in a single back-channel request. There is no browser redirect and no per-connector consent page. From the user's point of view, the connector is simply available as soon as their administrator enables it.
This flow is defined by the [MCP enterprise managed authorization extension](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) and is built on the standard [JWT bearer authorization grant (RFC 7523)](https://datatracker.ietf.org/doc/html/rfc7523). The assertion profile follows the [Identity Assertion JWT Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/).
<Note>
This page is for connector developers who need their authorization server to accept Enterprise Managed Auth. Identity provider setup and Claude admin console configuration are handled by the customer's administrator.
</Note>
## How it works
When a user whose organization has Enterprise Managed Auth configured invokes your connector, Claude obtains a signed identity assertion for that user and exchanges it directly at your token endpoint for an access token. The user never sees a browser redirect or a consent screen, and your MCP server receives the same kind of bearer token it would after the interactive OAuth flow.
```mermaid theme={null}
sequenceDiagram
autonumber
participant Claude
participant AS as Your authorization server
participant MCP as Your MCP server
Note over Claude: User is signed in to Claude through their organization's SSO
Claude->>AS: POST /token (grant_type=jwt-bearer, assertion=signed JWT)
AS->>AS: Fetch issuer JWKS and verify signature
AS->>AS: Validate iss, aud, exp, sub, and client_id
AS-->>Claude: access_token
Claude->>MCP: Tool call with Bearer access_token
MCP-->>Claude: Tool result
```
Two parties are involved in this exchange: the customer's identity provider signs the assertion, and your authorization server verifies it and issues the access token. Both roles are often served by commercial identity platforms, so the distinction here is about which tenant plays which role rather than about product type. The identity provider publishes its signing keys as a JSON Web Key Set, and your authorization server fetches that key set to verify each assertion.
## With lazy authentication
Enterprise Managed Auth also works with [lazy authentication](./lazy-authentication). When your server returns `401 Unauthorized` for a protected tool call, Claude normally shows the inline **Connect** card and runs the interactive OAuth flow. If the user's organization has Enterprise Managed Auth configured for your connector, Claude runs the silent JWT bearer exchange instead and retries the tool call without showing a prompt.
Your MCP server returns the same `401` with a `WWW-Authenticate` header as described in the [lazy authentication guide](./lazy-authentication#return-401-not-a-tool-error). Your authorization server must still meet the [requirements below](#authorization-server-requirements).
A fully authless server never returns `401`, so there is no point at which Claude can exchange an assertion. Enterprise Managed Auth does not apply to authless servers.
## Prerequisites
Before adding Enterprise Managed Auth, make sure the following are already in place.
* Your MCP server implements [MCP authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization), including Protected Resource Metadata (PRM) discovery, and follows the [MCP security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices). See our [authentication guide](./authentication) for Claude-specific requirements.
* Your authorization server registers Claude using either [Anthropic-held client credentials](./authentication#anthropic-held-client-credentials) or a [Client ID Metadata Document](./authentication#dcr-and-cimd-details).
<Warning>
Dynamic Client Registration (DCR) is not supported with Enterprise Managed Auth. The identity provider stamps a fixed `client_id` into every assertion it issues, so your authorization server must already recognize that client before the first assertion arrives. A client created on the fly through DCR cannot satisfy this requirement because its identifier will never match the value in the assertion.
</Warning>
## Authorization server requirements
<Note>
This section is for the authorization server operator. If your MCP server relies on a hosted identity platform, there is typically no code to write. Confirm that the platform supports the JWT bearer authorization grant and enable it for your tenant. If you run your own authorization server, the steps below describe what it needs to support.
</Note>
Support for this flow varies by product. The underlying capability is the JWT bearer authorization grant ([RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523)), which lets an authorization server exchange a signed JWT for an access token. Some commercial authorization servers and identity platforms support it today and others do not yet, so the first step is to confirm that yours does and that the customer's identity provider can be registered as a trusted issuer.
<Steps>
<Step title="Ensure the JWT bearer grant is supported">
Your authorization server must accept `urn:ietf:params:oauth:grant-type:jwt-bearer` at its token endpoint and advertise it in the `grant_types_supported` array of its [authorization server metadata (RFC 8414)](https://datatracker.ietf.org/doc/html/rfc8414):
```json theme={null}
{
"issuer": "https://auth.example.com",
"token_endpoint": "https://auth.example.com/token",
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}
```
Claude reads this metadata to discover whether your server supports Enterprise Managed Auth. The grant type must be listed here for the feature to be offered to the customer, even if your token endpoint would already accept it silently.
</Step>
<Step title="Register the trusted issuer">
For each customer, your authorization server needs to trust that customer's identity provider as a JWT issuer. Your authorization server fetches the identity provider's JSON Web Key Set and uses it to verify the signature on every incoming assertion.
Your authorization server is responsible for maintaining an explicit allowlist of trusted issuer URLs per tenant rather than accepting any well-formed JWT. An assertion whose `iss` is not on the tenant's allowlist must be rejected with `invalid_grant`, even if the signature is valid.
<Warning>
Never accept an identity assertion without full validation. As with all OAuth token handling, your authorization server must verify the signature, issuer, audience, expiry, and subject on every request. Use the JWT validation built into your authorization server product. If you need to inspect assertions in your own code, use the validation library or token introspection endpoint provided by your authorization server vendor rather than writing custom verification logic.
</Warning>
</Step>
<Step title="Understand the token request">
Claude sends a form-encoded `POST` to your authorization server's token endpoint:
```http theme={null}
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOi...
&client_id=your-registered-client-id
&scope=openid profile
&resource=https://mcp.example.com
```
The `assertion` parameter carries the signed JWT. The `client_id` is the value Claude is registered under at your authorization server. Claude also includes the `resource` parameter ([Resource Indicators, RFC 8707](https://www.rfc-editor.org/rfc/rfc8707)) set to your MCP server URL whenever the customer's identity provider supports forwarding it. Some identity provider configurations cannot pass a resource indicator through, so your authorization server should accept the request whether or not `resource` is present and use it for audience binding when it is.
Your authorization server validates the assertion according to the [JWT bearer token processing rules (RFC 7523 section 3)](https://datatracker.ietf.org/doc/html/rfc7523#section-3) and returns a standard OAuth token response. Claude then presents the returned access token as a `Bearer` credential on calls to your MCP server, exactly as it does after the interactive flow.
<Note>
The access token lifetime is set by your authorization server, and the assertion lifetime is set by the customer's identity provider. Anthropic does not control either value.
</Note>
</Step>
</Steps>
## Access token lifetime
Issue access tokens with whatever lifetime your security policy calls for. A short lifetime, such as one hour, does not force users to repeat single sign-on each time a token expires.
When a user signs in to Claude through their organization's SSO, Claude obtains a long-lived refresh token from the identity provider. Claude uses that refresh token to request a fresh identity assertion from the identity provider whenever it needs one, without any user interaction. Claude then exchanges the new assertion at your token endpoint for a new access token. From the user's point of view, the connection stays active for as long as the identity provider's refresh token remains valid.
The refresh token is issued by the customer's identity provider. Treat it as long-lived today. Identity provider administrators will be able to apply their own lifetime policy in the future.
## Testing your implementation
End-to-end testing requires a Claude organization with Enterprise Managed Auth enabled and an identity provider tenant configured to issue assertions for your authorization server's audience.
If your identity provider is Okta, refer to Okta's [Cross App Access participation guide](https://support.okta.com/help/s/article/claude-enterprise-managed-auth-with-okta-cross-app-access-xaa-beta-participation-guide?language=en_US) and configure your organization to be able to test your MCP's XAA implementation.
### Testing with the cross-app access playground
[Okta's cross-app access playground](https://xaa.dev) lets you exercise the flow without a Claude organization. This is useful while you develop, and when your organization's single sign-on is not on a supported identity provider. On the playground you can:
* Walk the full four-step flow end to end against a sandbox IdP, with every token shown decoded
* Point it at your own MCP server or REST API to check resource metadata discovery, the `WWW-Authenticate` hint on `401` responses, and token validation
* Point it at your own authorization server to check that it accepts an identity assertion over the JWT bearer grant, mints a scoped access token, and serves its metadata for discovery
* Bring your own OIDC or SAML identity provider in place of the sandbox one
* Re-run a single failed step and inspect service configurations, discovery documents, and a live event log
<Note>
Enterprise Managed Auth is in beta. [Register interest](https://docs.google.com/forms/d/e/1FAIpQLSf1goHGNDVFK7rncYuh6wnRpWSy7eGOcgL1i8uw3oyKFO9UUA/viewform) to get onboarded for testing.
</Note>
## Related resources
<CardGroup cols={2}>
<Card title="Authentication for connectors" icon="key" href="./authentication">
Baseline OAuth requirements your server must already meet.
</Card>
<Card title="Lazy authentication" icon="lock-open" href="./lazy-authentication">
Defer OAuth until a protected tool is actually invoked.
</Card>
<Card title="Testing your connector" icon="flask" href="./testing">
Verify your connector works end to end in Claude.
</Card>
<Card title="Troubleshooting" icon="wrench" href="./troubleshooting">
Diagnose common authentication and connection issues.
</Card>
</CardGroup>
connectors/building/index First recorded · 82 lines, first recorded
# Building custom connectors ## Getting started ### Key resources ## Transport & authentication ### Supported transports ### Authentication features ## Protocol features ### Supported ### Not yet supported ## Technical specifications ## Testing your server ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Building custom connectors
> Build your own MCP servers to connect Claude to your tools and data
## Getting started
<Note>
**Authentication is the most common stumbling block.** Before you build, read the [authentication reference](/docs/connectors/building/authentication)—Claude's auth support differs from the generic MCP spec in a few important ways.
</Note>
Not sure whether to build an MCP server, a plugin, or both? See [what to build](/docs/connectors/building/what-to-build).
<Tip>
**Build with Claude.** Install the official [`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev) in Claude Code—it walks you through building, testing, and packaging an MCP server interactively, using these docs as its reference.
</Tip>
### Key resources
* **SDK Examples**: [TypeScript](https://github.com/modelcontextprotocol/typescript-sdk) and [Python](https://github.com/modelcontextprotocol/python-sdk) SDKs contain server implementation examples
* **Protocol Specification**: [modelcontextprotocol.io](https://modelcontextprotocol.io)
* **Hosting Solutions**: Platforms like Cloudflare offer remote MCP server hosting with autoscaling and OAuth management
* **Auth Specifications**: Review the [authorization spec](https://modelcontextprotocol.io/specification/latest/basic/authorization) with emphasis on third-party service flows
## Transport & authentication
### Supported transports
Claude supports both Streamable HTTP and the legacy HTTP+SSE transport. The legacy HTTP+SSE transport is being deprecated in favor of Streamable HTTP.
### Authentication features
* Supports the [2025-03-26](https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization), [2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization), and [2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) auth specifications
* Dynamic Client Registration (DCR) enabled
* OAuth callback: `https://claude.ai/api/mcp/auth_callback` (hosted surfaces); loopback redirect for Claude Code — see [callback URLs](/docs/connectors/building/authentication#callback-urls)
* Token refresh and expiry support
* Custom credentials for non-DCR servers
## Protocol features
### Supported
* [Tools](https://modelcontextprotocol.io/specification/latest/server/tools), [prompts](https://modelcontextprotocol.io/specification/latest/server/prompts), and [resources](https://modelcontextprotocol.io/specification/latest/server/resources)
* [Text](https://modelcontextprotocol.io/specification/latest/schema#textcontent) and [image-based](https://modelcontextprotocol.io/specification/latest/server/tools#image-content) tool results
* [Text](https://modelcontextprotocol.io/specification/latest/schema#textresourcecontents) and [binary](https://modelcontextprotocol.io/specification/latest/schema#blobresourcecontents) resources
### Not yet supported
* Resource subscriptions
* Sampling
* Advanced/draft capabilities
## Technical specifications
| Constraint | Limit |
| -------------------------------------- | -------------------------------------------------------- |
| Claude.ai/Desktop max tool result size | \~150,000 characters |
| Claude Code max tool result size | 25,000 tokens (configurable via `MAX_MCP_OUTPUT_TOKENS`) |
| Claude Code timeout | Configurable via `MCP_TOOL_TIMEOUT` |
| Claude.ai/Desktop timeout | 300 seconds (5 minutes) |
| Transport protocol | Streamable HTTP (legacy HTTP+SSE being deprecated) |
## Testing your server
1. Add directly to Claude via **Customize > Connectors**
2. Use the [MCP inspector](https://modelcontextprotocol.io/docs/tools/inspector) to validate auth flows
3. Add to Claude Code with `claude mcp add` and check `/mcp` for status. See the [Claude Code MCP quickstart](https://code.claude.com/docs/en/mcp-quickstart).
## Related topics
<Columns cols={2}>
<Card title="MCP Overview" icon="plug" href="/docs/connectors/building/mcp">
Understanding the Model Context Protocol.
</Card>
<Card title="Submit to Directory" icon="paper-plane" href="/docs/connectors/building/submission">
Review requirements and submit your connector.
</Card>
<Card title="Test in Claude Code" icon="terminal" href="https://code.claude.com/docs/en/mcp">
Connect and debug your server with the Claude Code CLI.
</Card>
</Columns>
connectors/building/lazy-authentication First recorded · 247 lines, first recorded
# Lazy authentication for MCP servers ## Return 401, not a tool error ## Gate at the HTTP layer ## Serve the discovery documents ## OAuth discovery caching ## Step-up authorization ## Identify the client with CIMD ## Try it ## Adapting to your server
The first capture of this source. The page was already there, and this is what it said.
# Lazy authentication for MCP servers
> Let users call public tools immediately and defer OAuth until a protected tool is actually invoked.
Not every tool on an MCP server needs the user's identity. A product catalog can be browsed anonymously; an order history cannot. **Lazy authentication** (sometimes called *mixed auth*) lets a single server expose both: unauthenticated clients can connect, list tools, and call public ones, and the server only challenges for credentials when a protected tool is invoked. The challenge follows the [MCP authorization specification](https://modelcontextprotocol.io/specification/latest/basic/authorization).
In Claude, the challenge surfaces as an inline **Connect** card in the conversation. The user authenticates in a popup, Claude retries the same tool call automatically with the new token, and the turn continues — no context is lost.
<Note>
If the user's organization has [Enterprise Managed Auth](/docs/connectors/building/enterprise-managed-auth) configured for your connector, the `401` triggers a silent token exchange instead of the **Connect** card. The tool call is retried automatically and the user sees no prompt.
</Note>
The examples below are drawn from a single-file Express app using `@modelcontextprotocol/sdk` over Streamable HTTP.
## Return 401, not a tool error
The only detail that matters is **how** the server refuses an unauthenticated call to a protected tool.
It must fail the **HTTP request** with `401 Unauthorized` and a [`WWW-Authenticate`](https://datatracker.ietf.org/doc/html/rfc6750#section-3) header:
```http theme={null}
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token", resource_metadata="https://example.com/.well-known/oauth-protected-resource/mcp", scope="orders:read"
{"error":"invalid_token","error_description":"Authentication required for this tool"}
```
The body is advisory; the `401` status and `WWW-Authenticate` header carry the protocol signal. The optional `scope` parameter tells Claude which scopes to request during authorization — include the minimum your protected tools need. If you omit it, Claude requests the scopes your protected resource metadata advertises in `scopes_supported` (plus `offline_access` if your authorization server metadata lists it), which can produce an over-broad consent prompt.
It must **not** return a successful HTTP response wrapping a tool error:
```http theme={null}
HTTP/1.1 200 OK
{"jsonrpc":"2.0","result":{"isError":true,"content":[{"type":"text","text":"Please sign in"}]},"id":1}
```
<Warning>
A `200` with `isError: true` is an application-level tool failure. Claude passes the error text to the model as the tool result and moves on — there is no auth prompt. Only a transport-level `401` causes Claude to pause the call, run the OAuth flow, and retry. A `403` triggers re-authentication only when accompanied by `WWW-Authenticate: Bearer error="insufficient_scope"` for scope step-up; any other `403` is surfaced as a terminal error. If users are seeing "please sign in" text in the chat instead of a **Connect** button, the server is returning the wrong one.
</Warning>
The `resource_metadata` parameter in the `WWW-Authenticate` header points at the server's [RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728) Protected Resource Metadata (PRM), which in turn names the authorization server. That chain is how Claude discovers where to send the user without any of it being hard-coded in the client.
## Gate at the HTTP layer
Because the refusal must be an HTTP status, the check has to happen **before** the JSON-RPC message reaches the MCP SDK. Once a tool handler is running, its return value is already destined to be wrapped in a `200` response.
The sample inspects the parsed JSON-RPC body in the Express handler and short-circuits if the request is a `tools/call` for a protected tool and no valid bearer is present:
```ts src/index.ts theme={null}
const PROTECTED_TOOLS = new Set(["get_my_orders"]);
function callsProtectedTool(body: unknown): boolean {
const messages = Array.isArray(body) ? body : [body];
for (const msg of messages) {
if (
msg &&
typeof msg === "object" &&
(msg as { method?: unknown }).method === "tools/call"
) {
const name = (msg as { params?: { name?: unknown } }).params?.name;
if (typeof name === "string" && PROTECTED_TOOLS.has(name)) {
return true;
}
}
}
return false;
}
const WWW_AUTHENTICATE =
`Bearer error="invalid_token", ` +
`error_description="Authentication required for this tool", ` +
`resource_metadata="${BASE_URL}/.well-known/oauth-protected-resource/mcp", ` +
`scope="orders:read"`;
async function handleMcpPost(req: Request, res: Response): Promise<void> {
const token = extractBearer(req);
const authed = isTokenValid(token);
// Lazy-auth gate: fail with 401 BEFORE the MCP layer sees the request.
// initialize, tools/list, and public tool calls fall through.
if (!authed && callsProtectedTool(req.body)) {
res
.status(401)
.set("WWW-Authenticate", WWW_AUTHENTICATE)
.json({
error: "invalid_token",
error_description: "Authentication required for this tool",
});
return;
}
// Otherwise: stateless Streamable HTTP handling.
const transport = new StreamableHTTPServerTransport({
sessionIdGenerator: undefined,
enableJsonResponse: true,
});
const mcp = buildMcpServer(authed ? "demo-user" : null);
await mcp.connect(transport);
await transport.handleRequest(req, res, req.body);
}
app.post("/mcp", (req, res) => {
handleMcpPost(req, res).catch((err) => {
console.error("mcp request error", err);
if (!res.headersSent) {
res.status(500).json({
jsonrpc: "2.0",
error: { code: -32603, message: "Internal error" },
id: null,
});
}
});
});
```
`initialize`, `tools/list`, and calls to `list_products` never hit the gate, so the connector is fully usable before sign-in. When the user already has a valid token, every request — public or protected — carries it and the gate is a no-op.
The same pattern covers **scope upgrades**: if the bearer is valid but lacks a required scope, return `403 Forbidden` with `WWW-Authenticate: Bearer error="insufficient_scope", scope="…"` and Claude prompts the user to re-consent. See [Step-up authorization](#step-up-authorization) below for what scopes Claude requests on re-consent and how the challenge is cached.
## Serve the discovery documents
After a 401, Claude fetches the URL from `resource_metadata` to learn which authorization server to use:
```ts src/index.ts theme={null}
function protectedResourceMetadata() {
return {
resource: `${BASE_URL}/mcp`,
authorization_servers: [BASE_URL],
bearer_methods_supported: ["header"],
};
}
app.get("/.well-known/oauth-protected-resource", (_req, res) => {
res.json(protectedResourceMetadata());
});
// Path-suffixed variant per RFC 9728 section 3.1 — clients try this first when
// the resource URL has a path component (/mcp).
app.get("/.well-known/oauth-protected-resource/mcp", (_req, res) => {
res.json(protectedResourceMetadata());
});
```
Claude then fetches the authorization server's [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) metadata to find the `/authorize` and `/token` endpoints.
## OAuth discovery caching
Claude caches the discovery documents — your protected resource metadata and the authorization-server metadata it points to — **globally, keyed by URL**, with a staleness window of about five minutes by default. All Claude users connecting to the same server URL share a single cache entry, and distinct server URLs (for example, staging versus production) cache independently.
The refresh is lazy and best-effort: after you change `scopes_supported` (or any other discovery field), the new value is picked up by the first authorization that successfully re-runs discovery once the staleness window has elapsed, then propagates to everyone. There is no per-user expiry to wait for. If a refresh fails, Claude serves the stale entry and tries again on a later request, so an unreachable discovery endpoint doesn't immediately break existing connections — it just delays the change.
## Step-up authorization
The scope-upgrade case at the end of [Gate at the HTTP layer](#gate-at-the-http-layer) is the MCP specification's [Step-Up Authorization Flow](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#step-up-authorization-flow). When the bearer token is valid but missing a scope the requested tool needs, return `403 Forbidden` with a [`WWW-Authenticate`](https://datatracker.ietf.org/doc/html/rfc6750#section-3.1) challenge:
```http theme={null}
HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope", scope="orders:write"
```
Claude prompts the user to re-authorize and, on consent, retries the same tool call with the new token.
**Which scopes Claude requests on re-authorization.** Claude unions the scopes named in your `403` challenge with the scope your server advertises during discovery (the `scope` parameter on your initial `401` `WWW-Authenticate` response, or your protected resource metadata's `scopes_supported` if you don't send one). Scopes the user picked up in an earlier step-up aren't reliably carried forward into the next one. To make sure the user keeps a permission they still need, follow the [MCP spec's recommended approach](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#runtime-insufficient-scope-errors) and include it in the `403` `scope` value alongside the newly required scopes — don't return only the single missing scope and depend on the client to remember the rest.
If your `403` carries `error="insufficient_scope"` but **omits the `scope` parameter**, Claude still recognizes step-up and runs its normal scope selection: the discovery-time `WWW-Authenticate` scope first, then your protected resource metadata's `scopes_supported`, then the authorization server metadata's `scopes_supported`.
<Note>
The `scope` value from your `403` is cached **per user, per server** for up to fifteen minutes and consumed by the next re-authorization that user starts against your server. The cache holds the most recent challenge — a new `403` overwrites the previous one — and is cleared once it's used. Combined with the [global discovery cache](#oauth-discovery-caching) above, a newly-added scope is available to step-up shortly after the discovery cache refreshes, typically within about five minutes of deploying the updated metadata.
</Note>
## Identify the client with CIMD
The sample does **not** implement Dynamic Client Registration. Instead it advertises support for **Client ID Metadata Documents** ([draft-ietf-oauth-client-id-metadata-document](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/)) in its authorization-server metadata:
```ts src/index.ts theme={null}
function authorizationServerMetadata() {
return {
issuer: BASE_URL,
authorization_endpoint: `${BASE_URL}/authorize`,
token_endpoint: `${BASE_URL}/token`,
scopes_supported: ["profile", "orders:read"],
response_types_supported: ["code"],
grant_types_supported: ["authorization_code", "refresh_token"],
token_endpoint_auth_methods_supported: ["none"],
code_challenge_methods_supported: ["S256"],
client_id_metadata_document_supported: true,
};
}
```
With CIMD the `client_id` is itself an HTTPS URL that dereferences to the client's OAuth registration metadata. There is no per-client database and no `POST /register` round-trip: at `/authorize`, the server fetches the `client_id` URL, verifies the document is self-referential (its `client_id` field equals the URL it was served from), and checks the requested `redirect_uri` against the document's `redirect_uris`. Because the document is self-asserted, the consent screen must display the **host of the `client_id` URL** (not the `client_name` field) as the relying party, and the listed `redirect_uris` should be required to be same-origin with the `client_id` URL.
<Note>
Claude selects CIMD only when the authorization-server metadata advertises **both** `client_id_metadata_document_supported: true` **and** `"none"` in `token_endpoint_auth_methods_supported`. The second is required because Claude's CIMD client authenticates as a public client (`token_endpoint_auth_method: "none"`), so the token endpoint must accept [PKCE](https://datatracker.ietf.org/doc/html/rfc7636)-only requests without a client secret. If either property is missing, Claude falls back to looking for a `registration_endpoint`.
</Note>
For native clients, compare loopback IP `redirect_uri` values (`http://127.0.0.1/…`, `http://[::1]/…`) with the **port ignored**, per [RFC 8252 section 7.3](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) — native apps bind an ephemeral port at runtime. RFC 8252 section 8.3 discourages `http://localhost/…`, but Claude Code declares it in its CIMD and binds an ephemeral port at runtime, so apply the same port-agnostic match to `localhost` for compatibility. The sample's `redirectUriAllowed()` helper shows the comparison.
## Try it
<Steps>
<Step title="Run the server">
```bash theme={null}
npm install
npm run build
npm start
```
The server listens on `http://localhost:3000/mcp`.
</Step>
<Step title="Call a public tool without auth: 200">
```bash theme={null}
curl -s http://localhost:3000/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_products","arguments":{}}}'
```
</Step>
<Step title="Call a protected tool without auth: 401">
```bash theme={null}
curl -si http://localhost:3000/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_my_orders","arguments":{}}}'
```
Note the `WWW-Authenticate` header in the response.
</Step>
<Step title="Add it as a custom connector in Claude">
Claude reaches custom connectors from Anthropic's infrastructure, so `localhost` is not reachable directly. Expose the server over a public HTTPS tunnel (for example, `cloudflared tunnel --url http://localhost:3000` or `ngrok http 3000`), then in **Customize > Connectors**, select **Add custom connector** and enter the tunnel's `/mcp` URL. See [Testing your connector](/docs/connectors/building/testing) for details.
Ask Claude to list products (no prompt), then ask for your orders — the inline **Connect** card appears, and after authenticating the same call completes.
</Step>
</Steps>
The sample's README includes a longer `curl` walkthrough that drives the stub `/authorize` and `/token` endpoints directly.
## Adapting to your server
* List your protected tools in `PROTECTED_TOOLS`.
* Replace `isTokenValid()` with real verification: JWT signature, `iss` matches your authorization server, `aud` equals the `resource` value you advertise in the PRM, and `exp`; or [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) token introspection against your IdP.
* Point `authorization_servers` in the PRM at your real issuer and delete the stub `/authorize` and `/token` handlers. Keep `client_id_metadata_document_supported: true` in your issuer's metadata if you want registration-free onboarding for Claude clients.
* If your server uses stateful Streamable HTTP sessions, the gate still belongs in the `POST /mcp` handler, before `transport.handleRequest`.
connectors/building/managing-your-listing First recorded · 86 lines, first recorded
# Managing your directory listing ## Access the dashboard ## Track submission status ## Server health and usage metrics ### What the metrics cover ### Health ### Topline metrics ### Error breakdown ### Usage by product ### Usage by tool ## Edit your listing
The first capture of this source. The page was already there, and this is what it said.
# Managing your directory listing > Track submissions, monitor server health and usage metrics, and edit your Connectors Directory listing Organizations that submit to the [Connectors Directory](/docs/connectors/directory) get a submissions dashboard in Claude.ai at [Organization settings > Directory](https://claude.ai/admin-settings/directory/submissions). Use it to track submissions through review, monitor your published server's health and usage, and edit your listing. <Note> The dashboard covers directory-listed remote MCP servers only. Custom connectors and local servers (desktop extensions) don't appear here, and the dashboard shows only your own organization's submissions. </Note> ## Access the dashboard The dashboard is part of your organization's admin settings, so you need: * **A Team or Enterprise organization** * **Directory management access.** By default, only organization Owners and Primary owners have it. On Enterprise, an Owner can delegate access through a custom role with the **Directory** or **Libraries** permission; see [Before you start](/docs/connectors/building/submission#before-you-start) for the steps. Team plans don't have custom roles, so on Team this stays with Owners. The same access covers everything on this page: viewing submissions, metrics, and reviewer feedback, and editing and submitting listings. ## Track submission status The dashboard lists each of your organization's submissions with its current status. Open a submission to see its full details and any reviewer feedback. When reviewers request changes, their feedback appears on the submission's detail page; address it and resubmit from the same page. ## Server health and usage metrics <Note> Metrics are in beta. They're computed daily from directory usage and can lag by up to 24 hours. Time windows with fewer than 5 calls, per-tool rows with fewer than 5 calls, and per-product rows with fewer than 50 calls are omitted. </Note> Once your server is published, its detail page shows health and usage data. ### What the metrics cover All of the metrics on this page measure traffic from Claude: Claude.ai, Claude Desktop, Claude Code, and other Claude surfaces. Connections that people make to your server from other MCP clients, and local servers that run on a user's own machine, aren't visible to Anthropic and aren't counted. Your own server logs can therefore show activity that this page doesn't. Tool call totals, error rates, and latency are measured at Anthropic's HTTP connector proxy. Tool call users and directory rank are measured from the MCP message stream, which covers both the HTTP and legacy WebSocket transports. If users reach your server only over the legacy WebSocket transport, you'll still see tool call users and a directory rank, but no tool call totals, error rates, or latency data. ### Health The health badge summarizes your server's recent reliability: | Status | Meaning | | --------------- | ------------------------------------------------------------------------------------------------------------ | | **Healthy** | The 30-day disconnect rate is at or below 5% | | **Degraded** | The 30-day disconnect rate is above 5% | | **Collecting…** | The server is published, but there isn't enough data yet to compute a disconnect rate (metrics update daily) | | **Not live** | The server isn't published yet; health appears after publication | The disconnect rate is measured against every distinct Claude account that sent your server any MCP message in the last 30 days, including connection attempts that never completed: it is the share of those accounts that chose to disconnect your connector during those 30 days. ### Topline metrics * **Directory rank**: your position among published directory servers, highest first, ranked by the number of distinct Claude accounts that sent your server any MCP message in the last 30 days. Every MCP message counts toward the ranking, including `initialize` and `tools/list`, and it includes accounts whose connection attempt never finished authenticating — a broader population than the Tool call users card below. A "Trending" tag marks servers in the top 10 by recent growth in that same message-based count. * **Tool call users (30d)**: the number of distinct Claude accounts that made at least one tool call (`tools/call`) to your server in the last 30 days. Accounts that only attempted to connect, or connected and browsed your tools without calling one, aren't counted. This card was previously labeled "Active users (30d)" and counted every MCP message, including handshakes from connection attempts that never completed; the renamed metric counts only accounts that actually used your tools, so it is usually much smaller than the number the old card showed. * **Tool calls (30d)**: the number of `tools/call` requests Anthropic received for your server in the last 30 days. Protocol messages such as `initialize` and `tools/list` aren't counted here. This is a count of requests, not of users, so retries are included, as are requests that were turned away for authentication problems. * **Error rate (30d)**: of the tool calls above, the fraction that either failed at the request level (for example, with a 5xx response or a timeout) or returned an MCP tool result with `isError: true`. Tool-call requests that were turned away for authentication problems aren't counted as errors, but they are included in the total number of tool calls that the rate is measured against. Shown with the most common error types. ### Error breakdown A table breaks errors out over 1-day, 7-day, and 30-day windows: total calls, overall error rate, tool versus request error rates, HTTP 4xx and 5xx rates, and the top error types in each window. ### Usage by product A per-product table shows 7-day calls, error rate, and p50/p95/p99 latency, broken down by the Claude product the calls came from, such as Claude.ai, Claude Desktop, Claude Code, and Cowork. Only a fixed set of Claude surfaces is shown, and Anthropic's own internal monitoring traffic is excluded. Because this table covers a shorter window, drops low-volume rows, shows only a fixed set of Claude surfaces, and excludes internal monitoring traffic, its call counts won't add up to the 30-day tool call total above. That's expected. A high error rate on a single product may reflect a client-side issue on Anthropic's end rather than a problem with your server. ### Usage by tool A per-tool table shows 7-day calls, the overall error rate, and the tool-result error rate for your top 15 tools by call volume. ## Edit your listing Open your submission's detail page to edit the listing. You can change directly: * **Listing metadata**: tagline, description, categories, documentation and privacy policy links, support contact, and icon * **Company details**: company name and website * **Display name**: editable, but changing the name of a published server affects existing users and requires re-review Save your edits as you go, then submit them for review. Submitted changes show as pending until a reviewer approves them, and you can discard pending changes before they're approved. The URL slug is locked: it's permanent after publication, since it determines your listing URL. For other edits or escalations, email `[email protected]`.
connectors/building/mcp First recorded · 72 lines, first recorded
# Model Context Protocol (MCP) ## What is MCP? ## How MCP works ### Local vs remote servers ### Key components ## Security model ### User control ### Tool hints ## Building with MCP ### For developers ### Submitting to directory ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Model Context Protocol (MCP)
> Understanding the open standard powering Claude's connectors
The Model Context Protocol (MCP) is an open standard created by Anthropic for AI applications to connect with tools and data sources.
## What is MCP?
MCP provides a standardized way for AI assistants like Claude to:
* Connect to external tools and services
* Access data from various sources
* Perform actions on behalf of users
* Maintain security and user control
## How MCP works
### Local vs remote servers
| Type | Description | Use Case |
| -------------- | ---------------------- | --------------------------------- |
| **Local MCP** | Runs on your device | Desktop integrations, local tools |
| **Remote MCP** | Hosted on the internet | Web services, cloud applications |
### Key components
* **Tools**: Actions Claude can perform (search, create, modify)
* **Resources**: Data Claude can access (files, documents, records)
* **Prompts**: Predefined interactions for specific tasks
## Security model
### User control
* You authenticate each connector individually
* Permissions mirror your access on the external service
* You can disconnect at any time
### Tool hints
All MCP tools must declare:
* [`readOnlyHint`](https://modelcontextprotocol.io/specification/latest/schema#toolannotations-readonlyhint): Tool only reads data
* [`destructiveHint`](https://modelcontextprotocol.io/specification/latest/schema#toolannotations-destructivehint): Tool can modify or delete data
This helps Claude and users understand what actions are possible.
## Building with MCP
The [MCP documentation](https://modelcontextprotocol.io/docs) is the source of truth for building MCP servers.
### For developers
* Open specification at [modelcontextprotocol.io](https://modelcontextprotocol.io)
* [TypeScript SDK](https://github.com/modelcontextprotocol/typescript-sdk) and [Python SDK](https://github.com/modelcontextprotocol/python-sdk) available
* Cloudflare hosting support with OAuth
### Submitting to directory
Organizations can [submit MCP servers](/docs/connectors/building/submission) to the Connectors Directory for broader availability.
## Related topics
<Columns cols={2}>
<Card title="MCP in Claude Code" icon="terminal" href="https://code.claude.com/docs/en/mcp">
Connect MCP servers to Claude Code from the command line.
</Card>
<Card title="Submit to Directory" icon="paper-plane" href="/docs/connectors/building/submission">
Review requirements and submit your connector.
</Card>
</Columns>
connectors/building/mcp-apps/cross-compatibility First recorded · 35 lines, first recorded
# Building cross-platform MCP Apps ## How it works ### Server side ### Client side ## Platform differences ### Domain handling
The first capture of this source. The page was already there, and this is what it said.
# Building cross-platform MCP Apps
> Build MCP Apps that work with both Claude and ChatGPT using a single codebase
MCP Apps can run in both Claude and ChatGPT from a single codebase. The SDK auto-detects the host environment and uses the appropriate transport, though some platform-specific behaviors require attention.
## How it works
### Server side
Use [`registerAppTool()`](https://modelcontextprotocol.github.io/ext-apps/api/functions/server-helpers.registerAppTool.html) and [`registerAppResource()`](https://modelcontextprotocol.github.io/ext-apps/api/functions/server-helpers.registerAppResource.html) to register your tools and resources. These helper functions automatically generate platform-specific metadata, so you write the registration once and it works on both platforms.
### Client side
Call [`App.connect()`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#connect) without an explicit transport parameter. The SDK detects whether it's running in Claude or ChatGPT and uses the appropriate transport automatically.
## Platform differences
While the SDK handles most cross-platform concerns automatically, some behaviors vary between hosts.
### Domain handling
The [`Resource._meta.ui.domain`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html#domain) field format and validation rules are determined by each host platform. For example, hosts may use hash-based subdomains, URL-derived patterns, or other formats.
For Claude, compute the `Resource._meta.ui.domain` value by running this command, replacing `https://example.com/mcp` with your server URL:
```shell theme={null}
node -e 'const yourServerUrl = "https://example.com/mcp"; console.log(require("crypto").createHash("sha256").update(yourServerUrl).digest("hex").slice(0,32) + ".claudemcpcontent.com")'
```
Example output for `https://example.com/mcp`:
```
c3d80a4ed901ee05b21755a88273b4a4.claudemcpcontent.com
```
connectors/building/mcp-apps/design-guidelines First recorded · 411 lines, first recorded
# Design guidelines ## Overview ## What makes a good MCP App ## Display modes ### Inline card ### Inline carousel ### Full screen ## Mobile guidelines ### Host context for layout ### Display modes ### Content security policy ### Viewport and layout ### Touch targets ### Scrolling and gestures ### Transitions ### Dark mode ### Loading states ## Visual design ## Interaction patterns ### App vs. chat interactions ### Start simple ### Visible controls over hidden menus ## Accessibility ## Style variables ### Example usage
The first capture of this source. The page was already there, and this is what it said.
# Design guidelines
> Visual and interaction design guidelines for MCP Apps in Claude
## Overview
MCP Apps are interactive interfaces that appear within Claude's conversational flow. Think of them as natural extensions of the conversation, not separate apps that happen to appear alongside it. Your app inherits conversational context and helps users accomplish meaningful tasks without breaking flow.
**Core principles:**
* **Conversational.** Fit naturally into dialogue. Don't force users to learn new interaction patterns.
* **Contextual.** Use conversation history to inform what you display and when.
* **Integrated.** Inherit styling and conventions from the containing environment.
* **Adaptive.** Handle variable sizing, mobile viewports, and diverse accessibility needs gracefully.
<Tip>
See our [Figma UI kit](https://www.figma.com/community/file/1597641111449594397/mcp-apps-for-claude) for components and patterns to help you get started.
</Tip>
## What makes a good MCP App
**Good candidates:**
* Tasks that fit naturally into conversation like data analysis, document review, or project coordination
* Communication and collaboration context like message search results, conversation threads, or team member profiles
* Tasks with a clear start and end like booking, ordering or scheduling
* Information users can act on immediately
* Functionality that extends Claude's capabilities meaningfully
**Patterns to avoid:**
* Long-form or static content better suited for external viewing
* Complex multi-step workflows that exceed the display mode's scope
* Deep navigation (no drill-ins, breadcrumbs, or multiple views)
* Nested scrolling (inline cards should auto-fit content height)
* Menus and popovers (dropdowns, context menus, and popover panels can get clipped by container boundaries or create z-index conflicts with the host UI — prefer visible controls like segmented buttons, toggles, or inline options)
* Chat inputs or conversational UI (don't replicate Claude's features)
## Display modes
### Inline card
Compact components embedded directly in conversation. Good for summaries, confirmations, and quick actions. Keep them focused.
**When to use:**
* Status updates and confirmations
* Simple data displays or selections
* Brief summaries with optional expansion
* Quick actions that continue the conversation
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/inline-card-1.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=0c7825c89be73ad56d0a90e4c979401d" alt="Inline card example showing a compact component" width="1999" height="1423" data-path="images/mcp-apps/inline-card-1.png" />
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/inline-card-2.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=344f114b1012838b4805b48d496201c0" alt="Inline card example showing a data display" width="1999" height="1423" data-path="images/mcp-apps/inline-card-2.png" />
**Constraints:**
* Height: auto-fits to content (no nested scrolling)
* Max actions: 2, placed at the bottom of the card
* Max data points: 4-5
* No drill-ins, breadcrumbs, or multiple views
* No menus or popovers — use visible controls instead
**On mobile:** Inline cards render full-width within the conversation. Ensure all tap targets are at least 44pt. Content should adapt to narrower viewports without horizontal scrolling.
<img src="https://mintcdn.com/claude-ai/sLZLADaApRAVEV6C/images/mcp-apps/inline-card-mobile.png?fit=max&auto=format&n=sLZLADaApRAVEV6C&q=85&s=3d2afa48da4f1d31cce9c0bb91a18807" alt="Inline card mobile examples" width="1999" height="838" data-path="images/mcp-apps/inline-card-mobile.png" />
### Inline carousel
Side-by-side items for browsing options. Users swipe or scroll horizontally to explore.
**When to use:**
* Product listings or search results
* Location or venue options
* Media galleries
* Any set of comparable items
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/inline-carousel-1.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=ef6b5615726ad25708ebdedf586226ae" alt="Inline carousel example showing browsable items" width="1999" height="1423" data-path="images/mcp-apps/inline-carousel-1.png" />
**Constraints:**
* 3-8 items for scannability
* Each card: image + title + metadata (max 3 lines) + optional CTA
* 1 optional CTA per card
* Maintain consistent card dimensions within a carousel
* Cards should have consistent visual hierarchy
**On mobile:** Carousel cards are optimized for horizontal swipe. Design for thumb reach — keep primary actions in the lower portion of cards. Peek the next card to signal scrollability.
<img src="https://mintcdn.com/claude-ai/sLZLADaApRAVEV6C/images/mcp-apps/inline-carousel-mobile.png?fit=max&auto=format&n=sLZLADaApRAVEV6C&q=85&s=2bf64edd4fdefe8a37188ca4f2f32f4e" alt="Inline carousel mobile examples" width="1999" height="1022" data-path="images/mcp-apps/inline-carousel-mobile.png" />
### Full screen
Immersive interfaces for complex interactions. The conversation composer remains available so users can continue talking to your app through Claude. Apps provide their own fullscreen button. A close button appears in the native header bar when in fullscreen mode. In fullscreen mode, avoid the use of floating panels. Use collapsible sidebars, tabs or pagination to disclose details.
**When to use:**
* Data visualizations and dashboards
* Detailed analysis tools
* Document editing
* Content that benefits from focused attention
* Rich tasks requiring more space than inline allows
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/fullscreen-1.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=a4b491bb475bab8ed146c1bc953516ec" alt="Full screen mode example" width="1999" height="1423" data-path="images/mcp-apps/fullscreen-1.png" />
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/fullscreen-2.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=8523c5ae46ab7492586044ff5fabea32" alt="Full screen mode with data visualization" width="1999" height="1423" data-path="images/mcp-apps/fullscreen-2.png" />
**Constraints:**
* Your app provides its own fullscreen button; a close button appears in the native header bar
* The composer is always visible — design your UX to work with it
* No floating panels — use collapsible sidebars, tabs, or pagination to disclose details
* Chat sheet maintains conversational context
**On mobile:** Your app fills the entire screen with the chat input and navigation bar overlaid on top, so keep critical UI within the safe area. Use the full viewport width and support both portrait and landscape where it makes sense.
<img src="https://mintcdn.com/claude-ai/sLZLADaApRAVEV6C/images/mcp-apps/fullscreen-mobile.png?fit=max&auto=format&n=sLZLADaApRAVEV6C&q=85&s=d2802346090fd1a7af6a1bdc1d7c3263" alt="Full screen mobile examples" width="1999" height="716" data-path="images/mcp-apps/fullscreen-mobile.png" />
## Mobile guidelines
MCP apps on mobile share the same principles as web, but the constrained viewport and touch-based interaction require specific adaptations.
On mobile, Claude renders apps in a native WebView (WKWebView on iOS, WebView on Android) rather than a sandboxed iframe. Current mobile-only constraints: no camera/mic/location access, and connectors must be added via web or desktop before they appear on mobile.
### Host context for layout
The host passes layout hints via `hostContext`.
**Safe areas.** The interactive portion of your app should be rendered inside of the safe area to ensure it's not obscured by the mobile navigation bar or chat input and respects the chat screen's content margins. The user won't be able to interact with anything rendered outside the safe area (e.g. buttons obscured by a mobile navigation bar). Read `hostContext.safeAreaInsets.{top, right, bottom, left}` (in pixels) and apply them as padding on your root container, or as `scroll-padding` on scroll-snap containers so items come to rest inside the visible region. Safe areas are not mobile-specific: on web and desktop the composer can overlay the bottom of an inline app, so avoid placing interactive controls flush against any edge.
<img src="https://mintcdn.com/claude-ai/sLZLADaApRAVEV6C/images/mcp-apps/safe-area-fullscreen.png?fit=max&auto=format&n=sLZLADaApRAVEV6C&q=85&s=d789bcbba50a3bff53d677478421de30" alt="Safe area insets in full screen mode on web and mobile" width="1999" height="1153" data-path="images/mcp-apps/safe-area-fullscreen.png" />
**Borderless inline.** Set `_meta.ui.prefersBorder` to true or false to explicitly determine whether your content should render with a border. If no value is specified, content will be rendered borderless on web and bordered on mobile. In borderless mode your content runs edge-to-edge with no host padding, so honoring `safeAreaInsets` becomes essential; the bordered card's built-in padding otherwise absorbs most of them. Borderless works well for carousels and other horizontally-scrolling content that should bleed to the screen edges while in motion: apply `safeAreaInsets.left` and `.right` as `scroll-padding-inline` on the scroll container so items at rest sit clear of the device edges, but can scroll underneath them.
<img src="https://mintcdn.com/claude-ai/sLZLADaApRAVEV6C/images/mcp-apps/safe-area-borderless-mobile.png?fit=max&auto=format&n=sLZLADaApRAVEV6C&q=85&s=9936d8064beb2fc37e39b10ab1e727a9" alt="Safe area insets for borderless inline apps on mobile" width="1999" height="1857" data-path="images/mcp-apps/safe-area-borderless-mobile.png" />
Apps always fill the container width—there are no fixed breakpoints. Design responsively from 320px up to fullscreen using container queries and the hostContext CSS variables.
### Display modes
Declare which modes your app supports via `appCapabilities.availableDisplayModes` in `ui/initialize`. The host responds with the modes it supports, and your app can request a switch with `ui/request-display-mode`. Modes are `inline`, `fullscreen`, and `pip`.
### Content security policy
Declare external origins per `ui://` resource via `_meta.ui.csp`:
```json theme={null}
{
"_meta": {
"ui": {
"csp": {
"connectDomains": ["https://api.example.com"],
"resourceDomains": ["https://cdn.example.com"],
"baseUriDomains": []
}
}
}
}
```
By default, all external origins are blocked. `frameDomains` (embedding third-party iframes) is currently restricted in Claude pending security review.
### Viewport and layout
* Design for variable widths (320pt minimum, up to tablet)
* Respect safe areas on notched devices
* Full-width layouts — don't add side margins that waste mobile screen real estate
* Content should reflow gracefully; avoid fixed-width layouts
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/mobile-viewport-layout.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=d2244b6ff7e2d6c5e7b2c36fd2d901ed" alt="Viewport and layout do's and don'ts" width="1718" height="1238" data-path="images/mcp-apps/mobile-viewport-layout.png" />
### Touch targets
* Minimum tap target: 44 x 44pt (per Apple HIG / Material guidelines)
* Add sufficient spacing between interactive elements to prevent mis-taps
* Prefer larger, thumb-friendly buttons over small text links
* Place primary actions within natural thumb reach (lower portion of screen)
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/mobile-touch-targets.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=95bd5b4393d85a67b74e894331d5f4b0" alt="Touch target do's and don'ts" width="1718" height="1238" data-path="images/mcp-apps/mobile-touch-targets.png" />
### Scrolling and gestures
On mobile touch devices, the conversation view owns vertical scrolling. When your app is rendered inline, vertical pan gestures that start inside it are passed to the conversation scroll instead of to your content. This keeps a tall widget from trapping the user and is why inline apps should fit their content height rather than relying on an internal vertical scroll container—the host caps inline height and clips content that exceeds it.
Horizontal gestures (ex: carousels or panning a map) and taps work normally.
If your app genuinely needs its own vertically scrollable viewport, request fullscreen presentation with `ui/request-display-mode` instead of rendering inline (see [Full screen](#full-screen)).
### Transitions
* Inline cards expand to fullscreen with a smooth transition
* Provide a clear visual affordance for expansion (fullscreen button or tap-to-expand)
* Fullscreen close returns to the conversation at the same scroll position
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/mobile-transitions.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=343fe75a1428c1874568c10e02de9aa8" alt="Transition from inline card to full screen" width="1718" height="1222" data-path="images/mcp-apps/mobile-transitions.png" />
### Dark mode
All views must support both light and dark themes. Use the host's style tokens — they automatically adapt. Never hardcode colors. Test both modes.
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/mobile-dark-mode.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=79df1abf42e75b052ad7c28ac71c4413" alt="Dark mode examples on mobile" width="1999" height="1315" data-path="images/mcp-apps/mobile-dark-mode.png" />
### Loading states
Show skeleton screens while content loads. Match the layout structure of the final content so the transition feels seamless. Avoid spinners for inline content — skeletons feel more native.
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/mobile-loading-states.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=9e7df0fa2294bbcbcc24bf079cbc5ff6" alt="Loading state examples on mobile" width="1718" height="1130" data-path="images/mcp-apps/mobile-loading-states.png" />
## Visual design
MCP Apps should feel native to their environment while maintaining consistent visual hierarchy and accessibility standards. You can still express your brand through accent colors, custom controls and content.
**Design guidance**
**Color.** Use host tokens for all structural elements: backgrounds, text, borders, icons. You can use your own brand colors for accents and identity, but the core UI should use the provided palette.
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/color-tokens.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=173ce1948ae87b9e72b0854b5d27f4e1" alt="Color token examples for light and dark mode" width="1999" height="1863" data-path="images/mcp-apps/color-tokens.png" />
**Typography.** Stick to the three-level size scale (heading, body, caption) and two weights (regular, emphasized). This creates clear hierarchy without visual noise.
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/typography.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=51ce152aab3d975ae57c5e5792dc6097" alt="Typography scale examples" width="1999" height="936" data-path="images/mcp-apps/typography.png" />
<Note>
The Figma Community File uses Anthropic Sans and Anthropic Serif. When your app runs inside Claude, the host client provides Anthropic Sans at runtime through style variables. [Download and install the fonts from here](https://brand.anthropic.com/typography) for local development.
</Note>
**Borders.** Using a limited set of corner radii and thickness will keep your app feeling native to the surrounding UI.
<img src="https://mintcdn.com/claude-ai/IPtAfld1XUBVOx8m/images/mcp-apps/borders.png?fit=max&auto=format&n=IPtAfld1XUBVOx8m&q=85&s=1755cc995399c9d6bf25a1405ff139f4" alt="Border radius examples" width="1999" height="201" data-path="images/mcp-apps/borders.png" />
**Icons.** Use monochromatic, outlined icons that match the host's icon color tokens. Icons should support understanding, not be essential to it.
<img src="https://mintcdn.com/claude-ai/IXMfN0TT8kfXbN6T/images/mcp-apps/icons.png?fit=max&auto=format&n=IXMfN0TT8kfXbN6T&q=85&s=1454f1f3e5e13107cbe543e8d6d617df" alt="Icon style examples" width="1320" height="768" data-path="images/mcp-apps/icons.png" />
**Spacing.** Maintain generous padding and logical groupings. Balance information density with readability, adapting to viewport constraints.
## Interaction patterns
### App vs. chat interactions
Understanding the boundary between your app's interactions and Claude's conversational interface helps you build something that feels cohesive.
**Handle within your app:**
* Direct manipulation like sliders, toggles, and selections
* Filtering or sorting data you're already displaying
* Expanding and collapsing content sections
* Confirming or executing a prepared action ("Mark complete," "Send," "Save")
* Interacting with visualizations like hover states or clicking data points
Prefer controls with visible options (segmented buttons, toggle chips, inline tabs) over menus and dropdowns, which can conflict with the host container.
**Push to chat input:**
* Text entry and freeform input
* Follow-up questions or requests for clarification
* Requests to modify, refine, or redo something
* Navigation to different contexts or topics
* Anything that benefits from Claude's interpretation
If the interaction requires language understanding or generates a response from Claude, it goes through chat. If it's a direct UI action on content your app already controls, handle it in the app.
### Start simple
Reveal complexity only when users need it. The inline card might show a summary; fullscreen mode can offer the detailed view.
### Visible controls over hidden menus
Prefer controls with visible options (segmented buttons, toggle chips, inline tabs) over menus and dropdowns. Menus conflict with the host container and are harder to use on mobile.
## Accessibility
Maintain high contrast standards (WCAG AA minimum). Support keyboard navigation and provide text alternatives for visual content. Test with assistive technologies. Your app must be usable by everyone.
## Style variables
MCP Apps automatically receive style variables from the host client. Reference these CSS custom properties to create interfaces that feel native to Claude.
**Color tokens** cover backgrounds, text, and borders. Semantic accent colors signal status. All tokens automatically adapt to light and dark mode.
| | Light mode | Dark mode |
| :--------------------------- | :-------------- | :-------------- |
| **Background** | | |
| `color-background-primary` | `#FFFFFF` | `#30302E` |
| `color-background-secondary` | `#F5F4ED` | `#262624` |
| `color-background-tertiary` | `#FAF9F5` | `#141413` |
| `color-background-inverse` | `#141413` | `#FAF9F5` |
| `color-background-ghost` | `#FFFFFF (0%)` | `#30302E (0%)` |
| `color-background-info` | `#D6E4F6` | `#253E5F` |
| `color-background-danger` | `#F7ECEC` | `#602A28` |
| `color-background-success` | `#E9F1DC` | `#1B4614` |
| `color-background-warning` | `#F6EEDF` | `#483A0F` |
| `color-background-disabled` | `#FFFFFF (50%)` | `#30302E (50%)` |
| **Text** | | |
| `color-text-primary` | `#141413` | `#FAF9F5` |
| `color-text-secondary` | `#3D3D3A` | `#C2C0B6` |
| `color-text-tertiary` | `#73726C` | `#9C9A92` |
| `color-text-inverse` | `#FFFFFF` | `#141413` |
| `color-text-ghost` | `#73726C (50%)` | `#9C9A92 (50%)` |
Cut at 300 lines. The page has the rest.
connectors/building/mcp-apps/external-links First recorded · 70 lines, first recorded
# Opening external links from MCP Apps ## Default behavior ## Allowlisting link destinations ### Example ### Restrictions on custom schemes ## User-activation requirement ## Design for the modal
The first capture of this source. The page was already there, and this is what it said.
# Opening external links from MCP Apps
> How Claude handles ui/open-link requests, and how directory connectors can allowlist destinations to skip the confirmation modal
When your MCP App sends a `ui/open-link` request, Claude shows an "Open external link" confirmation modal before navigating. This protects users from being silently redirected by an embedded app.
Directory connectors can declare a set of trusted destinations that open immediately without the modal. Custom connectors and locally configured servers always show the modal.
## Default behavior
A `ui/open-link` request displays a confirmation modal showing the destination URL. The link opens in a new tab when the user confirms; the request resolves as cancelled if they dismiss the modal.
## Allowlisting link destinations
If your connector is published in the [Connectors Directory](/docs/connectors/directory), you can declare destinations that skip the modal. Provide them in the **Allowed link URIs** field when you [submit](/docs/connectors/building/submission) or update your directory listing.
Each entry must be one of two shapes:
| Entry shape | Example | Matches |
| ----------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| HTTPS origin | `https://docs.example.com` | Any `https://` URL whose hostname is exactly `docs.example.com` (case-insensitive). Subdomains do not match implicitly; list each one you need. Port is not compared. |
| Custom URI scheme | `example-app` or `example-app:` | Any URL with the scheme `example-app:`, typically a deep link into your native mobile or desktop app. |
Entries that do not fit one of these shapes are ignored. This includes bare hostnames such as `example.com`, `http://` origins, and malformed values.
### Example
Given the following allowlist:
```text theme={null}
https://example.com
https://docs.example.com
example-app
```
These destinations open immediately:
* `https://example.com/pricing`
* `https://docs.example.com/getting-started?ref=claude`
* `example-app://open/project/123`
These destinations still show the confirmation modal:
* `https://blog.example.com` (subdomain not listed)
* `http://example.com` (not HTTPS)
* `https://example.com.attacker.net` (different hostname)
### Restrictions on custom schemes
A custom-scheme entry must name a scheme your application registers and owns. Entries that name a generic, browser-internal, or platform-reserved scheme are rejected. This includes `http`, `https`, `file`, `data`, `javascript`, `blob`, `mailto`, `tel`, `sms`, `intent`, `android-app`, browser-extension schemes, and Windows shell schemes such as `search-ms` and `shell`.
## User-activation requirement
The modal is bypassed only when the `ui/open-link` request follows a real user gesture in your app, such as a button click.
If your app sends `ui/open-link` without a preceding gesture (programmatically, on a timer, or after the browser's activation window has expired), the modal is shown so the user's confirmation click supplies the gesture the browser requires to open a new tab.
<Note>
A bypassed `ui/open-link` request resolves successfully once the open is attempted; it does not indicate whether the browser actually opened the tab. Do not treat the response as confirmation that the user reached the destination.
</Note>
## Design for the modal
Even with an allowlist configured, your app should remain usable when the modal appears:
* Custom and local connectors always show the modal. Your app may run outside the directory during development or in self-hosted deployments.
* Destinations not on your allowlist, or added since your last published directory update, show the modal.
* Requests without user activation show the modal.
Provide enough context in your UI that the destination URL shown in the modal is recognizable to the user.
connectors/building/mcp-apps/getting-started First recorded · 114 lines, first recorded
# Get started with MCP Apps ## Try an example MCP App ### Connect an example server ### See it in action ## Build your own MCP App ## Migrate from OpenAI Apps SDK
The first capture of this source. The page was already there, and this is what it said.
# Get started with MCP Apps
> Learn how to test MCP Apps in Claude
## Try an example MCP App
### Connect an example server
Make sure you have installed and logged into Claude Desktop. Navigate to the [developer settings page](https://claude.ai/desktop/settings/desktop/developer) (**Settings > Developer**) and click the "Edit Config" button.
Add one of the example servers to your `claude_desktop_config.json`:
| Example | Description |
| ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| [**Customer Segmentation**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/customer-segmentation-server) | Data visualization with scatter charts and clustering analysis |
| [**Map**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/map-server) | Interactive 3D globe viewer using CesiumJS |
| [**QR Code**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/qr-server) | QR code generation with customizable colors and styling |
| [**ShaderToy**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/shadertoy-server) | Real-time GLSL shader compilation and display |
| [**Sheet Music**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/sheet-music-server) | ABC notation rendering with interactive audio playback |
| ⋮ | Explore [more examples](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples)—each with ready-to-use config snippets! |
<CodeGroup>
```json Customer Segmentation theme={null}
{
"mcpServers": {
"customer-segmentation": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/customer-segmentation-server", "--stdio"]
}
}
}
```
```json Map theme={null}
{
"mcpServers": {
"map": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/map-server", "--stdio"]
}
}
}
```
```json QR Code theme={null}
{
"mcpServers": {
"qr": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/qr-server", "--stdio"]
}
}
}
```
```json ShaderToy theme={null}
{
"mcpServers": {
"shadertoy": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/shadertoy-server", "--stdio"]
}
}
}
```
```json Sheet Music theme={null}
{
"mcpServers": {
"sheet-music": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/sheet-music-server", "--stdio"]
}
}
}
```
</CodeGroup>
Save and restart the desktop app to connect.
### See it in action
Once your local server is connected, prompt Claude to use it. For example, with the customer segmentation server, ask Claude to show you recent customer data.
Claude will prompt you for permission to display the App. Click "Always allow", and you'll see the MCP App render inline in the conversation.
## Build your own MCP App
Ready to add an MCP App to your own MCP server? Here are the key resources:
* [MCP Apps Quickstart](https://modelcontextprotocol.github.io/ext-apps/api/documents/Quickstart.html) - Step-by-step guide to building your first MCP App
* [SDK API Documentation](https://modelcontextprotocol.github.io/ext-apps/api/index.html) - Full API reference
* [Example implementations](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples) - Vanilla JS, React, Vue, Svelte, and more
If you are using an AI coding agent, [MCP Apps skills](https://github.com/modelcontextprotocol/ext-apps/tree/main/plugins/mcp-apps) provide guided development for agents that support the [Agent Skills](https://agentskills.io) standard, including Claude Code, Cursor, Gemini CLI, and others. In Claude Code, you can install the MCP Apps skills plugin with the following commands:
```
/plugin marketplace add modelcontextprotocol/ext-apps
/plugin install mcp-apps@modelcontextprotocol-ext-apps
```
Once installed, ask your agent to "Create an MCP App" or "Add a UI to my MCP tool".
<Tip>You can test remote MCP Apps locally via a proxy like [mcp-remote](https://www.npmjs.com/package/mcp-remote).</Tip>
## Migrate from OpenAI Apps SDK
If you are migrating an existing app from the OpenAI Apps SDK to the MCP Apps SDK, see the [migration reference](https://modelcontextprotocol.github.io/ext-apps/api/documents/Migrate_OpenAI_App.html).
You can also use the MCP Apps skills mentioned above to help migrate your apps. Ask your agent to "Migrate from OpenAI Apps SDK" or "Convert my OpenAI App to an MCP App".
***
We'd love to see what you build! Send feedback to [[email protected]](mailto:[email protected]) or open an issue on the [ext-apps repository](https://github.com/modelcontextprotocol/ext-apps/issues).
connectors/building/mcp-apps/instance-supersession First recorded · 241 lines, first recorded
# Supersede older widget instances ## How it works ## Mint the election key on the server ### Why not use client-side `Date.now()`? ## Run the election in the widget ### Read the key from the `toolresult` event ### Broadcast and compare on a shared channel ### Gate host-mutating calls on `!superseded` ### Reflect the state in the UI ## Special considerations ### Channel scope and `ui.domain` ### Fall back if the server key is delayed ### Fallback caveat: don't compare server and client timestamps ### Caching the key across remounts ### If you bypass the SDK `App` class ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Supersede older widget instances
> Keep only the newest copy of a widget active when its tool is called more than once in a conversation
Each time Claude calls a tool that renders an MCP App, a separate iframe is mounted in the conversation. There is no host API to unmount earlier instances when a newer one appears, so by default you end up with several live copies of the same widget, each independently pushing [model-context updates](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#updatemodelcontext) (data the widget feeds into Claude's context for the next turn) and [messages](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#sendmessage) to Claude.
If your widget represents a single piece of state, such as a shopping cart or a dashboard, only the most recent instance should remain interactive. You can use [`BroadcastChannel`](https://developer.mozilla.org/docs/Web/API/BroadcastChannel) to make earlier instances disable themselves.
The snippets on this page assume you have registered a UI resource and tool and created an `App` instance from `@modelcontextprotocol/ext-apps`. See the [SDK Quickstart](https://modelcontextprotocol.github.io/ext-apps/api/documents/Quickstart.html) if you haven't.
## How it works
All widget iframes from a single connector are served from the same sandbox origin on `*.claudemcpcontent.com` (the iframe sandbox includes [`allow-same-origin`](https://developer.mozilla.org/docs/Web/HTML/Element/iframe#sandbox)). That means a `BroadcastChannel` opened in one instance reaches every other instance from the same connector in the current conversation. See [Channel scope and `ui.domain`](#channel-scope-and-ui-domain) for how a fixed domain widens this.
The pattern has three parts:
1. **The server stamps each tool result with an election key.** It returns a `{createdAt, seq}` pair (server wall-clock time and a monotonic counter) in [`structuredContent`](https://modelcontextprotocol.io/specification/latest/server/tools#structured-content), the typed JSON payload slot of an MCP tool result. Tool results are stored in the conversation transcript, so every device and every remount of the widget sees the same key.
2. **Each widget announces its key on a shared channel.** Shortly after `connect()` resolves, the host delivers the tool result that mounted this widget (including its `structuredContent`) via the SDK's [`toolresult` event](https://modelcontextprotocol.github.io/ext-apps/api/types/app.AppEventMap.html). The widget reads its key from that event, opens a `BroadcastChannel`, and broadcasts the key.
3. **Any widget that sees a younger sibling marks itself superseded.** It greys out its UI, disables its buttons, and short-circuits all calls that mutate model context or inject messages.
## Mint the election key on the server
Use [`registerAppTool`](https://modelcontextprotocol.github.io/ext-apps/api/functions/server-helpers.registerAppTool.html) to register the tool, and return the key in `structuredContent` alongside your normal tool output. A per-process counter works for a demo; a production server should derive the key from something durable, such as a database row ID or a version number on the underlying record.
```ts theme={null}
import { registerAppTool } from "@modelcontextprotocol/ext-apps/server";
import { z } from "zod";
let callSeq = 0;
registerAppTool(
server,
"show_cart",
{
title: "Show cart",
description: "Render the user's shopping cart as an interactive widget.",
inputSchema: { items: z.array(z.string()).optional() },
_meta: { ui: { resourceUri: "ui://cart-demo/cart.html" } },
},
async ({ items }) => {
const list = items ?? [];
const seq = ++callSeq;
const createdAt = Date.now();
return {
content: [{ type: "text", text: `Cart rendered with ${list.length} item(s).` }],
// The election key travels with the tool result in the transcript,
// so rehydrated widgets on any device recover the same ordering.
structuredContent: { items: list, seq, createdAt },
};
},
);
```
### Why not use client-side `Date.now()`?
Client mount time does not reflect tool-call order. When a stored conversation is reopened, Claude lazy-mounts widget cells as they scroll into view, so an older widget can mount after a newer one and would win an election based on client timestamps. The server-minted key is written into the transcript at tool-call time and is identical everywhere.
## Run the election in the widget
The four snippets in this section form a single module; paste them in order into your widget entry file.
### Read the key from the `toolresult` event
Connect and read the values you need from the host: your instance ID from [`hostContext.toolInfo`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiHostContext.html#toolinfo), and the server-minted key from the `toolresult` event. The event's `structuredContent` is typed `Record<string, unknown>`, so cast it to the shape your server returns.
```ts theme={null}
import { App } from "@modelcontextprotocol/ext-apps";
type CartResult = { items?: string[]; createdAt?: number; seq?: number };
const app = new App({ name: "cart-demo", version: "1.0.0" });
let superseded = false;
let keyFinalized = false;
let orderKey: number | undefined;
let seq: number | undefined;
let items: string[] = [];
app.addEventListener("toolresult", (params) => {
const sc = params.structuredContent as CartResult | undefined;
if (sc?.items) items = sc.items;
if (sc && Number.isFinite(sc.createdAt)) {
orderKey = sc.createdAt;
seq = Number.isFinite(sc.seq) ? sc.seq : undefined;
keyFinalized = true;
announce(); // defined in "Broadcast and compare on a shared channel" below
}
});
await app.connect();
const hostContext = app.getHostContext();
const instanceId = hostContext?.toolInfo?.id ?? crypto.randomUUID();
```
### Broadcast and compare on a shared channel
Broadcast the key and compare against every sibling you hear from. The comparison is `createdAt`, tie-broken by `seq`, then by instance ID for determinism. Ignore inbound messages until your own key is finalized so you never reply with an undefined key.
```ts theme={null}
const channel = new BroadcastChannel("my-app-cart-supersede");
const peers = new Map<string, { orderKey: number; seq?: number; instanceId: string }>();
function isYounger(other: { orderKey: number; seq?: number; instanceId: string }) {
// keyFinalized guards every call site, so orderKey is set by the time this runs.
if (other.orderKey !== orderKey) return other.orderKey > orderKey!;
if (other.seq != null && seq != null && other.seq !== seq) return other.seq > seq;
return String(other.instanceId) > String(instanceId);
}
function recompute() {
superseded = [...peers.values()].some(isYounger);
render(); // defined in "Reflect the state in the UI" below
}
channel.onmessage = (ev) => {
const msg = ev.data;
if (!msg || msg.instanceId === instanceId) return;
if (!keyFinalized) return;
if (msg.type === "hello") {
channel.postMessage({ type: "born", instanceId, orderKey, seq });
}
peers.set(msg.instanceId, msg);
recompute();
};
function announce() {
channel.postMessage({ type: "hello", instanceId, orderKey, seq });
channel.postMessage({ type: "born", instanceId, orderKey, seq });
}
```
### Gate host-mutating calls on `!superseded`
The election only matters if superseded instances actually stop talking to Claude. Guard every call to [`updateModelContext`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#updatemodelcontext) or [`sendMessage`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#sendmessage):
```ts theme={null}
// addButton, card, badge: elements in your widget's DOM.
// pickRandomItem: your own helper that returns a string.
function updateModelContext() {
if (superseded) return;
app.updateModelContext({
content: [{ type: "text", text: `Cart has ${items.length} item(s): ${items.join(", ")}.` }],
});
}
addButton.onclick = () => {
if (superseded) return;
items.push(pickRandomItem());
render();
updateModelContext();
};
```
### Reflect the state in the UI
In your render function, disable buttons and show a banner that points the user to the newest instance:
```ts theme={null}
function render() {
card.classList.toggle("superseded", superseded);
badge.textContent = superseded ? "Superseded" : "Live";
addButton.disabled = superseded;
}
```
## Special considerations
The election above covers the common case. A production widget should also handle the following.
### Channel scope and `ui.domain`
`BroadcastChannel` is same-origin only. How far that origin extends depends on whether you set [`_meta.ui.domain`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html#domain) on your resource:
* **Without `ui.domain`** (the default), Claude derives the iframe origin from the conversation and connector, so the broadcast is scoped to a single conversation.
* **With a fixed `ui.domain`**, the origin is shared across every conversation and tab for your connector. A fixed channel name would let a widget in one conversation supersede a widget in another. Neither `hostContext` nor the tool-call arguments include a Claude-provided conversation ID, so if you need both a fixed domain and per-conversation elections, generate your own scope key on the server (for example, a UUID minted once per client connection) and return it in `structuredContent` for the widget to append to the channel name.
### Fall back if the server key is delayed
The main snippet above waits for the `toolresult` event before announcing. If you want the widget to participate in the election even when that event is slow to arrive, replace that listener with one that resolves a promise, and race the promise against a short timeout after `connect()`:
```ts theme={null}
let resolveServerKey!: (k: { orderKey: number; seq?: number }) => void;
const serverKeyReady = new Promise<{ orderKey: number; seq?: number }>(
(r) => (resolveServerKey = r),
);
// Replaces the toolresult listener from the first widget snippet.
app.addEventListener("toolresult", (params) => {
const sc = params.structuredContent as CartResult | undefined;
if (sc?.items) items = sc.items;
if (sc && Number.isFinite(sc.createdAt)) {
resolveServerKey({ orderKey: sc.createdAt!, seq: sc.seq });
}
});
// Place after the announce() definition in the broadcast snippet,
// so channel is initialized before announce() runs.
const serverKey = await Promise.race([
serverKeyReady,
new Promise<null>((r) => setTimeout(() => r(null), 1000)),
]);
orderKey = serverKey?.orderKey ?? Date.now();
seq = serverKey?.seq;
keyFinalized = true;
announce();
```
If the server key arrives after the timeout, adopt it, recompute `superseded` against the peers you have already heard from, and re-announce so siblings update their view of you. The recomputed result may flip the instance back to live.
### Fallback caveat: don't compare server and client timestamps
This applies only if you implemented the fallback above. If you fall back to a client-side `Date.now()` while waiting for the server key, tag the key with its source and refuse to compare a client value against a server value. A server `createdAt` from a tool call made hours ago will always be smaller than a fresh client timestamp, which would wrongly hand "live" to whichever instance happened to fall back. Include `keySource` in the broadcast payload (`announce()` and the `born` reply) and in the `peers` Map value type so siblings can read it:
```ts theme={null}
type KeySource = "server" | "client";
let keySource: KeySource = "client";
function isYounger(other: { orderKey: number; seq?: number; instanceId: string; keySource: KeySource }) {
if ((other.keySource === "server") !== (keySource === "server")) return false;
// keyFinalized guards every call site, so orderKey is set by the time this runs.
if (other.orderKey !== orderKey) return other.orderKey > orderKey!;
if (other.seq != null && seq != null && other.seq !== seq) return other.seq > seq;
return String(other.instanceId) > String(instanceId);
}
```
### Caching the key across remounts
On Claude.ai web, [`hostContext.toolInfo.id`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiHostContext.html#toolinfo) is the stable tool-use ID, so you can persist the resolved server key to `localStorage` keyed by that ID and reuse it on the next mount without waiting for the `toolresult` event again.
Treat this as an optimization rather than a correctness guarantee. On Claude iOS, `toolInfo.id` is `undefined` when a stored conversation is rehydrated, so there is no stable per-instance cache key. Detect that case and skip the cache; the server key from the `toolresult` event is the only ordering source that works on every platform.
### If you bypass the SDK `App` class
The snippets on this page use the SDK's [`App`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html) class. If you instead hand-roll a minimal `postMessage` bridge, it will silently drop requests sent from the host to the widget, such as `ping` (a liveness check) and [`ui/resource-teardown`](https://apps.extensions.modelcontextprotocol.io/api/interfaces/app.McpUiResourceTeardownRequest.html) (the host asking the widget to clean up before unmount). Claude.ai web does not currently send either to widgets, and Claude iOS sends `ui/resource-teardown` only when the user navigates away from the conversation, so ignoring them is harmless today. The `App` class handles the full request surface and is recommended for production.
## Related topics
* [Cross-platform compatibility](/docs/connectors/building/mcp-apps/cross-compatibility#domain-handling) for how `_meta.ui.domain` is computed on Claude.
* [SDK API reference](https://modelcontextprotocol.github.io/ext-apps/api/index.html) for `registerAppTool`, `App`, and `McpUiResourceMeta`.
connectors/building/mcp-apps/transparent-theming First recorded · 154 lines, first recorded
# Blend your MCP App with Claude's theme ## Let the host background show through ### Don't paint a body background ### Declare `color-scheme` in your document head ### Request a borderless frame ## Apply the host's style variables ### Read `hostContext` and listen for changes ### Reference the variables in your CSS ### Allow the host font origin in your CSP ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Blend your MCP App with Claude's theme
> Make your widget background transparent and style it with Claude's style variables
Claude renders MCP Apps inside a sandboxed iframe, and every frame between your widget and the chat surface already has a transparent background, so the conversation can show through. When you leave your own background transparent and style text and borders with the host's [style variables](/docs/connectors/building/mcp-apps/design-guidelines#style-variables), your app looks like part of the conversation rather than an embedded box, and it follows the user's light or dark mode automatically.
The snippets on this page assume you have registered a UI resource and created an `App` instance from `@modelcontextprotocol/ext-apps`. See the [SDK Quickstart](https://modelcontextprotocol.github.io/ext-apps/api/documents/Quickstart.html) if you haven't.
## Let the host background show through
Three settings on your side keep the transparency intact.
### Don't paint a body background
Any opaque background on `<html>` or `<body>` hides the chat surface behind it. Explicitly set both to `transparent`:
```css theme={null}
html,
body {
margin: 0;
background: transparent;
}
```
### Declare `color-scheme` in your document head
Browsers give iframe documents an opaque canvas backdrop (white in light mode, near-black in dark mode) when the iframe's [`color-scheme`](https://developer.mozilla.org/docs/Web/CSS/color-scheme) differs from the embedding page. Declaring both schemes opts your document into whichever mode the host is in, so the browser drops the backdrop and makes the CSS [`light-dark()`](https://developer.mozilla.org/docs/Web/CSS/color_value/light-dark) values in Claude's tokens resolve correctly:
```html theme={null}
<meta name="color-scheme" content="light dark" />
```
### Request a borderless frame
Set [`prefersBorder: false`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html#prefersborder) in your UI resource's [`_meta.ui`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html) object so the host doesn't wrap your widget in its own bordered card. Claude web's default is already borderless, but other hosts differ, so being explicit keeps your app portable. Register the resource with [`registerAppResource`](https://modelcontextprotocol.github.io/ext-apps/api/functions/server-helpers.registerAppResource.html):
```ts theme={null}
import {
registerAppResource,
RESOURCE_MIME_TYPE,
} from "@modelcontextprotocol/ext-apps/server";
registerAppResource(server, "My Widget", "ui://my-app/widget.html", {}, async () => ({
contents: [
{
uri: "ui://my-app/widget.html",
mimeType: RESOURCE_MIME_TYPE,
text: widgetHtml, // the bundled HTML string of your widget; see the SDK Quickstart
_meta: {
ui: {
prefersBorder: false,
// lets applyHostFonts load Anthropic Sans; see "Allow the host font origin in your CSP"
csp: { resourceDomains: ["https://assets.claude.ai"] },
},
},
},
],
}));
```
## Apply the host's style variables
Claude passes a [`hostContext`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiHostContext.html) object to your widget during the [`connect()`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#connect) handshake. The fields relevant to theming are:
| Field | Contents |
| :----------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `theme` | `"light"` or `"dark"` |
| `styles.variables` | CSS custom properties: `--color-background-*`, `--color-text-*`, `--color-border-*`, `--color-ring-*`, `--font-*`, `--border-radius-*`, `--border-width-*` |
| `styles.css.fonts` | `@font-face` rules for Anthropic Sans, served from `https://assets.claude.ai` |
The [Style variables](/docs/connectors/building/mcp-apps/design-guidelines#style-variables) section of the design guidelines lists every variable and its light- and dark-mode value.
### Read `hostContext` and listen for changes
The [`App`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html) class exposes the initial context via [`getHostContext()`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#gethostcontext) once `connect()` resolves, and delivers subsequent updates (such as the user toggling dark mode) through the [`hostcontextchanged`](https://modelcontextprotocol.github.io/ext-apps/api/types/app.AppEventMap.html) event. Register the listener before you connect so you don't miss an early update.
The SDK provides three helpers that do the DOM work for you, plus React hooks that wrap them:
* [`applyDocumentTheme(theme)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/app.applyDocumentTheme.html) sets `<html data-theme>` and the root `color-scheme`, so `[data-theme="dark"]` selectors and `light-dark()` values resolve correctly.
* [`applyHostStyleVariables(variables)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/app.applyHostStyleVariables.html) writes every entry in `styles.variables` onto `:root` as a CSS custom property.
* [`applyHostFonts(fontCss)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/app.applyHostFonts.html) injects the host's `@font-face` rules once.
* [`useApp(options)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/_modelcontextprotocol_ext-apps_react.useApp.html) creates and connects the `App` instance for you in React.
* [`useHostStyles(app, hostContext)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/_modelcontextprotocol_ext-apps_react.useHostStyles.html) applies all of the above and re-applies on `hostcontextchanged`.
Keep the `<meta name="color-scheme">` tag from the previous section even though `applyDocumentTheme` also sets `color-scheme` at runtime. The tag covers the first paint before your script runs and prevents an opaque-backdrop flash.
<CodeGroup>
```ts TypeScript theme={null}
import {
App,
applyDocumentTheme,
applyHostFonts,
applyHostStyleVariables,
type McpUiHostContext,
} from "@modelcontextprotocol/ext-apps";
function applyHostContext(ctx: Partial<McpUiHostContext>) {
if (ctx.theme) applyDocumentTheme(ctx.theme);
if (ctx.styles?.variables) applyHostStyleVariables(ctx.styles.variables);
if (ctx.styles?.css?.fonts) applyHostFonts(ctx.styles.css.fonts);
}
const app = new App({ name: "my-app", version: "1.0.0" });
// Updates carry only the fields that changed.
app.addEventListener("hostcontextchanged", (changed) => applyHostContext(changed));
await app.connect();
const initial = app.getHostContext();
if (initial) applyHostContext(initial);
```
```tsx React theme={null}
import { useApp, useHostStyles } from "@modelcontextprotocol/ext-apps/react";
function Widget() {
const { app } = useApp({
appInfo: { name: "my-app", version: "1.0.0" },
capabilities: {},
});
// Applies theme + CSS variables + fonts, and re-applies on host-context-changed.
useHostStyles(app, app?.getHostContext());
return <div className="card">…</div>;
}
```
</CodeGroup>
### Reference the variables in your CSS
Once the variables are on `:root`, reference them directly. Provide fallbacks so the widget is still readable when rendered outside a host:
```css theme={null}
body {
font-family: var(--font-sans, system-ui, sans-serif);
color: var(--color-text-primary, light-dark(#141413, #faf9f5));
}
.card {
border: var(--border-width-regular, 0.5px) solid var(--color-border-primary);
border-radius: var(--border-radius-md, 8px);
}
```
<Note>
Claude's token values use CSS `light-dark()`, so once `applyDocumentTheme` has set the root `color-scheme`, every `--color-*` variable resolves to the right variant without any `[data-theme]` selectors on your side.
</Note>
### Allow the host font origin in your CSP
For `applyHostFonts` to load the `@font-face` files, your resource's [`_meta.ui.csp`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html#csp) allowlist must include `https://assets.claude.ai` in [`resourceDomains`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceCsp.html#resourcedomains) (shown in the [`registerAppResource` snippet above](#request-a-borderless-frame)). `resourceDomains` also adds the listed origins to `script-src` and `style-src`, so keep it to origins you trust to serve executable code; prefer bundling third-party fonts into your widget rather than allowlisting public CDNs.
## Related topics
* [Design guidelines: Style variables](/docs/connectors/building/mcp-apps/design-guidelines#style-variables) and [Visual design](/docs/connectors/building/mcp-apps/design-guidelines#visual-design) for the full variable palette and usage guidance.
* [SDK API reference](https://modelcontextprotocol.github.io/ext-apps/api/index.html) for `App`, `McpUiHostContext`, and `McpUiResourceMeta`.
connectors/building/mcp-apps/troubleshooting First recorded · 109 lines, first recorded
# Troubleshooting MCP Apps ## Using developer tools ### Desktop ### iOS ## Problem: Tool call appears but the app is invisible ### Missing `app.connect()` call ### Iframe has zero height ## Problem: App doesn't render when tool results are large ## Problem: Assets or API requests fail only on iOS ## Problem: ui.domain validation fails
The first capture of this source. The page was already there, and this is what it said.
# Troubleshooting MCP Apps
> Debug and resolve common issues with MCP Apps
## Using developer tools
### Desktop
Claude Desktop's Developer Tools can help you debug MCP Apps. To use them:
1. Open **Help > Troubleshooting** and click **Enable Developer Mode**. A new **Developer** menu appears in the menu bar.
2. Open Developer Tools by pressing `Cmd+Option+I` (Mac) or `Ctrl+Shift+I` (Windows)
3. Inspect the tool call element and look for an iframe nested inside another iframe. Your app will be loaded as the content of the inner iframe.
<Tip>From the **Developer** menu, select **Reload MCP Configuration** after editing your `claude_desktop_config.json` to apply changes without restarting.</Tip>
### iOS
On iOS, the Claude app renders your MCP app inside a `WKWebView`. You can inspect it from a connected Mac using Safari's Web Inspector—see Apple's guide to [inspecting iOS](https://developer.apple.com/documentation/safari-developer-tools/inspecting-ios) for setup. Once connected, the Claude web view appears under your device in Safari's **Develop** menu, and you can use the console, network panel, and element inspector just as you would on desktop.
## Problem: Tool call appears but the app is invisible
This is the most common issue when developing MCP Apps. Check these two causes:
### Missing `app.connect()` call
Your app must call [`app.connect()`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#connect) (Vanilla JS) or [`useApp()`](https://modelcontextprotocol.github.io/ext-apps/api/functions/_modelcontextprotocol_ext-apps_react.useApp.html) (React) to establish communication with Claude Desktop.
<CodeGroup>
```javascript Vanilla JS theme={null}
import { App } from "@modelcontextprotocol/ext-apps";
const app = new App({ name: "My App", version: "1.0.0" });
// Register handlers before connecting
app.ontoolresult = (result) => {
// Handle tool results
};
await app.connect();
```
```javascript React theme={null}
import { useApp } from "@modelcontextprotocol/ext-apps/react";
function MyComponent() {
// The useApp hook handles connection automatically
const { app } = useApp({
appInfo: { name: "My App", version: "1.0.0" },
capabilities: {},
onAppCreated: (app) => {
app.ontoolresult = (result) => {
// Handle tool results
};
}
});
}
```
</CodeGroup>
<Warning>Event handlers like `app.ontoolinput` and `app.ontoolresult` won't be invoked until the app is connected.</Warning>
### Iframe has zero height
Your app needs a non-zero height to be visible. A zero height can occur if:
* Your app's container has no content yet
* You called `sendSizeChanged({ width, height: 0 })`
Check that your root element has explicit dimensions or content that gives it height.
## Problem: App doesn't render when tool results are large
When a tool result exceeds approximately 150,000 characters and Claude's code execution sandbox is active, the result is written to the sandbox filesystem instead of being passed inline to the conversation. Your app receives a pointer to the stored file rather than the structured content it needs, so it never hydrates.
<Note>This \~150,000-character threshold is specific to Claude.ai and Claude Desktop. Claude Code uses a separate 25,000-token default limit configurable via `MAX_MCP_OUTPUT_TOKENS`.</Note>
To avoid this, keep initial tool result payloads lean:
* **Paginate large results.** Return a summary or the first page of data, and let the user request more through follow-up interactions.
* **Fetch details on demand.** Use app-initiated tool calls to load additional data from within your widget as the user explores, rather than returning everything upfront.
* **Defer heavy content.** If your data includes large blobs—full document text, base64-encoded images, extensive logs—return identifiers or previews in the initial result and provide a separate tool to retrieve the full content when needed.
## Problem: Assets or API requests fail only on iOS
If your app loads on desktop and web but fails to fetch scripts, images, or API data on iOS, check whether your server, CDN, or WAF is gating access on the `Referer` header.
WebKit on iOS—both Safari and in the Claude iOS app—omits the `Referer` header on cross-origin subresource requests as part of its tracking prevention (WebKit bugs [206521](https://bugs.webkit.org/show_bug.cgi?id=206521) and [179053](https://bugs.webkit.org/show_bug.cgi?id=179053#c8)). A server that requires a `Referer` to allow the request will reject iOS traffic even though the same app works elsewhere.
**Fix:** Allowlist on the `Origin` header instead, which WebKit does send. Requests from your app carry an `Origin` of `{hash}.claudemcpcontent.com`—see [Domain handling](/docs/connectors/building/mcp-apps/cross-compatibility#domain-handling) to compute the hash for your server URL. Configure your infrastructure to allow requests whose `Origin` matches `*.claudemcpcontent.com` and return a corresponding `Access-Control-Allow-Origin` header.
<Note>This applies to requests your app makes directly from the user's device—loading bundles, images, or calling your own API from client-side code. MCP tool calls are proxied through Claude's backend and egress from Anthropic's published IP ranges, not the user's device.</Note>
## Problem: ui.domain validation fails
Setting [`_meta.ui.domain`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html#domain) on your resource opts your app into a stable sandbox origin, which you need if your app runs its own OAuth flow. Claude validates the value against your connector URL and shows an `Invalid ui.domain format` or `ui.domain mismatch` error instead of rendering the app when validation fails.
The value must be exactly `{hash}.claudemcpcontent.com`, where `{hash}` is the first 32 hexadecimal characters of the SHA-256 digest of your full connector URL. Compute it by running this command with your own URL:
```shell theme={null}
node -e 'const yourServerUrl = "https://example.com/mcp"; console.log(require("crypto").createHash("sha256").update(yourServerUrl).digest("hex").slice(0,32) + ".claudemcpcontent.com")'
```
Common causes of a mismatch:
* **The URL you hashed differs from the URL Claude connects to.** The hash covers the full URL string including scheme, path, and any trailing slash, so `https://example.com/mcp` and `https://example.com/mcp/` produce different values. Hash the exact URL configured in **Customize > Connectors**.
* **The connector is local (stdio).** Local connectors have no URL to hash, so `ui.domain` is not available for them. Remove the field, or deploy the server as a remote connector to use a stable origin.
See [Domain handling](/docs/connectors/building/mcp-apps/cross-compatibility#domain-handling) for how the origin is used across platforms.
connectors/building/mcpb First recorded · 173 lines, first recorded
# Build a desktop extension with MCPB ## What is an MCPB? ## Local (MCPB) vs remote: which to build ## Choose a language ## Platform support ## Quickstart ## manifest.json ## Add an icon ## User configuration ## How users install your MCPB ## Resources ## Get help ## Ready for distribution
The first capture of this source. The page was already there, and this is what it said.
# Build a desktop extension with MCPB
> Package a local MCP server as a single-click .mcpb install for Claude Desktop
<Note>
MCPB is the secondary distribution path. Remote MCP servers are recommended for directory listing—see [what to build](/docs/connectors/building/what-to-build).
</Note>
This guide covers building an MCP Bundle (`.mcpb`) for internal use, private distribution, or as a foundation for [submission to the Connectors Directory](/docs/connectors/building/submission).
## What is an MCPB?
An `.mcpb` file is a zip archive containing a local MCP server and a `manifest.json`. It enables single-click installation in Claude Desktop, similar to a browser extension.
Key characteristics:
* Runs locally on the user's machine
* Communicates via stdio transport
* Bundles all dependencies
* Works offline
* No OAuth required
See the [MCPB repository](https://github.com/modelcontextprotocol/mcpb) for the complete specification and the [Desktop Extensions blog post](https://www.anthropic.com/engineering/desktop-extensions) for an architecture overview.
## Local (MCPB) vs remote: which to build
| Choose MCPB when you need | Choose a remote connector when you need |
| -------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| Access to systems behind your firewall (JIRA, Confluence, internal wikis, private databases) | Cloud services and public APIs with centralized infrastructure |
| Authentication via existing SSO and browser sessions, no token management | OAuth flows with server-side token management |
| Zero-trust compliance inside corporate network boundaries | Distribution across Claude on web, mobile, and desktop |
| Direct filesystem access for code editing and Git operations | Centralized updates pushed to all users |
| Integration with locally installed tools (Docker, IDEs, databases) | Public-facing integrations used by multiple organizations |
| Hardware integration and desktop application control | |
| Privacy-sensitive operations that should not leave the user's machine | |
| One-click install with bundled Node.js runtime, no dependencies to manage | |
| No cloud infrastructure, VPN configuration, or firewall rules | |
| Organization-level admin controls (custom uploads, allowlists) | |
| Full control over authentication, authorization, and audit logs | |
**Key difference:** MCPBs run on the user's machine via stdio with access to local and internal resources. Remote connectors run on your servers via HTTPS and are accessed through Anthropic's infrastructure.
Organizations commonly build MCPBs as secure proxies to internal MCP servers, for internal documentation access, and to connect development tools while preserving their security architecture.
For remote connector guidance, see [building custom connectors](/docs/connectors/building/index).
## Choose a language
Node.js is strongly recommended:
* Ships with Claude Desktop on macOS and Windows, so users need no separate runtime
* Best compatibility and reliability with Claude Desktop
* Extensive MCP SDK support
## Platform support
Claude Desktop runs on macOS (`darwin`) and Windows (`win32`). Specify supported platforms in the `compatibility` section of your `manifest.json`. Test on both platforms even if you primarily develop on one.
See the [manifest spec compatibility section](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md#compatibility) for platform and runtime requirement details.
## Quickstart
<Steps>
<Step title="Install the MCPB CLI">
```bash theme={null}
npm install -g @anthropic-ai/mcpb
```
</Step>
<Step title="Create your MCP server">
Build a stdio MCP server using the [MCP SDK](https://www.npmjs.com/package/@modelcontextprotocol/sdk).
</Step>
<Step title="Generate the manifest">
```bash theme={null}
mcpb init
```
</Step>
<Step title="Bundle">
```bash theme={null}
mcpb pack
```
</Step>
<Step title="Install and test in Claude Desktop">
Double-click the generated `.mcpb` file.
</Step>
</Steps>
For detailed implementation guidance, see the [MCPB repository](https://github.com/modelcontextprotocol/mcpb), the [examples directory](https://github.com/modelcontextprotocol/mcpb/tree/main/examples) including a Hello World, and the [README "For Bundle Developers" section](https://github.com/modelcontextprotocol/mcpb/blob/main/README.md).
<Warning>
Before distributing your MCPB, review the testing and best-practices guidance in the MCPB README to ensure quality.
</Warning>
## manifest.json
The `manifest.json` file is required metadata describing what your MCPB does, how to run it, which tools it provides, and what configuration it needs.
| Reference | |
| ---------------------------------------------------------------------------------------- | --------------------------- |
| [MCPB Manifest Spec](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md) | Full schema with all fields |
| [Example manifests](https://github.com/modelcontextprotocol/mcpb/tree/main/examples) | Real-world implementations |
| [CLI documentation](https://github.com/modelcontextprotocol/mcpb/blob/main/CLI.md) | Command reference |
## Add an icon
Icons are optional but recommended. Place `icon.png` in your bundle root and reference it in `manifest.json`.
| Requirement | Value |
| ----------- | ----------------------------------------- |
| File name | `icon.png` (or a custom path) |
| Size | 512×512px recommended (minimum 256×256px) |
| Format | PNG with transparency |
| Location | Bundle root or specified path |
You can also provide multiple icon variants for different sizes and themes (light/dark mode). See the [manifest spec icons section](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md#icons) for variant syntax and best practices.
## User configuration
Define a `user_config` section in `manifest.json` and Claude Desktop automatically generates a settings UI for your extension. The [manifest spec user configuration section](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md#user-configuration) covers the full schema, configuration types, validation constraints, sensitive-data handling, and multi-select patterns.
## How users install your MCPB
Users can install three ways:
1. **Double-click** the `.mcpb` file
2. **Drag and drop** the `.mcpb` file into the Claude Desktop window
3. **Settings**: Settings → Extensions → Advanced settings → Install Extension… → select the `.mcpb` file
All three open an installation UI where the user reviews extension details and permissions, configures required settings, grants permissions, and completes installation. Installation is per-user; each user installs separately on their own system.
For the end-user installation experience and Team/Enterprise admin controls (organization management, allowlists, policy configuration), see [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop).
## Resources
**MCPB framework**
* [MCPB repository](https://github.com/modelcontextprotocol/mcpb): complete specification and tools
* [MCPB Manifest Spec](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md): full manifest schema
* [MCPB CLI documentation](https://github.com/modelcontextprotocol/mcpb/blob/main/CLI.md): command reference
* [MCPB examples](https://github.com/modelcontextprotocol/mcpb/tree/main/examples): reference implementations
**MCP protocol**
* [MCP specification](https://modelcontextprotocol.io/docs/getting-started/intro): protocol documentation
* [MCP quickstart](https://modelcontextprotocol.io/docs/develop/build-server): getting-started guide
* [TypeScript SDK](https://github.com/modelcontextprotocol/typescript-sdk): Node.js implementation
* [Python SDK](https://github.com/modelcontextprotocol/python-sdk): Python implementation
**Claude Desktop**
* [Release notes](https://support.claude.com/en/articles/12138966-release-notes): version updates
* [Desktop Extensions blog](https://www.anthropic.com/engineering/desktop-extensions): architecture overview
## Get help
* [MCPB GitHub issues](https://github.com/modelcontextprotocol/mcpb/issues): bug reports and feature requests
* [MCP specification repo](https://github.com/modelcontextprotocol/modelcontextprotocol): protocol questions
* [Claude support](https://support.claude.com/en/articles/9015913-how-to-get-support): general Claude Desktop support
Check repository discussions for community Q\&A, follow release notes for updates, and review the examples for implementation patterns.
## Ready for distribution
If you have a working MCPB and want broader distribution and discoverability, submit it to the Connectors Directory. See [submitting to the directory](/docs/connectors/building/submission) for requirements including:
* Mandatory tool annotations for all tools
* Privacy policy requirements
* Working examples that exercise each tool
* Test credentials where applicable
* The complete submission process and review timeline
connectors/building/review-criteria First recorded · 74 lines, first recorded
# Pre-submission checklist ## Tool design ### Separate read and write tools ### Reference API docs in custom query tools ### Provide tool annotations ### Keep tool names short ### Write narrow, accurate descriptions ## Avoid prompt-injection patterns ## Functional quality ## API ownership ## Unsupported use cases ## Submission requirements ## Before you submit
The first capture of this source. The page was already there, and this is what it said.
# Pre-submission checklist
> What Anthropic reviewers test, so you can pass on the first try
When you submit a server, it is automatically scanned for policy compliance and, by default, listed in the directory as a [community connector](/docs/connectors/verification). Anthropic may then escalate listings flagged as highly useful to Claude users to verified review, which is higher touch and slower; reviewers run a functional test of each tool. This escalation is assessed automatically, and you do not need to take any action. Every server in the directory must meet the criteria on this page, whichever label it carries. The label is a quality signal shown to users; it does not change how your connector runs once connected. This page surfaces the most common rejection reasons so you can self-correct before submitting. For the full legal text, see the [Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy).
## Tool design
### Separate read and write tools
A single tool that accepts both safe HTTP methods (GET, HEAD, OPTIONS) and unsafe methods (POST, PUT, PATCH, DELETE) is rejected. Do not ship a catch-all `api_request` tool with a `method` parameter.
Split into a read-only tool and one or more write tools. Ideally, split write operations further by action type (create, update, delete). Documenting safe versus unsafe operations within one tool's description does not satisfy this requirement—the operations must be in separate tools.
### Reference API docs in custom query tools
If a tool accepts freeform endpoint paths, query strings, or request bodies that the caller constructs, its description must include a link to or explicit name of the target API. For example: "Queries the Slack Web API—see [https://api.slack.com/methods](https://api.slack.com/methods)". A description like "Makes a request to the API" with no further context fails.
This applies only to custom query tools. Purpose-built tools that call a fixed endpoint internally do not need an API docs reference.
### Provide tool annotations
Every tool must include a `title` and the applicable hint—`readOnlyHint: true` for read-only tools, `destructiveHint: true` for tools that modify or delete data. These determine auto-permissions in Claude: read-only tools can run without per-call confirmation; destructive tools always prompt.
### Keep tool names short
Tool names must be 64 characters or fewer.
### Write narrow, accurate descriptions
Each tool description should state precisely what the tool does and when to invoke it. The description must match the tool's actual behavior.
## Avoid prompt-injection patterns
Tool descriptions are rejected if they:
* Instruct Claude to call external software or tools the user didn't request
* Interfere with Claude calling other tools
* Direct Claude to pull behavioral instructions from external sources
* Contain hidden, obfuscated, or encoded instructions
* Tell Claude to behave in ways unrelated to the tool's function, attempt to override system instructions, or promote products and services
Describe what the tool does. Do not tell Claude how to behave.
## Functional quality
* Every tool must return a successful response when called with valid parameters. Generic errors ("Internal Server Error", "Bad Request" with no detail) fail review.
* Validate inputs and return actionable error messages rather than silently accepting invalid data.
* Keep responses reasonably sized for the task. Do not return a full database dump when a summary was requested.
* Do not collect conversation data beyond what the tool needs for its function.
* Do not query Claude's memory, chat history, conversation summaries, or user files.
## API ownership
Your server must call your own first-party APIs, or APIs you legitimately proxy. The MCP server domain should match your service.
## Unsupported use cases
Connectors that do the following are not accepted:
* Transfer money, cryptocurrency, or other financial assets
* Generate images, video, or audio via AI models (design tools that produce diagrams, charts, or UI mockups are allowed)
## Submission requirements
* **Test credentials** are required and must be a fully populated account.
* **Allowed link URIs** are recommended if your server calls `ui/open-link`. Declared HTTPS origins and custom URI schemes open without a confirmation prompt; anything else still prompts the user. See [Allowed link URIs](/docs/connectors/building/submission#allowed-link-uris).
* **Public documentation** is required by your publish date—a blog post or help-center article is sufficient. You can share docs privately with Anthropic during review.
* **Plugins** must link a public GitHub repo; closed-source is not accepted.
* **MCPB** open-source and "spec will evolve" clauses in the [Software Directory Terms](https://support.claude.com/en/articles/13145338-anthropic-software-directory-terms) are required and not waivable.
## Before you submit
Run `claude plugin validate` on plugins. For MCP servers, exercise every tool through the [MCP Inspector](https://modelcontextprotocol.io/docs/tools/inspector) and as a [custom connector in Claude](/docs/connectors/building/testing).
connectors/building/submission First recorded · 172 lines, first recorded
# Submitting to the Connectors Directory ## What you can submit ## Before you start ## Directory terms & conditions ## Submission requirements ## Privacy policy requirements ## Allowed link URIs ## Asset specifications ### Carousel screenshots (MCP Apps) ### Detail card description ## Review process ## Submit your connector ### What to expect in the portal
The first capture of this source. The page was already there, and this is what it said.
# Submitting to the Connectors Directory
> Submit your MCP connector to the Connectors Directory
The [Connectors Directory](/docs/connectors/directory) aims to be a collection of high-quality, vetted, and reviewed MCP servers that are helpful and harmless to users. Anyone is welcome to build MCP servers, but only servers meeting the review standards outlined on this page will be included in the directory.
## What you can submit
Developers can submit:
* **Remote MCP servers** — internet-hosted servers that provide tools and data to Claude
* **Desktop extensions** — local MCP servers packaged as [MCP Bundles (MCPB)](https://github.com/modelcontextprotocol/mcpb) for Claude Desktop
* **[MCP Apps](/docs/connectors/building/mcp-apps/getting-started)** — MCP servers that surface interactive UI elements. These have the additional requirement of including screenshots for submission and listing in the directory.
## Before you start
Remote MCP server submissions happen inside Claude.ai, in the [submission portal](https://claude.ai/admin-settings/directory/submissions/new). The portal is part of your organization's admin settings, so you need:
* **A Team or Enterprise organization.** Admin settings aren't available on individual plans.
* **Directory management access.** By default, only organization Owners and Primary owners can submit and manage directory listings. On Enterprise, an Owner can delegate this to other members by creating a custom role in **Organization settings > Roles** with either the **Directory** permission (directory submissions only) or the **Libraries** permission (broader: it also covers managing the organization's plugins, connectors, and skills), and assigning that role. Team plans don't have custom roles, so on Team this stays with Owners.
Desktop extensions (MCPB) use a separate [submission form](https://clau.de/desktop-extention-submission) and don't require the portal.
## Directory terms & conditions
All servers 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)
By submitting a connector, you also agree to:
* Maintain your connector's security and functionality
* Respond to security issues promptly
* Provide accurate descriptions and documentation
## Submission requirements
All MCP connectors submitted to the directory must meet:
1. **Security**: Meet Anthropic's security standards
2. **Tool annotations**: All tools must include a `title` and the applicable `readOnlyHint` or `destructiveHint`
3. **Authentication**: Use OAuth 2.0 for authenticated services
4. **Privacy Policy**: Local connectors must include privacy policies
5. **Documentation**: Provide clear setup and usage instructions
If your connector opens external links, also provide your [allowed link URIs](#allowed-link-uris) so users aren't prompted to confirm each one.
## Privacy policy requirements
Local connectors must include:
1. "Privacy Policy" section in README.md
2. `privacy_policies` array in manifest.json (manifest\_version 0.2+)
3. HTTPS URLs to privacy policies
The privacy policy must cover:
* Data collection practices
* Usage and storage
* Third-party sharing
* Data retention
* Contact information
<Warning>
Missing or incomplete privacy policies result in immediate rejection.
</Warning>
## Allowed link URIs
If your connector uses the `ui/open-link` capability to open URLs in the user's browser or native apps, provide the list of link targets your server will request. Claude uses this list to suppress the "Open external link" confirmation prompt for destinations you've declared. Links to any other destination still work—users are simply asked to confirm before the link opens.
Provide each entry in one of two forms:
* **HTTPS origin** — `https://example.com`. Only the scheme and hostname are matched; paths, ports, and query strings are ignored. Subdomains are not implied—list each one (`https://app.example.com`, `https://docs.example.com`).
* **Custom URI scheme** — `myapp:` for deep links into a native app you own (for example, `spotify:` or `notion:`). Only the scheme is matched.
Every origin and scheme you list **must be owned by you** (the submitting organization). You may not list third-party domains or URI schemes registered to apps you don't publish. Entries you don't own will be removed during review.
<Note>
This field is optional. If omitted, your connector functions normally, but users are shown a confirmation prompt each time it opens a link.
</Note>
## Asset specifications
### Carousel screenshots (MCP Apps)
* **Format:** PNG
* **Width:** at least 1000px
* **Count:** 3–5 images
* **Crop:** to the app response only—**do not include the prompt** in the image
* **Aspect ratio:** any
* **Paired prompts:** provide the prompt text separately for each screenshot
* **Mobile:** no separate mobile assets are required—one batch covers all surfaces
* **Video/GIF:** not accepted
A carousel template is available in the [Anthropic MCP Apps Figma community file](https://www.figma.com/community/file/1597641111449594397/mcp-apps-for-claude).
### Detail card description
You write the detail card description in the submission portal. It is not editable by Anthropic. The disclaimer text shown on connector cards is general and not customizable per partner.
## Review process
Review times vary with queue volume. The submission portal is always open.
After you submit, track your submission's status and read reviewer feedback in the [submissions dashboard](https://claude.ai/admin-settings/directory/submissions). See [Managing your listing](/docs/connectors/building/managing-your-listing) for what's available there, including server health and usage metrics after publication. Email `[email protected]` for escalations.
Run the [pre-submission checklist](/docs/connectors/building/review-criteria) and, for plugins, `claude plugin validate` before you submit.
## Submit your connector
Ready to submit? Use the path that matches your connector type:
* **Remote MCP servers (including MCP Apps)**: submit through the [submission portal](https://claude.ai/admin-settings/directory/submissions/new) in Claude.ai admin settings. See [Before you start](#before-you-start) for access requirements.
* **Desktop extensions (MCPB)**: use the [desktop extension submission form](https://clau.de/desktop-extention-submission).
Skills are not a standalone submission type—bundle them in a [plugin](/docs/plugins/submit).
### What to expect in the portal
Before you start, have your documentation URL, privacy policy URL, icon, and test account credentials ready, plus carousel screenshots if you're submitting an MCP App (see [asset specifications](#asset-specifications) above).
The portal walks you through the following steps. Your progress saves automatically in your browser as you move between steps, so within a browser session you can jump back to earlier steps without losing work.
<Steps>
<Step title="Introduction">
Explains what a directory listing does and doesn't do: inclusion makes your connector discoverable but doesn't change the tools it exposes. The portal accepts remote MCP servers only. Local servers are distributed as [desktop extensions](https://clau.de/desktop-extention-submission) or [plugins](/docs/plugins/submit) instead.
</Step>
<Step title="Connection">
Connect the server you're submitting. You confirm the server URL (must be `https://`), the transport (streamable HTTP or SSE), and whether every user connects to the same URL or different users connect to different URLs.
</Step>
<Step title="Tools">
Your server's tools, prompts, and resources sync automatically from the connected server, grouped by whether their annotations declare them read-only or write (tools without annotations are grouped separately). If any tools are flagged for missing titles or annotations, fix them on your server before submitting.
</Step>
<Step title="Listing">
The public-facing listing: server name (100 characters max), tagline (55 characters max), description (2,000 characters max), one to five categories, documentation URL, privacy policy URL, support contact, icon, and the URL slug for your listing page. The slug is permanent once published.
</Step>
<Step title="Use cases">
Describe the primary use cases, what users need before they can connect (accounts, plans, or other setup), and whether the connector reads data, writes data, or both.
</Step>
<Step title="Company">
Company name and website, plus a primary contact for review updates. The contact name and email are pre-filled from your account.
</Step>
<Step title="Authentication">
How users authenticate: OAuth (with dynamic client registration, client ID metadata documents, or a static client ID held by Anthropic), a custom connection where users supply their own URL or credentials at connection time, or no authentication. See [authentication](/docs/connectors/building/authentication) for which modes are supported out of the box and which need coordination with the review team. If your server starts without authentication and individual tools prompt for it on demand, you can flag that here.
</Step>
<Step title="Data handling">
Whether the underlying API is your own, proxied from a partner with permission, or a third party's you don't control, and whether the connector handles personal health data or sponsored content.
</Step>
<Step title="Test & launch">
Test-account setup and access instructions detailed enough for a reviewer to access your server end to end: every link, credential, and step, including credentials for a fully populated account where relevant. You also confirm you've run every tool yourself, either via MCP Inspector or as a custom connector in Claude.
</Step>
<Step title="Compliance">
Seven policy acknowledgments covering the directory guidelines, first-party API usage, financial transactions, AI media generation, prompt injection, conversation data collection, and public documentation. All seven are required.
</Step>
<Step title="Review">
A final read-through of everything you've entered. Any quality warnings (for example, very short answers) are shown here and shared with the review team alongside your submission. Submit when you're ready.
</Step>
</Steps>
After you submit, your submission's status and any reviewer feedback appear in the [submissions dashboard](https://claude.ai/admin-settings/directory/submissions). See [Managing your listing](/docs/connectors/building/managing-your-listing).
connectors/building/testing First recorded · 43 lines, first recorded
# Testing your connector ## Test as a custom connector ## Test a local server ## Validate with MCP Inspector ## Detect Claude as the client ## Prepare test credentials for review ## Debugging
The first capture of this source. The page was already there, and this is what it said.
# Testing your connector
> Test your MCP server against Claude before submitting to the directory
Test your server against the real Claude client before submitting. There is no separate staging environment—you test in production using a custom connector.
## Test as a custom connector
Any Claude account (Free, Pro, Max, Team, or Enterprise) can add a custom connector. Go to **Customize > Connectors**, select **Add custom connector**, and enter your server's URL. Custom connectors use the exact same runtime as directory connectors, so what works here will work after publication.
## Test a local server
To test a server running on your machine, expose it as a public URL with a tunnel such as [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) or `ngrok`, then add the tunnel URL as a custom connector. This is the recommended pattern for iterating on MCP Apps as well.
<Warning>
A tunnel exposes your local server to the public internet. Keep authentication enabled on your server while tunneling, and shut the tunnel down when you're done testing.
</Warning>
## Validate with MCP Inspector
Use the [MCP Inspector](https://modelcontextprotocol.io/docs/tools/inspector) to verify protocol compliance, exercise your auth flow, and inspect tool schemas before connecting to Claude.
## Detect Claude as the client
Claude identifies itself in the MCP `initialize` handshake via `clientInfo`, but the exact value depends on the surface and the request path. You may see `"name": "claude-ai"`, `"name": "Anthropic"` (sometimes with a service suffix), or `"name": "claude-code"`:
```json theme={null}
{ "clientInfo": { "name": "Anthropic", "version": "1.0.0" } }
```
Don't gate behavior on an exact `name` or `version` string — both vary across surfaces, request paths, and releases. Use `clientInfo` for telemetry and coarse feature detection only, and remember it's unauthenticated: any client can claim any name, so it must never feed an authorization decision.
## Prepare test credentials for review
Directory submission requires test credentials. Provide a **fully populated account**—not an empty shell—so reviewers can exercise real functionality (list real records, search real data, exercise write tools on real resources). Include step-by-step setup instructions for someone unfamiliar with your service.
## Debugging
Partner-visible error logs are in development. In the meantime, use server-side logging on your end and the MCP Inspector to diagnose connection failures. Common causes of `initialize` timeouts include slow OAuth endpoints (keep discovery, registration, and token responses under ten seconds; see [endpoint latency](/docs/connectors/building/authentication#endpoint-latency)), overly strict `Origin`-header validation rejecting Anthropic's requests, and firewalls dropping Anthropic's egress traffic.
If your infrastructure logs show `403 Forbidden` responses your application didn't generate, your CDN or WAF is likely blocking Anthropic's traffic. See [firewall or WAF blocks Anthropic's traffic](/docs/connectors/building/troubleshooting#2-firewall-or-waf-blocks-anthropic%E2%80%99s-traffic) for the fix.
For a structured walkthrough of "Couldn't reach the MCP server" and "Authorization failed" errors, including DNS resolution checks, OAuth discovery diagnostics, and how to find the `ofid_` reference ID to include in a support request, see [troubleshooting connectors](/docs/connectors/building/troubleshooting).
connectors/building/troubleshooting First recorded · 162 lines, first recorded
# Troubleshooting connectors ## Find your reference ID ## "Couldn't reach the MCP server" ### 1. Hostname resolves to a private IP ### 2. Firewall or WAF blocks Anthropic's traffic ### 3. Your server URL redirects to a different host ### 4. OAuth discovery fails ## "Authorization with the MCP server failed" ### Microsoft Entra ID rejects the resource value ## Diagnostic checklist ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Troubleshooting connectors
> Diagnose and resolve common connection failures for custom and directory MCP connectors
This page covers the most common reasons a connector fails to connect or authenticate, and how to diagnose each one. The errors Claude shows in the UI ("Couldn't reach the MCP server" and "Authorization with the MCP server failed") cover more than one root cause, so the first step is figuring out which one you're hitting.
## Find your reference ID
When a connection fails, the error toast and the page URL include a reference ID that starts with `ofid_`. For example:
```text theme={null}
.../customize/connectors?step=start_error&flow_id=ofid_d32594c73257a651
```
Copy that ID and include it in any GitHub issue or support request. It lets Anthropic trace the exact failure on the server side. Reference IDs are time-limited, so report them soon after the failure.
<Tip>
If you're filing on the [`anthropics/claude-ai-mcp` issue tracker](https://github.com/anthropics/claude-ai-mcp/issues), include the `ofid_` value, your server URL, and what your server-side access logs show during the Connect attempt.
</Tip>
## "Couldn't reach the MCP server"
This error appears when Claude can't complete the connection handshake. Despite the wording, it isn't always a network failure. Work through these causes in order.
### 1. Hostname resolves to a private IP
claude.ai connectors run on Anthropic's infrastructure and reach your server over the public internet. Before making any request, Claude resolves your server's hostname and validates the result. If **any** resolved address is not globally routable, Claude rejects the connection before any HTTP request leaves Anthropic's network. Your server's access logs see nothing, and Claude reports "Couldn't reach."
Claude rejects the connection when the hostname:
* resolves to a private address (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`)
* resolves to a carrier-grade NAT address (`100.64.0.0/10`)
* resolves to a loopback or link-local address
* resolves to a mix of public and non-public addresses — every returned address must be globally routable
* has no `A` record from public DNS — connectors are IPv4-only, so a hostname that only publishes `AAAA` records can't be reached
**Common gotchas:**
* **Works in Claude Code or `curl` but not claude.ai.** The CLI and `curl` connect from your machine, while claude.ai connects from Anthropic's servers. If your hostname resolves differently inside and outside your network (split-horizon DNS), claude.ai may be getting a private IP.
* **Dynamic DNS providers.** Dynamic DNS hostnames often resolve to a home network behind NAT or carrier-grade NAT.
* **Internal corporate DNS.** A hostname that resolves on your VPN won't resolve to a routable address from the public internet.
**How to check:** Run `dig +short your-server.example.com` from a machine outside your network, or use a public DNS lookup service. Every returned address must be globally routable.
**How to fix:** Expose your server through a publicly-routable endpoint, such as a cloud host with a public IP, a public reverse proxy, or a tunnel. See [test a local server](/docs/connectors/building/testing#test-a-local-server) for the recommended tunnel setup.
### 2. Firewall or WAF blocks Anthropic's traffic
If your hostname resolves correctly but a CDN, WAF, bot-management rule, or rate limiter in front of your server blocks the request, the connection fails before your application sees it.
**How to check:** Look for `403` or `429` responses in your edge or CDN logs that your application didn't generate, especially during a Connect attempt.
**How to fix:** Allowlist Anthropic's published outbound IP range in your WAF or CDN configuration, or exempt your MCP and OAuth paths from the blocking rule. The current range is on the [IP address reference](https://platform.claude.com/docs/en/api/ip-addresses) page.
### 3. Your server URL redirects to a different host
If your registered MCP URL returns a `301`/`302`/`307`/`308` redirect to a different host (apex to `www.`, region routing, vanity domain to CDN), the `Authorization` header is dropped on the redirect per standard HTTP client security behavior. The redirect target receives an unauthenticated request and returns `401`, and the connection fails with "Authorization with the MCP server failed."
This also explains the common report "works in MCP Inspector or Claude Code CLI but not claude.ai." Local clients fail fast on a redirect, so the misconfiguration is visible immediately. claude.ai follows the redirect, drops the credential, and the failure surfaces later as an authorization error.
**How to check:** Run `curl -sI https://your-server.example.com/your-mcp-path` and look at the response status and `Location` header. If you see a `3xx` status pointing at a different host, that target is the URL you should register.
**How to fix:** Register the URL your server actually listens on, not a URL that redirects to it. Common culprits are apex-to-`www.` canonicalization, geographic or region routing, and vanity-domain-to-CDN redirects.
### 4. OAuth discovery fails
If your server requires authentication, Claude performs OAuth discovery before it can connect. A discovery failure surfaces as "Couldn't reach" even though your MCP endpoint itself is reachable. The most common causes:
* **Discovery metadata returns 404.** If your `401` response doesn't include a `WWW-Authenticate` header with a `resource_metadata` pointer, Claude looks for [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728) protected resource metadata and authorization server metadata at the standard `/.well-known/` paths on your MCP server's origin. If those paths return `404` and you haven't pointed Claude elsewhere, Claude has no way to start the OAuth flow.
* **No way to register a client.** Claude needs one of: [RFC 7591 dynamic client registration](https://www.rfc-editor.org/rfc/rfc7591) (a `registration_endpoint` in your authorization server metadata), [Client ID Metadata Documents](/docs/connectors/building/authentication#dcr-and-cimd-details) (`"client_id_metadata_document_supported": true`), or a pre-registered client. Without any of these, Claude can't obtain a client identity. See [supported authentication types](/docs/connectors/building/authentication#supported-authentication-types).
* **Authorization server is on a different host than the MCP server.** Claude discovers protected resource metadata from your MCP server, then makes a *second* round of discovery requests against the authorization server host listed in `authorization_servers`. If that host lives behind a different CDN or WAF, it must also be reachable from Anthropic's egress range. See [cross-host authorization servers](/docs/connectors/building/authentication#cross-host-authorization-servers).
**How to check:** From a public network, run:
```bash theme={null}
curl -i https://your-server.example.com/.well-known/oauth-protected-resource
curl -i https://your-server.example.com/.well-known/oauth-authorization-server
curl -i https://your-server.example.com/.well-known/openid-configuration
```
If your MCP endpoint includes a path component (such as `https://your-server.example.com/mcp`), append it to the well-known path: `/.well-known/oauth-protected-resource/mcp`.
The protected resource metadata should return `200` with valid JSON. For authorization server metadata, your server only needs to answer **one** of the two discovery endpoints — Claude tries `/.well-known/oauth-authorization-server` ([RFC 8414](https://www.rfc-editor.org/rfc/rfc8414)) first, then falls back to `/.well-known/openid-configuration` ([OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)). A `404` on one is expected if the other returns `200`. Most hosted identity providers (Auth0, Okta, Microsoft Entra, Keycloak, Supabase Auth) only serve `/.well-known/openid-configuration`.
Whichever metadata document resolves should advertise a `registration_endpoint` (DCR), `"client_id_metadata_document_supported": true` (CIMD), or you should be using pre-registered credentials. In a cross-host setup, run the protected-resource curl against your MCP server and the two authorization-server curls against your authorization server's issuer host.
## "Authorization with the MCP server failed"
This error appears after the OAuth flow has started. The most common causes:
* **Issuer mismatch.** The `issuer` value in your authorization server metadata must match the issuer that signs your tokens. If your tokens come from a third-party identity provider such as Supabase Auth or Auth0 but your metadata advertises a different issuer URL, validation can fail.
* **Audience mismatch.** The [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-handling) requires your server to verify each access token was issued for it. Claude sends the [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707) `resource` parameter on authorization and token requests, set to the canonical form of your MCP server URL — lowercase scheme and host, no trailing slash, no fragment, no default port — including any path component. Your authorization server should issue tokens with that audience, and your MCP server should accept the canonical value when checking `aud` rather than doing a strict byte-for-byte comparison against what the user typed. Or use whatever audience-binding mechanism your token format supports, as long as it confirms the token was minted for your server and not another service.
* **PKCE not supported.** Claude includes a PKCE `code_challenge` with `code_challenge_method=S256` in every authorization request. If your authorization server doesn't implement S256 PKCE, the flow fails at the token endpoint. The [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-code-protection) also requires authorization servers to advertise `"code_challenge_methods_supported": ["S256"]` so spec-compliant clients can verify support before starting the flow.
* **Refresh failures.** Use RFC 6749-compliant error codes when a refresh token expires. See [token refresh](/docs/connectors/building/authentication#token-refresh).
* **Slow token endpoint.** Claude waits up to 10 seconds for your `/token` response; if no response bytes arrive in that window, the flow fails here even if your server eventually issues the token. Check the end-to-end latency of your token handler and any proxy or gateway in front of it. See [endpoint latency](/docs/connectors/building/authentication#endpoint-latency).
### Microsoft Entra ID rejects the resource value
If your authorization server is Microsoft Entra ID and the token request fails with `AADSTS9010010` (sometimes surfaced as `invalid_target`), Entra is rejecting the `resource` value Claude sends because it does not match any Application ID URI registered on your app. Claude sets `resource` to your MCP server URL, including the path, and Entra issues a token when that value is listed under **Expose an API** → **Application ID URI** (`identifierUris` in the manifest) on the app registration that represents your protected API. The default `api://{client-id}` URI alone is not sufficient here, because Claude sends the full MCP server URL as the resource value.
**How to fix:**
1. In the [Microsoft Entra admin center](https://entra.microsoft.com), open the app registration that represents your protected API. If you have separate registrations for the OAuth client and the API, this is the API registration, not the client.
2. Under **Expose an API**, add your MCP server URL as an additional [Application ID URI](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-configure-app-expose-web-apis). The value must match exactly, including the path, without a trailing slash.
3. If your server validates the token audience (for example, through Azure App Service Authentication), add the API app's Application (client) ID and its `api://` URI to the allowed token audiences so your server accepts tokens issued for the API. This is the **Allowed token audiences** setting, not **Allowed client applications**, which is a different list.
4. If the OAuth client and the API are separate app registrations, confirm the client has an admin-consented API permission for the scope your API exposes.
If the OAuth flow completes successfully on your server (you see the token issued in your logs) but the connection still fails, file a [GitHub issue](https://github.com/anthropics/claude-ai-mcp/issues) with the `ofid_` reference ID and the timestamps from your server's OAuth logs.
## Diagnostic checklist
Run through these in order before filing an issue:
<Steps>
<Step title="Public DNS resolution">
From a network outside your own, confirm `dig +short your-server.example.com` returns a globally-routable address.
</Step>
<Step title="Public reachability">
From a public network, confirm `curl -i https://your-server.example.com/your-mcp-path` returns a response (a `401` or `405` is fine; a timeout or connection refused is not).
</Step>
<Step title="No redirect">
Run `curl -sI https://your-server.example.com/your-mcp-path` and confirm the response is not a `3xx` redirect to a different host. If it is, register the redirect target instead.
</Step>
<Step title="No WAF block">
Check your edge logs for `403` or `429` responses. Allowlist Anthropic's published egress range if needed. See the [IP address reference](https://platform.claude.com/docs/en/api/ip-addresses).
</Step>
<Step title="Discovery metadata">
Confirm `/.well-known/oauth-protected-resource` returns `200` with valid JSON, and that one of `/.well-known/oauth-authorization-server` or `/.well-known/openid-configuration` does the same — only one is needed. The authorization server metadata should include a `registration_endpoint` (DCR) or advertise `"client_id_metadata_document_supported": true` (CIMD), or you should be using pre-registered credentials, and it should advertise `"code_challenge_methods_supported": ["S256"]`.
</Step>
<Step title="Cross-host hint">
If your authorization server is on a different host than your MCP server, confirm your protected resource metadata's `authorization_servers` field points at it, and that the authorization server's host is reachable from Anthropic's egress range and answers `/.well-known/openid-configuration` (or `/.well-known/oauth-authorization-server`). See [cross-host authorization servers](/docs/connectors/building/authentication#cross-host-authorization-servers).
</Step>
<Step title="Collect the reference ID">
Reproduce the failure and copy the `ofid_` value from the error URL. Include it, your server URL, and your server-side logs in your report.
</Step>
</Steps>
## Related topics
<Columns cols={2}>
<Card title="Authentication" icon="lock" href="/docs/connectors/building/authentication">
OAuth requirements and supported auth types.
</Card>
<Card title="Testing" icon="flask" href="/docs/connectors/building/testing">
How to test your server before publishing.
</Card>
<Card title="Lazy authentication" icon="hourglass" href="/docs/connectors/building/lazy-authentication">
The 401 + WWW-Authenticate discovery handshake.
</Card>
<Card title="IP address reference" icon="network-wired" href="https://platform.claude.com/docs/en/api/ip-addresses">
Anthropic's published IP ranges for allowlisting.
</Card>
</Columns>
connectors/building/what-to-build First recorded · 59 lines, first recorded
# What should I build: MCP, plugin, or both? ## The recommendation ## When to build only one ## What a plugin can bundle ## How they coexist ## Skills are not a standalone directory type ## Build it with Claude ## Next steps
The first capture of this source. The page was already there, and this is what it said.
# What should I build: MCP, plugin, or both?
> Decide between an MCP server, a plugin, or both for your Claude integration
Most partners ship two things: a remote MCP server and a plugin that wraps it. They serve different purposes, and together they give users the best experience.
## The recommendation
Build a **remote MCP server with OAuth** first to provide connectivity and core functionality. Then create a **plugin with skills** that helps users get the most out of that MCP server.
| | MCP server | Plugin |
| ---------------- | ------------------------------------------------ | ------------------------------------------------ |
| **What it is** | A live tool surface Claude calls over HTTP | An installable bundle of skills and connectors |
| **Mental model** | "Claude can call your API" | "Claude knows how to *use* your product" |
| **Contains** | Tools, prompts, resources, optionally MCP App UI | Skills, MCP connector references, slash commands |
| **Works in** | Claude.ai, Desktop, mobile, Cowork, Claude Code | Claude Code, Cowork |
## When to build only one
**MCP server only** is fine when your integration is simple and doesn't need skills—a few well-named tools that Claude can use without additional guidance.
**Plugin only** is fine when you already have a public API or CLI that doesn't need an MCP wrapper. A plugin can ship skills that teach Claude to use that API or CLI directly.
## What a plugin can bundle
A plugin can contain any combination of:
* Skills only
* A single MCP connector reference
* Skills plus one or more MCP connectors
* Multiple MCP connectors
Plugins can reference both remote and local MCP servers. A remote MCP works on every Claude surface (web, mobile, Cowork, Desktop, Claude Code); a local MCP works only in Claude Desktop and Claude Code. Most MCP servers are remote.
## How they coexist
A plugin references a remote MCP server by **URL**. If a user has both your directory connector and your plugin installed, Claude sees one set of tools—the plugin and the connector point at the same server. If a plugin references an MCP URL that isn't in the directory, the connector appears as **Custom** in the user's settings.
Both MCP servers and plugins can update without Anthropic involvement. When you add tools to your MCP server, plugins that reference it pick them up automatically. Plugin updates are pushed via GitHub and pass through automated screening.
## Skills are not a standalone directory type
Skills are user-shared micro-workflows. **Plugins are the distribution mechanism for skills**—you can't submit a skill to the directory on its own. If you have skills to ship, bundle them in a plugin.
## Build it with Claude
The fastest way to scaffold an MCP server is with Claude itself. Install the official [`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev) in Claude Code and run `/mcp-server-dev:build-mcp-server`—it interviews you about your use case, picks the right deployment model, and generates a working server.
## Next steps
<Columns cols={2}>
<Card title="Build an MCP server" icon="server" href="/docs/connectors/building/index">
Start with the MCP building guide.
</Card>
<Card title="Build a plugin" icon="puzzle-piece" href="/docs/plugins/overview">
Bundle skills and connectors together.
</Card>
</Columns>
connectors/custom/desktop-extensions First recorded · 82 lines, first recorded
# Desktop extensions ## What are desktop extensions? ## MCPB (MCP Bundles) ### Key features ## When to use desktop vs remote ## Enterprise deployment ## Security considerations ## Getting started ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Desktop extensions
> Deploy enterprise-grade MCP servers with MCPB
Desktop extensions allow you to deploy local MCP servers for Claude Desktop with enterprise-grade features using MCPB (MCP Bundles).
<Note>
Available for Team and Enterprise plans with Claude Desktop.
</Note>
## What are desktop extensions?
Desktop extensions are local MCP servers that run on user devices, providing:
* Local tool access without internet dependency
* Enhanced security for sensitive operations
* Custom integrations for internal tools
* Enterprise deployment capabilities
## MCPB (MCP Bundles)
MCPB is Anthropic's utility for building and deploying desktop extensions:
* Package MCP servers for distribution
* Handle cross-platform compatibility
* Manage dependencies
* Support enterprise deployment
### Key features
* **Bundling**: Package your MCP server with all dependencies
* **Distribution**: Deploy to users via your organization's channels
* **Updates**: Manage version updates centrally
* **Security**: Sign and verify extensions
## When to use desktop vs remote
| Use Case | Recommended |
| --------------------------- | ----------------- |
| Access to local files/tools | Desktop Extension |
| Internet-hosted services | Remote MCP |
| Sensitive enterprise data | Desktop Extension |
| Public APIs | Remote MCP |
| Offline capability needed | Desktop Extension |
## Enterprise deployment
For Team and Enterprise plans, admins can:
1. Build custom desktop extensions
2. Package with MCPB
3. Deploy through enterprise software management
4. Control which extensions are available to users
## Security considerations
Desktop extensions run locally with user permissions:
* Access only what the user can access
* No data transmitted unless explicitly designed
* Full audit capability for enterprise
* Revocable by administrators
## Getting started
1. Review the [MCPB documentation](https://github.com/modelcontextprotocol/mcpb)
2. Build your MCP server
3. Bundle with MCPB
4. Test locally
5. Deploy to your organization
## Related topics
<Columns cols={2}>
<Card title="Building Connectors" icon="hammer" href="/docs/connectors/building/">
Learn to build MCP servers.
</Card>
<Card title="Remote MCP" icon="globe" href="/docs/connectors/custom/remote-mcp">
Using cloud-hosted connectors.
</Card>
</Columns>
connectors/custom/remote-mcp First recorded · 148 lines, first recorded
# Third party connectors with remote MCP ## What are third party connectors? ### Finding connectors ## Adding custom connectors ### For Team and Enterprise plans ### For Free, Pro, and Max plans ### Enabling connectors in chat ## Authenticating with request headers ### Adding a request header ### Enter the full header value ## Managing connectors ## Security and privacy ### Best practices ### Tool actions ## Reporting issues ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Third party connectors with remote MCP
> Connect Claude to your tools using the Model Context Protocol
Custom connectors enable you to link Claude directly to your essential tools and data sources using the Model Context Protocol (MCP).
## What are third party connectors?
Custom connectors allow Claude to operate within your preferred software and leverage comprehensive context from your external tools.
You can:
* Connect Claude to existing remote MCP servers
* Build your own remote MCP servers for any tool
### Finding connectors
Browse the [Connectors Directory](/docs/connectors/directory) to discover third-party MCP servers that are ready to use across all Claude products. Some are verified by Anthropic and others are community connectors; see [connector verification](/docs/connectors/verification).
## Adding custom connectors
You can manually add any third-party connector to Claude as long as you have the URL of that remote MCP server.
<Warning>
**Security Notice**: Custom connectors allow connections to unverified services. Claude can access and perform actions within these services, so review security considerations carefully.
</Warning>
### For Team and Enterprise plans
**Owners must:**
1. Navigate to **Organization settings > Connectors**
2. Select **Add**, then **Custom**. If Claude asks for the connector type, choose **Web**.
3. Enter the remote MCP server URL
4. Optionally configure OAuth Client ID/Secret in Advanced settings
5. Click "Add"
**Members then:**
1. Go to **Customize > Connectors**
2. Find the connector with "Custom" label
3. Click "Connect" to authenticate
### For Free, Pro, and Max plans
1. Navigate to **Customize > Connectors**
2. Click "Add custom connector"
3. Enter the remote MCP server URL
4. Optionally configure OAuth credentials
5. Click "Add"
### Enabling connectors in chat
Use the "+" button in your chat interface to access "Connectors," where you can enable/disable connectors per conversation.
## Authenticating with request headers
<Note>
Request header authentication is in beta. This feature is being slowly rolled out to customers; contact Anthropic for early access.
</Note>
If your MCP server authenticates with an API key, bearer token, or other fixed credential instead of OAuth, you can configure it in the **Request headers** section of the Add custom connector dialog. Claude stores each header value securely, does not show it again after you save, and sends it on every request to your server.
Request headers suit services where everyone in your organization shares one credential, such as an internal tool or a service account. If each person needs to sign in with their own account, use OAuth instead.
You can also use request headers in addition to OAuth, including OAuth with your own pre-registered client credentials. Headers configured on an OAuth connection are sent on every request alongside the OAuth bearer token. This is useful for verifying where a request came from, passing additional client metadata, or working with tunnels and gateways that need their own routing header. The one exception is `Authorization`: OAuth owns that header, so it cannot be configured as a request header on an OAuth connection.
### Adding a request header
1. In the Add custom connector dialog, open **Request headers**.
2. Select a header name from the list, or enter one manually. Claude accepts a fixed set of standard authentication and routing header names such as `authorization`, `x-api-key`, and `x-auth-token`. Header names are restricted to this allowlist for security reasons: each name is reviewed before Claude will send it to a third-party server, which prevents connector configuration from being used to send arbitrary header names. To request an addition to the allowlist, contact your Anthropic representative.
3. Enter the header value exactly as your server expects to receive it.
4. Choose whether the header is **Required**. When a required header has no stored value at connection time, the connection fails. When an optional header has no value, Claude simply omits it from the request.
5. Repeat for any additional headers your server needs (you can add up to four), then click **Add**.
### Enter the full header value
Claude sends the value exactly as you enter it. It does not add an authentication scheme or any other prefix.
For an `Authorization` header, include the scheme in the value:
| You enter | Claude sends |
| ------------------- | ---------------------------------- |
| `Bearer your-token` | `Authorization: Bearer your-token` |
| `your-token` | `Authorization: your-token` |
Most servers that use bearer tokens reject the second form. If your server's documentation shows `Authorization: Bearer YOUR_TOKEN`, enter `Bearer ` followed by your token, including the space. The same applies to Basic authentication: enter `Basic ` followed by the base64-encoded credentials.
## Managing connectors
To remove or edit connectors:
1. Go to **Customize > Connectors**
2. Click "Remove" or select the three-dot menu
3. Follow prompts to edit or remove
## Security and privacy
### Best practices
* Only connect to servers from trusted organizations
* Carefully review requested permission scopes during authentication
* Be aware of prompt injection risks; Claude has built-in protections
* Monitor for unexpected changes in tool behavior
### Tool actions
Remote MCP servers enable Claude to invoke tools that can:
* Read data from applications
* Create, modify, or delete data
* Take actions on your behalf
**Usage guidelines:**
* Monitor Claude's actions for unintended effects
* Review tool approval requests carefully
* Only click "Always allow" for trusted servers
* Turn off connectors you aren't using with the toggles in the chat "+" menu's **Connectors** item
* Block individual tools you don't need under **Customize > Connectors** by selecting the connector and setting the tool's permission to **Blocked**
## Reporting issues
Report malicious MCP servers to [Anthropic's Bug Bounty Program](https://www.anthropic.com/responsible-disclosure-policy).
## Related topics
<Columns cols={2}>
<Card title="Building Connectors" icon="hammer" href="/docs/connectors/building/">
Learn to build your own MCP servers.
</Card>
<Card title="Connectors Directory" icon="book" href="/docs/connectors/directory">
Browse pre-built connectors.
</Card>
<Card title="MCP Overview" icon="plug" href="/docs/connectors/building/mcp">
Understand the Model Context Protocol.
</Card>
<Card title="Desktop Extensions" icon="desktop" href="/docs/connectors/custom/desktop-extensions">
Deploy enterprise-grade MCP servers.
</Card>
<Card title="MCP in Claude Code" icon="terminal" href="https://code.claude.com/docs/en/mcp-quickstart">
Add the same server to Claude Code from the command line.
</Card>
</Columns>
connectors/directory First recorded · 65 lines, first recorded
# Connectors directory ## How the directory works ## Browsing the directory ## Requesting a connector on a Team plan ## When a connector's endpoint changes ## Submitting to the directory ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Connectors directory > Browse verified and community MCP integrations for Claude The Connectors Directory is a catalog of [MCP](/docs/connectors/building/mcp) servers that work across all Claude products — Claude.ai, Claude Desktop, Claude Mobile, Claude Code, and Cowork. The directory contains both verified connectors and community connectors. Verified connectors are reviewed by Anthropic for security, reliability, and compatibility. Community connectors pass Anthropic's automated checks but are not reviewed in depth by Anthropic. The label reflects how much review a connector has had, not how it works: verified and community connectors work the same way once connected. See [connector verification](/docs/connectors/verification) to learn what each label means. <Note> All connectors in the directory are subject to the [Anthropic Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy) and the [Anthropic Software Directory Terms](https://support.claude.com/en/articles/13145338-anthropic-software-directory-terms). </Note> ## How the directory works * The same catalog serves Claude.ai, Cowork, Desktop, mobile, and Claude Code. * Directory connectors are eligible for **Suggested Connectors**—in-chat recommendations when relevant to the user's task. Every directory entry is included automatically. * Ranking is usage-based, similar to other app stores. * No domain-ownership proof (DNS or `.well-known`) is required—that requirement applies only to the open MCP Registry, not the Anthropic Directory. * The help-docs link shown in the in-product connector setup flow is not partner-customizable. Directory connectors and custom connectors run on the same infrastructure—see [directory vs custom](/docs/connectors/building/directory-vs-custom). ## Browsing the directory Access the Connectors Directory through: * **[Customize > Connectors](https://claude.ai/customize/connectors)** in claude.ai * **[Organization settings > Connectors](https://claude.ai/admin-settings/connectors)** for Team/Enterprise admins ## Requesting a connector on a Team plan On Claude Team plans, members who do not have permission to enable connectors see a **Request** button on each directory connector instead of a connect action. Selecting **Request** sends the connector to your organization's admins for review. The button changes to **Requested** while the request is pending. If you are a Team admin with permission to manage connectors, member requests appear in two places: * **[Organization settings > Connectors](https://claude.ai/admin-settings/connectors)** shows a **Requested by your team** section above the connector list. * **[Organization settings > Notifications](https://claude.ai/admin-settings/notifications)** lists each requested connector on the **Requests** tab, and the **Notifications** item in the admin sidebar shows a count badge while requests are pending. From either location you can enable the connector for your organization or dismiss the request. Claude shows the requesting member the outcome the next time they open the connectors directory. ## When a connector's endpoint changes Occasionally a provider updates the endpoint URL behind its directory listing, for example moving a server from `https://mcp.example.com/sse` to `https://mcp.example.com/mcp`. This is a routine change on the provider's side. Here is what you may notice in Claude: * **Your existing connection keeps working.** Connectors you added before the change keep using the endpoint they were installed with, and your authentication is unaffected. * **It appears as a custom connector.** Because your connector no longer matches the updated directory listing, it shows under "Custom" in [Customize > Connectors](https://claude.ai/customize/connectors) instead of as a named directory connector. * **The directory listing shows as not installed.** Adding the connector from the directory again without removing the original gives you two connections: your original one and a new one on the updated endpoint. To move to the new endpoint, remove the connector and re-add it from the directory. Claude prompts you to authenticate with the service again. ## Submitting to the directory Organizations can submit their MCP servers for review and inclusion in the directory: 1. Review the [submission guidelines](/docs/connectors/building/submission) 2. Ensure your server meets security and compatibility standards 3. Submit through the [submission portal](https://claude.ai/admin-settings/directory/submissions/new) in Claude.ai admin settings Submitting requires a Team or Enterprise organization and directory management access (organization Owners by default); see [Before you start](/docs/connectors/building/submission#before-you-start). After publication, the same dashboard shows your server's health and usage; see [Managing your listing](/docs/connectors/building/managing-your-listing). ## Related topics <Card title="Build a connector" icon="code" href="/docs/connectors/building/index"> Create your own MCP server. </Card>
connectors/getting-started First recorded · 130 lines, first recorded
# Get started with connectors ## What you'll learn ## Prerequisites ## Setting up your first connector ### Step 1: Access connector settings ### Step 2: Choose a connector ### Step 3: Authenticate ## Using connectors in conversations ### In chat ### In projects ## Connector-specific tips ### Google Drive ### Gmail & Calendar ### GitHub ### Slack ### Microsoft 365 ## Best practices ## Troubleshooting ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Get started with connectors
> Learn to connect Claude to your tools and data
This tutorial walks you through setting up and using Claude's connector integrations to enhance your workflow.
## What you'll learn
* Setting up your first connector
* Using connectors in conversations
* Best practices for each integration
* Troubleshooting common issues
## Prerequisites
* A Claude account (Pro, Max, Team, or Enterprise for most connectors)
* Accounts on the services you want to connect
## Setting up your first connector
### Step 1: Access connector settings
1. Go to [claude.ai](https://claude.ai)
2. Select **Customize** in the sidebar
3. Select **Connectors**
### Step 2: Choose a connector
Available connectors include:
* Google Drive, Gmail, Calendar
* GitHub
* Slack
* Microsoft 365
### Step 3: Authenticate
1. Click "Connect" next to your chosen service
2. Log in to your account on that service
3. Grant Claude the requested permissions
4. Return to Claude
## Using connectors in conversations
### In chat
1. Start a new conversation
2. Click the "+" button
3. Select "Add from \[Service]"
4. Choose the content you want to include
5. Ask your question
### In projects
1. Open your project
2. Click "Add Content"
3. Select the connector
4. Add documents to your project knowledge
## Connector-specific tips
### Google Drive
* Best for: Document analysis, research
* Add multiple Google Docs for comprehensive context
* Documents sync automatically with updates
### Gmail & Calendar
* Best for: Finding information, scheduling context
* Ask questions like "What did Sarah say about the budget?"
* Claude can search your emails but can't send them
### GitHub
* Best for: Code understanding, documentation
* Add entire repositories or specific files
* Use with Projects for persistent codebase context
### Slack
* Best for: Finding discussions, team context
* Search channels and direct messages
* Requires installing the earlier Claude in Slack app first
### Microsoft 365
* Best for: Enterprise document search
* Access SharePoint, OneDrive, Outlook, Teams
* Requires a work or school Microsoft account
## Best practices
1. **Connect what you need**: Only connect services with relevant data
2. **Review permissions**: Understand what Claude can access
3. **Keep context focused**: Don't overload with too much data
## Troubleshooting
<AccordionGroup>
<Accordion title="Connector won't authenticate">
* Clear browser cookies and try again
* Check that you have the right account permissions
* Try a different browser
</Accordion>
<Accordion title="Data not showing up">
* Verify you have access to the data in the source service
* Wait a moment for sync to complete
* Try disconnecting and reconnecting
</Accordion>
<Accordion title="Connection expired">
* Go to Customize > Connectors
* Click "Reconnect" or "Refresh"
* Re-authenticate with the service
</Accordion>
</AccordionGroup>
## Related topics
<Columns cols={2}>
<Card title="Connectors Overview" icon="plug" href="/docs/connectors/overview">
See all available connectors.
</Card>
<Card title="Custom Connectors" icon="code" href="/docs/connectors/custom/remote-mcp">
Build your own integrations with MCP.
</Card>
</Columns>
connectors/github/index First recorded · 77 lines, first recorded
# GitHub integration ## Adding GitHub repositories ### In chats ### In projects ## Connecting to private repositories ## Best practices ## What information is retrieved ## Frequently asked questions
The first capture of this source. The page was already there, and this is what it said.
# GitHub integration
> Connect your code repositories to Claude
Connect GitHub repositories directly to Claude to provide comprehensive context for software development tasks. Claude can understand your codebase and assist with development questions.
<Note>
Available on all plans including Free.
</Note>
## Adding GitHub repositories
### In chats
1. Click the "+" button in the lower left corner of the chat interface
2. Select "Add from GitHub" from the dropdown menu
3. Use the file browser to select specific files and folders
4. When sending your message, Claude accesses and processes the selected content
### In projects
1. Click the "+" button in your project knowledge section
2. Select "GitHub" from the dropdown
3. Search accessible repositories or paste a repository URL
4. Use the file browser to select specific files and folders
5. Your selected content is added to project knowledge
**Keeping content current:**
* Use the "Sync" icon to ensure you're working with the latest codebase
* Use the "Configure files" icon to modify which files Claude analyzes
<Note>
If you're not authenticated with GitHub, you'll be redirected to authenticate before using the integration.
</Note>
## Connecting to private repositories
If you see a warning after entering a valid URL, you're likely attempting to connect to a private repository.
Follow the link to the GitHub App where you can:
* **Grant access yourself**: Choose between allowing Claude access to all repos or specific ones
* **Request access**: GitHub organization administrators receive an email notification. Once approved, you can sync and access the repository
## Best practices
1. **Start small**: Begin with a small codebase subset to understand how Claude interprets your code
2. **Iterate and refine**: Ask follow-up questions if initial responses need clarification
3. **Combine with human expertise**: Use Claude's insights as a starting point for team discussion
4. **Thoughtful file selection**: Include key files central to your task while staying within token limits
5. **Regular updates**: Refresh GitHub sync periodically, especially before new analysis or major repo changes
## What information is retrieved
| Retrieved | Not Retrieved |
| -------------- | ------------------- |
| File names | Commit history |
| File contents | Pull requests |
| Branch content | Issues |
| | Repository metadata |
## Frequently asked questions
<AccordionGroup>
<Accordion title="What if my repository updates after adding it?">
Click "Sync now" to fetch the latest changes from your repository.
</Accordion>
<Accordion title="Can I add multiple repositories?">
Yes, add multiple repositories to provide comprehensive context, provided they fit within Claude's context window.
</Accordion>
<Accordion title="What happens if I lose repository access?">
You won't be able to view its contents in projects where it was previously added. The repository preview is removed, but conversation history remains.
</Accordion>
</AccordionGroup>
connectors/google/calendar First recorded · 79 lines, first recorded
# Google Calendar integration ## Connect Google Calendar ## How to use Calendar integration ### 1. Ask about your schedule ### 2. Review Claude's response ### 3. Follow up ## Privacy and data handling ### Authentication ### Data access ## Limitations ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Google Calendar integration
> Access your calendar and meeting information with Claude
The Google Calendar integration enables Claude to understand your calendar commitments, helping you manage your schedule more effectively.
<Note>
Available on Pro, Max, Team, and Enterprise plans.
</Note>
## Connect Google Calendar
1. In claude.ai, go to **Customize > Connectors**.
2. Find Google Calendar and click **Connect**.
3. Sign in to your Google account and grant the requested permissions.
On Team and Enterprise plans, an Owner or Primary Owner must enable the integration for your organization before it appears in your connector list. For the full walkthrough, including troubleshooting, see [Get started with connectors](/docs/connectors/getting-started).
## How to use Calendar integration
### 1. Ask about your schedule
Simply ask Claude questions about your calendar. Claude automatically detects when calendar data is needed.
**Example questions:**
* "What meetings do I have tomorrow?"
* "When is my next meeting with the product team?"
* "Do I have any conflicts next week?"
* "Who's attending the budget review meeting?"
### 2. Review Claude's response
Claude provides answers that include:
* Clear answers to your questions
* Citations indicating which calendar events were used
* Links to original events when applicable
### 3. Follow up
You can ask for more details about:
* Meeting attendees
* Event timing and duration
* Related meetings and patterns
## Privacy and data handling
### Authentication
You must authenticate directly to your Google account. For Claude for Work (Team/Enterprise) plans, an Owner or Primary Owner must enable integrations at the account level.
### Data access
* Claude accesses only data from your connected Google account
* Access occurs only when you explicitly request it
* Minimum information is retrieved to answer your question
* Your existing calendar permissions are mirrored
## Limitations
<Warning>
* Claude cannot create, modify, or delete calendar events
* Claude cannot send calendar invitations
* Only calendars you have access to can be searched
</Warning>
## Related topics
<Columns cols={2}>
<Card title="Gmail" icon="envelope" href="/docs/connectors/google/gmail">
Search and analyze your emails.
</Card>
<Card title="Google Drive" icon="google-drive" href="/docs/connectors/google/drive">
Connect your documents.
</Card>
</Columns>
connectors/google/drive First recorded · 89 lines, first recorded
# Google Drive integration ## How to add Google Docs ### In chats ### In projects ## Supported file types ## Key features ## Frequently asked questions ## Troubleshooting ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Google Drive integration
> Connect Google Docs directly to Claude
The Google Drive integration lets you connect Google Docs directly to Claude on paid Claude.ai plans. You can add documents by pasting URLs or selecting recent files to provide context for your conversations.
<Note>
Available on Pro, Max, Team, and Enterprise plans.
</Note>
## How to add Google Docs
### In chats
1. Click the plus sign (+) in the chat interface
2. Select "Add from Google Drive"
3. Authenticate with Google on first use
4. Search recent documents or paste a document URL
5. Claude accesses and processes the document when you send your message
### In projects
The integration works only in private projects:
1. Click "Add Content" in project knowledge
2. Select "Google Drive"
3. Authenticate on first use
4. Search or paste a document URL
5. The document becomes available to Claude within that project
## Supported file types
| Type | Supported | Notes |
| -------------------- | --------- | -------------------------------- |
| Google Docs | ✅ | Up to 10MB, text extraction only |
| Google Sheets | ❌ | Not currently supported |
| Google Slides | ❌ | Not currently supported |
| Images in docs | ❌ | Not extracted |
| Comments/Suggestions | ❌ | Not extracted |
<Tip>
Convert .docx files by opening in Google Docs, clicking "File," then "Save as Google Docs."
</Tip>
## Key features
* **Live sync**: Documents continue syncing with the latest Google Drive version
* **Multiple documents**: Add multiple docs if they fit the context window
* **Permission-based**: You can only sync documents you have permission to view
## Frequently asked questions
<AccordionGroup>
<Accordion title="Do documents update after I add them?">
Yes, documents continue syncing with the latest Google Drive version.
</Accordion>
<Accordion title="Can I add multiple documents?">
Yes, you can add multiple docs as long as they fit within the context window.
</Accordion>
<Accordion title="What happens if I lose access to a document?">
You'll lose document preview access but your conversation history remains.
</Accordion>
</AccordionGroup>
## Troubleshooting
For reconnection errors:
1. Navigate to **Customize > Connectors**
2. Find Google Drive
3. Click the menu button (...)
4. Select "Disconnect"
5. Authenticate again when prompted
For persistent issues, disconnect from Google account connections at [myaccount.google.com](https://myaccount.google.com), search "Claude for Google Drive," and delete all connections.
## Related topics
<Columns cols={2}>
<Card title="Gmail" icon="envelope" href="/docs/connectors/google/gmail">
Search and analyze your emails.
</Card>
<Card title="Google Calendar" icon="calendar" href="/docs/connectors/google/calendar">
Access your calendar information.
</Card>
</Columns>
connectors/google/gmail First recorded · 82 lines, first recorded
# Gmail integration ## Connect Gmail ## How to use Gmail integration ### 1. Ask a question ### 2. Review Claude's response ### 3. Follow up ## Understanding citations ## Privacy and data handling ### Authentication ### Data access ## Limitations ## Related topics
The first capture of this source. The page was already there, and this is what it said.
# Gmail integration
> Search and analyze emails with Claude
The Gmail integration enables Claude to search your emails and provide answers based on your email content, reducing time spent retrieving information.
<Note>
Available on Pro, Max, Team, and Enterprise plans.
</Note>
## Connect Gmail
1. In claude.ai, go to **Customize > Connectors**.
2. Find Gmail and click **Connect**.
3. Sign in to your Google account and grant the requested permissions.
On Team and Enterprise plans, an Owner or Primary Owner must enable the integration for your organization before it appears in your connector list. For the full walkthrough, including troubleshooting, see [Get started with connectors](/docs/connectors/getting-started).
## How to use Gmail integration
### 1. Ask a question
Simply ask Claude a question that needs email information. Claude automatically detects when email data is needed.
**Example questions:**
* "What did Sarah say about the project deadline?"
* "Find emails about the Q4 budget review"
* "Summarize my conversation with the sales team last week"
### 2. Review Claude's response
Claude provides answers that include:
* Clear answers to your questions
* Citations indicating which emails were used
* Links to original sources when applicable
### 3. Follow up
You can ask for more details, such as:
* Requesting additional email information
* Finding related threads
* Summarizing longer conversations
## Understanding citations
Citations show which specific emails Claude used to answer your question. You can follow links back to original sources for verification and additional context.
## Privacy and data handling
### Authentication
You must authenticate directly to your Google account. For Claude for Work (Team/Enterprise) plans, an Owner or Primary Owner must enable integrations at the account level.
### Data access
* Claude accesses only data from your connected Google account
* Access occurs only when you explicitly request it
* Minimum information is retrieved to answer your question
* Your existing Gmail permissions are mirrored
## Limitations
<Warning>
* Claude cannot create, send, or modify emails
* Embedded images in emails are not visible to Claude
* Only emails you have access to can be searched
</Warning>
## Related topics
<Columns cols={2}>
<Card title="Google Calendar" icon="calendar" href="/docs/connectors/google/calendar">
Access your calendar information.
</Card>
<Card title="Google Drive" icon="google-drive" href="/docs/connectors/google/drive">
Connect your documents.
</Card>
</Columns>
connectors/microsoft/365 First recorded · 118 lines, first recorded
# Microsoft 365 connector ## Capabilities ## Setup requirements ### Prerequisites ### Phase 1: Administrator setup ### Phase 2: User enablement ## Usage ### Example queries ## What you can access ## Write actions ## Permissions ## Troubleshooting
The first capture of this source. The page was already there, and this is what it said.
# Microsoft 365 connector
> Connect SharePoint, OneDrive, Outlook, and Teams to Claude
The Microsoft 365 connector enables Claude to search, analyze, and act on information across SharePoint, OneDrive, Outlook, and Teams.
<Note>
Available on all Claude plans: Free, Pro, Max, Team, and Enterprise. On Team and Enterprise plans, an organization Owner must enable the connector before members can connect.
</Note>
## Capabilities
With this connector, Claude can:
* **Search and analyze documents** across SharePoint sites and OneDrive libraries
* **Access email threads** and analyze Outlook communications
* **Review meeting information** from Teams Calendar
* **Pull insights** from Teams Chat discussions
* **Send and manage email**, including drafts, labels, mail filters, and automatic replies
* **Manage calendar events** and find meeting times
* **Create and update files** in SharePoint
## Setup requirements
On Free, Pro, and Max plans, no organization-level setup is needed. Connect from **Customize > Connectors** in claude.ai. A Microsoft Entra Global Administrator still needs to grant one-time tenant consent for your Microsoft organization.
### Prerequisites
* A work or school Microsoft account on a Microsoft Entra tenant (personal accounts such as outlook.com, hotmail.com, or live.com aren't supported)
* Claude user with Owner or Primary Owner role (Team and Enterprise plans)
* Global Administrator access to Microsoft Entra tenant
* Active Microsoft 365 accounts for all users (Team and Enterprise plans)
### Phase 1: Administrator setup
**Automatic Setup (Recommended):**
1. Navigate to **Organization settings > Connectors**
2. Select **Add**, then **All available**
3. Find Microsoft 365 and select "Add to your team"
4. Connect individually and grant organization-wide permissions
5. (Optional) Restrict user access or revoke specific permission scopes
### Phase 2: User enablement
Once enabled by administrators, team members:
1. Navigate to **Customize > Connectors**
2. Find Microsoft 365 and click "Connect"
3. Authenticate with credentials
## Usage
Ask Claude questions requiring Microsoft 365 data, or ask Claude to take an action such as sending an email or updating a file. Claude automatically detects and uses the necessary tools.
### Example queries
* "Find the Q4 strategic planning document in SharePoint"
* "Summarize email conversations about the product launch"
* "What discussions happened in Teams about the marketing campaign?"
* "Review meeting notes from last week's leadership sync"
* "Draft a reply to the latest email about the vendor contract"
* "Schedule a 30-minute sync with the design team next week"
## What you can access
| Service | Capabilities |
| ----------------------- | ---------------------------------------------------------------------------------------------------------- |
| **SharePoint/OneDrive** | Search and analyze documents; create and update files in SharePoint |
| **Outlook** | Search email threads and archived emails; send and manage mail; create, update, and delete calendar events |
| **Teams Calendar** | Review meeting summaries and attendance |
| **Teams Chat** | Access channel and chat discussions |
## Write actions
Claude can take actions in Outlook and SharePoint: send mail and manage drafts; organize mail with labels, filters, and trash; set automatic replies; create, update, and delete calendar events; and create and update files in SharePoint. Read and search tools work the same whether or not write actions are enabled.
Write actions are controlled by your organization's administrators in two places:
1. **Approve the write permissions.** If your tenant's consent for the connector covers only read permissions, a Microsoft Entra Global Administrator or Application Administrator approves the updated permission set (mail, calendar, mailbox settings, and file writes) under **Enterprise applications** in the Entra admin center. This is a one-time action per tenant.
2. **Turn on write actions.** If write actions are off for your organization, administrators turn them on for all users in the Microsoft 365 connector configuration, or enable them for specific users with role-based access control (beta).
Claude cannot attach files to the drafts it creates and cannot send Teams messages.
For setup steps, see [Connect to Microsoft 365](https://support.claude.com/en/articles/15183774-connect-to-microsoft-365) and [Set up the Microsoft 365 connector](https://support.claude.com/en/articles/12542951-set-up-the-microsoft-365-connector) in the help center. The [Microsoft 365 connector security guide](https://support.claude.com/en/articles/12684923-microsoft-365-connector-security-guide) covers the permission model.
## Permissions
<Note>
All permissions are delegated: Claude acts on behalf of users and can only access and change content that you already have permission to access and change in Microsoft 365. Write actions are available when your administrators enable them (see [Write actions](#write-actions)).
</Note>
## Troubleshooting
<AccordionGroup>
<Accordion title="Authentication failures">
* Verify correct Microsoft 365 credentials
* Check active license status
* Review organizational third-party app policies
* Try a different browser
* Clear cookies and cache
</Accordion>
<Accordion title="Documents not found">
* Verify direct access to the document in Microsoft 365
* Ensure document is in SharePoint/OneDrive (not local)
* Recently uploaded documents may need time to index
* Use specific SharePoint site names
* Search by exact filename
</Accordion>
<Accordion title="Incomplete search results">
* Be more specific about requirements
* Specify locations and date ranges
* Use exact phrases
* Break complex queries into simpler questions
</Accordion>
</AccordionGroup>
connectors/overview First recorded · 92 lines, first recorded
# Connectors overview ## How connectors work ## Types of connectors ### Prebuilt integrations ### Remote MCP servers ### MCP Apps ### MCP Bundles ### Self-serve local MCP ## Ways to connect ### Connectors directory ### Third-party connectors ## Related concepts ### Plugins ## Platform availability ## Next steps
The first capture of this source. The page was already there, and this is what it said.
# Connectors overview
> Connect Claude to external tools, data, and UI through MCP
Connectors extend Claude's capabilities by connecting it to external tools and data sources. They are powered by the [Model Context Protocol (MCP)](/docs/connectors/building/mcp), an open standard created by Anthropic that provides a unified way for AI applications to interact with the outside world.
## How connectors work
Connectors can do two things:
* **Provide tools and information** — Give Claude access to external data and the ability to take actions (search files, read emails, create issues, etc.)
* **Surface UI components** — Render interactive visual elements directly in the conversation through [MCP Apps](/docs/connectors/building/mcp-apps/getting-started)
<Note>
**Building for Claude?** Most partners ship both a remote MCP server and a plugin that wraps it with skills. See [what to build](/docs/connectors/building/what-to-build) for the decision guide.
</Note>
## Types of connectors
### Prebuilt integrations
Anthropic provides first-party integrations with popular services like Google Drive, Gmail, Google Calendar, GitHub, Slack, and Microsoft 365. These are ready to use with no setup beyond authentication. See [Getting started](/docs/connectors/getting-started) for setup instructions.
### Remote MCP servers
[Remote MCP servers](/docs/connectors/custom/remote-mcp) communicate with Claude over the internet, giving it access to cloud-hosted tools and data. You can connect to existing remote MCP servers or build your own for any tool or service.
### MCP Apps
[MCP Apps](/docs/connectors/building/mcp-apps/getting-started) allow MCP servers to display interactive UI elements in conversational MCP clients. Rather than only returning text, an MCP App can render charts, maps, forms, and other visual components directly in the chat. See the [design guidelines](/docs/connectors/building/mcp-apps/design-guidelines) and [cross-platform compatibility](/docs/connectors/building/mcp-apps/cross-compatibility) docs for building MCP Apps.
### MCP Bundles
[MCP Bundles (MCPB)](/docs/connectors/custom/desktop-extensions) package MCP servers with their dependencies for distribution as desktop extensions. MCPB handles cross-platform compatibility, dependency management, code signing, and centralized version updates — making it suitable for enterprise deployment of local MCP servers to Claude Desktop.
### Self-serve local MCP
Local MCP servers distributed through third-party package registries like npm or PyPI cannot be listed directly in the Connectors Directory. To distribute a local server, package it as an [MCPB](/docs/connectors/building/mcpb) for the Desktop Extensions gallery, or bundle it in a [plugin](/docs/plugins/overview) using `.mcp.json` and submit it to the [plugin directory](/docs/plugins/submit).
## Ways to connect
### Connectors directory
The [Connectors Directory](/docs/connectors/directory) is an open catalog of MCP servers from Anthropic and third-party developers, available across all Claude products. It includes both connectors that Anthropic has verified and community connectors; see [connector verification](/docs/connectors/verification) to learn what each label means.
### Third-party connectors
You can build and connect your own MCP servers for proprietary tools or workflows. See [Third-party Connectors](/docs/connectors/custom/remote-mcp) for remote MCP and [Desktop Extensions](/docs/connectors/custom/desktop-extensions) for local integrations.
## Related concepts
### Plugins
[Plugins](/docs/plugins/overview) combine MCP connectors, [Skills](/docs/skills/overview), slash commands, and sub-agents into shareable capability packages. They are available in Claude Code and Cowork. You can also [submit your plugin](/docs/plugins/submit) to the plugin directory.
## Platform availability
Prebuilt integrations and directory connectors work across all Claude products:
* **Claude.ai** — Full remote MCP support & MCP Apps
* **Claude Desktop** — Full MCP support and local desktop extensions
* **Claude Mobile** — Remote MCP access
* **Claude Code** — Remote MCP access and plugins
* **Claude Cowork** — Full MCP and plugin support
## Next steps
<Columns cols={2}>
<Card title="Getting started" icon="rocket" href="/docs/connectors/getting-started">
Set up your first connector.
</Card>
<Card title="Connectors directory" icon="grid-2" href="/docs/connectors/directory">
Browse verified and community integrations.
</Card>
<Card title="Build a connector" icon="code" href="/docs/connectors/building/index">
Create your own MCP server.
</Card>
<Card title="MCP Apps" icon="window" href="/docs/connectors/building/mcp-apps/getting-started">
Build UI components for Claude.
</Card>
<Card title="MCP in Claude Code" icon="terminal" href="https://code.claude.com/docs/en/mcp-quickstart">
Add an MCP server to Claude Code from the command line.
</Card>
<Card title="Claude Code documentation" icon="terminal" href="https://code.claude.com/docs">
Install, configure, and use the Claude Code CLI.
</Card>
</Columns>
connectors/slack/index First recorded · 96 lines, first recorded
# Slack integration ## Claude in Slack (earlier app) ### Ways to interact with Claude ## Installation ### For Slack admins ### For individual users ## Slack connector ### Enabling the connector ## Managing connections ### Viewing connection status ### Disconnecting ## Privacy & data ## Troubleshooting
The first capture of this source. The page was already there, and this is what it said.
# Slack integration > Use Claude directly in Slack and connect your workspace Integrate Claude and Slack in two ways: add Claude directly to your Slack workspace, or enable the Slack connector for your Claude apps. <Note> This page covers the earlier per-user Claude in Slack app. The current product is [Claude Tag](/docs/claude-tag/overview), which gives your team one Claude identity set up by an admin. If your organization used the earlier app, see [Migrate from the earlier Claude in Slack](/docs/claude-tag/admins/migrate-from-earlier). </Note> ## Claude in Slack (earlier app) Claude is available to paid Slack plan users. Slack admins must approve the app before individual users can access it. ### Ways to interact with Claude 1. **Direct messaging**: Start private conversations with @Claude 2. **AI assistant panel**: Click Claude's icon in Slack's AI assistant header 3. **Thread participation**: Mention @Claude in any thread for assistance All surfaces support the same Claude capabilities you've enabled, including web search and tool integrations. <Note> Team and Enterprise plan users with Claude Code access can route coding tasks directly to Claude Code by mentioning @Claude. </Note> ## Installation ### For Slack admins 1. Navigate to the Claude app in Slack's App Marketplace 2. Click "Add to Slack" 3. Review and approve for your organization 4. Deploy org-wide or to specific workspaces **For multi-workspace deployment:** * Access your Slack management workspace * Navigate to **Integrations → Installed apps → Add to more workspaces** * Toggle through relevant workspaces ### For individual users 1. Find Claude in your apps list or the Slack App Marketplace 2. Click "Connect Account" 3. Select your organization 4. Click "Authorize" to grant access 5. Return to Slack and click "+ New Chat" or @mention Claude **Tip**: Add Claude to your Slack header by clicking the three dots and selecting "Add this app to header." ## Slack connector Available for Team and Enterprise plans, the Slack connector allows Claude to search your workspace's channels, direct messages, and files for relevant context. <Warning> You must install Claude in Slack before enabling and using the Slack connector. </Warning> ### Enabling the connector **For Owners**: Navigate to **Organization settings > Connectors** and enable the Slack connector. **For Individual Users**: Go to **Customize > Connectors**, find Slack, and click "Connect." ## Managing connections ### Viewing connection status 1. Click Claude in your Slack sidebar 2. Go to the "Home" tab 3. View your connection details ### Disconnecting **Claude app**: Go to Claude's Home tab and click the red "Disconnect" button. **Slack connector**: Go to [claude.ai/customize/connectors](https://claude.ai/customize/connectors), find Slack, and select "Disconnect." <Note> Disconnecting removes your account connection and deletes past conversations within 30 days. </Note> ## Privacy & data * Slack conversations remain separate from your Claude web history * Conversations initiated in Slack don't appear in your Claude chat history * Each platform maintains separate conversation histories * Conversations auto-delete within 30 days if you disconnect * Slack retention policies apply to your workspace messages ## Troubleshooting <Accordion title="Can't install Claude in Slack"> If your company Slack requires admin approval and you lack admin access, you'll see a "Request to install" prompt. Contact your Slack Admin to approve the app. </Accordion>
connectors/verification First recorded · 48 lines, first recorded
# Connector verification ## Verified ## Community ## Custom ## The directory is optional ## Advice for all third-party connectors ## List your own connector
The first capture of this source. The page was already there, and this is what it said.
# Connector verification > How Anthropic reviews connectors, and what Verified, Community, and Custom mean The [Connectors Directory](/docs/connectors/directory) includes connectors built by Anthropic and by third-party developers. Each connector shows how much Anthropic has reviewed it, so you can decide what to connect to. ## Verified Anthropic has reviewed this connector for quality and security. Verified connectors show a checkmark next to their name. ## Community A third-party developer built this connector. It passed Anthropic's automated checks, but Anthropic has not reviewed it in depth. Community connectors show a "Community" label in the directory and in [Customize > Connectors](https://claude.ai/customize/connectors). Before you connect one, Claude shows a reminder that it has not been reviewed in depth. The label is a quality signal. It affects how the connector is displayed and discovered in the directory, not how the connector itself functions: once connected, a community connector works the same way as a verified one. ## Custom You added this connector yourself. Anthropic has not reviewed it. See [custom connectors](/docs/connectors/custom/remote-mcp) to learn how to add one. ## The directory is optional The directory is a catalog, not a separate kind of connector. Connectors in the directory and custom connectors you add yourself use the same technology. If you have a connector's URL, it can be added as a custom connector. A connector does not need to be in the directory for you to use it. Listing a connector in the directory makes it discoverable by other people and gives it a review label (a checkmark if Anthropic has verified it, or "Community" if it passed Anthropic's automated checks). It does not change the tools the connector exposes. See [directory vs custom](/docs/connectors/building/directory-vs-custom) for a detailed comparison. ## Advice for all third-party connectors Whatever the label, this advice applies to any connector built by someone other than Anthropic: * Only connect to servers from developers and organizations you trust. * A connector's developer controls which tools it exposes and can change them at any time. * Anthropic does not run a third-party connector's servers and does not control how it handles your data. * Carefully review requested permission scopes during authentication. * Be aware of prompt injection risks; Claude has built-in protections. * Monitor for unexpected changes in tool behavior. For more, see [security and privacy](/docs/connectors/custom/remote-mcp#security-and-privacy). ## List your own connector If you build connectors and want yours in the directory, start with the [review criteria](/docs/connectors/building/review-criteria) and the [submission guidelines](/docs/connectors/building/submission).
cowork/changelog First recorded · 814 lines, first recorded
# Changelog
The first capture of this source. The page was already there, and this is what it said.
# Changelog > Release notes for Claude Desktop <Update label="v1.30096.1" description="2026-08-13"> **General** * Fixed Find (Cmd+F) doing nothing the first time it was pressed after launch. * Fixed right-to-left text in the composer scrambling around embedded left-to-right words; code blocks stay left-to-right. * Fixed the Artifacts entry missing from the sidebar on Windows machines that can't run local Cowork; it now opens the Artifacts gallery. * Fixed macOS asking for notification permission as soon as the app launched, instead of when the first notification is about to appear. * Fixed the app crashing at launch, or on a system theme change, on some Linux installs (most often repackaged builds); it now falls back to a default tray icon. **Code** * Added Rewind to cloud sessions (message menu, Esc Esc, or `/rewind`), and fixed rewound-away messages reappearing when a rewound cloud or Remote Control session was reopened. * Fixed an interrupted Claude Code download (for example, after a crash or power loss mid-install) leaving Code sessions on that computer unable to start, most often on Windows. * Fixed an unanswered permission or plan-approval prompt in a cloud session sometimes being treated as approved after the session's environment disconnected. * Fixed cloud sessions marked as needing input sometimes opening without the question or approval prompt. * Fixed Remote Control sessions sometimes never connecting when opened while idle, staying off your other devices after a stop or interruption until turned back on by hand, and looking idle instead of reporting that the host computer is offline. * Fixed copy and paste problems: transcript text pasted into rich-text apps lost the spaces around inline code, bold, and italics and mangled code blocks, and Cmd+C after selecting text in the Plan view copied nothing. **Cowork** * Fixed the earlier conversation being discarded when you chose Go back after a failed task resume, or edited a message right after the app restarted. * Fixed memory saves failing when the Claude Code `managed-settings.json` policy sets `allowManagedPermissionRulesOnly`. * Fixed Cowork on Windows failing on every launch with "VM service not running" after its background service had stopped; the service is now restarted automatically, and otherwise the error explains that restarting the computer restores it. * Fixed Cowork sometimes pulling you back to the bottom of a task after you had scrolled up, for example when a sub-agent step finished. **3P** * Added `otlpAuthMode` and `otlpHeadersHelper`, two ways to authenticate telemetry exports without static `otlpHeaders`: set `otlpAuthMode` to `inference-credential` to reuse the signed-in user's inference token, or point `otlpHeadersHelper` at an executable that prints the collector headers as JSON. * Added an optional `inferenceGatewayOidc.resource` subfield that sends an RFC 8707 resource indicator on gateway sign-in and token refresh, for identity providers that audience-restrict access tokens. * 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 before it takes effect, the same prompt `inferenceGatewayBaseUrl` already shows. Managed deployments (bootstrap URL set by device management, or `trustBootstrapDelivery: true`) see no change. * Changed `claudeAiImport`: an imported session now asks the user to confirm once (Trust and resume) before Claude continues it for the first time; this also applies to sessions imported before this update. * Fixed a single malformed `allowedPluginMarketplaces` (beta) entry disabling every configured marketplace; the entry is now skipped and reported. * Fixed sending messages failing when a bootstrap server turned Cowork off (`coworkTabEnabled` set to `false`); the home screen now opens directly into Chat. * Fixed OpenTelemetry exports being rejected when the configured gateway also serves as the telemetry collector endpoint. </Update> <Update label="v1.28929.0" description="2026-08-11"> **General** * Added the standard macOS full-screen keyboard shortcut, with an Enter Full Screen and Exit Full Screen item in the View menu. * Fixed a startup error on some Linux systems, most often repackaged or containerized installs, that left the app without a tray icon and recurred on every system theme change. * Fixed commands in the built-in terminal failing with error -1743 when controlling other apps on macOS, instead of showing the Automation permission prompt. * Fixed sign-in on macOS repeatedly failing with "Failed to login, it may have been cancelled"; Claude now opens the sign-in page in your default browser when the system sign-in sheet is unavailable. * Fixed some Windows installs (MSIX packages and enterprise-managed roaming profiles) failing to save chat history, settings, and scheduled tasks, and Cowork failing to start with "Download failed" after an app update. * Fixed the app's memory use growing without bound during long-running sessions. **Code** * Removed the ability for scheduled-task runs and other unattended sessions to start dev servers in the Browser preview; other sessions now approve each distinct dev server command once rather than on every start. * Fixed app settings, and the app's record of session worktrees, being discarded when those files had been re-saved with a UTF-8 byte-order mark by an external editor. * Fixed forked sessions starting from the original base branch instead of the parent session's current branch. * Fixed importing Claude Code CLI sessions changing the order of existing sessions in `claude --resume`. * Fixed sessions failing to resume, reporting their conversation history as missing, after Claude had moved the session into a worktree. * Fixed file uploads through Claude in Chrome from a Code session failing with "Invalid arguments for tool file\_upload". **Cowork** * Fixed a follow-up message sent while Claude was still writing a reply sometimes being dropped, with the reply cut off. **3P** * Added history import. When `claudeAiImport.enabled` is `true`, users can bring a Claude.ai data export, Cowork, Code, and Chat sessions from other Claude installs on the same computer or from an app data folder they choose, and terminal Claude Code sessions into the app from Settings > Import. `claudeAiImport.bannerBehavior` controls an optional banner on new tasks that offers it: `off` (default), `detect` (only when earlier sessions are found on the computer), or `show` (everyone, until dismissed or imported). * Added `modelPrefer1mContext`. When `true`, a user who has not yet chosen a model starts on the 1M-context variant of the default model whenever the deployment marks or reports that model as 1M-capable, including auto-discovered models. Saved selections are never changed. Defaults to `false`. * Added the gateway address, `inferenceGatewayBaseUrl`, to the one-time bootstrap consent prompt. When a bootstrap server delivers it and the bootstrap URL was not set through device management, each user is asked once at launch to allow the address, and again if it later changes; the app does not connect to the gateway until they choose Allow. Existing installs prompt the first time they start this version. Set `trustBootstrapDelivery` to `true` in your device-management profile or local configuration file to accept it for everyone in advance. * Changed the Code tab to be hidden entirely, rather than shown greyed out, when an administrator has disabled Code. * Fixed a session opened in a new window on Windows having no title bar, window controls, or drag area. * Fixed stored sign-ins being lost when the system keychain was temporarily locked. * Fixed the Chat tab ignoring `toolSearchEnabled`, which sent every connector's tool definitions with each request and could exceed the context window when many connectors were configured; Chat now loads them on demand when the key is `true`, as Cowork and Code do. * Fixed the credential-expired notice and the session error banners in Cowork and Code offering no way to sign in again when the credential comes from a helper script (`inferenceCredentialHelper`); they now show "Sign in again", which re-runs the helper. * Fixed the model picker reverting to the standard-context variant in new sessions, after relaunch, and when switching between Chat and Cowork once the 1M-context variant had been chosen. </Update> <Update label="v1.26832.0" description="2026-08-06"> **General** * Added a "Start a new project" option to the "Add to project" menu, which opens the create-project dialog. * Added Esc as a way to end voice mode in the chat composer. * Added the ability to add suggested skills in local sessions, and plugins from your personal marketplaces, directly from their suggestion cards. * Fixed Claude Desktop on Linux entering a crash-and-relaunch loop that consumed heavy processor time when automatic session restore ran into persistent graphics failures. * Fixed starting a chat inside a project showing a blank screen until the response finished, and leaving the chat without its project name or title. * Fixed the scheduled-task prompt editor not being announced to screen readers as a labeled multiline text box. **Code** * Added session-window restore: Claude Code session windows that were open when you quit now reopen the next time you launch the app. * Changed permission-mode picks so they apply to the folder where you made them instead of becoming a machine-wide default. * Removed the "Always allow" option when approving dev server starts in the Browser preview; each new server start now asks, and a server that has crashed asks again instead of restarting silently. * Fixed "Try again" on session-error cards sometimes doing nothing, and a failed send's retry card and prompt text now survive an app relaunch. * Fixed leftover session workspaces building up on disk until new sessions could fail with a disk-space error. * Fixed repository pickers in project settings and scheduled tasks timing out or omitting repositories in large organizations; they now load quickly, can search every repository, and can load more results. **Cowork** * Added a ⋮ menu to scheduled tasks in the sidebar, including Mark as unread for the latest run. * Added a confirmation before a link in a live artifact opens in your browser, with a per-site "Don't ask again" option. **3P** * Added `updateViaUpdatesHost`. Set it to `true` to read the update feed from `releases.claude.com`, a host that serves only the desktop update check and carries no model API, so networks that block `api.anthropic.com` can still receive updates. Installer downloads continue to come from `downloads.claude.ai`. Defaults to `false`. * Added an access mode to each `allowedWorkspaceFolders` entry. Set `mode` to `ro` to let Claude read and search a folder without changing it: in Cowork, writes are blocked and Claude is directed to put modified copies in the session outputs folder. In the Code tab this covers Claude's file tools only; Bash in the Code tab and SSH sessions do not yet enforce it. Entries without `mode` stay read-write, so existing configurations are unchanged. * Added optional `:port` suffixes to `coworkEgressAllowedHosts` entries, for example `internal.corp.com:8443` or `*.corp.com:8443`, restricting that entry to the named port. This applies to the sandbox's web fetch now, and to shell egress once the updated virtual machine image ships; on the Code tab, a port-scoped entry is treated as its bare host (any port). Entries without a port keep allowing any port, and an invalid entry is dropped on its own with a warning in the logs. * Added settings that decide where users sign in for inference to the one-time bootstrap consent prompt: the Azure AI Foundry Entra tenant and client, Bedrock IAM Identity Center, the Vertex OAuth client and workforce identity, and gateway OIDC. Set `trustBootstrapDelivery` to `true` in your device-management profile to accept these for everyone in advance. * Added the merged Chat and Cowork home as the default. The "New" button starts a chat or a task from one composer, and the sidebar shows Home, which lists chats and tasks together, alongside Code. * Changed the `trustBootstrapLocalExec` key name to `trustBootstrapDelivery`, reflecting that it now covers sign-in targets as well as helper scripts and connectors. The previous name continues to work in existing profiles. * Fixed chats started inside a Project not picking up the Project's Instructions and Context links, including reading the files linked there. * Fixed Code sessions on a custom gateway endpoint ending with an idle-timeout error while the gateway was still sending keep-alive responses. * Fixed Code tab sessions on gateway and direct API key deployments still sending nonessential traffic to `api.anthropic.com` after an administrator turned off nonessential telemetry. * Fixed model selections provided by your deployment being overridden by an out-of-date Claude Code `managed-settings.json` left on the device. * Fixed the published `bootstrap-config-v2.schema.json` describing flat keys instead of the nested shape the app's own configuration export uses. </Update> <Update label="v1.25927.0" description="2026-08-04"> **General** * Added a chevron next to the composer's microphone button that switches between dictation and voice mode and keeps your choice; clicking the microphone now starts dictation right away. * Fixed `⌘K` (or `Ctrl+K` on Windows and Linux) search missing results from tool output and archived sessions. * Fixed a crash on macOS during passkey and Touch ID prompts when the system language is German, Spanish, French, Hindi, Indonesian, Italian, Japanese, or Korean. * Fixed automatic and menu-triggered update restarts interrupting an in-progress Claude Code or Cowork task. * Fixed the app being left with no usable window: a failure during startup now shows an error dialog and records the details to a file, and a window the system shut down under low memory reloads instead of staying blank. **Code** * Added automatic resume for sessions interrupted when your computer goes to sleep. A banner with a manual Continue button appears only when resuming isn't safe, and you can continue the session in the cloud instead. * Added capture and annotation for the page the Browser pane is showing, including external sites, so you can mark up what you see and attach the image to chat. * Fixed a crash while using the in-app browser on pages with heavy console or network activity. * Fixed messages sent while Claude was working disappearing from a session after it was reloaded from disk. * Fixed sessions sometimes becoming permanently unopenable, showing "No messages yet" while their conversation history was still on disk. * Fixed starting a session and swapping repositories stalling in organizations with very large repository lists: the pickers now load repositories page by page, find the rest as you type, say when more are available by searching, and report a failed search instead of showing empty results. **Cowork** * Added pasted and attached images to the session's uploads folder, so Claude can open and edit the actual file. * Fixed "Allow for this task" not appearing for connector tools when your organization has turned off persistent "Always allow". * Fixed documents showing an internal file id instead of their title, including in export filenames and approval prompts. * Fixed long-running workspace shell commands, such as large database queries, being cut off too early. * Fixed scheduled task problems: a cron expression using `7` for Sunday never ran, stalled runs kept running in the background until the app was restarted, and "Allow for all scheduled runs" appeared on prompts where the choice could not be saved, so the task asked again on every run. **3P** * Added Projects for organizing Chat conversations: create a project, start a chat inside it, or move existing chats in. Projects stays available even when your administrator has turned the Cowork tab off. * Added `inferenceGatewayOidcAuthFlow` and `inferenceVertexWorkforceAuthFlow`, which choose whether identity-provider sign-in for gateway and Vertex workforce-identity credentials runs in the system browser (the default) or through the operating system's Microsoft account broker on Windows and macOS, so sign-in can satisfy Conditional Access policies that require a managed device. * Added `managedMcpServers[].oauth.authFlow`, which 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. * Added `skillCreationEnabled`, which controls whether users can create and upload their own skills. It defaults to on; setting it to `false` hides the creation and upload surfaces and turns off Claude's skill-creation tools. It appears in the Setup window under workspace restrictions. * Added `trustBootstrapLocalExec`. Each user is now asked once for consent when the bootstrap configuration includes settings that run local commands, such as credential helpers and local connectors. Set this key to `true` to accept them for everyone in advance. It defaults to `false` and is accepted only from MDM or a local configuration file. * Added a built-in GitHub connector to `managedMcpServers`: 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. The connector is also configurable from the Setup window. * Added support for mounting Windows mapped network drives into the Cowork sandbox, so shell commands and document processing can work with files on network drives, and fixed adding a mapped network-drive folder mid-session being rejected with a message to use the folder picker. * (breaking) Changed the nested v2 bootstrap response: `deploymentDisplayName` and `deploymentDisplaySubtitle` now sit under `appearance`, and `endUserAttribution` and `userContentRendererUrl` under `workspace`. The flat MDM key names are unchanged. * Changed `managedMcpServers` and `microsoftAuthBroker` to be supported on standard deployments as well, so an administrator can enable the built-in Microsoft 365 connector by adding it to `managedMcpServers` through MDM. It stays off unless configured. * Changed where several keys can be delivered from: `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 consent prompt above. * Deprecated `organizationPluginsUrl` and removed it from the configuration reference. The key is still honored, but organization plugins are better configured with `allowedPluginMarketplaces`. * Updated `enduserAttribution` to the corrected spelling `endUserAttribution`. The previous spelling is still accepted and now records a configuration warning. * Fixed connector sign-in recovery: connectors no longer ask you to sign in again after a slow startup when the credentials are still valid, and the GitHub connector shows its Reconnect card on the next tool call after its token is revoked on github.com instead of staying stuck. * Fixed tasks failing with "Couldn't start this task" for the rest of the session when the app launched while the network or the sign-in credential was unavailable. * Fixed the app losing administrator-enabled features, such as the Chat tab, for the rest of the session when the organization's configuration server was unreachable at launch. It now retries in the background and recovers. * Fixed the home composer and sidebar still offering Cowork when an administrator has turned the Cowork tab off; Cowork is now hidden instead of greyed out, while Chat and Projects remain available. </Update> <Update label="v1.24012.11" description="2026-08-03"> **General** * No user-facing changes. **Code** * No user-facing changes. **Cowork** * No user-facing changes. **3P** * Fixed sessions started while configured MCP servers were still connecting having no connector tools until a new conversation was started. * Fixed the Microsoft 365 connector not appearing after first-time sign-in until the app was restarted. </Update> <Update label="v1.24012.9" description="2026-07-24"> **General** * No user-facing changes. **Code** * No user-facing changes. **Cowork** * Fixed plugin hooks silently doing nothing on Windows. **3P** * Added the `mcpPersistentAlwaysAllowEnabled` managed configuration key, letting admins disable the persistent "Always allow" approvals for MCP tools while keeping session-scoped approvals available. * Added the five-level effort selector for Claude Opus 5 in the model picker. Extended thinking is always on for Opus 5. </Update> <Update label="v1.24012.0" description="2026-07-21"> **General** * Added an option to keep custom plugin marketplaces up to date automatically, and fixed a marketplace refresh reporting success before the sync ran and re-adding an existing marketplace not refreshing its contents. * Improved keyboard and screen reader support across the app: settings tabs and share-visibility choices respond to arrow keys, dialogs announce meaningful titles, decorative graphics no longer clutter screen reader output, and the find bar, search fields, and pane resize handles show a visible focus outline and announce their size. * Fixed failed uploads being reported as corrupted or unsupported files, and retries showing a "Server is busy" message for unrelated errors. * Fixed safety-block notices suggesting you switch models when no alternative model was available for that topic. * Fixed the app failing to launch when its settings file or logs folder was corrupted, and saved sessions disappearing after a relaunch when one session's stored data was invalid. * Fixed the app window resizing abruptly and losing its saved size and position when signing in or out; it now animates smoothly in place. **Code** * Added iOS Simulator support: Claude Code can build your iOS app, launch the simulator, and verify the result without leaving the session. * Added iOS Simulator and Android Emulator buttons to the session titlebar when the agent launches an app on a device, so the pane is one click to reopen. * Added Pause Project, which pauses a project's coordinator and new session spawning from settings and shows a Resume banner above the composer. * Added screenshot annotation in the composer: click a staged image, open the pencil, and draw with pen, shapes, text, and colors before sending. * Improved how large sessions open: the newest messages paint first while older history loads in the background. * Fixed Code sessions affecting the wrong files: background worktree cleanup could switch or reset the main repository checkout when a worktree folder was only partially removed, and new sessions could copy uncommitted files from the original folder. * Fixed session list problems: finished sessions still showing as running, deleted sessions reappearing as empty "Session not found on disk" entries after an update, archived sessions still appearing active on claude.ai and other devices, and sessions started from claude.ai missing Rename, Archive, and Delete in the sidebar menu. * Fixed the app freezing when Claude Code updated its configuration file during concurrent use, and web pages in the Browser pane freezing the app with alert and confirm dialogs. **Cowork** * Added /usage and /cost to Cowork tasks: an inline card shows your plan limits and the session's usage without sending anything to the model. * Improved background computer use so it types faster and no longer leaves menus stuck open on screen. * Updated folder access prompts for cloud Cowork tasks to note that files Claude uses leave your device and are processed on Anthropic's servers. * Fixed changes to Instructions for Claude sometimes not applying to new sessions, and edits reverting to an earlier version while a session was running, including after an app restart. * Fixed Cowork workspace problems: the Windows workspace failing to start when its virtual disk files were compressed, a backgrounded shell command leaving a session stuck reporting "already running", and bash commands failing when several subtasks ran them at once. * Fixed the message input staying stuck in a sending state when a folder access dialog went unanswered. **3P** * Added `deploymentDisplayName` and `deploymentDisplaySubtitle` to customize the deployment name and an optional subtitle shown in the account menu and sidebar. * Added `enduserAttribution`, which shows the signed-in user's identity in the sidebar, account menu, and Code tab, and includes it as the OpenTelemetry `enduser.id` attribute on telemetry sent to your configured collector. Administrators can turn it off, and an existing static `enduser.id` is kept. * Added `oauth.authorizationUrl` and `oauth.tokenUrl` to managed MCP servers for identity providers that do not serve a discovery document, and `oauth.additionalRedirectReferrerHosts` to allow sign-in callbacks from hosts other than the authorization URL's. * Added `userContentRendererUrl`, which sets the HTTPS origin that renders artifact and file previews; leave it unset to use the default Anthropic-hosted renderer. * Added a `broker` option to `inferenceFoundryAuthFlow` that signs in to Azure AI Foundry through the operating system's native account broker on Windows or Company Portal on macOS, so sign-in can satisfy Conditional Access policies that require a compliant device. Windows and macOS only. * Added a Usage page in Settings for custom deployments, showing token usage across Chat, Cowork, and Code. * Added Microsoft 365 Teams tools (send to a chat, channel, or thread; create a chat; @mention people) and formatted-body support for Outlook reply drafts. * Added the 1M context option in the model picker for gateway-discovered models that report the capability in `/v1/models`, without requiring an `inferenceModels` entry. * Changed telemetry on bootstrap-server deployments to default to disabled until the server explicitly enables it (previously only FedRAMP hosts), and added the ability to disable error and usage reporting through bootstrap configuration. * Fixed managed MCP connectors: a server that requires authentication now opens a sign-in window even when its configuration does not explicitly enable OAuth, and an `oauth` entry with sign-in fields but a missing or empty `clientId` is now rejected at load with a clear error instead of silently attempting automatic registration. * Fixed managed MCP tool policies that block all tools by default with per-tool exceptions denying the excepted tools in Claude Code sessions. * Fixed sessions, skills, and plugins intermittently disappearing after sign-in or configuration changes. * Fixed the Claude.ai sign-in option being hidden on deployments configured with a bootstrap URL; it is now hidden only when the administrator explicitly disables the deployment mode chooser. * Fixed the bundled Microsoft 365 connector showing only an opaque tool error when its sign-in expired; it now shows an inline Reconnect card. * Fixed the token-cap setup fields so the maximum tokens per window and the token cap window hours are required together; setting only one previously produced a cap that enforced nothing. </Update> <Update label="v1.22209.3" description="2026-07-19"> **General** * Fixed sessions on Windows failing on every turn with a "Socket is closed" error when traffic passed through a corporate proxy that inspects encrypted connections, by updating the bundled Claude Code CLI to 2.1.215. Interrupted responses now retry on a fresh connection instead of ending the turn. **Code** * No user-facing changes. **Cowork** * No user-facing changes. **3P** * No user-facing changes. </Update> <Update label="v1.22209.0" description="2026-07-16"> **General** * Improved responsiveness while artifacts generate, so typing and scrolling stay smooth during generation. * Improved the "Add to project" menu to show only projects you can move into, with your own projects listed first. * Fixed rare freezes when a transcript contained very large whitespace-padded messages or tool output. * Fixed tool errors blaming an organization policy when a site was actually blocked by your own site permissions or settings. **Code** * Added controls for project owners to remove members from a shared project and copy an invite link from the members dialog. * Added per-row actions to queued messages (Edit in composer, Send now, and Remove), with right-click support. * Fixed a new session sometimes taking over the directory another session was still working in. * Fixed Code sessions hanging at startup when skill syncing was slow, and tools on your shell `PATH` staying undetected when shell environment detection timed out at startup. * Fixed freezes, a stuck "loading earlier messages" spinner, and blank rendering when scrolling back through very large session transcripts or when a running task's output grew very large. * Fixed the New session button, `⌘N` (or `Ctrl+N` on Windows and Linux), and the project header "+" discarding an unsent composer draft. **Cowork** * Improved writing drafts to consistently appear as preview cards before being staged in a connected app such as Slack. * Fixed documents Claude creates not reliably opening in the editor. * Fixed files edited by Claude sometimes reading back stale or truncated content on Windows. * Fixed the chat window freezing and not updating while Claude uses your computer. * Fixed the document editor sometimes attributing your own typing to Claude while autosaving. * Fixed working documents disappearing from the Documents panel after a temporary disk error. **3P** * Added `disableBrowserExternalNavigation`, which admins can set to `true` in Claude Code's `managed-settings.json` to keep the Code tab's Browser pane limited to localhost for both users and Claude. Local dev servers and file previews are unaffected. * Added `otlpTracesEnabled` (beta), which also exports OpenTelemetry traces from Cowork tasks and Code sessions to your configured collector. * Updated the allowed workspace folders policy to also apply to Code sessions on SSH hosts, evaluated against the folders on the remote host. * Fixed enforcement of the managed Auto mode opt-out. * Fixed plugins being treated as required by your organization when their marketplace name merely resolved under a required marketplace entry; only the exact entry a name resolves to now applies, so affected plugins can be uninstalled again. * Fixed saving a skill created in chat failing; skills now save to the app's local skill storage.
Cut at 300 lines. The page has the rest.
cowork/guide/dispatch First recorded · 94 lines, first recorded
# Run tasks in the background with Dispatch ## Prerequisites ## Start a Dispatch task ## How Dispatch routes work ## Track task status ## Approve actions Dispatch needs ## Continue from a finished task ## Assign tasks from your phone ## Related
The first capture of this source. The page was already there, and this is what it said.
# Run tasks in the background with Dispatch
> Assign work to a Dispatch agent that plans, runs, and reports on tasks while you do something else, on this computer or from your phone.
Dispatch is a long-running agent in Cowork that takes high-level instructions and carries them out in the background. You describe an outcome in a single conversation; the Dispatch agent breaks it into tasks, runs each one as a separate Cowork or Code session, and surfaces the results in the sidebar when they finish.
Unlike a normal Cowork chat, you don't watch each step. Dispatch is for work you want to start and come back to later.
## Prerequisites
Dispatch requires a Pro or Max plan and the latest Claude Desktop app on macOS or Windows.
## Start a Dispatch task
The Dispatch agent appears as **Dispatch** in the left sidebar. Selecting it opens a single conversation with the agent.
<Steps>
<Step title="Open Dispatch from the sidebar">
Select **Dispatch** in the left side panel.
</Step>
<Step title="Describe the outcome">
Tell the agent what you want done, the same way you'd brief a colleague. For
example: "Summarize the open Linear issues tagged reliability and draft a
status update for the team channel."
</Step>
<Step title="Let Dispatch plan and run">
The agent decides how to split the work and starts one or more child tasks.
Each child task appears under the Dispatch group in the sidebar with its own
status.
</Step>
</Steps>
You converse with one Dispatch agent, but it can run many child tasks beneath that conversation. Child tasks don't spawn further children of their own.
## How Dispatch routes work
The Dispatch agent routes each child task to the surface that fits it.
| Task type | Runs in | Examples |
| -------------- | -------------------------------------------------------------------------------------- | ------------------------------------------ |
| Coding work | Code, against a workspace you've already set up | Fix a bug, open a pull request, run tests |
| Knowledge work | Cowork, in the [project](/docs/cowork/guide/projects) you specify (or your default project) | Research, write a document, organize files |
When starting a task, you can tell the agent which Code workspace or Cowork project to use. If you don't, it lists what's available and chooses.
## Track task status
Each child task shows its current state in the sidebar. Select any task to open its full transcript, the steps Claude took, and any files it produced.
| State | Meaning |
| --------------- | ---------------------------------------------------------- |
| Running | Claude is actively working on the task |
| Awaiting input | The task needs information from you before it can continue |
| Awaiting answer | The task asked you a question and is waiting for a reply |
| Completed | The task finished |
| Error | The task stopped because something went wrong |
| Archived | You marked the task as done and set it aside |
## Approve actions Dispatch needs
When a child task needs permission to take an action (such as running a command or writing a file outside its workspace), the prompt is forwarded to you. If you don't respond within ten minutes, the request is automatically denied and the task continues without that action.
Permission prompts behave the same as in a normal Cowork session.
## Continue from a finished task
Select any child task in the sidebar to open its session. You can read the transcript, send follow-up messages, or ask the Dispatch agent to start a new task that builds on the result.
## Assign tasks from your phone
When Claude Desktop is running, your computer registers as a Dispatch host. From the Claude mobile app, you can start a Dispatch conversation that runs on your desktop, then check results from either device.
<Steps>
<Step title="Keep your desktop ready">
Leave Claude Desktop open with your computer awake and online.
</Step>
<Step title="Open Dispatch on mobile">
In the Claude mobile app, open Dispatch and describe the task. The work runs
on your desktop.
</Step>
<Step title="Review on either device">
Progress and results appear in the Dispatch sidebar on desktop and in the
mobile app.
</Step>
</Steps>
## Related
* [Organize work with projects](/docs/cowork/guide/projects) for the project context Dispatch routes knowledge work into
* [Cowork overview](/docs/cowork/overview) for how Dispatch fits alongside sessions and projects
cowork/guide/plugins First recorded · 96 lines, first recorded
# Install plugins ## What a plugin can contain ## Install a plugin ## Use a Git repository as a marketplace ## Limits ## Plugins managed by your organization ## Update and remove plugins ## Related
The first capture of this source. The page was already there, and this is what it said.
# Install plugins
> Add packaged skills, connectors, and agents to Cowork from the plugin marketplace or a file.
A plugin is a package that extends what Claude can do in Cowork. Installing one can add skills, MCP connectors, subagents, slash commands, or hooks in a single step. Plugins come from the marketplace, from your organization, or from a file you upload.
Plugins are available in Cowork and Code. They aren't used in Chat.
## What a plugin can contain
A plugin's manifest declares any combination of the following.
| Component | What it adds |
| ---------- | ---------------------------------------------------------- |
| Skills | Reusable instructions that teach Claude a workflow |
| Connectors | MCP servers that give Claude access to an external service |
| Agents | Specialized subagents Claude can delegate to |
| Hooks | Scripts that run at defined points in a session |
After installing, open the plugin to see what it provides. Skills and agents appear as tabs; connectors and hooks have their own pages.
## Install a plugin
Open **Customize** in the sidebar, then **Plugins**.
<Steps>
<Step title="Browse the marketplace">
Select **Browse plugins** to see available plugins. The default marketplace
is Anthropic's official catalog; you can add other marketplaces by URL.
</Step>
<Step title="Install">
Select a plugin and click **Install**. If the plugin includes a connector
that needs authentication, you're prompted to sign in.
</Step>
<Step title="Review components">
Open the installed plugin to see its skills, connectors, agents, and hooks.
Enable or disable individual components as needed.
</Step>
</Steps>
To install from a file instead, select the upload option on the Plugins page and select the plugin package.
## Use a Git repository as a marketplace
A Git repository that contains plugin packages can serve as a marketplace. This is the typical way teams distribute their own plugins without publishing to the public catalog. Repositories on GitHub (including GitHub Enterprise) are supported; public repositories on GitLab and Bitbucket also work.
<Steps>
<Step title="Add the repository">
On the Plugins page, select **Add marketplace** and enter the repository's
URL. Cowork accepts the standard `https://github.com/owner/repo` form and
the `owner/repo` shorthand for GitHub.
</Step>
<Step title="Install plugins from it">
Plugins defined in the repository appear alongside plugins from other
marketplaces. Install them the same way.
</Step>
</Steps>
Click **Update** on a marketplace to pull the latest plugins from its repository.
For administrator-managed marketplaces, see [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) in the deployment guide.
## Limits
The following are the default limits for plugin packages and marketplaces.
| Limit | Value |
| ---------------------------------- | ------ |
| Plugin package size (uncompressed) | 200 MB |
| Files per plugin package | 5,000 |
| Marketplace repository archive | 512 MB |
| Plugins per marketplace | 500 |
| Marketplaces you can add | 25 |
The in-app skill viewer previews individual files up to 1 MB. Larger files appear in the file list as "too large to preview" but are still available to Claude at runtime.
## Plugins managed by your organization
On Team and Enterprise plans, administrators can require certain plugins for everyone in the organization. Required plugins install automatically and show **This plugin is required by your organization**; you can't remove them.
For how administrators provision plugins, see [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) in the deployment guide.
## Update and remove plugins
Cowork checks for plugin updates from the marketplace they came from. If you've edited a plugin's files locally, Cowork detects the change and warns you before an update would overwrite it.
To remove a plugin you installed, open it under **Customize → Plugins** and click **Uninstall**. Organization-managed plugins can only be removed by an administrator.
## Related
* [Plugins overview](/docs/plugins/overview) for how plugins work across Claude products
* [Submit a plugin](/docs/plugins/submit) to publish your own to the marketplace
* [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) for administrator provisioning
cowork/guide/projects First recorded · 76 lines, first recorded
# Organize work with projects ## What a project holds ## Create a project ## Work inside a project ## Cowork projects and claude.ai projects ## Archive a project ## Related
The first capture of this source. The page was already there, and this is what it said.
# Organize work with projects
> Group folders, instructions, and context into a Cowork project so Claude starts each session with the right setup.
A Cowork project collects everything Claude needs for a recurring area of work: the local folders to read and write, standing instructions, useful links, and a dedicated memory store. When you start a session inside a project, Claude is already set up with that context.
Projects live on your computer. They aren't synced to the cloud or shared with other people.
## What a project holds
Each project bundles the following, and you can change any of it after creation.
| Item | Purpose |
| ------------------ | ------------------------------------------------------------------------------------- |
| Description | What the project is for; Dispatch reads it when choosing a project for a task |
| Folders | One or more local folders Claude can read and write inside this project's sessions |
| Instructions | Standing guidance applied to every session in the project |
| Links | Reference URLs (documents, dashboards, repositories) Claude can consult |
| Projects from Chat | Projects you made in Chat (claude.ai) whose knowledge this Cowork project can draw on |
| Memory | A project-scoped memory store that persists across sessions |
## Create a project
Open **Projects** in the left navigation and choose the **+** button to start. You're offered three starting points.
<Steps>
<Step title="Choose a starting point">
Select **Start from scratch** to create an empty project with a new folder,
**Import a project** to bring an existing claude.ai project into Cowork, or
**Use an existing folder** to point at a folder you already work from.
</Step>
<Step title="Name and describe it">
Give the project a name and a short description so you can tell it apart in
the sidebar.
</Step>
<Step title="Add folders and instructions">
Attach the local folders Claude should have access to, and write any
standing instructions you want applied to every session.
</Step>
</Steps>
You can attach more folders, links, or projects from Chat at any time from the project's settings.
## Work inside a project
Select a project in the sidebar to start a new Cowork session with that project's folders mounted and instructions applied. Files Claude creates land in the project's folders; what Claude learns during the session is saved to the project's memory for next time.
[Dispatch](/docs/cowork/guide/dispatch) can also route background tasks into a project, so long-running work picks up the same folders, instructions, and memory.
When you drag files or folders into a project, individual files are copied into the project's first folder and folders are mounted as additional project folders. Claude reads individual files up to 50 MB.
## Cowork projects and claude.ai projects
A Cowork project is not the same thing as a project on claude.ai. They're stored separately and have different capabilities.
| | Cowork project | claude.ai project |
| ------------------------ | --------------------- | --------------------------- |
| Lives | On your computer only | In your Claude account |
| Holds local folders | Yes | No |
| Shareable with teammates | No | Yes, on Team and Enterprise |
You can link a claude.ai project into a Cowork project so Cowork sessions can draw on its knowledge. Linking doesn't merge them; the claude.ai project stays where it is.
## Archive a project
Archiving removes the project from your list and deletes its metadata (name, instructions, links, memory). It does not touch the local folders you attached; your files stay exactly where they are on disk.
To archive, open the project's menu in the sidebar and choose **Archive**.
## Related
* [Run tasks in the background with Dispatch](/docs/cowork/guide/dispatch) to run work inside a project without watching each step
* [Install plugins](/docs/cowork/guide/plugins) to extend what Claude can do in a project's sessions
* [Cowork overview](/docs/cowork/overview) for how projects relate to sessions and Dispatch
cowork/monitoring First recorded · 236 lines, first recorded
# Monitoring ## Setup ## Events ### Event correlation ### Standard attributes ### User prompt event ### Model response event ### Tool result event ### API request event ### API error event ### Tool decision event ## Event analysis ## Backend considerations ## Service information ## Security and privacy
The first capture of this source. The page was already there, and this is what it said.
# Monitoring > Track Cowork usage and activity across your organization with OpenTelemetry Track Cowork usage and activity across your organization by exporting events through [OpenTelemetry](https://opentelemetry.io/) (OTel). Cowork exports events via the OTel logs/events protocol, giving you visibility into user prompts, model responses, API requests, tool usage, and errors. <Note> Monitoring is available for Team and Enterprise plans. OTel monitoring requires Claude desktop app version 1.1.4173 or later. </Note> ## Setup Configure monitoring from the Cowork admin settings: 1. Navigate to **Admin settings > Cowork** 2. Configure the following fields: | Field | Description | Example | | ----------------- | ----------------------------------------- | ----------------------------------- | | **OTLP endpoint** | Your OpenTelemetry collector URL | `http://collector.example.com:4318` | | **OTLP protocol** | Transport protocol | `http/json` or `http/protobuf` | | **OTLP headers** | Authentication headers for your collector | `Authorization=Bearer your-token` | 3. Save your settings 4. Start a new Cowork session — settings are loaded at session start, so existing sessions won't pick up the new configuration <Note> The OTel exporter runs inside the Cowork VM, so it is subject to the session's egress rules. If your organization restricts network egress, Cowork automatically adds your collector's hostname to the session's egress allowlist. You don't need to add it at **Admin settings > Capabilities > Network egress**. </Note> ## Events Cowork exports the following events to your OTel collector. By default, events include metadata only. User prompt content, model response text, and tool details are included only when you enable them with the [`otlpContentCapture`](/docs/third-party/claude-desktop/telemetry#content-capture) setting. ### Event correlation When a user submits a prompt, Cowork may make multiple API calls and run several tools. The `prompt.id` attribute links all events back to the single prompt that triggered them. | Attribute | Description | | ----------- | ------------------------------------------------------------------------------------ | | `prompt.id` | UUID v4 identifier linking all events produced while processing a single user prompt | To trace all activity triggered by a single prompt, filter your events by a specific `prompt.id` value. On third-party deployments, you can additionally enable OpenTelemetry trace export with the [`otlpTracesEnabled`](/docs/third-party/claude-desktop/telemetry#traces-beta) setting (beta). When it is enabled, events emitted while a prompt is processed also carry `trace_id` and `span_id`, linking them to the session's trace spans for end-to-end correlation in your observability backend. ### Standard attributes All events include these attributes: | Attribute | Description | | ---------------------- | -------------------------------------------------------------------------------------------- | | `session.id` | Unique session identifier | | `organization.id` | Organization UUID | | `user.account_uuid` | User's account UUID | | `user.account_id` | Account ID in tagged format matching Anthropic admin APIs (for example, `user_01BWBeN28...`) | | `user.id` | Anonymous device/installation identifier | | `user.email` | User email | | `workspace.host_paths` | Host workspace directories selected in the desktop app (string array) | | `terminal.type` | Terminal type (`non-interactive` for Cowork) | <Note> The account attributes — `organization.id`, `user.account_uuid`, `user.account_id`, and `user.email` — are populated from the user's Anthropic account, so they appear on first-party deployments only. On [third-party deployments](/docs/third-party/claude-desktop/overview) there is no Anthropic account and these attributes are absent; instead, the export carries the signed-in user's identity as the `enduser.id` resource attribute, described under [User attribution](/docs/third-party/claude-desktop/telemetry#user-attribution). The `process.owner` resource attribute (the operating-system login name) is standard OpenTelemetry process metadata and is present on all deployments. </Note> ### User prompt event Logged when a user submits a prompt. **Event name**: `user_prompt` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | --------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `prompt_length` | Length of the prompt | | `prompt` | Prompt content | ### Model response event Logged when the model completes a response that includes text output. Requires Claude desktop app version 1.17377 or later. **Event name**: `assistant_response` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `model` | Model that produced the response | | `request_id` | API request identifier | | `response_length` | Length of the response | | `response` | Model response text. Includes text output only; thinking content is excluded. Truncated to 60 KB. When model response capture is disabled, the value is the literal string `<REDACTED>`. | Model responses are captured when [`otlpContentCapture`](/docs/third-party/claude-desktop/telemetry#content-capture) includes `assistantResponses`, and also whenever user prompts are captured. ### Tool result event Logged when a tool completes execution. **Event name**: `tool_result` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `tool_name` | Name of the tool | | `success` | `"true"` or `"false"` | | `duration_ms` | Execution time in milliseconds | | `error` | Error message (if failed) | | `decision_type` | Either `"accept"` or `"reject"` | | `decision_source` | How the decision was made — `"config"`, `"hook"`, `"user_permanent"`, `"user_temporary"`, `"user_abort"`, or `"user_reject"` | | `tool_result_size_bytes` | Size of the tool result in bytes | | `mcp_server_scope` | MCP server scope identifier (for MCP tools) | | `tool_parameters` | JSON string containing tool-specific parameters, including `mcp_server_name` and `mcp_tool_name` for MCP tools | | `tool_input` | JSON-serialized tool arguments. Individual strings over 512 characters are truncated; entire string limited to \~4K characters. Applies to all tools including MCP tools. | ### API request event Logged for each API request to Claude. **Event name**: `api_request` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------------- | --------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `model` | Model used (e.g., `claude-sonnet-5`) | | `cost_usd` | Estimated cost in USD | | `duration_ms` | Request duration in milliseconds | | `input_tokens` | Number of input tokens | | `output_tokens` | Number of output tokens | | `cache_read_tokens` | Number of tokens read from cache | | `cache_creation_tokens` | Number of tokens used for cache creation | | `speed` | `"fast"` or `"normal"` | ### API error event Logged when an API request to Claude fails. **Event name**: `api_error` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | --------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `model` | Model used | | `error` | Error message | | `status_code` | HTTP status code as a string, or `"undefined"` for non-HTTP errors | | `duration_ms` | Request duration in milliseconds | | `attempt` | Attempt number (for retried requests) | | `speed` | `"fast"` or `"normal"` | ### Tool decision event Logged when a tool permission decision is made. **Event name**: `tool_decision` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------ | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `tool_name` | Name of the tool | | `decision` | Either `"accept"` or `"reject"` | | `source` | Decision source — `"config"`, `"hook"`, `"user_permanent"`, `"user_temporary"`, `"user_abort"`, or `"user_reject"` | ## Event analysis The exported events support a range of analyses: **Tool usage patterns** — Analyze tool result events to identify most frequently used tools, success rates, average execution times, and error patterns. **Cost monitoring** — Track `cost_usd` from API request events to understand usage trends across users and teams. Group by `user.account_uuid` or `organization.id` for per-user or per-team breakdowns. **Performance monitoring** — Track API request durations and tool execution times to identify performance bottlenecks. <Note> Cost values from events are approximations. For official billing data, refer to your billing dashboard. </Note> ## Backend considerations Your choice of logs backend determines the types of analyses you can perform: * **Log aggregation systems** (e.g., Elasticsearch, Loki): Full-text search and log analysis * **Columnar stores** (e.g., ClickHouse): Structured event analysis and complex queries * **Observability platforms** (e.g., Honeycomb, Datadog): Advanced querying, visualization, and alerting ## Service information All events are exported with the following resource attributes: | Attribute | Description | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `service.name` | `cowork` | | `service.version` | Claude app version | | `host.arch` | Host architecture (e.g., `arm64`) | | `os.type` | Operating system type (e.g., `darwin`) | | `os.version` | Operating system version string | | `enduser.id` | The signed-in user's identity, on third-party deployments only. Controlled by the [`endUserAttribution`](/docs/third-party/claude-desktop/configuration#enduserattribution) setting; see [User attribution](/docs/third-party/claude-desktop/telemetry#user-attribution). | | `process.owner` | Operating-system login name | ## Security and privacy * Events are only exported when an admin configures the OTLP endpoint * User prompt content is included only when you enable `userPrompts` in [`otlpContentCapture`](/docs/third-party/claude-desktop/telemetry#content-capture) * On Claude desktop app version 1.17377 or later, model response text is included when you enable `assistantResponses` in `otlpContentCapture`, and also whenever user prompt content is included * The `tool_input` attribute (file paths, URLs, search patterns, and other arguments) is included only when you enable `toolDetails` in `otlpContentCapture` * On first-party deployments, `user.email` is always included in event attributes, so configure your telemetry backend to filter or redact it if this is a concern * On third-party deployments, `user.email` is absent; the export identifies users with the `enduser.id` resource attribute, controlled by the [`endUserAttribution`](/docs/third-party/claude-desktop/configuration#enduserattribution) setting
cowork/overview First recorded · 36 lines, first recorded
# Overview ## Key capabilities ## Extend Cowork with integrations
The first capture of this source. The page was already there, and this is what it said.
# Overview
> Learn about Cowork, Anthropic's agentic workspace
Cowork uses the same agentic architecture that powers Claude Code, accessible within Claude Desktop without opening the terminal. Rather than responding to prompts sequentially, Claude tackles intricate, multi-step tasks autonomously. Describe a desired outcome, then return later to completed work — polished documents, organized files, synthesized research, and more.
## Key capabilities
* **Works directly on your computer** — Claude reads and writes local files without requiring manual uploads or downloads.
* **Claude in Chrome** — Pair [Claude in Chrome](https://claude.com/chrome) with Cowork to automate your tasks on any website.
* **Sub-agent coordination** — Complex work gets divided into smaller tasks with parallel workstreams for faster results.
* **Professional outputs** — Creates polished deliverables including Excel spreadsheets with functional formulas, PowerPoint presentations, and formatted documents.
## Extend Cowork with integrations
Cowork supports the same extensibility features available across Claude products:
<Columns cols={2}>
<Card title="Connectors" icon="plug" href="/docs/connectors/overview">
Connect Claude to your tools and data sources using MCP.
</Card>
<Card title="Skills" icon="wand-magic-sparkles" href="/docs/skills/overview">
Teach Claude reusable workflows with custom instructions.
</Card>
<Card title="Plugins" icon="puzzle-piece" href="/docs/plugins/overview">
Bundle skills, connectors, and more into shareable packages.
</Card>
<Card title="Monitoring" icon="chart-line" href="/docs/cowork/monitoring">
Track usage and activity across your organization.
</Card>
</Columns>
You manage connectors, skills, and plugins from **Customize** in the sidebar. Cowork loads the ones enabled for your claude.ai account, synced at session start, and doesn't read the [Claude Code](https://code.claude.com/docs/en/skills) CLI's `~/.claude` directory on your machine. To use a skill or plugin that exists only in `~/.claude`, add it in **Customize**.
government/account/overview First recorded · 29 lines, first recorded
# Your account ## What's here ## The page footer ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Your account > Check your own account details, usage limits, and active sessions. > **Who this is for:** Anyone with a Claude for Government account. The Account portal is where you view your own details rather than manage other people. It covers your own identity details, your personal usage allowance, and the places you are currently signed in. Nothing you do here affects any other user. Every user has access to this portal regardless of what role they hold. If you are a regular user with no administrative role, this is also where you land immediately after signing in, and it is the only part of the web portal you will see. > **For organization owners:** You land in the organization admin area instead when you sign in. You can reach your own account pages at any time from the **Switch to user view** link in the page footer, and return the same way. ## What's here * The [**Account**](/docs/government/account/profile) tab shows who you are, including your name, email address, organization, role, and seat tier. Everything on this tab is read-only. Your name and email come from your agency's directory; your organization, role, and seat tier are set by your directory or by an administrator. * The [**Usage**](/docs/government/account/usage) tab shows how much of your personal allowance you have used in the current 5-hour and 7-day windows, and when each one next resets. If you have hit a limit and Claude is paused, this tab is marked with a pulsing indicator in the navigation so you can spot it at a glance. * The [**Sessions**](/docs/government/account/sessions) tab lists every browser and desktop application where you are currently signed in, with the option to sign any of them out remotely. ## The page footer At the bottom of every page in this portal you will find your email address and a **Sign out** button. Signing out from the footer ends the session you are currently using and, where your agency uses single sign-on, also ends your session with the identity provider so that you will be prompted for credentials the next time you visit. > **For organization owners and tenant administrators:** The footer also includes a **Switch to admin view** link that takes you back to the administrative area. ## Things to know * **Nothing here is editable.** Your name, email, organization, role, and seat tier are all set in your agency's directory or by an administrator, and they flow into Claude for Government automatically. If any of these details are wrong, the [Account](/docs/government/account/profile) page explains where each one comes from and who to contact. * **The three tabs are independent.** Looking at your usage or your sessions has no effect on the other tabs, and the Sign out button in the footer works from any of them. * **The pulsing indicator on the Usage tab is the only alert in this portal.** It appears while either of your usage limits is full and disappears on its own once the limit resets.
government/account/profile First recorded · 45 lines, first recorded
# Account ## What you'll see ## How to change these details ## If your seat tier says "No seat assigned"
The first capture of this source. The page was already there, and this is what it said.
# Account > Use this page to confirm that you are signed in as the right person and to see what access you have been given. > **Who this is for:** Anyone with a Claude for Government account. Use this page to confirm that you are signed in as the right person and to see what access you have been given. The **Account** tab is the landing page of the user area. It shows the basics of your account in one place: your name and avatar at the top, followed by four fields that describe your access. Everything on this page is read-only. The values come from your agency's identity system and from settings that an administrator controls, so this page is for checking your details rather than changing them. ## What you'll see | Field | What it means | Where it comes from | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | **Email** | The address you sign in with. It is the unique identifier for your account, and notifications such as sign-in links are sent to it. | Your agency's identity provider. | | **Organization** | The organization you belong to within your agency's tenant. A tenant is your agency's overall space in Claude for Government, and it can contain several organizations (for example, one per bureau or office). Your organization determines which administrators manage your access and which usage pool your activity draws from. | Set when your account was created or when directory sync placed you. | | **Role** | What you are allowed to manage. **User** means you can use Claude but do not administer anything. **Owner** means you can manage your organization's users, seats, and settings. **Primary Owner** is the same as Owner with a few additional safeguards: a primary owner cannot be removed by other owners, and each organization can have at most three of them. | Assigned by an organization owner or by directory sync. | | **Seat tier** | The allowance you have been given. A seat tier is a named package that sets two things for you: how much Claude usage you get (shown on the [Usage](/docs/government/account/usage) tab) and which Claude models you are allowed to use. The tiers themselves, their names, and what each one includes are defined by your agency, so the name you see here is specific to your deployment. | Assigned to you by an organization owner. | The name and avatar at the top come from your agency's directory. The avatar is generated from your name; you cannot upload a custom picture. ## How to change these details None of these fields can be edited on this page. Where to go instead depends on the field: * **Name or email.** These are owned by your agency's identity provider or directory. Update them there, and the change flows into Claude for Government automatically the next time you sign in or the next time directory sync runs. You do not need to do anything inside Claude for Government. * **Organization.** Users cannot move themselves between organizations. If you have been placed in the wrong organization, ask your organization's owner or a tenant administrator to move you. * **Role.** An organization owner can promote or demote users between **User** and **Owner** in the administrative area. Ask your organization's owner if your role needs to change. * **Seat tier.** An organization owner assigns and changes seat tiers from the administrative area. See the next section if yours is missing. <Tip> If you are helping a colleague troubleshoot, ask them to read out this page. It tells you in one screen which organization they are in, what role they hold, and whether they have a seat, which is usually enough to diagnose a "Claude is not working for me" report. </Tip> ## If your seat tier says "No seat assigned" <Note> This section only appears when you do not have a seat tier. If a tier name is shown in the Seat tier field, you can skip this section. </Note> Without a seat tier you can sign in and see the portal, but you cannot send any messages to Claude, and the [Usage](/docs/government/account/usage) tab will show "No seat tier assigned" instead of your allowance. This is the expected state for a brand-new account that has not yet been given a seat, or for an account whose seat was deliberately removed. Ask your organization's owner to assign you a seat. Once they do, the tier name appears here immediately and you can start using Claude straight away without signing out and back in. > **For organization owners:** When you view your own profile with no seat, the page links you straight to **Admin → Users** so you can assign yourself one. Owners are not given a seat automatically; administrative access and Claude usage are granted separately, so you must assign a seat to yourself the same way you would for any other user.
government/account/sessions First recorded · 54 lines, first recorded
# Sessions ## What each row shows ## What is not shown ## How long sessions last ## Signing out of other sessions ### What actually happens when you sign out another session ## If you see a session you don't recognize
The first capture of this source. The page was already there, and this is what it said.
# Sessions > Use this page to see every place you are currently signed in to Claude for Government and to sign out of any of them remotely. > **Who this is for:** Anyone with a Claude for Government account. Use this page to see every place you are currently signed in to Claude for Government and to sign out of any of them remotely. A session is created each time you sign in, whether that is in a web browser or in the Claude desktop application. This page lists your active sessions so you can confirm that nothing unexpected has access to your account, and clean up after yourself on a computer you no longer have. ## What each row shows Each row is one active sign-in. The one you are using right now is labeled **this session** and always appears at the top of the list; the rest are ordered with the most recent first. * **Client** tells you which kind of application the sign-in is for. It shows **Browser** for a web sign-in, or **Desktop app** for the Claude application installed on a computer. * **via …** tells you how that session was established. **Single sign-on** means you authenticated through your agency's identity provider. **Device pairing** means a code shown in the desktop application was entered and approved in a browser, linking that application to your account. **Email link** means a one-time link was sent to your inbox and followed to sign in. * **Signed in** tells you when the session started. The time is shown in your local time zone along with a relative hint such as "2 days ago". ## What is not shown To limit how much information about your devices is held in the system, the list deliberately does not include IP addresses, locations, device names, or browser details. You can tell a browser session from a desktop session and you can see when each one started, but you cannot tell two browser sessions apart by device. When in doubt, sign out anything you cannot positively account for; signing back in is quick. ## How long sessions last Sessions expire after a period of inactivity, and using a session extends it. Once you have been inactive for longer than the idle timeout, that browser tab or desktop application prompts you to sign in again the next time it tries to do anything. The idle timeout is set by your agency or organization; unless they have chosen a shorter value, it is 24 hours. Your agency or organization can set a maximum session length in addition to the idle timeout. When a session reaches that length, it expires even if you have been using it the whole time, and the browser tab or desktop application prompts you to sign in again. Sessions that expire either way drop off this list automatically. Sessions can also end early in three ways: you sign one out from this page, you use the **Sign out** button in the page footer to end the session you are currently using, or an administrator deactivates your account or your organization, which immediately invalidates every session you have. ## Signing out of other sessions <Note> These controls only appear when you have sessions besides the one you are using. If this is your only sign-in, the list shows just the current session and no sign-out buttons. </Note> * To end one session, select **Sign out** on its row. * To end everything except the one you are using, select **Sign out *N* other sessions** below the list. Neither of these affects the session you are currently using, and there is no confirmation prompt; the session is revoked as soon as you select the button. To sign out of the session you are using right now, use the **Sign out** button in the page footer instead. ### What actually happens when you sign out another session The sign-out is recorded the moment you select the button. The other browser or desktop application is not sent a live message, but the very next thing it tries to do (load a page, send a message, or refresh) will be refused and it will be returned to the sign-in screen. In practice this means the other session is cut off within seconds of any activity. A request that was already in flight at the instant you revoked may finish, but nothing new can start. Signing out another session from this page does not touch your agency's single sign-on session, so if the person at that other computer tries to sign back in, the identity provider may still let them straight through without re-entering a password. If that is a concern (for example, you left a shared computer signed in), sign the session out here first, then contact your agency's identity team to end the single sign-on session, or change your directory password. <Tip> Signing out here versus signing out from the footer behave differently at the identity provider. The footer **Sign out** ends both your Claude for Government session and your single sign-on session, so you will be asked for credentials the next time you visit. The per-row **Sign out** on this page ends only the Claude for Government session and leaves single sign-on alone. </Tip> ## If you see a session you don't recognize Sign it out from here right away. You can use **Sign out *N* other sessions** if you want to be certain you have cleared everything. If an unrecognized session reappears after you have done so, or anything else about the list looks wrong, report it to your organization's administrator so they can investigate through your agency's identity system.
government/account/usage First recorded · 68 lines, first recorded
# Usage ## How limits work ## When a limit fills up ## Reading the reset times ## Keeping the numbers current ## If you keep hitting limits ## If the page says "No seat tier assigned"
The first capture of this source. The page was already there, and this is what it said.
# Usage > Use this page to see how much of your Claude allowance you have used and when it refreshes. > **Who this is for:** Anyone with a Claude for Government account. Use this page to see how much of your Claude allowance you have used and when it refreshes. Check this page if Claude tells you that you have reached a limit, or if you simply want to see how much headroom you have left before you start a large piece of work. Claude Desktop does not show how much of your allowance you have used. To check, sign in to the web portal in your browser and open the **Usage** tab. ## How limits work Your seat tier (the allowance package an administrator has assigned to you) gives you two rolling windows that run at the same time: * The **5-hour window** limits how much you can use in a short burst. * The **7-day window** limits how much you can use across a whole week. Each window shows a progress bar, a percentage from 0% to 100%, and the time it next resets. The bar will never show more than 100% even if your last message pushed you slightly past the line. Both windows refill automatically on their own schedules, so you never need to do anything to get your allowance back. Usage is not counted in messages. Each message to Claude consumes an amount of your allowance proportional to how much work it takes to answer, so a short question uses very little while a long conversation or a request that produces a lot of output uses more. That is why the page shows a percentage rather than a message count. If a request to Claude fails because of a problem on the service side, the allowance it would have used is given back to you automatically. If you cancel or close a response while it is still being written, that message still counts against your allowance. ## When a limit fills up If **either** window reaches 100%, your Claude access pauses until that window resets. While paused you can still sign in, browse the portal, and review past conversations, but you cannot send new messages. When this happens, you will see a banner at the top of this page telling you which limit you have hit and when it will clear, and the **Usage** tab in the navigation is marked with a pulsing indicator so you can spot it from anywhere in the account area. If both windows happen to be full at the same time, the banner names the one that resets later, since that is the one actually holding you. <Note> The paused banner and the navigation indicator only appear while a limit is actually at 100%. Once the window resets, both disappear on their own. </Note> The page also shows your seat tier name in the top right, so you can tell at a glance which allowance you are on. Below the windows there is a **How do these limits work?** link that expands a short plain-language summary, which can be useful when walking a colleague through the page. <Tip> This page shows your personal limits only. If you are on a self-managed seat tier, your organization also draws from a shared credit balance. If that balance runs out or your organization reaches a spend cap your tenant administrator set, Claude will tell you that your organization is out of credits rather than that you have reached a limit, and nothing on this page will look full. A spent balance is resolved by Anthropic adding credits to the account. A reached spend cap clears when the rolling window moves forward or when a tenant administrator raises the cap. </Tip> ## Reading the reset times Each window can be in one of three states, and the text beneath its label tells you which: * **Resets …** means the window is running. You will see a countdown such as "in 2 hr" if the reset is less than a day away, or a date and time if it is further out. Hover over the text to see the other format. Reset times always land on the top of an hour; the clock starts from the hour in which you sent your first message in the window, so your 5-hour window always ends on a round hour rather than at an odd number of minutes. * **Starts when a message is sent** means you have not used anything in this window yet. The window has no timer at all until you send your first message, at which point the countdown starts and the percentage begins to climb. * **Resets on next request** means the window's time has already passed but you have not sent anything since. The display may still show the old percentage, but the very next message you send will clear it to 0% and start a fresh window. You are not actually limited in this state even if the bar looks full. ## Keeping the numbers current The **Last updated** line at the bottom tells you when these figures were fetched. The page does not refresh on its own while you have it open, so if you have been using Claude in another tab or in the desktop application, the numbers here can fall behind. Select the refresh icon next to **Last updated** to pull the latest figures, or simply leave the page and come back. ## If you keep hitting limits Your organization owner can move you to a seat tier with a larger allowance. The tiers that are available, and what each one includes, are defined by your agency, so ask your administrator which options exist. When an administrator changes your seat tier, the usage you have already accumulated in each window carries over; what changes is the size of the allowance it is measured against. This means the percentages on this page will jump the moment the change is made: moving to a larger tier makes the same usage a smaller share of the new allowance, so the bars drop, while moving to a smaller tier makes them rise and can put you straight into a paused state if you had already used more than the new tier allows. The windows still reset at the same times they would have before. Separately from changing your tier, an administrator can also reset your usage windows, which clears both bars to 0% immediately. This is a distinct action that an administrator takes deliberately; it does not happen automatically as part of a tier change. ## If the page says "No seat tier assigned" <Note> This message replaces the whole page and only appears when you do not have a seat. If you can see the progress bars, this does not apply to you. </Note> You do not have a seat yet, so there is no allowance to show and you cannot send messages to Claude. Ask your organization owner to assign you one. Once they do, this page will show your limits straight away without you needing to sign out and back in.
government/config/overview First recorded · 105 lines, first recorded
# How Config works ## How settings are applied ### Setting kinds ### Locks ## When changes take effect ## Working with the list ## Previewing impact ## Comparing settings across levels ### Looking up one person's settings ## Group-specific settings ### When someone belongs to more than one group ## What differs between the tenant and organization levels ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# How Config works > Understand how product settings in Claude for Government are resolved across the tenant, directory groups, and organizations, and how to find, change, compare, and lock them. > **Who this is for:** Tenant administrators and organization owners who set product behavior for the people they manage. The **Config** page in the admin portal is where you set product behavior such as the session timeout, Claude Desktop banner, product availability, and telemetry for the people you manage. The same page appears at both the tenant and the organization level, with the same list of settings, and this page explains how the two levels fit together. For the settings themselves, see [Available settings](/docs/government/config/settings). ## How settings are applied Each setting is resolved through a chain that runs from the Anthropic default, to your tenant, to each organization. Directory groups add two further levels, described under [Group-specific settings](#group-specific-settings) below. A value set at any level becomes the starting point for the levels below it. An organization that doesn't set a value uses the tenant's value, and a tenant that doesn't set a value uses the Anthropic default. When you expand a setting you can see each step of this chain, which value is currently **In effect**, where it came from, and (in the tenant view) which organizations have set their own value. ### Setting kinds Settings combine across the chain in one of three ways, and the kind is fixed per setting (you don't choose it): * A **simple value** is replaced at each level, and the most specific level that set it wins. Most settings work this way. * A **restriction** is a limit where the tightest value across all levels wins. Any level can tighten the limit but none can loosen it. For example, if the tenant sets a session timeout of 30 minutes, an organization can set 15 but cannot set 60. The value that takes effect is always the shortest one in the chain. * A **collection** accumulates entries from each level. A level can add entries to what the level above provided, or replace the list entirely. ### Locks A **lock** prevents levels below from changing a setting. When you lock a setting at your level it shows as **Enforced** to you, and levels below see it as **Managed**, which means it is read-only for them. Any value a lower level had previously set is ignored while your lock is in place, and it comes back into effect if you later remove the lock. A tenant lock makes the setting read-only for every organization. A lock you set at the organization level prevents any group-level value within your organization from taking priority over it. **Locked by Anthropic** is the **Managed** state when the lock was applied by Anthropic at the application level rather than by your own tenant. It appears on features that are not available in Claude for Government, and only Anthropic can change or unlock those settings. Settings that may contain secrets, such as telemetry headers, are never echoed back in the chain view. You see that a value is set, but not what it is. ## When changes take effect Settings that govern the admin portal, such as whether organizations may manage seat tiers, apply immediately. Settings that govern the Claude applications themselves, such as the Claude Desktop banner, product availability, and telemetry endpoint, are delivered to each member's application the next time it refreshes its configuration, which happens when the application is launched or the member signs in. You do not need to push anything, but members who are currently running the application may need to restart it to pick up a change. Lowering the session idle timeout applies to new sign-ins only, and so does raising or removing the maximum session length. Lowering the maximum session length, or setting one for the first time, also reaches members who are already signed in, taking up to one idle timeout period to do so, as described under [Maximum session length](/docs/government/config/settings#maximum-session-length). ## Working with the list Settings are grouped by category in the sidebar on the left. Select a category to see its settings; the number beside each category shows how many settings it contains. Each setting appears as an expandable card showing its name, a one-line description, which products it applies to, its current value, and where that value comes from (for example, **From Anthropic default** or **Set at tenant**). Click a card to expand the full chain and the editor. The scope bar above the list shows which level you are editing and lets you switch between levels when you have access to more than one. Use **Compare config across levels** to see every setting side by side across the full chain. To change a setting, expand it, adjust the value, and save. To remove your value and return to whatever the level above provides, reset it. ## Previewing impact After you change a setting at the tenant level, a **Preview impact** button appears next to **Save changes**. Select it to see a table listing every organization with its current effective value and what it would become after your change. Organizations where nothing would change are marked **unchanged**. This is especially useful when locking a setting, so you can see which organizations currently have a different value that your lock will take priority over. Preview isn't available for settings whose values are hidden for security reasons (for example, settings that can contain authorization tokens). For those settings the preview shows whether a value is set rather than what it is. <Note> **Preview impact** is available at the tenant level because it shows the effect of a tenant change across every organization. It does not appear at the organization level. </Note> ## Comparing settings across levels Select **Compare config across levels** at the top of the Config page to open a read-only table that lays every setting out side by side across the full chain. This view is for understanding how a value got to be what it is, and for spotting which levels have set their own value for which settings. You can't change anything from here; each row has an **Edit** link that takes you back to that setting on the main Config page. The table has one row per setting and one column per level in the chain: the **Anthropic default**, your **Tenant**, **Groups** (tenant-wide group settings), each **Organization** you can see, **Org groups** (group settings scoped to one organization), and the **Final value** that actually takes effect. A dash means that level has not set a value for that setting. A lock icon next to a value means that level has locked it, and anything below it in the chain is ignored. Use the **All levels** / **Final only** toggle to hide the middle columns and show just the setting, where it was set, and the final value. Before you pick a person, the **Groups** and **Organization** columns list every group and organization that has set its own value for that setting, so you can see at a glance where different values have been set across the levels you can see. ### Looking up one person's settings Type a name into the search box above the table to see exactly what settings apply to that person. The table re-resolves every setting from that person's point of view: the **Groups** column shows the value from the one group that applies to them (with any lower-priority groups they belong to shown faded, since those do not count), the **Organization** column shows their organization's value, and the **Final value** column shows what they actually get. A summary card above the table lists the tenant, group, and organization being used for the lookup. Click any row to expand a plain-English explanation of how the final value was reached, for example "Anthropic's default is On. Your tenant hasn't changed it. The Program-Reviewers group sets this to Off." This is the quickest way to answer a question like "why is this turned off for this person?" or "why can't this person use Code in Claude Desktop?" ## Group-specific settings In addition to setting values for your whole tenant or organization, you can set values for the members of a directory group. A directory group is a group that your identity provider has pushed to Claude for Government over SCIM, as described on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page. There are two kinds of group level: * **Tenant-wide group settings** sit between the tenant and the organization in the chain. A value set here takes priority over the tenant default for the group's members, in every organization they belong to. Tenant administrators manage these. * **Organization group settings** are scoped to one organization. A value set here applies only to people who are both a member of the group and a member of that organization, and it is the most specific level in the chain. Organization owners manage these for their own organization and see the same list of groups the tenant does. To edit settings for a group, open the scope bar above the settings list and choose the group's name from the dropdown. The page switches to show the same settings editor, now scoped to that group. Editing, saving, resetting, and locking all work the same way as at the other levels. Anything locked at a higher level still shows as **Managed** here and cannot be changed. ### When someone belongs to more than one group Only one group's settings apply to any given person. When someone is a member of more than one group, the settings from their highest-priority group that has any configuration are used, and the other groups are ignored for that person. The priority order is set by a tenant administrator on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page by dragging the groups into the order they want. The same priority order is used wherever configuration is resolved for a person; seat-tier group mappings on the [Provisioning](/docs/government/org-admin/provisioning) page use a separate fixed order. At the organization level the priority order is shown for reference and cannot be reordered there. If no groups appear in the scope bar dropdown, none have been synced from the identity provider yet. Connect SCIM on the Identity and access page and push groups from your directory, and they will appear automatically. <Note> Two settings, **Organization instructions** and **Organization Analytics connector**, can be set at the tenant and organization levels but not at either group level. </Note> ## What differs between the tenant and organization levels The Config page shows the same list of settings at both levels, and almost all of them can be set at either level. The genuine differences are: * **Two settings can be set only by a tenant administrator.** [Let organizations manage their own seat tiers](/docs/government/config/settings#let-organizations-manage-their-own-seat-tiers) and [Compliance API](/docs/government/config/settings#compliance-api) appear on both pages, but are always read-only at the organization level. * **Preview impact appears only at the tenant level.** See [Previewing impact](#previewing-impact) above. * **Group priority is set at the tenant level.** Organization owners see the priority order for reference but cannot change it. * **Tenant administrators can open any organization's Config page** and act on that organization's behalf. Organization owners see only their own organization. * **Inherited plugins are labeled at the organization level.** Plugins the tenant has added appear under a **From levels above** heading on the organization page; see [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards). For more detail see [Config at the tenant level](/docs/government/tenant-admin/configuration) and [Config at the organization level](/docs/government/org-admin/configuration). ## Things to know * Some settings can only be changed by tenant administrators (and not by organization owners at all), regardless of whether they are locked. These are noted in the [Available settings](/docs/government/config/settings) descriptions. * Resetting a setting removes only that level's value. Values set at other levels are unaffected and remain in effect once yours is gone.
government/config/plugins-and-connectors First recorded · 69 lines, first recorded
# Manage plugins and connectors ## Plugins versus connectors ## Plugin archive formats ### What a plugin archive can contain ## Plugins that run code ## Install behavior ## Where plugins are added ## Update or remove a plugin ## Connector tool policies for members
The first capture of this source. The page was already there, and this is what it said.
# Manage plugins and connectors > Choose between plugins and connectors in Claude for Government, prepare plugin archives for upload, decide how plugins install for members, update and remove plugins, and understand how connector tool policies apply to members. > **Who this is for:** Tenant administrators and organization owners who deliver plugins and connectors to the members they manage. You add plugins on the **Plugins** card and connectors on the **Connectors** card of the **Config** page in the admin portal. The card controls themselves are described under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards), and this page covers the tasks around them, from choosing between a plugin and a connector to keeping plugins up to date. To distribute skills to members, bundle them in a plugin, as described under [Skills for administrators](/docs/government/desktop/skills#skills-for-administrators). ## Plugins versus connectors A connector gives Claude access to another service, such as a search tool your agency runs, and the **Connectors** card is the way to deliver a connector to members. A plugin is a package that changes how Claude works. It can add skills, slash commands, and sub-agents, and it can carry hooks, which are scripts a plugin author includes to run automatically at defined points during a session, such as when a session starts. For adding a connector, see [Connectors](/docs/government/connectors/overview). For what a plugin can contain across Claude products, see the [Plugins overview](/docs/plugins/overview); the Claude for Government differences are covered below. A plugin you upload on the **Plugins** card delivers its skills, slash commands, sub-agents, and hooks to members, and its hooks run on the member's machine. In Claude for Government, a connector declared in a plugin you upload here is not connected, so to give members a connector, add it on the **Connectors** card instead. ## Plugin archive formats The **Plugins** card accepts a single `.zip` file. The file can be one plugin package or a marketplace archive that holds several plugins, such as the downloaded ZIP of a repository that publishes a set of plugins. A single plugin package can be up to 10 MB, and a marketplace archive can be up to 15 MB. When you upload a marketplace archive, the preview lists the plugins it found, and you select which ones to add. Only plugins whose files are packaged inside the archive are added, so an entry in the marketplace listing that points to a plugin hosted elsewhere is skipped. The plugins you add from one archive are grouped under a **Tag**, prefilled from the marketplace's name, which lets you identify the set later. To refresh the set, upload a new version of the same marketplace archive with the same **Tag**. The preview lists any plugin you added from that marketplace before that the new version no longer contains, and you can remove those plugins in the same step. ### What a plugin archive can contain A plugin package is laid out around a manifest at `.claude-plugin/plugin.json`. The [plugins reference](https://code.claude.com/docs/en/plugins-reference) describes the general plugin format. Claude for Government accepts the narrower set described here, so a package that follows only the general reference can be rejected. The manifest is a JSON object, saved as UTF-8 without a byte-order mark, which some Windows editors add unless told otherwise. It has two required keys. `name` becomes the plugin's identity everywhere it appears, in lowercase letters, digits, hyphens, and underscores, up to 64 characters and starting with a letter or digit. `version` is 1 to 64 characters. Add a short `description` for the preview and the plugin's row. Uploading an archive whose name matches a plugin you already added replaces that plugin, whatever the two versions say. Content sits in a fixed set of folders, all lowercase and case-sensitive: `skills/`, `commands/`, `agents/`, `hooks/`, and `monitors/`, plus `.claude-plugin/` for the manifest and an optional `icon.png`. Each folder accepts specific file types. `commands/` and `agents/` take `.md` files, `hooks/` and `monitors/` take `.json` files, and `skills/` takes six text formats (`.md`, `.txt`, `.json`, `.yaml`, `.yml`, `.csv`). The root can also hold `README.md`, `LICENSE`, `LICENSE.txt`, `CLAUDE.md`, `CONNECTORS.md`, and `.mcp.json`. Other text files in those six formats, at the root or in folders of your own, are accepted but not used by Claude. Any other file type, anywhere in the archive, is rejected. Apart from the optional icon, everything in an archive must be text in UTF-8. There is no way to ship a script, or any other binary asset such as an image, through the card, which is narrower than what members can add to skills on their own devices. File and folder names must be ASCII. Nothing in the archive may start with a dot apart from `.claude-plugin/` and a root `.mcp.json`: repository files such as `.github/` or `.gitattributes` must be left out, while `.gitignore` and `.DS_Store` are dropped for you. Paths inside the zip must use forward slashes: File Explorer's **Compress to ZIP file**, 7-Zip, `tar.exe`, PowerShell 7, and Python's `zipfile` all write them, while Windows PowerShell 5.1's `Compress-Archive` can write backslash paths, which the upload rejects. A zip that wraps everything in one top folder, which is what zipping the plugin folder or downloading a repository as a ZIP produces, works, as long as the repository holds no other dot-prefixed files. The upload looks inside the wrapper. Apple's `__MACOSX/` folders are dropped quietly too, and an archive can hold up to 50 MB of uncompressed content. Inside `skills/`, each skill is one folder holding a `SKILL.md` whose frontmatter `name` matches the folder name, with any reference files beside it. A bare skill archive, such as a zip of just the skill folder or a `.skill` file from Claude Desktop, is not a plugin: add the manifest and move the folder under `skills/` to convert it. For the path from writing a skill to delivering it, see [Building and deploying your own skills](/docs/government/desktop/skills#building-and-deploying-your-own-skills). In a marketplace archive, each plugin sits in its own subdirectory, and the marketplace listing points at those subdirectories. A listing entry whose source is the archive root itself, `./`, is not supported and adds nothing, so for a repository laid out as a single plugin with its own marketplace file, remove the marketplace file and upload it as one plugin. A package is marked **Runs code** when it declares components that can run code on members' machines. That means any file under `hooks/` or `monitors/`, a `.mcp.json` at the root, or a manifest key that declares them, such as `hooks` or `mcpServers`. The keys the upload recognizes as descriptive are `name`, `version`, `description`, `author`, `displayName`, `keywords`, `homepage`, `repository`, `license`, and `icon`. Any other key turns the marker on. ## Plugins that run code The upload preview marks any plugin that declares components that can run code on the member's machine, for example hooks or an [MCP server](/docs/connectors/overview), and you confirm that you trust such a package before it is added. For a marketplace archive, one confirmation covers every marked plugin in the batch. After you add it, the plugin's row on the **Plugins** card keeps a **Runs code** marker, so you can see at a glance which of the plugins you have added contain these components. The marker reflects what a plugin declares. In Claude for Government, a marked plugin's hooks run on the member's machine at defined points during a session, its local MCP server never runs, and a connector declared in a plugin you upload here is not connected. Treat the marker as a prompt to review the package yourself. You are responsible for the plugins you distribute to members, so read each plugin's contents before you upload it. ## Install behavior Each plugin on the **Plugins** card has an install behavior that you set when you add it and can change later on its row. **Auto-install** installs the plugin on every member's Claude Desktop without the member doing anything. **Members choose** offers the plugin to members, who install it themselves from their organization's plugins in Claude Desktop, as described in [Plugins in Claude Desktop](/docs/government/desktop/plugins). You do not need to push anything for a plugin to reach members. Claude Desktop syncs your organization's plugin list when it starts and periodically while it runs, so an auto-installed plugin appears on its own, and a member who already has the application open receives it at the next sync. A member can remove a plugin you installed automatically, and it stays removed for that member. In Claude Desktop, members can also add plugins of their own, by uploading a plugin file or having Claude create one, as described in [Plugins in Claude Desktop](/docs/government/desktop/plugins). Those plugins are separate from the ones you add and do not appear on the **Plugins** card. ## Where plugins are added Plugins are added at the tenant or organization level. Plugins the tenant adds flow to every organization and appear on each organization's **Plugins** card under **From levels above**, as described under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards). A tenant administrator can lock the plugin list, which makes it read-only for organizations, following the lock behavior in [How Config works](/docs/government/config/overview#locks). [Group levels](/docs/government/config/overview#group-specific-settings) inherit the plugins of their tenant or organization, so the **Plugins** card is read-only when you view a group. ## Update or remove a plugin To update a plugin, upload the new version's archive. Because its name matches the plugin you added, the upload updates that plugin, the preview marks the update before you save, and members who have the plugin receive the new version automatically. To remove a plugin, click its remove icon and save the change. Removing a plugin stops delivering it, and there is not currently a way to uninstall a plugin remotely from members' devices, so members who already installed it keep their copy until they remove it themselves, as described under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards). ## Connector tool policies for members You add and edit connectors on the **Connectors** card, and for each one you choose the products that receive it and set a policy for each of its tools. See [Connectors](/docs/government/connectors/overview) for the three-step wizard. On Claude Desktop, that tool policy shapes what members experience. A tool you switch off is blocked, so Claude cannot use it. A tool you switch on is available and asks the member on every use, and members are not offered a lasting approval for it. A tool you do not list is left to the member to turn on or off, and its approval prompts follow the member's own choices, which can include lasting approval unless your organization turns that off.
government/config/settings First recorded · 117 lines, first recorded
# Available settings ## Settings list ### Session idle timeout ### Maximum session length ### Let organizations manage their own seat tiers ### Compliance API ### Telemetry endpoint (Claude Desktop) ### Telemetry headers (Claude Desktop) ### Claude Desktop banner ### Product availability ### Allowed network hosts ### Allowed workspace folders ## Tool and connector cards
The first capture of this source. The page was already there, and this is what it said.
# Available settings > Reference for the product settings on the Config page in Claude for Government, including session timeout, maximum session length, telemetry, Claude Desktop banner, product availability, and the tool and connector cards. > **Who this is for:** Tenant administrators and organization owners who set product behavior for the people they manage. This page describes the settings on the **Config** page in the admin portal. Each setting is written once here and can be set at both the tenant and organization level unless noted otherwise. For how the levels combine, what locking does, and how to compare and preview, see [How Config works](/docs/government/config/overview). ## Settings list ### Session idle timeout Controls how long a member can stay inactive before being signed out. The value must be a whole number of minutes, 15 or higher, and the Anthropic default is 1440 minutes (24 hours). A lower value applies at the next sign-in; a higher value applies on the next request. This is a restriction, so each level can shorten the timeout but not lengthen it past what the level above allows, and the value that takes effect is always the shortest one in the chain. ### Maximum session length Controls how long a member can stay signed in before they have to sign in again, even if they are active the whole time. The value must be a whole number of minutes from 60 to 525,600 (365 days), and by default there is no maximum. The maximum is an absolute limit on a session's lifetime that is independent of the session idle timeout, and a session ends as soon as it reaches either limit. This is a restriction, so each level can set or shorten the maximum but not lengthen it past what the level above allows, and the value that takes effect is always the shortest one in the chain. A shorter maximum, or a new maximum where there was none before, also applies to members who are already signed in. Open sessions pick up the change while the member is active rather than instantly, so allow up to one session idle timeout period (24 hours by default) for it to reach everyone who is currently signed in. Any session that has not picked it up by then has already expired from inactivity. The maximum always counts from when the member originally signed in, so a session that is already older than the new maximum ends when it picks up the change and the member is prompted to sign in again. A longer maximum, or resetting the setting to remove a maximum set at your level, applies only at each member's next sign-in. Sessions that are already open keep the limit they already have, and raising or removing the maximum does not restore sessions that a shorter value has already shortened or ended. When a session ends because it reached the maximum, the member signs in again, just as they do after the idle timeout. Your identity provider decides whether that sign-in asks the member to authenticate again (for example with a password, a multi-factor prompt, or a PIV card) or passes them straight through, according to its own session and re-authentication policy. Examples of that policy are the sign-in frequency control in Microsoft Entra Conditional Access and authentication policies in Okta. If you want members to authenticate again when they sign back in after reaching the maximum, set your identity provider's re-authentication interval to no longer than the maximum session length. ### Let organizations manage their own seat tiers Controls whether organization owners may create and edit self-managed seat tiers on the [Tiers](/docs/government/org-admin/seat-tiers) page, in addition to the Anthropic-managed ones. Only tenant administrators can change this setting; it is always read-only at the organization level, and organization owners cannot grant themselves the capability. When it is off, the **New seat tier** button and the edit and delete controls on the Tiers page are hidden, and the **Reset usage limits** action on the [Users](/docs/government/org-admin/users) page is also unavailable. <Note> **Set at the tenant level only.** This setting is read-only for organization owners. </Note> ### Compliance API Controls whether the [Compliance API](/docs/government/org-admin/compliance-api) is available. When it is off, organization owners cannot create new keys and every request to the API returns an error, including requests made with keys that were valid before. Listing and revoking existing keys remains available even when this is off, so that a disabled organization can still revoke an exposed key. <Note> **Set at the tenant level only.** This setting is read-only for organization owners. </Note> ### Telemetry endpoint (Claude Desktop) The base address of the collector where Claude Desktop sends usage telemetry using the [OpenTelemetry](https://opentelemetry.io/) protocol (OTLP), for example `https://otel-collector.example.gov:4318`. Claude Desktop appends the OTLP request paths `/v1/logs` and `/v1/metrics` itself, so enter the address without those suffixes. Leaving the value empty disables telemetry. The value must begin with `https://` and may include a port and a path prefix. Its host must be a hostname or a private-network address, and a public IP address is refused. A matching **Telemetry endpoint (Claude for Microsoft 365)** setting covers that product. Point this address at a receiver that accepts OTLP over HTTP in both its protobuf and JSON encodings. An [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) does this by default and conventionally listens for OTLP over HTTP on port 4318. If your logging or SIEM platform accepts only its own HTTP ingestion format, run an OpenTelemetry Collector that receives OTLP and forwards to that platform, and enter the collector's address here. Claude Desktop on each member's device connects to this address itself rather than through the Claude for Government service. The collector must therefore be reachable from your members' networks and must present a TLS certificate that their operating system trusts. Members pick up a new or changed endpoint the next time they start Claude Desktop. From then on your collector receives OpenTelemetry logs and metrics for each member's activity under three `service.name` values: * `cowork` for Chat and Cowork activity * `claude-code-desktop` for Code sessions * `claude-desktop` for error events from the application itself Each conversation turn produces events such as `user_prompt`, `api_request`, and `tool_result` that record the model, token counts, durations, and tool names. Every record also carries the member's operating-system login name as the `enduser.id` and `process.owner` resource attributes. Message text, file contents, and tool output are not included. See the [event reference in Monitoring](/docs/cowork/monitoring#events) for each event's attributes. Claude Desktop keeps working when the collector refuses requests or cannot be reached, and members see no error. To confirm telemetry is arriving, check your collector's own request logs or metrics for requests to `/v1/logs` after a member has restarted Claude Desktop and sent a message. ### Telemetry headers (Claude Desktop) Headers that Claude Desktop sends with every telemetry request, typically the credential your collector requires. Leave the setting empty if your collector does not require one. Because the value may contain a secret, it is never displayed after you save it; you see only that it is set. Write each header as `Name=value`, for example `Authorization=Bearer <token>`. To send more than one header, separate them with commas, as in `Authorization=Bearer <token>,X-Tenant=agency`. Because the comma is the separator, a header value itself cannot contain one. Spaces and `=` characters within a value are fine. ### Claude Desktop banner A persistent banner shown at the top of Claude Desktop. You can set the text, colors, and an optional link, and preview the result as you edit. Banner text may be up to 200 characters, leading and trailing spaces are rejected, colors must be valid hex codes, and the link (if set) must begin with `https://`. An empty banner is valid and simply hides it. The system-use notification shown at sign-in is separate from this banner. It is fixed text and cannot be edited. Use the Claude Desktop banner setting if you need a configurable message inside the application. ### Product availability A group of separate switches that control which Claude products and features are available to members. Each switch appears as its own row: **Claude Desktop**, **Chat in Claude Desktop**, **Advanced file analysis in Chat**, **Cowork in Claude Desktop**, **Code in Claude Desktop**, **Claude Code**, and **Claude for Microsoft 365**. All are on by default. Turning a switch off makes that product or feature unavailable. The **Chat in Claude Desktop**, **Cowork in Claude Desktop**, and **Code in Claude Desktop** switches each make one part of the app available to members. Chat is for simple conversations, Cowork is for longer tasks that Claude works through on its own in a local workspace folder, and Code is for software development. The **Claude Code** switch is separate and controls the standalone Claude Code command-line tool. When Chat and Cowork are both available, Claude Desktop presents them together as **Home** in its sidebar, next to **Code**. From Home, a member chooses **Chat** or **Cowork** in the message box, and the sidebar lists their chats and tasks together. Turning a switch off also changes this layout. For example, with **Chat in Claude Desktop** off, the sidebar shows **Cowork** in place of Home and the message box offers no choice, and with **Cowork in Claude Desktop** off, the message box offers Chat only. If Chat, Cowork, and Code are all turned off, Claude Desktop keeps Cowork on. There is no setting that chooses what Claude Desktop opens to, or whether the message box starts on Chat or Cowork. <Note> This layout applies to Claude Desktop 1.26832.0 and later. Earlier versions show **Chat**, **Cowork**, and **Code** as three separate tabs, controlled by the same switches. </Note> ### Allowed network hosts A list of hostnames that tools in Claude Desktop may reach, for example to install packages or fetch web pages. This covers the tools Claude uses during Cowork tasks, web fetch in Chat, and the sandboxed shell commands of Code sessions on macOS. For how the list applies to Code sessions on each operating system, see [Code in Claude Desktop](/docs/government/security/security-and-data-handling#code-in-claude-desktop). The connection to Claude is always allowed and does not need to be listed. An empty list shows as **Claude connection only**. Use **Add package registries** to add npm, PyPI, GitHub, crates.io, and other common registries so that Claude can install libraries; hosts added this way appear together as a single **Package registries** pill with a count. This list does not cover addresses on your private network, direct IP addresses, or Web search, so do not rely on it alone to restrict network access. ### Allowed workspace folders Controls which folders members can pick as a project folder in Claude Desktop, and where Claude can read and write files. Leave it unset to allow any folder. Add folder paths to limit members to those locations, or check **Block all workspace folders** to allow none, in which case Claude can still work in Chat and Cowork in folders it creates inside its own sandbox. A Code session starts only in a folder this setting permits, and [Code in Claude Desktop](/docs/government/security/security-and-data-handling#code-in-claude-desktop) describes how the setting applies to Code sessions on each operating system. You can list Windows and Mac paths together, and each device uses only the paths for its platform. An unset value shows as **Any folder** and an empty list shows as **No folders**. ## Tool and connector cards Alongside the settings list, the Config page shows cards for the built-in tools (Web search, Web fetch, and Shell commands), the built-in connector (Microsoft 365), a **Connectors** card for the ones you add yourself, and a **Plugins** card for plugin packages you upload. A connector is an integration that lets Claude reach an external service on a user's behalf. The **Web search** card controls whether Claude can search the web in Claude Desktop. It is off by default. When you turn it on you are shown a short description of how search works and asked to acknowledge it before the setting is saved. A **Require approval for each search** sub-setting sits below the toggle and becomes available once web search is on; it is on by default, and turning it off lets each member choose whether to approve every search or allow searches to run automatically. The **Web fetch** card controls whether Claude can fetch web pages in Claude Desktop. It is on by default, and fetches are subject to the Allowed network hosts list above. A **Require approval for each fetch** sub-setting sits below the toggle. Turning it on asks the member to approve every page fetch before it runs; when it is off (the default), each member chooses whether to approve fetches or allow them automatically. The **Shell commands** card controls whether Claude can run shell commands during tasks in Claude Desktop. It is on by default, and turning it off also turns off Advanced file analysis in Chat. A **Require approval for each command** sub-setting sits below the toggle. Turning it on asks the member to approve every shell command before it runs; when it is off (the default), each member chooses whether to approve commands or allow them automatically. Chat always asks before each command regardless of this setting. The **Microsoft 365** card lets members reach your agency's Microsoft 365 content, including SharePoint, OneDrive, Outlook, and Teams, from Claude Desktop. Each member signs in with their own Microsoft account. Enter the **Tenant ID** and **Client ID** from an application you register in Microsoft Entra, choose the **Azure cloud** your Microsoft tenant is in, and select which Microsoft Graph permissions to allow under **Access**. The connector is off while Tenant ID and Client ID are both blank. See [Set up the Microsoft 365 connector](/docs/government/connectors/microsoft-365) for the full walkthrough. The **Connectors** card lists the Model Context Protocol servers you have added for your own systems. Each connector is defined once and applied to the products you choose. See the [Connectors](/docs/government/connectors/overview) page for how to add and manage them. The **Plugins** card lets you upload plugin packages and deliver them to members in Claude Desktop. A plugin bundles skills, slash commands, and sub-agents for Claude Desktop, and can also carry hooks and declare connectors; see [Manage plugins and connectors](/docs/government/config/plugins-and-connectors) for how each component behaves in Claude for Government and the [Plugins overview](/docs/plugins/overview) for what a plugin can contain. Plugins are delivered only to Claude Desktop. Click **Add plugins** and drop a `.zip` file. The file can be a single plugin package or a whole marketplace archive, for example the **Download ZIP** of a GitHub repository that holds several plugins. A preview shows each plugin's name, version, and description, and marks any plugin that declares components that can run code on the member's machine, for example hooks or an MCP server. In Claude for Government, a plugin's hooks run on the member's machine at defined points during a session; a plugin's declared local MCP server is disabled and does not run. For those plugins, you confirm that you trust the package before it is added. See [Plugins that run code](/docs/government/config/plugins-and-connectors#plugins-that-run-code) for what the marker means and how these components behave in Claude for Government. Each plugin you add appears as a row with an **Auto-install** or **Members choose** control. **Auto-install** installs the plugin for every member automatically, and **Members choose** makes it available for members to install themselves. Click the remove icon to queue a plugin for removal. Changes you make in these rows are staged: nothing is applied until you click **Save changes**, and **Discard** clears the pending changes. Plugins you add through the **Add plugins** dialog take effect as soon as you confirm them in that dialog. Removing a plugin stops delivering it, and members who already installed it keep their copy until they remove it themselves. At the organization level, plugins the tenant has added appear under a **From levels above** heading with an **Inherited from your tenant** badge. You can see them there but cannot change or remove them. Upload a plugin with the same name at your organization level to take priority over one. <Tip> The Claude for Government deployment may include additional settings that are not listed above. Any extra setting follows the same chain, status badges, and edit and reset behavior. </Tip>
government/connectors/microsoft-365 First recorded · 197 lines, first recorded
# Set up the Microsoft 365 connector ## Before you start ## Register an application in Microsoft Entra ### If your Microsoft tenant is in a US Government cloud ### Allow outbound network access ## Configure the connector on the Config page ## Choose which Microsoft 365 permissions to allow ### Read access ### Read access requiring administrator approval ### Write access ## What members see ### Brokered sign-in requirements ## Common problems ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Set up the Microsoft 365 connector
> Register an application in your Microsoft Entra tenant so that Claude Desktop can read your agency's Outlook, OneDrive, SharePoint, and Teams content on each member's behalf.
> **Who this is for:** Organization owners and tenant administrators who want Claude to reach their agency's Microsoft 365 content, and who can register an application in Microsoft Entra ID (or can work with someone who can).
The Microsoft 365 connector lets Claude read and search your agency's Outlook mail and calendar, OneDrive and SharePoint files, and Teams chat from Claude Desktop. The connector runs locally on each member's machine: when a member signs in with their own Microsoft account, Claude Desktop calls Microsoft Graph directly from their device, so those calls and the member's sign-in tokens stay between their device and Microsoft and never pass through any Anthropic service. What Claude reads into a conversation is then handled like anything else the member sends to Claude.
Because each member signs in individually, Claude can only reach content that the signed-in member can already open in Microsoft 365. Your existing Microsoft 365 permissions, sharing rules, and Conditional Access policies apply unchanged.
Setup has two parts. First, someone with administrator access in Microsoft Entra ID registers an application in your Microsoft tenant. Then you enter that application's details on the **Microsoft 365** card on the [Config](/docs/government/org-admin/configuration) page.
## Before you start
You need someone with the **Cloud Application Administrator**, **Application Administrator**, or **Global Administrator** role in your Microsoft Entra tenant. That person registers the application and approves the Microsoft Graph permissions for your whole tenant. If that isn't you, send them the [Register an application in Microsoft Entra](#register-an-application-in-microsoft-entra) section below; you can fill in the Config page form once they send you the two IDs.
Open the [Config](/docs/government/org-admin/configuration) page in another tab and find the **Microsoft 365** card. You'll paste two values from Entra into it at the end.
## Register an application in Microsoft Entra
<Steps>
<Step title="Create the app registration">
1. In the [Microsoft Entra admin center](https://entra.microsoft.com), open **App registrations** from the left navigation and select **+ New registration**.
2. Enter a display name, for example "Claude for Government Microsoft 365".
3. Under **Supported account types**, choose **Single tenant only - \{your organization}**. Older versions of the portal label this option **Accounts in this organizational directory only (Single tenant)**.
4. Leave **Redirect URI** blank for now, and select **Register**.
</Step>
<Step title="Add the redirect URIs">
On the new application's left navigation, go to **Manage** > **Authentication** and open the **Redirect URI configuration** tab (on older versions of the portal, select **+ Add a platform** instead).
1. Select **Add redirect URI**. In the sidebar, choose the **Mobile and desktop applications** card (the Windows, UWP, and Console card, not the iOS/macOS card).
2. Leave the suggested redirect URIs unchecked. In the **Custom redirect URIs** box, enter `http://localhost` and select **Configure**.
3. Close the sidebar. A **Mobile and desktop applications** section now appears on the Authentication page. Select **Edit** on that section, and in the empty box that appears under `http://localhost`, enter each of the two broker redirect URIs below (a new empty box appears after you enter each one). Replace `APPLICATION_CLIENT_ID` with the **Application (client) ID** shown on the application's Overview page, and select **Save** at the top when done.
```text theme={null}
ms-appx-web://Microsoft.AAD.BrokerPlugin/APPLICATION_CLIENT_ID
msauth.com.anthropic.claudefordesktop://auth
```
The `http://localhost` URI is the standard loopback redirect for browser sign-in. When a member signs in through their browser, Microsoft Entra sends the response to a temporary listener on the member's own machine, so it never leaves the device. The other two URIs let Claude Desktop sign in through the operating system's account broker on Windows and macOS devices that meet the [brokered sign-in requirements](#brokered-sign-in-requirements). Brokered sign-in carries the device-identity claim that Conditional Access policies such as **Require compliant device** evaluate, so register all three now even if you are not sure you need them.
<Note>
All three URIs must be under **Mobile and desktop applications**, not **Web**. Registering them as **Web** causes Entra error `AADSTS50011` at sign-in. After you save, Entra may display the `msauth.com.anthropic.claudefordesktop://auth` URI under a separate **iOS/macOS** section. That's expected, since both sections are public-client platforms. To double-check, open **Manage** > **Manifest** and confirm the three URIs appear under `publicClient.redirectUris` rather than `web.redirectUris`. If the list also contains `msauth.com.anthropic.claudefordesktop.helper://auth`, remove that entry. Claude Desktop does not use it.
</Note>
</Step>
<Step title="Allow public client flows">
Still under **Authentication**, find **Allow public client flows** (on the **Settings** tab under **Web and SPA settings**, or under **Advanced settings** on older versions of the portal), set it to **Yes**, and select **Save**.
This tells Microsoft Entra that the application runs on end-user devices and does not hold a secret. Claude Desktop signs in as a public client with no client secret, and with this setting off, brokered sign-in on managed devices fails with Entra error `AADSTS7000218`.
<Warning>
Setting **Allow public client flows** to **Yes** also permits the device-code sign-in flow, which attackers can abuse for phishing. To close that path, apply a tenant Conditional Access policy that blocks the device-code authentication flow. Scope the policy to **All resources**, not to this app registration, because Conditional Access evaluates the resource a token is requested for rather than the requesting client.
</Warning>
</Step>
<Step title="Add and approve Microsoft Graph permissions">
On the application's left navigation, go to **Manage** > **API permissions**.
1. Select **+ Add a permission** > **Microsoft Graph** > **Delegated permissions**.
2. Add `User.Read` (under **User**) and `offline_access` (under **OpenId permissions**). `User.Read` is usually already listed on a new application, so leave it in place. The connector always requests these two at sign-in, so they must be approved regardless of what you select under **Access** later.
3. Add every permission you plan to select under **Access** on the Config page. At minimum, add the eight Default permissions (`Mail.Read`, `Mail.Read.Shared`, `Calendars.Read`, `Calendars.Read.Shared`, `Files.Read.All`, `Sites.Read.All`, `Chat.Read`, `OnlineMeetings.Read`), since those are pre-selected on the Config page. See [Choose which Microsoft 365 permissions to allow](#choose-which-microsoft-365-permissions-to-allow) for what each one does and for the optional write permissions.
4. Select **Add permissions**.
5. Select **Grant admin consent for \{your tenant name}** and confirm.
The **Grant admin consent** step approves these permissions once for every member of your Microsoft tenant, so individual members are not asked to approve them again when they sign in. Until you complete this step, members see Entra error `AADSTS65001` at sign-in (or, on tenants that allow members to approve permissions themselves, a per-member consent prompt).
<Note>
A delegated permission lets the application act on a member's behalf, limited to whatever that member can already do. It does not let Claude see content the member cannot see. For example, granting `Files.Read.All` lets Claude read files the signed-in member can open, not every file in your tenant.
</Note>
</Step>
<Step title="Copy the two IDs">
On the application's **Overview** page, copy the **Application (client) ID** and the **Directory (tenant) ID**. You'll paste both into the Config page when you [configure the connector](#configure-the-connector-on-the-config-page).
</Step>
</Steps>
### If your Microsoft tenant is in a US Government cloud
Microsoft 365 GCC (the standard Government Community Cloud) uses the commercial Microsoft Entra service, so follow the steps above unchanged and leave **Azure cloud** set to **Commercial** when you [configure the connector on the Config page](#configure-the-connector-on-the-config-page).
GCC High and DoD tenants use the Azure Government cloud instead. Register the application at `https://entra.microsoft.us` (or `https://portal.azure.us`) rather than `entra.microsoft.com`, and select the matching **Azure cloud** value when you [configure the connector on the Config page](#configure-the-connector-on-the-config-page). Claude Desktop then signs in at `login.microsoftonline.us` and calls `graph.microsoft.us` (or `dod-graph.microsoft.us` for DoD) instead of the commercial hosts.
### Allow outbound network access
The connector calls Microsoft directly from each member's device, so devices need outbound HTTPS access to the Microsoft Entra and Microsoft Graph hosts for your cloud.
| Azure cloud | Sign-in host | Microsoft Graph host |
| ---------------------- | --------------------------- | ------------------------ |
| Commercial | `login.microsoftonline.com` | `graph.microsoft.com` |
| US Government GCC-High | `login.microsoftonline.us` | `graph.microsoft.us` |
| US Government DoD | `login.microsoftonline.us` | `dod-graph.microsoft.us` |
No outbound access to any Anthropic host is needed for the connector's Microsoft 365 calls.
## Configure the connector on the Config page
On the [Config](/docs/government/org-admin/configuration) page, expand the **Microsoft 365** card and fill in the form.
| Field | What to enter |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tenant ID** | The **Directory (tenant) ID** from the application's Overview page. |
| **Client ID** | The **Application (client) ID** from the application's Overview page. |
| **Azure cloud** | **Commercial** for most tenants, including Microsoft 365 GCC. Choose **US Government GCC-High** or **US Government DoD** only if your Microsoft tenant is in one of those clouds. |
| **Access** | The Microsoft Graph permissions the connector requests when a member signs in. The standard read-only permissions are already selected; add or remove permissions as needed. See [Choose which Microsoft 365 permissions to allow](#choose-which-microsoft-365-permissions-to-allow). |
Save the card. The connector is delivered to each member's Claude Desktop the next time it refreshes its configuration, which happens at launch or sign-in. Members who already have Claude Desktop open may need to restart it.
## Choose which Microsoft 365 permissions to allow
The **Access** picker controls which Microsoft Graph delegated permissions Claude Desktop requests when a member signs in. The permissions marked **Default** below are already selected when you first open the card and give read-only access to the member's mail, calendar, files, sites, Teams chat, and online meetings. Add write or administrator-approval permissions if you need them, or clear read permissions you do not want. At least one permission must be selected.
Whatever you select here must also be added and approved on the Entra app registration (step 4 above). Keep the two lists in sync. Claude Desktop also always requests `User.Read` and `offline_access`. These two do not appear in the picker, but they must still be approved on the Entra app registration.
### Read access
| Permission | What it lets Claude do |
| --------------------------------- | --------------------------------------------------------------------------- |
| `Mail.Read` (Default) | Read the member's mail |
| `Mail.Read.Shared` (Default) | Read mail in mailboxes shared with the member |
| `Calendars.Read` (Default) | Read the member's calendar events |
| `Calendars.Read.Shared` (Default) | Read events on calendars shared with the member and find free meeting times |
| `Files.Read.All` (Default) | Read files the member can open in OneDrive and SharePoint |
| `Sites.Read.All` (Default) | Read SharePoint site content the member can open |
| `Chat.Read` (Default) | Read the member's Teams chats |
| `OnlineMeetings.Read` (Default) | Read the member's online meetings |
| `MailboxSettings.Read` | Read the member's mail rules and automatic-reply settings |
### Read access requiring administrator approval
These two permissions always require the **Grant admin consent** step in Entra, regardless of your tenant's user-consent policy. Until that step is done, sign-in fails for every member when either permission is requested.
| Permission | What it lets Claude do |
| ---------------------------------- | ----------------------------------------------------- |
| `ChannelMessage.Read.All` | Include Teams channel messages in chat search results |
| `OnlineMeetingTranscript.Read.All` | Read meeting transcripts |
### Write access
Write permissions let Claude take actions in Microsoft 365 on the member's behalf, such as sending mail, creating calendar events, and editing files. Members approve each write action in Claude Desktop before it runs. The connector is read-only unless you select at least one of these.
| Permission | What it lets Claude do |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Mail.Send` | Send mail, send drafts, and forward mail on the member's behalf. Forwarding and sending drafts also use a mail read permission (any of `Mail.Read`, `Mail.Read.Shared`, or `Mail.ReadWrite`) for pre-send checks. |
| `Mail.ReadWrite` | Create, edit, and delete drafts; trash, restore, and delete messages; apply and remove labels on messages |
| `Calendars.ReadWrite` | Create, update, delete, and respond to calendar events |
| `Files.ReadWrite.All` | Create, edit, rename, move, copy, and delete files and folders the member can edit in OneDrive and SharePoint |
| `Sites.ReadWrite.All` | Additional SharePoint write access beyond files. No Claude action requires this permission; `Files.ReadWrite.All` covers file actions in both OneDrive and SharePoint. |
| `ChatMessage.Send` | Send messages in the member's existing Teams chats |
| `ChannelMessage.Send` | Post messages to Teams channels |
| `Chat.Create` | Start new Teams chats |
| `MailboxSettings.ReadWrite` | Manage the member's labels, mail rules, and automatic replies |
<Note>
Removing a permission from the **Access** picker changes what Claude Desktop requests the next time a member signs in, but it does not revoke permissions that Microsoft Entra has already approved for the application. To revoke a permission entirely, remove it in the Entra admin center under **Enterprise applications** > your application > **Permissions**.
</Note>
## What members see
After you save the card, **Microsoft 365** appears under **Settings** > **Connectors** in each member's Claude Desktop. The member selects **Connect** and signs in with their Microsoft work account. On devices that meet the brokered sign-in requirements below, this opens the operating system's account picker; otherwise, it opens the default browser. Once connected, Claude can search and read the member's Microsoft 365 content in conversations.
Sign-in tokens are stored encrypted on the member's device and persist across restarts, so members are not asked to sign in again each session. Selecting **Disconnect** deletes the connector's stored tokens from the device. On the brokered sign-in path, the device's work or school account is managed by the operating system and remains after Disconnect, so selecting **Connect** again can re-acquire tokens without a fresh prompt. To end a member's access entirely, revoke the member's sessions in the Entra admin center (revocation takes effect once the member's current access token expires), or remove the account from the device in Windows Settings (**Accounts** > **Access work or school**) or macOS Company Portal.
### Brokered sign-in requirements
If your Conditional Access policies require a compliant or managed device, sign-in must carry a device-identity claim. Brokered sign-in provides that claim directly; browser sign-in provides 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 the Enterprise SSO integration deployed). Without the claim, members see Entra error `AADSTS53000` or `AADSTS53003` when Claude calls Microsoft 365.
Brokered sign-in requires the broker redirect URIs from step 2, **Allow public client flows** set to **Yes** (step 3), and the following on each device:
| Platform | Broker availability requirements |
| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Windows | Windows 10 or Windows Server 2019 or later. The device is joined or registered to Entra ID (Entra joined, Entra hybrid joined, or Entra registered). |
| macOS | macOS 10.15 or later. The Mac is enrolled in device management and registered in Entra ID. **Intune Company Portal** is installed, and an **Extensible SSO** configuration profile of type **Redirect** pointed at the Microsoft Enterprise SSO plug-in is deployed through device management. The broker is unavailable without Company Portal and the SSO profile. |
When the broker is unavailable, Claude Desktop falls back to browser sign-in automatically and stays on browser sign-in until Claude Desktop restarts.
When the broker is available, it carries the device claim, and Conditional Access then evaluates that claim against your policy, so the device must also satisfy whichever grant control your policy applies: marked compliant in Intune (or by a partner compliance integration that reports to Intune) for a **Require compliant device** policy, or hybrid joined for a **Require Entra hybrid joined device** policy. A device with a working broker that does not satisfy the policy still fails with `AADSTS53000` or `AADSTS53003`.
## Common problems
| What the member sees | What it means | How to fix it |
| ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Entra error `AADSTS50011` at sign-in | One of the redirect URIs from step 2 is missing from the app registration, was entered with a different value, or was added under the **Web** platform instead of **Mobile and desktop applications**. The error message names the URI that Claude Desktop sent. | Compare it with step 2 and add or correct that URI under **Mobile and desktop applications**. |
| Entra error `AADSTS900971` at sign-in on macOS | No redirect URI is registered for macOS brokered sign-in. | Add `msauth.com.anthropic.claudefordesktop://auth` under **Mobile and desktop applications** (step 2). |
| Entra error `AADSTS65001` at sign-in | The Microsoft Graph permissions have not been approved for the tenant, or a permission the connector requests is not listed under the app registration's **API permissions** (so **Grant admin consent** never covered it). | Confirm that every permission selected under **Access** on the Config page, plus `User.Read` and `offline_access`, is listed under the app registration's **API permissions**. Add any that are missing, then select **Grant admin consent** (step 4). |
| A Microsoft consent prompt appears at sign-in even though you selected **Grant admin consent** | Same cause as `AADSTS65001` above, on a tenant that allows members to approve permissions themselves. | See the `AADSTS65001` row above. |
| Entra error `AADSTS7000218` at sign-in | **Allow public client flows** is set to **No** on the app registration. | Set it to **Yes** (step 3). |
| Entra error `AADSTS53000` or `AADSTS53003` when Claude calls Microsoft 365 | A Conditional Access policy requires a compliant or managed device, and either sign-in fell back to the browser because brokered sign-in is not available, or the device does not satisfy the policy's grant control. | Meet the [brokered sign-in requirements](#brokered-sign-in-requirements) for the member's platform, confirm the device satisfies whichever grant control your policy applies (marked compliant, or hybrid joined), and restart Claude Desktop. On macOS, the most common broker cause is a missing Company Portal install or Extensible SSO profile. |
| Entra error `AADSTS700016` at sign-in | The **Client ID** or **Tenant ID** on the Config page does not match an application in the selected **Azure cloud**. | Re-check the Client ID and Tenant ID against the application's Overview page, and confirm that **Azure cloud** matches the cloud where you registered the application. |
| Sign-in or Claude's Microsoft 365 calls fail with a network error and no `AADSTS` code | The member's device cannot reach the Microsoft Entra or Microsoft Graph host for your Azure cloud. | Allow outbound HTTPS to the hosts listed under [Allow outbound network access](#allow-outbound-network-access). |
| A tool returns a permission error | The Microsoft Graph permission that tool needs is not approved on the app registration, or is not selected under **Access**. | Add the permission in both places and select **Grant admin consent** again. |
## Things to know
* Read and write permissions are separate per Microsoft 365 service. You can approve read broadly while limiting write to specific services or none at all by selecting only the permissions you want under [Choose which Microsoft 365 permissions to allow](#choose-which-microsoft-365-permissions-to-allow).
* The **Access** selection applies to everyone who receives this connector card. There is no separate per-group write toggle inside the card. To give different groups different permissions, set the card at the group scope on the Config page; see [Group-specific settings](/docs/government/config/overview#group-specific-settings).
government/connectors/overview First recorded · 56 lines, first recorded
# Connectors ## The Connectors card ## Adding a connector ### Step 1: Server ### Step 2: Discover tools ### Step 3: Policy & scope ## Editing and removing a connector
The first capture of this source. The page was already there, and this is what it said.
# Connectors > Add Model Context Protocol servers for your own systems, choose which Claude products receive each one, and set which of their tools are available to members. > **Who this is for:** Tenant administrators and organization owners who want Claude to reach their agency's own systems (for example, an internal search service or a ticketing tool) from Claude Desktop and other Claude products. Use this page to add Model Context Protocol servers for your own systems, choose which Claude products receive each one, and set which of their tools are available to members. A **connector** is a link between Claude and an external service. The service runs a Model Context Protocol (MCP) server, which is a standard way for a service to publish a set of tools that Claude can call. You add the server once here, and Claude for Government delivers it to the products you select. ## The Connectors card The **Connectors** card appears on your [tenant](/docs/government/tenant-admin/configuration) or [organization](/docs/government/org-admin/configuration) Config page alongside the built-in connector cards. It lists every connector you have added, with each one's name, address, the products it applies to, and a summary of how many of its tools are allowed. Click **Add connector** to open the wizard, or click the edit icon next to a connector to change it. Connectors are set at the tenant or organization level. When you are viewing a group scope, the card is read-only and points you to the organization or tenant settings where connectors are configured. ## Adding a connector The **Add connector** button opens a three-step wizard. ### Step 1: Server Enter the details of the MCP server. * **Name** is a short identifier for the connector. It must be lowercase letters, digits, hyphens, or underscores. * **Server URL** is the address of the server's MCP endpoint. It must begin with `https://`. * **Transport** selects how Claude talks to the server. Choose HTTP or SSE to match what your server supports. * **Authentication** selects how Claude proves who it is to the server. **None** sends no credentials. **Header (shared secret)** sends a fixed header (for example, an authorization token) with every request; the value is stored securely and shown as `••••` after you save. **OAuth (members sign in)** has each member sign in on first use, and their tokens stay on their own machine. **OAuth (pre-registered app)** also has each member sign in, through an app you register with the server's sign-in provider ahead of time. For **OAuth (pre-registered app)**, enter the **Client ID** your provider issued when you registered the app. A single-tenant Microsoft Entra app also needs its **Tenant ID** and the **Scope** the app requests. Enter the scope that your server's own API expects (for example, an `api://` scope for an app registered in your tenant), because Microsoft Graph scopes such as `Mail.Read` would give the connector's server access to members' Microsoft 365 data. Neither OAuth option stores a secret. When you choose either OAuth option, a confirmation checkbox appears on the final step asking you to confirm that the server address is exactly the one you intend, because members are sent to a sign-in page that the server chooses. When sign-in happens somewhere other than the server itself, for example when you set a tenant ID for a Microsoft Entra app, the checkbox names both that sign-in address and the server address. ### Step 2: Discover tools This step tries to list the tools the server offers so that you can set policy on the next step. Discovery runs from your own browser and is best-effort; many servers cannot be reached this way (for example, because they require authentication or are on a private network), and you can always add tools by name on the next step instead. Click **Discover tools** to run the probe. If the server answers, the tools it advertises are listed. If the server asks for sign-in, a **Sign in to discover** option appears: confirm the sign-in host, sign in through the popup, and the probe runs again with that one-time credential. The credential is used once in your browser for this probe and is never stored; it is separate from the **Authentication** choice on the Server step, which controls how members authenticate later. The **Sign in to discover** option does not appear when you choose **OAuth (pre-registered app)**, because this probe does not sign in with the app you registered. Add the tools by name on the next step. ### Step 3: Policy & scope Choose which products receive this connector and which of its tools are available. Under **Apply to**, tick the products that should receive this connector: Claude Desktop and Microsoft 365. A connector with no products ticked is saved but delivered nowhere, which is a way to pause it. A connector that uses OAuth cannot be applied to Microsoft 365, because per-user sign-in is not available there. A connector with any tool switched off in the table below also cannot be applied to Microsoft 365, and the checkbox is disabled with a **needs every tool on** note until every tool is on. Under **Tool policy**, the table lists the tools found during discovery with an on/off switch for each. **Refresh tools** probes the server again and fills in any tools that are new since you last looked, keeping the switches you have already set. **Add tool** lets you type a tool name by hand when discovery could not reach the server. On Claude Desktop, a tool you switch off is blocked, a tool you switch on is available and each member still approves its use, and a tool that is not listed at all is left to the member to enable or disable. You cannot apply this connector to Microsoft 365 while any tool in this table is switched off. If you are editing a connector that already applies to Microsoft 365 and you switch a tool off, a warning tells you that saving will remove it from Microsoft 365. Click **Save** to create the connector. It appears in the **Connectors** card and is delivered to the products you ticked. ## Editing and removing a connector Click the edit icon next to a connector in the card to open the same wizard with its current values filled in. Changing the authentication method clears any stored secret and the app details saved for **OAuth (pre-registered app)**. Click the remove button next to a connector to delete it; it is withdrawn from every product at the next refresh.
government/deploy-desktop/configure First recorded · 213 lines, first recorded
# Connect Claude Desktop to Claude for Government ## Choose how to deploy ## Before you begin ## The managed setting ### How the app uses the bootstrap address ## Configure a single machine ## Deploy to your fleet ### macOS ### Windows ### Linux ### Order of deployment ## Confirm it worked ## Troubleshooting ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Connect Claude Desktop to Claude for Government
> Choose between single-machine setup and fleet deployment, understand the administrator requirements for each, and connect Claude Desktop to Claude for Government.
> **Who this is for:** IT administrators who install Claude Desktop on agency devices and connect it to Claude for Government.
A fresh install of Claude Desktop connects to claude.ai. To connect it to Claude for Government instead, each device needs one managed setting that tells the app where to reach Claude for Government. Once that setting is in place, everything else that governs the app (which products and features are available, model access, [connectors](/docs/government/connectors/overview), usage limits, the Claude Desktop banner) is controlled through the [tenant](/docs/government/tenant-admin/configuration) and [organization](/docs/government/org-admin/configuration) configuration pages in this portal and delivered to each user when they sign in.
## Choose how to deploy
There are two ways to get Claude Desktop installed and connected to Claude for Government. They differ in who runs the installer, what rights that requires, and how the setting reaches the app.
| | Configure a single machine | Deploy to your fleet |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Best for | Confirming the app works on a representative device before a wider rollout, or setting up a small group of devices by hand | Production rollout across your agency |
| Who installs the app | A person at the device | Your device management system (for example Intune, Configuration Manager, or Jamf) |
| Administrator rights to install | Needed by the person doing each install | Not needed by end users; the management system installs with elevated rights |
| How the address is set | Entered in the app's built-in configuration window | Pushed as a configuration profile alongside the app |
For a production rollout, use your device management system so end users never need administrator rights. The single-machine path is for testing first or for a small group you set up by hand, with an administrator doing each install. That path can also export a ready-made profile for your management system, so it is a useful starting point even when the fleet path is your destination.
## Before you begin
Confirm each of the following before you start either path.
* **User accounts exist.** Claude Desktop signs users in to the same accounts as this portal. For each user, including your own test account, check with your tenant administrators that the user can sign in (a [routing rule](/docs/government/tenant-admin/identity-and-access) covers them) and has a [seat tier](/docs/government/org-admin/seat-tiers) with at least one model enabled.
* **Devices can reach Claude for Government.** Claude Desktop on every device must reach the Claude for Government host over HTTPS on port 443. That one host carries the app's configuration and chat traffic.
* **Browsers can reach sign-in.** Sign-in happens in the user's default web browser, not in the app. Browsers on each device must reach the Claude for Government host, its sign-in service (a separate host that your Anthropic representative provides), and your agency's identity provider.
* **The device meets Claude Desktop's requirements.** See the Claude Desktop [system requirements](/docs/third-party/claude-desktop/installation#system-requirements) for macOS and Windows device requirements. For a Windows fleet, work through the [Windows fleet checklist](/docs/government/deploy-desktop/windows-checklist), which covers the Virtual Machine Platform feature that Cowork needs along with the installer, policy, and network prerequisites.
* **Windows devices used for Code have Git for Windows.** On Windows, only the Code part of Claude Desktop needs Git for Windows. Chat and Cowork work without it. Install Git on the devices whose users will work in Code, or turn **Code in Claude Desktop** off under [Product availability](/docs/government/config/settings#product-availability) so that users are not prompted to install Git.
* **You can install the app.** Installing by hand needs administrator rights on each device; see [Configure a single machine](#configure-a-single-machine) for what that means on each platform. Installing through your device management system does not, because the management system installs with elevated rights. The [macOS deployment guide](https://support.claude.com/en/articles/12611117-deploy-claude-desktop-for-macos) and the [Windows deployment guide](https://support.claude.com/en/articles/12622703-deploy-claude-desktop-for-windows) cover where to download the installer and how to distribute it.
* **The app is current.** The configuration mechanism on this page requires Claude Desktop 1.10628.0 or later.
## The managed setting
The setting is called `bootstrapUrl`, and its value is the Claude for Government host followed by the fixed path `/gateway-api/user/bootstrap`.
```text theme={null}
https://<claude-for-government-host>/gateway-api/user/bootstrap
```
The Claude for Government host is the same domain name you use to access Claude for Government. If you are unsure of it, ask your Anthropic representative. The app uses the address exactly as entered; it fetches each user's configuration from it and starts sign-in from it, so include the full path.
### How the app uses the bootstrap address
The address is the same for every device and user in your agency and carries no credentials or user information, so the same profile is safe to push to your whole fleet. A request to the address without a signed-in session is refused.
When a user chooses **Sign in with your organization**, the app asks the Claude for Government host to start a sign-in, shows the pairing code it receives, and opens the host's sign-in page in the user's default browser. That page asks for the user's agency email address, then sends the browser to the sign-in service and on to your agency's identity provider. After signing in, the user acknowledges the system-use notification, confirms that the code shown in the browser matches the one in the app, and approves.
Claude for Government then issues the app a session for that user, which the app stores encrypted on the device. The app presents that session, and nothing from the profile, when it downloads the user's configuration from this address and when it sends chat traffic to the same host. It re-checks the configuration about every 30 minutes and at each launch.
The configuration that the app downloads for a user includes the following settings, all of which you manage in this portal.
| What the app receives | Where it is set |
| --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Which of Chat, Cowork, and Code the user can open, and whether Advanced file analysis is on in Chat | [Product availability](/docs/government/config/settings#product-availability) on the Config page |
| The models the user can choose | The user's [seat tier](/docs/government/org-admin/seat-tiers) |
| Connectors, plugins, and the settings for the built-in tools | The [tool and connector cards](/docs/government/config/settings#tool-and-connector-cards) on the Config page |
| The hosts that tools may reach | [Allowed network hosts](/docs/government/config/settings#allowed-network-hosts) |
| The folders a user can choose as a workspace | [Allowed workspace folders](/docs/government/config/settings#allowed-workspace-folders) |
| The banner shown across the top of the app | [Claude Desktop banner](/docs/government/config/settings#claude-desktop-banner) |
| Where the app sends your agency's own telemetry, if you have set a collector | [Telemetry endpoint (Claude Desktop)](/docs/government/config/settings#telemetry-endpoint-claude-desktop) |
## Configure a single machine
<Note>
Installing by hand needs administrator rights on the device. On Windows, the installer registers a Windows system service, so it must run as a local administrator. On macOS, installing to the shared Applications folder requires an administrator. On Linux, installing the package requires root.
</Note>
Claude Desktop has a built-in configuration window that is hidden until you enable developer mode. These steps use it to set the address on one machine without any management tooling.
<Steps>
<Step title="Launch the app without signing in">
Install Claude Desktop on the test machine and open it. On Windows, run the installer while signed in as a local administrator. The claude.ai sign-in screen appears; this is expected before the app is configured. Stay on this screen.
</Step>
<Step title="Enable developer mode">
From the **Help** menu, choose **Troubleshooting**, then **Enable Developer Mode**, and confirm the prompt. On Windows the **Help** menu is under the application menu (☰) on the sign-in screen. The app relaunches with a **Developer** menu added.
</Step>
<Step title="Open the configuration window">
From the **Developer** menu, choose **Configure Third-Party Inference**. This is the correct option for Claude for Government despite the name. The window opens on its **Connection** section.
</Step>
<Step title="Enter the bootstrap address">
In the window's left sidebar, click **Source**. On an unconfigured machine it appears last in the list and is dimmed, but is still clickable. Enter the full address from the section above in the **Bootstrap config URL** field. Leave every other field alone; Claude for Government supplies the provider, credentials, and model list after sign-in.
</Step>
<Step title="Apply and sign in">
Click **Apply Changes** and let the app relaunch. The sign-in screen now offers **Sign in with your organization** alongside the claude.ai option. Choose it. The app shows a pairing code and opens the sign-in page in your browser. Sign in with your agency credentials, confirm that the code in the browser matches the one in the app, and approve. The app picks up the session and opens to Claude.
</Step>
<Step title="Run the verification checklist">
Work through [Confirm it worked](#confirm-it-worked) below.
</Step>
</Steps>
After the test, the same configuration window has an **Export** menu that produces files ready for your management system: a `.mobileconfig` profile for macOS, a `.reg` file for Windows, an ADMX template for Intune or Group Policy, and a Profile Manifest for Jamf. Before exporting, turn on **Disable Claude.ai sign-in** in the window's **Workspace** section so the exported profile hides the claude.ai option on managed devices.
## Deploy to your fleet
When your device management system deploys Claude Desktop, end users receive the app without running an installer themselves. The management system installs the package with the system or root account on each platform, so end users need no administrator rights and see no elevation prompt. Push both the app installer and the configuration profile below through the same system.
The recommended profile contains two keys. In the macOS and Windows profiles below, write every value as a string exactly as shown, including booleans as the strings `"true"` or `"false"`; the Linux file uses native JSON types, as shown.
| Key | Value | Purpose |
| ------------------------------ | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| `bootstrapUrl` | `https://<claude-for-government-host>/gateway-api/user/bootstrap` | Required. Points the app at Claude for Government. |
| `disableDeploymentModeChooser` | `"true"` | Recommended. Hides the claude.ai sign-in option so users can only sign in to Claude for Government. |
No other keys are needed; Claude for Government supplies everything else per user after sign-in. The profile contains no secrets, only a host. Keys documented for other Claude plans, such as `forceLoginOrgUUID` or `loginSsoOrgDomain`, apply only to claude.ai workspaces and are not used here.
### macOS
Claude Desktop reads managed preferences in the `com.anthropic.claudefordesktop` domain. Deploy a configuration profile that sets the two keys in that domain as strings.
```xml theme={null}
<key>bootstrapUrl</key>
<!-- substitute the Claude for Government host -->
<string>https://<claude-for-government-host>/gateway-api/user/bootstrap</string>
<key>disableDeploymentModeChooser</key>
<string>true</string>
```
Most device management consoles, including Jamf and Intune, build the profile around these keys for you. For a complete `.mobileconfig` ready to upload, use the Export menu described in the single-machine path.
For a device-management rollout on macOS, also set `disableAutoUpdates` to the string `"true"` in the profile and push updates through your management system, so the in-app updater never prompts users for administrator rights.
### Windows
Claude Desktop reads string (`REG_SZ`) values by name under `HKLM\SOFTWARE\Policies\Claude`. Deliver them with Intune, Group Policy, or any tool that writes machine policy. The ADMX template from the Export menu makes both keys available in the policy editor. As a `.reg` file:
```text theme={null}
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Claude]
; substitute the Claude for Government host
"bootstrapUrl"="https://<claude-for-government-host>/gateway-api/user/bootstrap"
"disableDeploymentModeChooser"="true"
```
The `.reg` file from the Export menu targets `HKEY_CURRENT_USER`, which is correct for single-machine testing. For fleet deployment, deliver the values under `HKEY_LOCAL_MACHINE` as shown here.
<Note>
Cowork, the agentic workspace in Claude Desktop, requires the **Virtual Machine Platform** Windows optional feature. Enable that feature through your device management system before rollout. On a device where the feature is not enabled, Cowork is unavailable until someone turns the feature on, which requires administrator rights that a standard user does not have. Chat works regardless of this feature. The [Windows fleet checklist](/docs/government/deploy-desktop/windows-checklist) lists the remaining Windows prerequisites.
</Note>
### Linux
Place a JSON file at `/etc/claude-desktop/managed-settings.json` containing the same keys at the top level.
```json theme={null}
{
"bootstrapUrl": "https://<claude-for-government-host>/gateway-api/user/bootstrap",
"disableDeploymentModeChooser": true
}
```
The file must be a regular file (not a symlink), and the file and its directory must be owned by root and must not be group- or world-writable. If the permissions are wrong, the app rejects the file, logs the reason to `main.log`, and treats the device as managed but unreadable, so local settings are also disabled until the permissions are corrected and the app is relaunched.
### Order of deployment
Deploy the configuration before the app wherever you can. A user whose device already has the profile opens Claude Desktop for the first time and lands directly on the Claude for Government sign-in screen, with no opportunity to sign in to claude.ai by mistake.
<Note>
Once `bootstrapUrl` or any other connection key is present in the profile, the device is managed. The in-app configuration window becomes read-only, and locally authored settings, including a single-machine test configuration, are ignored in favor of the profile. Removing the profile returns the device to local control.
</Note>
The app reads managed configuration at launch. After you change the profile on a device where the app is already running, have the user fully quit and reopen it.
## Confirm it worked
Run through these checks on a configured machine from either path.
<Steps>
<Step title="Check the sign-in screen">
Launch the app. The sign-in screen offers **Sign in with your organization**. On a managed device with `disableDeploymentModeChooser` set, it is the only option. If only the claude.ai sign-in appears, the configuration did not reach the app.
</Step>
<Step title="Check that the device is managed">
On a device that received the profile through your management system, open the configuration window (the first three steps of the single-machine path). It should be read-only with a banner noting that your organization manages the configuration. If it is still editable, no recognized key reached the app, even if your management console reports the profile as delivered. The diagnostic report's Configuration section (next step) shows exactly what the app read.
</Step>
<Step title="Generate a diagnostic report">
From **Help**, choose **Troubleshooting**, then **Generate Diagnostic Report**. The report's Configuration section lists which keys the app read, where each came from, and any values that failed to parse. Secret values are redacted, so the report is safe to attach to a help-desk ticket.
</Step>
<Step title="Sign in and send a message">
Sign in as a provisioned test user. Chat works and the model picker lists the models you expect for that user's seat tier.
</Step>
<Step title="Confirm per-user settings arrived">
After sign-in, what the app offers matches that user's [product availability](/docs/government/config/settings#product-availability) settings (with everything on, the sidebar shows **Home** and **Code**), and any organization-managed connectors appear in the app. One end-to-end test is to set a short message in the **Claude Desktop banner** setting on the tenant [Config](/docs/government/tenant-admin/configuration) page during rollout; if the message appears across the top of the app after sign-in, per-user delivery is working. If sign-in succeeds but none of these settings arrive, re-check the configured address.
</Step>
</Steps>
## Troubleshooting
| What you see | Likely cause | What to do |
| --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Only the claude.ai sign-in screen; no organization option | The configuration never reached the app: the profile was not delivered, a key name is misspelled, the value is in the wrong location or registry type, or the app was not relaunched after the change | Verify delivery in your management console, generate a diagnostic report and check its Configuration section, then fully quit and reopen the app |
| Sign-in times out, or the browser says the code expired | The app stops waiting after about five minutes | Cancel and start sign-in again; a fresh code is issued |
| The diagnostic report or `main.log` shows "Managed configuration is invalid; local settings are disabled until it is fixed" | The app detected a managed profile but could not read any of its values | Correct the profile and redeploy; the report's Configuration section names each key that failed |
| Signed in, but the model picker is empty | The user has no seat tier, or none of the tier's models is available in Claude for Government | Have an organization owner check the user's seat on the [Users](/docs/government/org-admin/users) page and the tier's models on the [Seat tiers](/docs/government/org-admin/seat-tiers) page |
For anything else, the app writes its log to `~/Library/Logs/Claude-3p/main.log` on macOS, `%LOCALAPPDATA%\Claude-3p\logs\main.log` on Windows, and `~/.config/Claude-3p/logs/main.log` on Linux. The log records which configuration keys were read or dropped and why. The diagnostic report from the verification checklist produces a bundle, without conversation content, that you can send to your Anthropic representative.
## Things to know
* Configuration changes made in this portal do not need to be pushed to devices. The app re-checks Claude for Government for changes about every 30 minutes and at each launch, and prompts users to relaunch when something changed.
* New and retired models appear in the model picker without any profile change or app update; model access is controlled through [seat tiers](/docs/government/org-admin/seat-tiers).
* Claude Desktop keeps itself updated by default. If your agency distributes software through its own pipeline, add `disableAutoUpdates` with the value `"true"` to the same profile and redistribute installers yourself.
* The sign-in flow and what a user sees on the [Sessions](/docs/government/account/sessions) page after pairing a device are covered on that page.
government/deploy-desktop/windows-checklist First recorded · 69 lines, first recorded
# Windows fleet checklist ## Device requirements ## Installer and packaging ## Application control rules ## Cowork virtualization ## Configuration values ## Network access ## User accounts and seats
The first capture of this source. The page was already there, and this is what it said.
# Windows fleet checklist > Device, installer, virtualization, policy, network, and account prerequisites to confirm before deploying Claude Desktop across a Windows fleet for Claude for Government. > **Who this is for:** IT administrators and desktop engineering teams who are preparing a Windows fleet for Claude Desktop connected to Claude for Government. Use this checklist to confirm what your devices, policies, network, and user accounts need before you push Claude Desktop to a Windows fleet. Several items concern the virtual machine that Claude Desktop runs on each device for Cowork, the agentic workspace in Claude Desktop, and for Advanced file analysis in Chat. When every item is in place, follow [Connect Claude Desktop to Claude for Government](/docs/government/deploy-desktop/configure) to deliver the managed setting and the app. ## Device requirements * **Windows version and architecture.** Devices need Windows 10 version 2004 (build 19041) or later, including Windows 11, on x64 or Arm64 hardware. See the Claude Desktop [system requirements](/docs/third-party/claude-desktop/installation#system-requirements). Devices in Windows S mode cannot run Cowork. * **Memory and disk.** Plan for at least 8 GB of memory and about 20 GB of free space on the drive that holds `%LOCALAPPDATA%`. Cowork keeps its workspace there after downloading it the first time a user starts a task. Cowork still starts on a device with less memory, but tasks run slowly. ## Installer and packaging * **Use the `.msix` package.** Cowork is available only when Claude Desktop is installed from the `.msix` package. The legacy `.exe` installer gives you Claude Desktop without Cowork. See [Install the app](/docs/third-party/claude-desktop/installation#install-the-app). * **Install machine-wide.** Have your management system (for example Intune or Configuration Manager) provision the package for all users from the system account, or provision it from an elevated PowerShell session with `Add-AppxProvisionedPackage` or the equivalent DISM command. The package registers a Windows service that Cowork uses, so an install run by a standard user fails, and installing by hand requires a local administrator. The [Windows deployment guide](https://support.claude.com/en/articles/12622703-deploy-claude-desktop-for-windows) covers downloading and distributing the package. * **Allow trusted app installation.** Make sure Windows policy allows trusted app packages to install from outside the Microsoft Store. If your security baseline configures **Allow all trusted apps to install** (the `ApplicationManagement/AllowAllTrustedApps` policy), set it to enabled. Windows Developer Mode is not required. * **Intune scripts.** For Intune, Anthropic publishes [install and detection scripts](https://downloads.claude.ai/releases/enterprise/intune/Claude-Intune-README.md) that deploy the `.msix` as a Win32 app, so that Intune keeps reporting the app as installed after the app updates itself. * **Offline installer.** For networks that cannot reach `downloads.claude.ai`, deploy the [offline installer](/docs/third-party/claude-desktop/installation#offline-installation), which includes the components that Cowork and Code otherwise download from that host. * **Nothing else to pre-install.** The `.msix` package is self-contained, with no separate runtimes or frameworks to install first. Git for Windows is needed only on devices whose users will work in Code; see [Before you begin](/docs/government/deploy-desktop/configure#before-you-begin). * **Software intake.** The package is MSIX rather than MSI or EXE, and Intune, Configuration Manager, and PowerShell deploy MSIX natively. If your software intake process names MSI or EXE packages specifically, confirm that it accepts MSIX. An MSIX package installs without prompts when your management system deploys it and takes no vendor-specific switches. ## Application control rules If you enforce application control with AppLocker or App Control for Business (formerly Windows Defender Application Control), allow Claude Desktop by publisher or by package family name rather than by path, and let the rule match any version, so that it keeps matching as the app updates. | Identifier | Value | | ---------------------- | ---------------------- | | Package name | `Claude` | | Package family name | `Claude_pzs8sxrjxfjjc` | | Publisher display name | Anthropic, PBC | These values identify the `.msix` package from the download site and the offline installer, and they do not change between versions or architectures. Cowork also runs an agent helper, a separate executable signed by Anthropic that the app places under each user's profile rather than inside the package. If AppLocker executable rules or endpoint security software with path-based rules apply on your devices, allow the helper by publisher too, as described under [Endpoint security software](/docs/third-party/claude-desktop/installation#endpoint-security-software). ## Cowork virtualization Cowork runs the shell commands that Claude issues inside a dedicated virtual machine that the app manages on each device, and Advanced file analysis in Chat uses the same virtual machine. Users install nothing for this, but each device must be able to start the virtual machine. The [Cowork readiness check](/docs/third-party/claude-desktop/installation#check-device-readiness) is a small program that verifies most of the requirements below on a device without installing anything or signing in. Run it on one device of each hardware model, and resolve what it reports before the broad rollout. * **Virtual Machine Platform.** Enable the **Virtual Machine Platform** optional Windows feature (`VirtualMachinePlatform`) on every device before rollout, for example by running `Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart` from an elevated PowerShell session, then restart the device so that the feature takes effect. Turning the feature on requires administrator rights, so a standard user cannot enable it later. * **Hardware virtualization.** Turn on hardware virtualization in each device's firmware (Intel VT-x or AMD-V on x64 devices). * **Service logon right.** The virtual machine runs under an account in the built-in `NT VIRTUAL MACHINE\Virtual Machines` group (SID `S-1-5-83-0`), the same group that Hyper-V and WSL 2 use, so a fleet where either of those works already meets this requirement. You only need to act if your security baseline manages the **Log on as a service** right through Group Policy. In that case, include this group, and keep it out of **Deny log on as a service**. * **Uncompressed application data.** Leave `%LOCALAPPDATA%\Claude-3p` out of NTFS compression and Encrypting File System (EFS) policies, because the virtual machine's disk cannot start from a compressed or EFS-encrypted folder. * **Virtual desktops.** On virtual desktop infrastructure, the Windows desktops themselves run as virtual machines, so Cowork can start only where the hosting platform exposes nested virtualization to them. Run the readiness check on one desktop in each pool, and make Cowork available to virtual desktop users only where it passes. On a device that does not meet these requirements, Chat still works apart from Advanced file analysis, and Cowork reports that it is unavailable. If a device meets them and Cowork still fails to start, check whether endpoint security software is blocking the Cowork agent helper, as described under [Application control rules](#application-control-rules). ## Configuration values * **Two registry values.** Push the two values described under [Windows](/docs/government/deploy-desktop/configure#windows) as machine policy under `HKLM\SOFTWARE\Policies\Claude`: the required `bootstrapUrl` and the recommended `disableDeploymentModeChooser`. No other values are needed, because everything else reaches each user from Claude for Government at sign-in. * **Delivery order.** Deliver the values before the app wherever you can, so that users land directly on the Claude for Government sign-in screen, as [Order of deployment](/docs/government/deploy-desktop/configure#order-of-deployment) explains. ## Network access Claude Desktop's own traffic is HTTPS on port 443, and you can allowlist it by hostname. The [Security and data handling](/docs/government/security/security-and-data-handling#network-egress-required-domains-and-proxies) page explains what each connection carries. * **App traffic.** Allow Claude Desktop on every device to reach the Claude for Government host, which carries the app's configuration and chat traffic. * **Browser sign-in traffic.** Allow the browser on every device to reach the Claude for Government host, the Claude for Government sign-in service (a separate host that your Anthropic representative provides), and your agency's identity provider. Sign-in happens in each user's default browser, not in the app. * **`downloads.claude.ai`.** The app downloads the Cowork workspace and the Claude Code command-line tool from this host when a user starts a Cowork task, a Code session, or Advanced file analysis in Chat. The offline installer includes both, so devices installed with it need this host only for application updates while automatic updates are on. * **`www.claudeusercontent.com`.** This host serves the frame that displays artifact previews. * **Update hosts.** While automatic updates are on, also allow the hosts listed under Auto-updates in [Required egress paths](/docs/third-party/claude-desktop/telemetry#required-egress-paths). The telemetry rows there never apply, because Claude for Government does not send telemetry to Anthropic. * **Hosts your tools and connectors use.** Allow the hosts you add to [Allowed network hosts](/docs/government/config/settings#allowed-network-hosts) (such as package registries), the addresses of any connectors you configure on the Config page (including Microsoft 365 if you set up that connector), and your telemetry collector if you set one. * **Proxies.** The app and the Cowork workspace follow the operating system's proxy settings, including PAC files, as described under [Proxy support](/docs/third-party/claude-desktop/telemetry#proxy-support). If your proxy inspects TLS, validate sign-in, a chat, and a Cowork task on a pilot device before rollout. ## User accounts and seats Make sure every user in the rollout can sign in and has a seat before their device is set up. Each user needs a [routing rule](/docs/government/tenant-admin/identity-and-access) that covers them and a [seat tier](/docs/government/org-admin/seat-tiers) with at least one model enabled. A user without a seat tier can sign in but gets an empty model picker, which can look like a device problem and is covered in the [Troubleshooting](/docs/government/deploy-desktop/configure#troubleshooting) table.
government/desktop/import First recorded · 43 lines, first recorded
# Import your data from Claude for Government Web ## Before you begin ## Run the import ## If your import fails
The first capture of this source. The page was already there, and this is what it said.
# Import your data from Claude for Government Web
> Copy your conversations, projects, and files from Claude for Government Web into Cowork in Claude Desktop.
> **Who this is for:** Anyone who used Claude for Government Web (the web app) and now uses Claude Desktop connected to Claude for Government.
The import copies your conversations, their attached files, and the projects you created, which arrive as [Cowork](/docs/cowork/overview) projects. It does not copy projects that other people shared with you.
## Before you begin
* **An account on the web app.** It must use the same work email address as your Claude for Government account in Claude Desktop. The import does not work with a personal claude.ai account.
* **Sign-in to the web app in your default browser.** The import opens a browser tab there for you to approve a one-time code.
> **For administrators:** Anthropic enables the import for each organization, so there is no [product setting](/docs/government/config/settings) for it. If your users should have the import and it does not appear for them, contact your Anthropic representative. Imported conversations and projects land in Cowork, so members need Cowork turned on under [product availability](/docs/government/config/settings#product-availability).
## Run the import
<Steps>
<Step title="Open the import dialog">
In Claude Desktop, open **Settings**, then the **Cowork** page, and click **Import** in the **Claude for Government Web import** row. The **Import from Claude for Government Web** dialog opens.
</Step>
<Step title="Sign in and approve the code">
Click **Sign in**. Claude Desktop shows a one-time code and opens your default browser to the web app. Sign in there with your work account if you are asked to, confirm that the code in the browser matches the one in the app, and approve it.
</Step>
<Step title="Start the import">
Back in the dialog, check that the email address shown is your work account, then click **Import**. The import can take a few minutes and continues in the background, so you can close the dialog while it runs.
</Step>
<Step title="Check the results">
If the dialog is open when the import finishes, it reports **Import complete** with the number of conversations, projects, and files it brought over. Otherwise, find your imported conversations in the app's sidebar, listed with your other chats and tasks.
</Step>
</Steps>
## If your import fails
| What you see | Likely cause | What to do |
| -------------------------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Your data is over the import's size limit | You have more data than the import can bring over | Remove conversations or files you no longer need in the web app, in line with your organization's records policy, then run the import again. |
| The account does not match your organization | You signed in to the web app with a different account | Start the import again and sign in with your work account. |
For anything else, try the import again; if it keeps failing, contact your administrator.
government/desktop/plugins First recorded · 36 lines, first recorded
# Plugins in Claude Desktop ## Where plugins come from ## Find and install plugins ## Manage installed plugins ## What plugins add in Claude for Government
The first capture of this source. The page was already there, and this is what it said.
# Plugins in Claude Desktop > Find, install, create, and remove plugins in Claude Desktop for Claude for Government, and understand what plugins add in this deployment. > **Who this is for:** Anyone who uses Claude Desktop in Claude for Government and wants to find, install, or create plugins. A plugin is a package that adds capabilities to Claude in a single step, such as skills, slash commands, sub-agents, and hooks. Plugins work in Cowork and in Code. See the [Plugins overview](/docs/plugins/overview) for more on what a plugin can contain. ## Where plugins come from In Claude for Government, plugins reach you in four ways: * Your administrators add plugins for your organization, and some of them install automatically. * You upload a plugin file you have. * You ask Claude to create a plugin with you. * You add a plugin marketplace and install plugins from it. Claude for Government does not include a public plugin marketplace; your administrators add your organization's plugins. You can also add a plugin marketplace of your own from **Browse plugins**. Your deployment's network controls determine whether a marketplace can be downloaded. ## Find and install plugins Open **Customize** in the sidebar, then **Plugins**. The organization plugins you have installed are listed under **Organization plugins**. To find the rest, select **Browse plugins** and open the **Organization** tab, which lists every plugin your administrators have made available to you. A plugin your administrators set to install automatically is already installed. A plugin they offer for you to choose stays available on the **Organization** tab until you install it. To install a plugin from a file, select **Add plugin**, then **Upload plugin**, and choose the plugin's `.zip` file. Claude Desktop shows a notice reminding you to install only plugins you trust, since uploaded plugins are not controlled by Anthropic. To have Claude build one, select **Add plugin**, then **Create with Claude**, and describe the plugin you want. Claude builds it for you, and you install the result. ## Manage installed plugins Open an installed plugin to see the skills, slash commands, sub-agents, and hooks it provides, and turn individual components on or off. To remove a plugin, open it and click **Uninstall**. Most plugins you uninstall stay removed for you, including ones your administrators set to install automatically. A plugin your organization requires cannot be removed, and Claude Desktop tells you it is required by your organization if you try. A plugin you upload or create is added only on the device you are using. ## What plugins add in Claude for Government A plugin adds its skills, slash commands, sub-agents, and hooks, and its hooks run on your machine at defined points during a session. The connectors you can use are the ones your administrators provide, which appear under **Customize**, then **Connectors**. Connectors declared by a plugin you add yourself are not added to Claude Desktop's connectors, and a local [MCP server](/docs/connectors/overview) declared by a plugin never runs.
government/desktop/skills First recorded · 55 lines, first recorded
# Skills in Claude Desktop ## Where skills come from ## Create and manage skills ## Skills for administrators ## Building and deploying your own skills
The first capture of this source. The page was already there, and this is what it said.
# Skills in Claude Desktop
> What skills are in Claude for Government, where they come from, how to create and manage your own, and how administrators distribute skills to members.
> **Who this is for:** Anyone who uses Claude Desktop in Claude for Government. The last two sections are for administrators who distribute skills to members.
A skill is a set of instructions, with optional scripts and resources, that Claude loads when a task matches it, so you can teach Claude a workflow once and reuse it. See the [Skills overview](/docs/skills/overview) for how skills work.
## Where skills come from
In Claude for Government, your skills come from three places:
* Skills you create yourself, which are stored on your device.
* Skills bundled in plugins your administrators deliver, which arrive with the plugin as described in [Plugins in Claude Desktop](/docs/government/desktop/plugins).
* Skills that ship with Claude Desktop for common document tasks, such as working with spreadsheets and presentations, which Claude loads automatically when a task calls for them.
## Create and manage skills
Open **Customize** in the sidebar, then **Skills**, to see your skills and turn any of them on or off. Select **Add skill**, then choose **Create with Claude** to build one with Claude's help, **Write skill instructions** to write it yourself, or **Upload a skill** to add a skill file you have. You can also ask Claude to save a workflow as a skill while you work on a task. The [skill authoring guide](/docs/skills/how-to) describes the file format for skills you write by hand.
Open a skill you created to rename or delete it. Skills you create are stored on your device, so they are available only there.
If your organization restricts skill creation through device managed configuration, the options to create and upload skills are hidden, and Claude does not offer to create or update skills in your conversations.
## Skills for administrators
The admin portal does not currently have a skills view or per-skill controls, so there is no setting that allows, blocks, or distributes a skill on its own. To distribute skills to the members you manage, bundle them in a plugin, which can be as small as the skill plus a plugin manifest, and add it on the **Plugins** card, as described in [Manage plugins and connectors](/docs/government/config/plugins-and-connectors).
A plugin set to **Auto-install** delivers its skills to every member without the member doing anything. A skill you distribute this way is managed through the plugin that carries it, so to change or retire the skill, update or remove the plugin.
## Building and deploying your own skills
This section walks the full path from writing a skill to delivering it to the members you manage: write the skill, package it as a plugin, upload the plugin, and check the result on a device. The packaging rules live under [Plugin archive formats](/docs/government/config/plugins-and-connectors#plugin-archive-formats).
**Write the skill.** A skill is a folder named after the skill, holding a `SKILL.md` file. The file starts with YAML frontmatter carrying `name` and `description`, followed by the instructions as markdown. The folder name must match the `name` in the frontmatter. The [skill authoring guide](/docs/skills/how-to) covers the format and what makes instructions work well. You can also have Claude help, with **Create with Claude** as described under [Create and manage skills](#create-and-manage-skills), or by asking Claude to draft the skill in a Cowork task, where those are available in your deployment. If Claude hands back a `.skill` file, keep the folder it came from instead. A `.skill` file is a zip of the bare skill folder, and the **Plugins** card accepts only plugin packages, so the folder needs the plugin wrapper described next.
**Mind the text-only rule.** A skill delivered through the admin portal can contain only text files, in these formats: `.md`, `.txt`, `.json`, `.yaml`, `.yml`, `.csv`. Skills you create on your own device can include scripts and binary assets such as images, and the skill authoring guide describes those, but a plugin upload that contains them is rejected, so keep a skill you plan to distribute textual.
**Package it as a plugin.** Arrange the skill inside a plugin and zip it. The smallest valid package is the manifest plus your skill folder under `skills/`:
```text theme={null}
acme-skills.zip
├── .claude-plugin/
│ └── plugin.json
└── skills/
└── brand-guidelines/
├── SKILL.md
└── palette.csv
```
`plugin.json` needs two keys, and a description is worth adding, for example `{"name": "acme-skills", "version": "1.0.0", "description": "Agency writing skills"}`. One plugin can carry several skills, one folder per skill. Zipping the plugin folder itself also works, since the upload accepts the single wrapping folder. Claude can do the assembly in a Cowork task: give it the layout above, paste in the full rules from [Plugin archive formats](/docs/government/config/plugins-and-connectors#plugin-archive-formats), and ask it to arrange the files and produce the zip. Claude Desktop in Claude for Government does not include a packaging skill, so put the layout in your request rather than assuming Claude knows it.
**Upload it.** On the **Config** page, open the **Plugins** card, click **Add plugins**, and drop the zip. The preview shows the plugin's name, version, and description. A plugin packaged as above, with only skills and the three manifest keys, is not marked **Runs code**. The marker and its confirmation appear when a package declares components that can run code on members' machines, or carries a manifest key the upload does not recognize, as described under [Plugins that run code](/docs/government/config/plugins-and-connectors#plugins-that-run-code). Choose **Auto-install** to deliver the skills to every member, or **Members choose** to let members install the plugin themselves.
**Check it on a device.** The upload checks packaging, not skill content, so a plugin whose `SKILL.md` is malformed uploads without complaint and simply never loads as a skill. After adding the plugin, open Claude Desktop as a member: install the plugin if you chose **Members choose**, then give Claude a task the skill should match and confirm Claude picks it up. To change the skill later, update the plugin, as described under [Update or remove a plugin](/docs/government/config/plugins-and-connectors#update-or-remove-a-plugin).
government/org-admin/analytics First recorded · 78 lines, first recorded
# Analytics ## How the data is gathered ## Managed and self-managed views ## Credits (self-managed view only) ## Active users ## Usage ## CSV exports ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Analytics > Use this page to review requests, tokens, spend, top users, and credit balance over time across your organization, and to download the data as CSV files for offline reporting. > **Who this is for:** Organization owners who need to understand how their organization is using Claude and how quickly it is consuming credits. Use this page to review requests, tokens, spend, top users, and credit balance over time across your organization, and to download the data as CSV files for offline reporting. Because this data takes a moment to compute, the page starts with a **Load analytics** button. After the data loads, the results are cached for the rest of your session. You can click **Refresh** to fetch the latest numbers, and this button becomes available again 30 seconds after the previous load. A **Download** menu next to **Refresh** saves what the page shows as CSV files, described in [CSV exports](#csv-exports). ## How the data is gathered Usage figures on this page are compiled from the same metering that enforces your users' rate limits, so the request, token, and spend numbers here will closely match what your users experienced. All times are shown in your browser's time zone; if your browser reports a time zone the service does not recognize, times fall back to UTC. ## Managed and self-managed views A control at the top switches between **Anthropic-managed tiers** and **Self-managed tiers**. The two are shown separately because their economics differ: managed-tier seats are purchased as seats, while **self-managed tiers** (tiers your organization created itself on the [Tiers](/docs/government/org-admin/seat-tiers) page) draw down the billing account's balance. Spend figures and the credit panel are therefore shown only in the **Self-managed** view. If your organization has only one kind of tier, the control does not appear and the page shows only the matching view. If all of your seat tiers are Anthropic-managed, you see only the managed view, with no spend figures, credit panel, or burndown chart. ## Credits (self-managed view only) <Note> The credit panel and burndown chart only appear in the **Self-managed tiers** view, and only once credit data is available for your organization. The runway estimate within the panel only appears once there has been enough recent activity to compute a burn rate. </Note> When credit data is available, the credit panel shows the current position of the account your organization draws from as of right now. It displays the **Credits remaining** out of the total added to the account, with a progress bar marked at the 70 percent and 90 percent warning thresholds. It also shows a runway estimate that tells you roughly how many days remain at your trailing 7-day burn rate, and it adds a **Depleted**, **Low balance**, or **Approaching limit** badge when one of those conditions applies. The runway figure divides your remaining balance by your average daily spend over the last seven complete days. It is shown as "less than 1 day" when the balance is nearly exhausted and as "more than 180 days" when spend is low enough that a longer projection would not be meaningful. If there has been no spend at all in the last seven days, no runway is shown. Below the panel, the **Credit burndown** chart plots your balance, with markers on the days credits were added, and projects forward to the date you are estimated to reach \$0. The chart reaches back 30 days, or 90 days when you set the time-window selector described below to **90 days**. <Tip> The credit panel always reflects the current position and is not affected by the time-window selector. The 7-day lookback used for the burn rate is also fixed and does not change when you switch the usage window. </Tip> ## Active users The **Active users** section shows how many distinct people used Claude over fixed periods: the average number of daily active users over the last 7 days, the number of weekly active users over the last 7 days, and the number of monthly active users over the last 30 days. These figures always use the same fixed lookbacks and are not affected by the time-window selector below. ## Usage Everything below the **Usage** divider is scoped to a time window that you choose with the **24 hours**, **7 days**, **30 days**, or **90 days** selector. The summary tiles show the number of requests, the input and output token counts (a token is roughly a piece of a word, and it is the unit that Claude's usage is measured in), and, in the self-managed view, the estimated spend for the selected window. The **Token usage** chart plots input and output tokens over the window. It shows hourly data when you select the 24-hour window and daily data for the longer windows. The **Active users over time** chart plots the number of distinct users who made at least one request in each period of the window, using the same hourly or daily buckets as the token chart. The **By product** table breaks usage down by which Claude product it came from (for example, Claude Desktop or Claude Code), with the same request, token, and spend columns as the other tables. This table only appears once your deployment has recorded usage from at least one product. The **By model** table lists each model used in the window along with its request count, input tokens, output tokens, and, in the self-managed view, its spend. The **Top users** table lists the most active users in the window with the same columns. The table starts with ten rows, and you can click **Show more** to reveal additional users. Up to 100 users are listed individually, and beyond that a note tells you how many more are not listed. ## CSV exports The **Download** menu at the top of the page, next to **Refresh**, saves what the page shows as CSV files. **All** downloads a ZIP archive of the current view, one CSV file per table. The other entries download one table each: **Summary**, **Usage over time**, **By product**, **By model**, and **Top users**, with **Credit burndown** and **Credit top-ups** added in the self-managed view. The menu becomes available again 30 seconds after the previous download. Exports follow the view and the time window you have selected. The credit files match the burndown chart, reaching back 30 days, or 90 days when you select the **90 days** window. In the summary file, the credit figures are the account's position at the time of the export, not spend within the window. The ZIP archive includes an `export_info.csv` file recording the export's context, including when it was made, the organization, the view, the window and its date range, and the time zone the dates are in. In the self-managed view it also records the date range the credit files cover. File names state the view, the time span, and the dates covered, and single-table files also name their table. The top users file lists every user the **Top users** table can show, whether or not you have expanded the table with **Show more**, and adds each user's ID and account status to the columns shown on screen. ## Things to know * Claude for Government does not currently offer a programmatic usage or analytics API. Usage data is available through this admin portal page. The [Compliance API](/docs/government/org-admin/compliance-api) returns governance and audit events, not usage metrics. * A user counts as **active** in the selected window if they made at least one request in it, regardless of which seat tier they were on at the time. * The **spend** column appears only in the self-managed view and is the amount debited from your billing account's balance. The managed view has no spend column because managed-tier usage is covered by the seat price rather than by credit drawdown. * To see how close each user is to their 5-hour and 7-day limits, use the **Usage** bars on the [Users](/docs/government/org-admin/users) page. The **Top users** table on this page shows how much each listed user consumed in the window, not how close they are to a limit. * If the credit panel is missing from the self-managed view, credit data for your organization's billing account is unavailable. The rest of the page will still load. * Usage that was cleared with **Reset usage limits** on the [Users](/docs/government/org-admin/users) page still appears here. The reset only clears the counter that enforces a user's limit; it does not remove the activity from analytics.
government/org-admin/billing First recorded · 46 lines, first recorded
# Billing ## Billing account ## Seats ### Rules for changing seat allocations
The first capture of this source. The page was already there, and this is what it said.
# Billing > Use this page to see the balance your organization spends from and any spend caps set on it, and to adjust your organization's seat allocation. > **Who this is for:** Organization owners who want to see the balance their organization spends from and any spend caps set on it, and manage their organization's seat allocation. Use this page to see the balance your organization spends from and any spend caps your tenant administrator has set, and to adjust your organization's seat allocation. A **billing account** is the funding pool that pays for one or more organizations in your tenant. Your organization's usage on self-managed seat tiers draws directly from this account's balance, and Anthropic adds credit to the account. Your tenant administrator can also set a **spend cap** on your organization, which limits how much it can draw from the account in a rolling 5-hour or 7-day window. <Note> The **Billing** tab appears in the navigation when the billing account is active and your own organization is active on it. If the tab is hidden, this page is still reachable from a direct link. Funding is arranged with Anthropic by your tenant administrators; contact them about credits or spend caps. </Note> ## Billing account At the top you see the billing account's available balance, or, when the balance is not shown to you, a line explaining who manages the account. The balance is shared by every organization the account funds. Below the balance, the page shows the spend caps currently set on your organization, in the form "\$X per 5 hours, \$Y per 7 days", or "No spend caps are set" if none are. These caps are set by your tenant administrator and cannot be changed here. A cap of \$0 pauses your organization's spending from the account, and a banner appears on this page saying so. When the account's balance reaches 70 percent, 90 percent, and 100 percent consumed, a spend-alert banner appears on every page of the organization admin portal and an email is sent to your organization's owners. The banner stays in place until Anthropic adds more credits to the account. Your organization's usage against the account balance is shown on the [Analytics](/docs/government/org-admin/analytics) page. ## Seats The **Seats** section shows the pool of Anthropic-managed seats funded by this account. For each tier the table shows the **Pool** total, which is the number of seats granted to the account, the **Distributed** count, which is how many of those seats have been handed out to organizations, and the **Remaining** count, which is the number still available to distribute. <Note> The seat allocation editor below only appears when the account has at least one seat tier in its pool. </Note> An editor below the table lets you set how many seats of each tier your organization holds. Enter the number you want for each tier and click **Save**. The change takes effect immediately. ### Rules for changing seat allocations The editor enforces the following rules and will refuse a save that violates any of them. * You cannot request more seats for a tier than the billing account has remaining in its pool after accounting for other organizations. * You cannot reduce a tier's seat count below the number of users currently seated on it in your organization. Move users off the tier on the [Users](/docs/government/org-admin/users) page first, then lower the count. * You can set a tier to zero seats, which removes the tier from your organization entirely, but only if no one is seated on it. * Each tier's seat count can be at most 100,000. <Tip> Saving a seat allocation also triggers a directory provisioning sync. If users were previously left unassigned because a tier was full, the sync will now seat them automatically up to the new limit. </Tip>
government/org-admin/compliance-api First recorded · 152 lines, first recorded
# Compliance API ## Managing API keys ## Calling the API ### Query parameters ### Response format ### Identifying users ### Activity types ## Connecting to your SIEM ## When the API is disabled ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Compliance API
> Stream your organization's audit events into a SIEM or log management system.
> **Who this is for:** Organization owners and the security or compliance teams who connect Claude for Government to their agency's log management or SIEM platform.
The Compliance API is a read-only HTTP endpoint that lets your security tools pull a continuous feed of audit events covering administrative activity across your organization, such as sign-ins, role changes, key creations, and seat assignments. A scheduled job can poll the endpoint and forward each event to a SIEM such as Splunk or Microsoft Sentinel.
The API is available to every Claude for Government organization by default, and it is read-only, so a compromised key cannot change anything in your organization.
## Managing API keys
Open **Compliance API** in the organization admin portal to create and manage keys. The page lists every key that has been issued for your organization, showing its name, a hint with the last few characters of the key so you can tell them apart, when it was created, and whether it is active or revoked.
To create a key, enter a name and click **Create key**. The full value is shown once, immediately after creation. Copy it somewhere safe before clicking **Done**.
<Warning>
The full key value is shown **only once**, at creation time. If you lose it, create a new key and revoke the old one.
</Warning>
Keys never expire on their own, so rotate them on whatever schedule your agency's policy requires. You can keep more than one key active at a time, which lets you rotate without interrupting your SIEM feed: create a new key, update your collector to use it, confirm events are still arriving, and then revoke the old key. Revoking a key takes effect immediately, and the next request made with it returns a 401.
Each key is scoped to the organization it was created in. A request can only ever return events for that one organization, regardless of who holds the key.
## Calling the API
Send a GET request to `/v1/compliance/activities` on the Claude for Government host provided to you during onboarding, with your key in the `x-api-key` header.
```http theme={null}
GET /v1/compliance/activities?since=2026-07-01T00:00:00Z&limit=500
Host: <your-deployment-host>
x-api-key: <your-compliance-api-key>
```
### Query parameters
| Parameter | Description |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `since` or `created_at.gte` | The earliest event time to return, as an RFC 3339 timestamp or epoch seconds. A lower bound is required on every request that does not carry a cursor. |
| `until` or `created_at.lte` | The latest event time to return, in the same format. Optional. |
| `after_id` | An opaque cursor that continues from where a previous page left off. Pass the `last_id` value from the previous response. |
| `before_id` | An opaque cursor that pages in the other direction. Pass the `first_id` value from the previous response. Cannot be combined with `after_id`. |
| `actor_ids[]` | Return only events performed by the listed actors. Repeat the parameter to pass more than one. |
| `activity_types[]` | Return only events of the listed types. Repeat the parameter to pass more than one. |
| `limit` | Maximum events per page, from 1 to 5000. Defaults to 100. |
The exclusive bounds `created_at.gt` and `created_at.lt` are also accepted if your collector needs them.
### Response format
The response is a JSON envelope containing a page of events and the cursors for the next and previous pages.
```json theme={null}
{
"data": [
{
"id": "activity_01js0example000000000000",
"type": "user.signed_in",
"created_at": "2026-07-01T14:22:09.412Z",
"organization_id": "org_00000000-0000-0000-0000-000000000000",
"organization_uuid": "00000000-0000-0000-0000-000000000000",
"actor": {
"type": "user_actor",
"user_id": "usr_00000000-0000-0000-0000-000000000000",
"email_address": "[email protected]"
},
"user_id": "usr_00000000-0000-0000-0000-000000000000",
"user_email": "[email protected]"
}
],
"has_more": true,
"first_id": "<opaque cursor>",
"last_id": "<opaque cursor>"
}
```
The `actor` object identifies who performed the action. Its `type` is one of:
* `user_actor` for a person acting through the product or admin portal.
* `admin_api_key_actor` for an action taken through an administrative API key.
* `anthropic_actor` for an action performed by Anthropic personnel or systems on your behalf, such as initial provisioning. No individual identity is included.
Each event also carries fields specific to its type, such as the role a user was changed to or the name of a key that was created.
### Identifying users
When one of your own users performs an action, `actor.user_id` and `actor.email_address` name them, including on sign-in events. Actions taken by Anthropic personnel or automated systems appear as `anthropic_actor` with no individual identity, by design.
On every `user.*` activity, two top-level fields identify the user the event is about, so your SIEM can map events back to people in your directory without a separate lookup.
| Field | Description |
| ------------ | -------------------------------------------------------------------------------- |
| `user_id` | The Claude for Government user ID, in the same `usr_` format as `actor.user_id`. |
| `user_email` | The user's email address at the time of the event. |
The user an event is about is not always the actor. When an owner changes someone's role, the `actor` block names the owner and these fields name the user whose role changed.
```json theme={null}
{
"id": "activity_01js1example000000000000",
"type": "user.role_changed",
"created_at": "2026-07-02T09:18:33.205Z",
"organization_id": "org_00000000-0000-0000-0000-000000000000",
"organization_uuid": "00000000-0000-0000-0000-000000000000",
"actor": {
"type": "user_actor",
"user_id": "usr_00000000-0000-0000-0000-000000000001",
"email_address": "[email protected]"
},
"user_id": "usr_00000000-0000-0000-0000-000000000002",
"user_email": "[email protected]",
"old": "user",
"new": "owner"
}
```
The top-level `user_id` and `user_email` fields appear on activities recorded after they were added to the API. Earlier activities are not updated, so your collector should treat these fields as optional.
### Activity types
Event types use a dotted `resource.action` naming convention. The categories emitted today include:
* **Users** such as `user.created`, `user.signed_in`, `user.role_changed`, `user.deactivated`, and `user.reactivated`.
* **Organizations** such as `org.created`, `org.renamed`, and `org.deactivated`.
* **Credentials** such as `api_key.created`, `scim_token.created`, and `scim_token.revoked`.
* **Seats and tiers** such as `seat_allocation.set`, `seat_allocation.tier_assigned`, `seat_tier.created`, and `seat_tier.updated`.
* **Configuration** such as `org_config.capabilities_set`.
New types may be added over time, so a collector should forward unfamiliar types rather than reject them.
## Connecting to your SIEM
Most deployments run a small scheduled worker that polls the API on a fixed interval, forwards each event to the SIEM's HTTP ingest endpoint, and records a time watermark so the next run picks up where the last one left off.
A typical run requests `since=<watermark>`, forwards every event returned, and if `has_more` is true, follows `after_id=<last_id>` for each further page until `has_more` is false. After all pages are drained, advance your watermark to the newest `created_at` you saw. Event `id` values are stable and unique, so your collector can deduplicate on `id` and safely retry a page or use an overlapping `since` without creating duplicate records in the SIEM.
## When the API is disabled
Your tenant administrator can turn off the **Compliance API** setting on the [tenant Config page](/docs/government/tenant-admin/configuration). When that setting is off, the Create key button is hidden in the portal, and every call to `/v1/compliance/activities` returns a 400 error, including calls made with keys that were valid before the setting changed.
Listing and revoking existing keys in the portal remains available even when the setting is off, so an exposed key can still be revoked.
## Things to know
* The Claude for Government Compliance API is served from the Claude for Government service hostname, not from `api.anthropic.com`. Use the same host you use to reach the admin portal.
* There is no separate Splunk add-on. The polling pattern described under [Connecting to your SIEM](#connecting-to-your-siem) is the reference implementation for a Splunk HTTP Event Collector job.
* The desktop application's OpenTelemetry export is a separate log stream configured with **Telemetry endpoint (Claude Desktop)** on the [Config](/docs/government/config/settings#telemetry-endpoint-claude-desktop) page. It carries per-session tool and telemetry events to a collector you specify, while this API carries administrative audit events. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) for what the OpenTelemetry export includes.
* The Compliance API returns governance and audit events only. It does not return conversation content, files, or anything your users type into Claude.
* Each organization can hold up to 50 active keys at once. Revoked keys do not count toward this limit.
* Events are returned newest first within each page.
* `first_id` and `last_id` are opaque cursors. Pass them back exactly as received rather than constructing them yourself.
* If your network enforces a [tenant restriction](/docs/government/tenant-admin/tenant-restrictions), the same restriction applies to Compliance API requests.
government/org-admin/configuration First recorded · 21 lines, first recorded
# Config at the organization level ## What is specific to the organization level
The first capture of this source. The page was already there, and this is what it said.
# Config at the organization level > View and change the product settings that apply to everyone in your organization, and see where each effective value comes from. > **Who this is for:** Organization owners who set product behavior, such as the session timeout, Claude Desktop banner, and product availability, for everyone in their organization. Use this page to view and change the product settings that apply to everyone in your organization, and to see where each effective value comes from. The Config page works the same way at the tenant and organization levels, with the same list of settings. See [How Config works](/docs/government/config/overview) for the levels model, locks, groups, comparing across levels, and looking up one person's settings, and [Available settings](/docs/government/config/settings) for what each setting does. This page covers only what is specific to the organization level. ## What is specific to the organization level **Managed settings.** A setting that your tenant has locked shows as **Managed** and is read-only here. Any value you had previously set is ignored while the lock is in place, and it comes back into effect if the tenant later removes the lock. See [Locks](/docs/government/config/overview#locks). **Settings only the tenant can change.** [Let organizations manage their own seat tiers](/docs/government/config/settings#let-organizations-manage-their-own-seat-tiers) and [Compliance API](/docs/government/config/settings#compliance-api) are always read-only here, regardless of whether they are locked. **Inherited plugins.** Plugins the tenant has added are labeled **Inherited from your tenant** and cannot be changed from here. See [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards). **Group settings within your organization.** A value you set for a directory group at this level applies only to people who are both a member of the group and a member of your organization, and it is the most specific level in the chain. Group priority is set by your tenant administrator and is shown here for reference; you cannot reorder it from the organization portal. See [Group-specific settings](/docs/government/config/overview#group-specific-settings). **Your own organization only.** Organization owners manage only their own organization's Config page. Tenant administrators can open any organization's Config page and act on that organization's behalf.
government/org-admin/overview First recorded · 78 lines, first recorded
# Organization administration ## Key concepts ## Who can access it ## Getting around ## Pages in this portal ## How changes take effect
The first capture of this source. The page was already there, and this is what it said.
# Organization administration > Manage the people, seats, and settings for a single organization within your agency. > **Who this portal is for:** Organization owners. If you manage multiple organizations across your agency, see the [Tenant administration](/docs/government/tenant-admin/overview) guide instead. The organization admin portal is where you manage the people, seats, and settings for a single organization in Claude for Government. It covers the day-to-day work of administering who has access, how much they can use, and how the Claude products behave for your users. ## Key concepts Before you use the portal, it helps to understand how the pieces fit together. Your agency's deployment is a **tenant**, which is the top-level container that holds one or more **organizations**. An organization is a self-contained group of users with its own seats, settings, and usage. Most administrators work at the organization level, while tenant administrators oversee all of the organizations together and control tenant-wide resources such as single sign-on, directory provisioning, and billing accounts. Every person in an organization holds a **role**, which determines whether they can reach this portal at all, and occupies a **seat** on a **seat tier**, which determines which Claude models they can use and how much they can use them. Seat tiers come in two kinds: * **Anthropic-managed tiers** that are supplied to you as a fixed number of seats. * **Self-managed tiers** that your organization defines itself and that draw from the billing account's balance. ## Who can access it You can reach the organization admin portal if your role in the organization is **Owner** or **Primary Owner**. Users who hold the standard **User** role are redirected to their personal account page instead. > **For tenant administrators:** You can also open this portal for any organization in your tenant. When your tenant contains more than one organization, an **Acting as** selector appears at the top of every admin page so you can choose which organization you are currently managing. All the changes you make while acting as an organization apply to that organization, and the audit trail records your own identity as the actor. ## Getting around The portal header shows your organization's name, and a navigation bar below it gives you access to each admin page. <Note> If the account your organization draws from crosses a warning threshold, a banner appears just below the navigation on every page of this portal. When your organization manages the account or is the only one using it, the banner tells you the percentage of credits used. When the account is shared with other organizations and yours does not manage it, the banner instead says credits are running low and points you to your tenant administrators. The banner stays in place until more credits are added to the account, and it escalates in color and wording if usage crosses a higher threshold. Every owner sees the banner, including when the Billing tab is hidden, so that you always know when your organization is running low. </Note> > **For owners and tenant administrators:** You can reach the user view from the **Switch to user view** link in the page footer. If you are also a tenant administrator, the footer additionally offers **Switch to tenant view**. ## Pages in this portal The navigation groups the pages into three sections. **People** | Page | What it's for | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | [Users](/docs/government/org-admin/users) | Find users, change their role or seat tier, check their usage, and reset their rate limits. | | [Seats](/docs/government/org-admin/seats) | See how many seats of each tier your organization has and how many are currently in use. | | [Tiers](/docs/government/org-admin/seat-tiers) | Review the Anthropic-managed seat tiers and create your own tiers with custom model access and spend limits. | | [Group mappings](/docs/government/org-admin/provisioning) | Map directory groups to seat tiers and roles so that users added through your directory land in the right place automatically. | **Usage** | Page | What it's for | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | | [Analytics](/docs/government/org-admin/analytics) | Review requests, tokens, spend, top users, and credit balance over time across your organization. | | [Compliance API](/docs/government/org-admin/compliance-api) | Create and manage read-only API keys that stream your organization's audit events to a SIEM or log management system. | | [Billing](/docs/government/org-admin/billing) | See the billing account that funds your organization, its balance and any spend caps, and adjust your seat allocation. | **Settings** | Page | What it's for | | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | [Config](/docs/government/org-admin/configuration) | Adjust product settings such as telemetry, the Claude Desktop banner, and product availability for everyone in your organization. | | [Readiness](/docs/government/org-admin/readiness) | See what is blocking users from using Claude and where each item is resolved. | <Warning> The **Billing** tab only appears when the billing account is active and your own organization is active on it. If you don't see it, contact your tenant administrators about credits or spend caps. </Warning> <Warning> The **Group mappings** tab only appears if automatic directory provisioning has been set up for your tenant. If you don't see it, your tenant administrator has not connected a directory, and users are placed by the tenant's routing rules alone. </Warning> <Note> Single sign-on and the SCIM provisioning connection are configured at the tenant level, so they are managed on the [tenant portal's Identity and access page](/docs/government/tenant-admin/identity-and-access) rather than here. </Note> ## How changes take effect Most changes you make in this portal take effect immediately. Changing a user's seat tier, updating a spend limit, or resetting a user's rate limits applies to their very next request. Product configuration changes are picked up the next time a user's Claude application refreshes its settings, which happens when the application is launched or when the user signs in. Group mapping changes trigger an immediate re-sync so you do not need to wait for a scheduled cycle.
government/org-admin/provisioning First recorded · 56 lines, first recorded
# Group mappings ## How provisioning works ## Group to seat tier ## Group to role ## How mappings are applied ## Group to organization routing ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Group mappings > Use this page to map the groups pushed from your identity provider to seat tiers and roles in this organization. > **Who this is for:** Organization owners who want directory groups to drive seat tiers and roles automatically. Use this page to map the groups pushed from your identity provider to seat tiers and roles in this organization. <Note> The **Group mappings** tab only appears in the navigation if automatic directory provisioning has been set up for your tenant. If you don't see the tab, your tenant administrator has not connected a directory. </Note> **SCIM** (System for Cross-domain Identity Management) is the standard protocol that identity providers such as Okta and Microsoft Entra use to push user accounts and group memberships into other applications. Once a SCIM connection is in place, your directory groups appear here and you can map each one to a **seat tier** (a named level of access that determines which Claude models and usage limits a user gets) and a **role** (which controls whether a user can access this admin portal). <Note> The SCIM connection itself, including the base URL and secret token, is set up once for the whole tenant on the [tenant portal's Identity and access page](/docs/government/tenant-admin/identity-and-access). This page only covers the group mappings for your organization. </Note> ## How provisioning works Your identity provider pushes users and groups to Claude for Government whenever something changes in your directory, and most providers also run a full sync periodically (the default interval depends on your identity provider). Each push is written to a staging area first and then applied to your real user list by a reconciliation pass. Reconciliation runs automatically whenever your identity provider pushes a change and also whenever you add, edit, or remove a mapping on this page. You do not need to trigger it manually, and you do not need to wait for a scheduled cycle after changing a mapping. ## Group to seat tier To add a mapping, choose a group and a tier and click **Add**. Existing mappings are listed with a **Remove** button. Each group can be mapped to at most one tier, and you can only select tiers that are available to this organization (either an Anthropic-managed tier you have been allocated or a self-managed tier you created on the [Tiers](/docs/government/org-admin/seat-tiers) page). <Note> The **Add** form only appears when at least one synced group is still unmapped. If no groups have appeared at all, assign groups to the Claude for Government application in your identity provider and run a provisioning sync first. </Note> ## Group to role The same mechanism can set a user's role. Map a directory group to **User** or **Owner**, and members of that group receive that role when they are provisioned. You cannot map a group to Primary Owner; that role must always be granted manually on the [Users](/docs/government/org-admin/users) page. ## How mappings are applied When a provisioned user belongs to several mapped groups, the first matching tier mapping and the first matching role mapping in a fixed order win. This order is deterministic but not one you can configure, so it is best to avoid assigning a user to overlapping mapped groups. A provisioned user who belongs to no mapped group is placed on a seat using the automatic assignment described on the [Seats](/docs/government/org-admin/seats) page and is given the standard **User** role. If a mapped tier has no free seats when a user is provisioned, the user is created but left **Unassigned** and has no model access. They will be seated automatically on the next reconciliation after seats become available, for example after you increase the allocation on the [Billing](/docs/government/org-admin/billing) page or another user is deactivated. Adding, changing, or removing a mapping triggers a full reconciliation immediately, so existing users are re-evaluated against the new mapping without waiting for your identity provider's next sync. ## Group to organization routing > **For tenant administrators:** Mapping directory groups to organizations is handled on the [tenant portal's Identity and access page](/docs/government/tenant-admin/identity-and-access) rather than here. ## Things to know * Provisioning is the source of truth while it is connected. A seat tier or role you set manually on the [Users](/docs/government/org-admin/users) page will be overwritten on the next reconciliation if the user's group mappings say otherwise. Make permanent changes in your directory instead. * Deactivating a user in your directory deactivates them in Claude for Government and releases their seat. Reactivating them in the directory reactivates them here and attempts to seat them again. * The reconciliation pass protects against removing your last administrator. It will not deactivate the organization's only active Primary Owner, and it will not deactivate the tenant's only tenant administrator, even if your directory says to. * A group mapping cannot be saved if it points at a seat tier that no longer exists, and a seat tier cannot be deleted on the [Tiers](/docs/government/org-admin/seat-tiers) page while a mapping still points at it.
government/org-admin/readiness First recorded · 36 lines, first recorded
# Readiness ## How the checklist is presented ## What each check means ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Readiness > Use this page to see everything that is stopping people in your organization from using Claude, and where each blocker is resolved. > **Who this is for:** Organization owners who are setting up an organization for the first time, or who need to find out why their users are unable to use Claude. Use this page to see everything that is stopping people in your organization from using Claude, and where each blocker is resolved. Your organization is ready when a member can sign in, hold a seat on a tier that reaches a working model, and send a message that the organization can pay for. This page runs that check and lists each step that is complete, blocked, or waiting on someone else. You would normally work through it once when the organization is first set up and then return whenever the **Settings** menu shows a notification dot, which appears whenever anything on this page needs attention. ## How the checklist is presented Each step sits on a vertical track with a status marker. * A **green check** means the step is complete. The label is struck through and you can ignore it. * A **filled circle** marks the step you should act on next. It expands to explain why it is blocked and offers an **Open** button that takes you to the page where the fix is made. * A **clock** means the step is blocked but you are not the person who can clear it. A line underneath tells you whether it is waiting on Anthropic, on your tenant administrator, or on the owner of a shared billing account. * A **hollow circle** is a step still to come. It stays collapsed until the steps ahead of it are cleared. Use **Refresh** at the top right after you make a change elsewhere to see the updated state without leaving the page. ## What each check means * **Activate the tenant** appears on its own if your agency's tenant is still being provisioned by Anthropic or has been deactivated. Nobody in any organization can sign in until this clears. Only Anthropic can resolve it, so contact your Anthropic representative. * **Activate the organization** appears on its own if this organization has been deactivated. While it is inactive its members cannot sign in and none of the other checks can be cleared. Reactivation is handled by Anthropic. If the organization's billing account has also been retired, the page explains that it must be assigned a new account before it can be brought back. * **Add credits** checks that the billing account your organization draws from has enough balance to cover at least one request on the cheapest model available to it. Until it does, every message from a user on a self-managed tier is refused. Credit is added to the billing account by Anthropic, so this step shows who to contact: your tenant administrator, or the owner of the organization that manages the shared billing account. * **Raise the organization's spend cap** appears when a tenant administrator has set a spend cap on your organization that is lower than the cost of one request on the cheapest model available. Every request from a user on a self-managed tier is refused until the cap is raised or cleared. Only a tenant administrator can change caps, so this step shows **Waiting on your tenant admin**. * **Allocate seats** checks that the organization has been allocated at least one seat of any tier. This is advisory. Without an allocation you can still assign tiers to people individually, but anyone who signs in before you do lands without a seat and cannot send messages. **Open Seats** or **Open Billing** takes you to the page where allocations are set, depending on how your billing account is managed. If the shared seat pool is already fully distributed, the step instead explains that the pool needs to be raised and shows who can do that. * **Assign a model to your seat tier** checks that at least one seat tier in this organization can actually reach a working model, meaning a model that is enabled, priced, and allowed by a tier whose usage limits are high enough to cover a single request. If no tier qualifies, nobody can send a message regardless of credits or seats. **Open Tiers** takes you to the [Seat tiers](/docs/government/org-admin/seat-tiers) page to add a model or raise a tier's limits. If every tier available to you is Anthropic-managed, only Anthropic can change its model list, so the step shows a waiting state. * **Enable a product** checks that at least one Claude product, such as Claude Desktop, Claude Code, or Claude for Microsoft 365, is enabled for this organization. This is advisory. With nothing enabled, direct API access still works, but no client application can start. Enable a product on the [Config](/docs/government/org-admin/configuration) page. ## Things to know * Every **Open** button goes to the page where the fix belongs. You make the change there and return here to see it reflected. * If a step you expect to clear yourself is shown as waiting on your tenant administrator, it usually means the resource it checks is managed at the tenant level. Your tenant administrator can clear it from the [tenant Readiness page](/docs/government/tenant-admin/readiness), which shows every organization's checklist in one place. * Hover the help icon next to any step's label for a one-line explanation of what the check looks for.
government/org-admin/seat-tiers First recorded · 57 lines, first recorded
# Seat tiers ## The tier list ## Anthropic-managed versus self-managed tiers ## Creating a self-managed tier ## Viewing and editing a tier ## Deleting a tier ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Seat tiers > Use this page to see the models and spend limits attached to each tier and, when permitted, to create and edit self-managed tiers. > **Who this is for:** Organization owners who need to review the seat tiers available to their organization or define their own. Use this page to see the models and spend limits attached to each tier and, when permitted, to create and edit self-managed tiers. A **seat tier** bundles together which Claude models a user may access and how much they may spend in a given period. Every user sits on exactly one tier (or is unassigned), and the tier they hold controls their day-to-day limits. The **Tiers** page lists every tier available to your organization. ## The tier list Tiers are listed with Anthropic-managed tiers first, followed by your organization's self-managed tiers. Each entry shows the tier's name, how many users are currently on it, and the seat limit if one applies. Clicking any tier opens its detail page. ## Anthropic-managed versus self-managed tiers **Anthropic-managed tiers** are defined by Anthropic and allocated to you through your tenant's billing account. On the detail page you can see which models the tier allows, but the spend limits are not shown and you cannot change the tier's settings or delete it. These tiers are paid for as seats rather than through credit drawdown, so their per-user spend limits are an internal detail that Anthropic manages on your behalf. **Self-managed tiers** are created by your organization. They draw from the billing account your organization spends from instead of a fixed seat count, and you have full control over their name, spend limits, and allowed models. A self-managed tier may or may not have a seat limit, depending on how it was allocated; when it has no limit, you can place as many users on it as you wish and the account's balance and any spend cap set on your organization are the effective constraint. ## Creating a self-managed tier Click **New seat tier** and fill in the form. * **Name** sets what the tier is called, for example *Analyst* or *Reviewer*. Names must be unique within your organization, and cannot duplicate the name of any Anthropic-managed tier. * **Five-hour spend limit** sets the most each user on this tier can spend in any rolling 5-hour window, expressed in dollars. When a user reaches this amount, further requests are refused until the window rolls forward. Set it to zero to allow no usage at all. * **Seven-day spend limit** does the same for a rolling 7-day window. Both limits apply at the same time, so whichever is reached first stops the user. * **Allowed models** controls which Claude models users on this tier may use. If you leave it empty, users on the tier have no model access regardless of their spend limits. * **Sort order** is a number that controls the order in which a seat is automatically chosen for a newly provisioned user (lowest number is tried first). If two tiers share the same sort order they are ordered consistently, but it is clearer to give each tier a distinct value. An organization may create up to 50 self-managed tiers. <Warning> The **New seat tier** button only appears if your tenant has allowed organizations to manage their own seat tiers. This permission is controlled by the **Let organizations manage their own seat tiers** setting on the tenant's Config page. If you don't see the button, ask a tenant administrator. </Warning> ## Viewing and editing a tier A tier's detail page shows its current values along with an **Allowed models** section that groups the permitted models by family. <Note> The **Edit** form and **Delete** button only appear on self-managed tiers. For an Anthropic-managed tier the page is read-only. </Note> For a self-managed tier the **Edit** form lets you update any of the fields above. Changes take effect immediately for every user on the tier: if you lower the spend limit, a user who is already over the new limit will be blocked on their next request until their window rolls forward, and if you remove a model from the allowlist it becomes unavailable to every user on the tier straight away. ## Deleting a tier The **Delete** button removes a self-managed tier entirely. Deletion is permanent and cannot be undone from this portal. You can only delete a tier that nothing references. If any users are still assigned to it, any API keys are bound to it, or any group mapping on the [Group mappings](/docs/government/org-admin/provisioning) page points at it, the delete is refused with a message telling you so. Reassign or remove those references first, then delete the tier. ## Things to know * Changing a tier's **Sort order** affects where newly provisioned users land, but it does not move anyone who already has a seat. * The spend limits are per user, not per tier. Ten users on a tier with a \$20 seven-day limit can together spend up to \$200 from the billing account over seven days. * Moving a user between tiers does not reset their usage counters. A user who has spent \$15 in the current 5-hour window carries that spend with them, and it is measured against the new tier's limit on their next request.
government/org-admin/seats First recorded · 49 lines, first recorded
# Seats ## What you see ## How seats are assigned automatically ## What you can do here ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Seats > Use this page to check your organization's seat counts at a glance before assigning or reclaiming seats on the Users page. > **Who this is for:** Organization owners who need to see how many seats of each tier are available and how many are in use. Use this page to check your organization's seat counts at a glance before assigning or reclaiming seats on the Users page. The **Seats** page shows how many seats your organization has for each seat tier and how many of them are currently assigned to users. It is the default landing page when you open the organization admin portal. A **seat tier** is a named level of access that defines which Claude models a person can use and how much they can use them over a rolling time window. Every user in your organization occupies exactly one seat, and that seat belongs to a tier (or the user is **Unassigned**, in which case they have no model access at all). ## What you see Seats are grouped into two sections based on who controls the tier. <Note> Each section below only appears when your organization has at least one tier of that kind. If you have neither, the page shows a message explaining that seats are distributed by your tenant administrators. </Note> **Anthropic-managed tiers** are defined by Anthropic and allocated to your organization from your tenant's seat pool. For each one the table shows the **Assigned** count, which is how many of your users are on that tier, alongside the **Limit**, which is the number of seats your organization has been allocated. You cannot assign more users to a tier than its limit allows. **Self-managed tiers** are tiers that your organization created itself on the [Tiers](/docs/government/org-admin/seat-tiers) page. For each one the table shows the **Assigned** count and, if a seat limit has been allocated for that tier, the **Limit**. These tiers draw from the billing account your organization spends from, so the effective constraint is usually the account's balance and any spend cap set on your organization rather than a seat count. ## How seats are assigned automatically When a new user is created in your organization, whether they arrive through single sign-on or through directory provisioning, Claude for Government tries to place them on a seat tier automatically so they can start working right away. If the user arrives through directory provisioning and belongs to a group you have mapped to a specific tier on the [Group mappings](/docs/government/org-admin/provisioning) page, that mapping takes precedence and the user is placed on the mapped tier if a seat is available. Otherwise the system walks through all of your tiers, both Anthropic-managed and self-managed, in sort order (lowest first) and places the user on the first tier that has a free seat. Self-managed tiers may or may not have a seat limit, depending on how they were allocated. A user is left **Unassigned** only when every tier that has a seat allocation is full. An unassigned user has no model access until an owner assigns them a seat manually on the [Users](/docs/government/org-admin/users) page or until more seats become available. <Tip> If you see an Anthropic-managed tier whose **Assigned** count equals its **Limit**, new users cannot land on it automatically. Either increase the allocation on the [Billing](/docs/government/org-admin/billing) page, move existing users to a different tier to free seats, or ask a tenant administrator to add seats. </Tip> ## What you can do here This page is read-only. To move a user onto a different tier, use the [Users](/docs/government/org-admin/users) page. To create or edit self-managed tiers, use the [Tiers](/docs/government/org-admin/seat-tiers) page. <Tip> To change how many seats of an Anthropic-managed tier your organization holds, go to the [Billing](/docs/government/org-admin/billing) page if it is available to you, or ask a tenant administrator. </Tip> ## Things to know * The **Assigned** count includes only active users. When a user is deactivated, their seat is released immediately and becomes available for someone else. * Changing a tier's limit on the Billing page does not move any users. If you lower a limit, you must first move enough users off the tier so the assigned count fits within the new limit, because the system will not let you reduce an allocation below the number of people currently seated on it. * The sort order that controls automatic assignment is managed on the [Tiers](/docs/government/org-admin/seat-tiers) page. Anthropic-managed tiers have a fixed order set by Anthropic, and self-managed tiers sort wherever their sort order number places them relative to the managed ones.
government/org-admin/setup-wizard First recorded · 64 lines, first recorded
# Setup wizard ## How the wizard is laid out ## Step 1: Welcome ## Step 2: Seat tiers ## Step 3: Seats and credits ## Step 4: Products ## Step 5: Finish ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Setup wizard > Walk through the steps that get your organization ready for users after a tenant administrator creates it. > **Who this is for:** Organization owners setting up a newly created organization, or returning to finish setup later. When a tenant administrator creates your organization and names you as its primary owner, a few things still need to be in place before your team can use Claude. The setup wizard walks you through those items in order, shows you which ones are already done, and tells you when something is waiting on someone else. Until setup is complete, a banner reading **A few steps remain before your team can use Claude** appears at the top of every page in the organization admin portal. Click **Resume setup** in that banner to open the wizard. The banner goes away once everything is ready, and it reappears on its own if a required item later becomes incomplete, for example if the billing account's balance runs out or a spend cap is set too low. You don't need to finish the wizard in one sitting. Use **Continue later** on any step to return to the admin portal, and come back through the banner whenever you are ready. ## How the wizard is laid out The wizard is titled **Set up your organization** and lists five steps down the left side. Each step shows a green check once its requirement is met, and you can click any step to jump straight to it. The checks reflect the live state of your organization rather than whether you have visited the step, so a step can already be checked when you arrive and can lose its check if something changes later. At the bottom of every step, **Continue later** exits to the admin portal and **Next** moves to the following step. ## Step 1: Welcome The first step confirms which organization and tenant you are setting up and what your role is. It also explains the division of responsibility: single sign-on and provisioning are configured by your tenant administrator rather than here, so your members will appear in this organization automatically once they sign in through the tenant's identity provider. There is nothing to fill in on this step. ## Step 2: Seat tiers A seat tier sets which Claude models a group of users can access and how much they can spend in a given period. This step lists every tier available to your organization. Anthropic-managed tiers are shown first and are labeled **Managed by Anthropic**, followed by any self-managed tiers your organization has defined. Each row shows the tier name and the number of allowed models, and self-managed tiers also show their five-hour and seven-day spend limits. Click any tier to open it. An Anthropic-managed tier opens as a read-only summary, because its limits are set by Anthropic. A self-managed tier opens as an editable form where you can change the name, spend limits, and allowed models without leaving the wizard. If your tenant lets organizations manage their own tiers, an **Add seat tier** button appears below the list so you can create one here. If that button is missing, your tenant has not turned on **Let organizations manage their own seat tiers**, and only Anthropic can create or change tiers for your organization. The step is checked once at least one of your tiers has at least one model allowed. See [Seat tiers](/docs/government/org-admin/seat-tiers) for more on creating and editing tiers. ## Step 3: Seats and credits This step shows whether your organization has the seats and credits it needs. Seats are allocated by your tenant administrator, and Anthropic adds credits to the billing account your organization draws from, so this step is a status display rather than a form. It is here so you can see at a glance whether you are still waiting on someone. Two status lines are shown: * **Add credits** is complete once the billing account your organization draws from has enough balance to serve at least one request. This is funded by Anthropic through your tenant administrator, so when it is incomplete the line shows **Waiting on your tenant admin**. Use **View billing** to open the [Billing](/docs/government/org-admin/billing) page and see the current balance and any spend caps set on your organization. * **Allocate seats** is complete once your organization has been allocated at least one seat. Use **View seats** to open the [Seats](/docs/government/org-admin/seats) page and see the counts. The step is checked only when both lines are complete. If either one is still waiting, contact a tenant administrator. ## Step 4: Products These are the Claude products your members sign in to, such as Claude Desktop, Claude Code, and Claude for Microsoft 365. This step shows an on/off switch for each one. Turning a product on allows your members to sign in to that application. This step is marked **Optional** in the step list, and you can leave every product off and still complete setup. A product that is not available appears with its switch disabled and a note to contact Anthropic if you would like it enabled. You can change these switches later from the [Config](/docs/government/org-admin/configuration) page. ## Step 5: Finish The final step shows the full readiness checklist for your organization so you can confirm everything is in place. Completed items are crossed out, and any item that is still outstanding shows the reason and who it is waiting on. If anything required is still incomplete, a warning banner appears at the top of this step and the primary button reads **Continue later**. Back in the admin portal the **Resume setup** banner will stay in place until the outstanding items are resolved. Once every required item is complete, the warning goes away, the primary button changes to **Go to the Admin Console**, and your users can sign in and start using Claude. ## Things to know * The wizard makes the same changes as the matching pages in the admin portal. Creating a seat tier here is exactly the same as creating one on the Tiers page. * Checks in the step list are derived from your organization's current state, so they update whenever that state changes, even outside the wizard. * Once setup is complete the subtitle changes to **Setup complete. Revisit any step to make changes**, and you can return at any time to review or adjust what you set.
government/org-admin/users First recorded · 84 lines, first recorded
# Users ## Finding users ## What's shown for each user ## Understanding roles ## Changing a user's role ## Assigning a seat tier ## Resetting a user's limits ## Deactivated users ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Users > Use this page to find a user, change their role or seat tier, check how close they are to their usage limits, and reset those limits when needed. > **Who this is for:** Organization owners who need to manage individual users' roles, seat tiers, and usage limits. Use this page to find a user, change their role or seat tier, check how close they are to their usage limits, and reset those limits when needed. The **Users** page lists everyone in your organization and lets you manage their access. ## Finding users Type into the search box to filter the list by name or email address. Use **Filters** to include deactivated accounts. ## What's shown for each user Each user appears as a card with their name, email address, and the following fields: | Field | Description | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Role** | The user's role in this organization. You can change it directly from the dropdown. | | **Seat tier** | Which seat tier the user currently occupies. You can change it directly from the dropdown. | | **Usage** | Two bars showing how much of the user's 5-hour and 7-day spend limits are currently used, with the exact percentage alongside each. Hover over the bars to see when each limit resets. Users who have no seat tier show a dash instead of the bars. | | **Last login** | The date and time the user last signed in. | The **…** menu on each card has the **Reset usage limits** action, which clears the user's current rate-limit windows. The menu appears only when your organization has at least one [self-managed seat tier](/docs/government/org-admin/seat-tiers). ## Understanding roles A **role** controls what a person can do in the admin portal. It has no effect on which Claude models they can use or how much they can use them; those are controlled by the seat tier. * A **User** can use the Claude products but has no admin access. * An **Owner** can access this organization admin portal and perform every action described in this guide except for granting or removing the Primary Owner role. * A **Primary Owner** has the same access as an Owner and is additionally protected so that an organization can never be left without one. Only a Primary Owner can promote another user to Primary Owner or demote an existing one. An organization must always have at least one active Primary Owner and may have up to three. Keeping more than one is recommended so that you are never locked out if a single Primary Owner is unavailable. ## Changing a user's role Use the **Role** dropdown on a user's row to move them between User, Owner, and Primary Owner. The change applies immediately, and a user who is promoted to Owner can open the admin portal as soon as they refresh. The following safeguards apply and the dropdown will refuse the change if any of them would be violated. * You cannot change your own role. To be promoted or demoted, ask another Owner or Primary Owner to make the change for you. * Only a Primary Owner can grant or remove the Primary Owner role. An Owner can freely move people between User and Owner, but any change that crosses into or out of Primary Owner must be made by a Primary Owner. * You cannot demote the organization's only active Primary Owner. Promote a second person to Primary Owner first, then demote the original. * You cannot promote a deactivated user to Primary Owner. Reactivate them first. * You cannot add a fourth Primary Owner. Demote one of the existing Primary Owners first if you need to make room. <Warning> If your organization uses directory provisioning with a group-to-role mapping, be aware that the next sync will re-apply the mapped role and may overwrite a manual change you make here. To make a permanent role change for a provisioned user, update their group membership in your identity provider instead. </Warning> ## Assigning a seat tier Use the **Seat tier** dropdown to move a user onto a different tier or back to **Unassigned**. An unassigned user has no model access at all, which is the appropriate state for someone who should keep their account but should not consume any Claude usage. The dropdown lists Anthropic-managed tiers first, each labeled *Managed by Anthropic*, followed by your self-managed tiers with a short summary of their model count and spend caps. If a tier has no seats remaining it appears marked **(at capacity)** and cannot be selected, unless the user is already on it. Changing a user's tier takes effect on their very next request. If you move someone to a tier with a different set of allowed models, any model that is no longer in their tier's allowlist becomes unavailable to them immediately. <Warning> If your organization uses directory provisioning with a group-to-tier mapping, the next sync will re-apply the mapped tier. For provisioned users, adjust their directory group membership rather than changing the tier here. </Warning> ## Resetting a user's limits Every seat tier sets a rolling **5-hour** and **7-day** spend limit for each user. When a user reaches either limit, further requests are refused until the window rolls forward. If a user on a self-managed tier has hit a limit and you want them to continue working immediately, use **Reset usage limits** in the **…** menu on their card. This clears both of their current windows so their next request is admitted. The reset does not refund or alter any credits that have already been consumed, and it does not change anything shown on the [Analytics](/docs/government/org-admin/analytics) page; it only clears the per-user counter that enforces the limit. <Warning> The reset button is disabled for users on Anthropic-managed tiers because those limits are set by Anthropic and are not yours to waive. Additionally, if a user moved off an Anthropic-managed tier within the last seven days, the reset button is temporarily unavailable for them and the tooltip tells you when it becomes available again. </Warning> ## Deactivated users Accounts are deactivated through your directory's SCIM provisioning rather than from this page. A deactivated user cannot sign in and does not occupy a seat. Deactivating a user releases their seat immediately, and reactivating them later will attempt to place them back on a seat using the same automatic assignment logic described on the [Seats](/docs/government/org-admin/seats) page. Deactivated users keep their role, but a deactivated Primary Owner does not count toward the "at least one" rule or the limit of three. You must always have at least one *active* Primary Owner. ## Things to know * Claude for Government has exactly three organization roles: **User**, **Owner**, and **Primary Owner**. There are no additional roles such as Billing or Developer. Tenant administrator access is a separate tenant-level membership managed on the [Admins](/docs/government/tenant-admin/admins) page, not an organization role.
government/overview First recorded · 90 lines, first recorded
# Claude for Government administrator guide ## How your deployment is organized ### Tenant ### Organizations ### Users ## Billing accounts ## The three views ### A note on tenant administrators ## How people get access ## Where to go next
The first capture of this source. The page was already there, and this is what it said.
# Claude for Government administrator guide > Set up and manage Claude for Government for your agency: how tenants, organizations, users, seats, and credits fit together. > **Who this guide is for:** Administrators who set up and manage Claude for Government for their agency. > **Find your section:** > > | If you are… | Start with | > | --------------------------- | ------------------------------------------------------------- | > | A tenant administrator | [Tenant administration](/docs/government/tenant-admin/overview) | > | An organization owner | [Organization administration](/docs/government/org-admin/overview) | > | Any user | [Your account](/docs/government/account/overview) | > | Anyone using Claude Desktop | [Use Claude Desktop](/docs/government/desktop/plugins) | This guide covers the portals used to manage Claude for Government: how access, seats, and usage are organized, and who is responsible for each part. If you just want to use Claude for Government, you don't need this guide. You can simply sign in and start a conversation, and come back here when you need to manage other people's access or understand why something is configured the way it is. ## How your deployment is organized Claude for Government is organized as a three-level hierarchy: **Tenant** → **Organizations** → **Users** ### Tenant The tenant is the top level, and it represents your agency's overall deployment. There is exactly one tenant per agency, and it holds the things that are shared across everyone: your connection to your identity provider for single sign-on, automatic user provisioning (where your directory system creates and updates accounts for you), the list of verified email domains, and the pool of credits and seats issued to you by Anthropic. The tenant is managed by a short list of **tenant administrators**. They create organizations, decide how seats are divided among them and what spend caps are set, and set policies that apply across the whole agency. ### Organizations An organization is a group of users who share a pool of seats and a set of policies, with its own spend caps. You might create one organization for each bureau, office, or program, or you might run the whole agency as a single organization. Most agencies start with a single organization. You would create more when you need any of the following: * Separate billing accounts so one group's usage never draws down another group's balance. * Separate usage reporting for each bureau or program. * Different product settings, seat tiers, or access rules for different parts of your agency. Each organization has its own owners, its own members, its own seat assignments, and its own configuration. The organizations all share the tenant's single sign-on connection, so you configure identity once and every organization uses it. ### Users A user is a single person. Every user belongs to exactly one organization, and two properties control what they can do: * A user's **role** determines what they can manage. Most people have the **User** role, which means they use Claude but don't administer anything. **Owners** and **Primary Owners** manage the organization: they manage members' roles and seats, and adjust organization-level settings. * A user's **seat tier** determines how much they can use Claude. A seat tier is a named bundle of usage limits (for example, how much Claude usage a person gets in a given period). A user with no seat assigned can sign in and see their account, but they can't send messages until an owner assigns them a seat. A user never belongs to more than one organization at a time. Moving a person between organizations keeps the same account; their role and seat assignment are managed separately in the new organization. ## Billing accounts A **billing account** is where your agency's credits and seats live. Anthropic sets up one or more billing accounts with your agency, and each one holds a prepaid credit balance (a dollar amount that is drawn down as people use Claude) and a pool of seats (a fixed number of seats in each tier). Every organization is linked to exactly one billing account, and usage by that organization draws directly from the account's balance. Several organizations can share the same billing account, or each organization can have its own. Tenant administrators divide each billing account's seat pool among the organizations it funds, and can set per-organization spend caps to control how much any one organization draws from a shared balance. ## The three views The portal has three views. Which ones you can reach depends on your role, and you switch between them using the link in the page footer. | View | Who has it | What it's for | | -------------------------------------------------------- | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [**Tenant**](/docs/government/tenant-admin/overview) | Tenant administrators | Creating organizations, configuring identity and access (single sign-on, provisioning, and routing rules), distributing seats, setting spend caps, and managing who else is a tenant administrator. | | [**Organization admin**](/docs/government/org-admin/overview) | Organization owners and tenant administrators | Managing users and seats, setting usage tiers, viewing analytics, and configuring organization-level settings. | | [**Account**](/docs/government/account/overview) | Everyone | Viewing your own profile, checking your usage limits, and managing where you're signed in. | When you sign in, you land on the most relevant view for you. Organization owners land on the organization admin view, and everyone else lands on their account view. This includes tenant administrators who are not also an organization owner; they start on their account view and can use the **Switch to admin view** link in the page footer, and from there switch to the tenant view. ### A note on tenant administrators Being a tenant administrator is separate from the role you hold inside an organization. Roles (User, Owner, and Primary Owner) control what you can do within a single organization, while tenant administrator status is granted by adding someone to the tenant's **Admins** list and controls access to the settings that sit above every organization. The two are independent: an organization owner is not automatically a tenant administrator, and a tenant administrator does not automatically hold any particular role inside any organization. > **For tenant administrators:** Because the tenant sits above every organization, you can also open the organization admin view and act on behalf of any organization in the tenant, even ones you don't belong to. When the tenant has more than one organization, an organization switcher appears at the top of the admin view so you can choose which one you're managing. ## How people get access Users reach your deployment in one of two ways, both of which are configured by a tenant administrator on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page: * **Single sign-on.** The user enters their agency email address and is redirected to your identity provider (for example, Microsoft Entra, Okta, or ADFS). When they return authenticated, Claude for Government evaluates your tenant's routing rules to decide which organization they belong in. * **Directory provisioning.** If your identity provider supports SCIM, which is a standard way for directory systems to keep accounts in sync with other applications, you can connect it so that your directory pushes users and group memberships to Claude for Government automatically. Routing rules then place each provisioned user in an organization based on their group membership. Routing rules are the only way in. A new person who does not match any rule cannot sign in until a rule is added that covers them. Routing rules are also re-evaluated each time an existing member signs in, so a rule change can move someone to a different organization the next time they sign in. ## Where to go next * Read [**Tenant administration**](/docs/government/tenant-admin/overview) if you're a tenant administrator managing the overall deployment. * Read [**Organization administration**](/docs/government/org-admin/overview) if you're an owner managing a single organization. * Read [**Your account**](/docs/government/account/overview) if you want to understand your own profile, usage, and sessions.
government/security/security-and-data-handling First recorded · 187 lines, first recorded
# Security and data handling ## Claude Desktop ### Sandbox and isolation ### Code in Claude Desktop ### Network egress, required domains, and proxies ### Approvals and Auto mode ### Connectors ### Telemetry and logging ### Data storage and retention ### Web search and web fetch ### Chat and Cowork differences ## More information
The first capture of this source. The page was already there, and this is what it said.
# Security and data handling
> Answers for agency security review: sandbox isolation, network egress and required domains, approvals, connector credentials, telemetry, and where data is stored.
> **Who this is for:** Security, compliance, and IT reviewers who are assessing Claude for Government for their agency, and administrators who need to explain the product's runtime behavior.
The answers on this page cover the Claude Desktop application in Claude for Government and address the security and data-handling questions that come up most often during agency security review. Claude Desktop offers three ways to work with Claude: **Chat** for simple conversations, **Cowork** for longer tasks with a local workspace folder, and **Code** for software development. Each answer states what is specific to Claude for Government (the FedRAMP High boundary, the defaults Anthropic applies for government tenants, and the relevant admin portal control), then links to the Claude Desktop documentation for the underlying mechanism. For assurance materials such as the security architecture overview, SOC 2 report, and penetration testing summary, request access through the [Anthropic Trust Center](https://trust.anthropic.com).
## Claude Desktop
The sections below cover the Claude Desktop application. For the admin portal and the Compliance API, see the [Organization administration](/docs/government/org-admin/overview) and [Tenant administration](/docs/government/tenant-admin/overview) sections.
### Sandbox and isolation
In Cowork, and for the file-analysis steps in Chat, the Claude Desktop application runs shell commands and model-written code inside a dedicated local virtual machine. In Claude for Government, this sandbox is always the execution path for the code and shell commands that Claude runs in Chat and Cowork. Code sessions run on the workstation itself rather than in the virtual machine, as described under [Code in Claude Desktop](#code-in-claude-desktop). For the detailed threat model and isolation design, request the security architecture overview through the [Anthropic Trust Center](https://trust.anthropic.com).
<AccordionGroup>
<Accordion title="What does the sandbox isolate, and what runs outside it?">
The sandbox virtual machine runs the shell commands and model-written code of Cowork sessions and of the file-analysis steps in Chat. The agent loop, built-in file tools, web fetch, and the connector client run in the Claude Desktop application on the user's device and are governed by separate controls: per-action approval prompts, administrator-set per-tool policies, and the network egress allowlist applied when each tool runs. Code sessions also run outside the virtual machine, as described under [Code in Claude Desktop](#code-in-claude-desktop). For a deeper description of the layered controls inside and outside the virtual machine, see the security architecture overview available through the [Anthropic Trust Center](https://trust.anthropic.com).
</Accordion>
<Accordion title="What can the sandbox reach on the host?">
The sandbox sees the workspace folders the user has attached to the session, its own scratch area, and read-only reference material bundled by the application (such as skill and plugin directories). It does not see the rest of the user's filesystem. File-read and file-write tools default to those same attached folders, and prompt the user before reading or writing outside them; see [Approvals and Auto mode](#approvals-and-auto-mode). Administrators can restrict which local folders users may attach with **Allowed workspace folders** on the [Config](/docs/government/config/settings#allowed-workspace-folders) page; the desktop client then refuses folders outside that list in both the workspace picker and Claude's file tools. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access) for how folder scoping is enforced.
</Accordion>
<Accordion title="How are attached folders made available to the sandbox?">
When a user attaches a local folder to a Cowork session, the entire folder is made available to that session's sandbox as a filesystem mount, so changes Claude makes are written directly to the folder on disk. A mapped network drive on Windows is an exception: Claude's host-side file tools can read, write, and search it, but shell commands in the sandbox cannot reach network shares, so a task that runs a script or build against those files must copy them to a local folder first (see [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access#network-drives-on-windows)). Files the user attaches individually to a conversation are copied or hard-linked into a per-conversation uploads directory and mounted read-only; where the filesystem hard-links, edits to the original file while the conversation is open can be visible to it. The allowed-folders setting is a policy control enforced by the desktop application. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access).
</Accordion>
<Accordion title="Which file types need the sandbox in Chat?">
Some attachment types, such as Excel and PowerPoint, need a conversion step that runs inside the sandbox. Enabling **Advanced file analysis in Chat** under **Product availability** on the [Config](/docs/government/config/settings#product-availability) page lets Claude run code against attachments in an offline sandbox, including that conversion. You do not need to make Cowork available to get this capability. See [Chat in Claude Desktop](/docs/third-party/claude-desktop/chat) for how Chat handles file attachments.
</Accordion>
</AccordionGroup>
### Code in Claude Desktop
Code sessions use Claude Code built into the desktop application and run on the user's workstation itself, not in the virtual machine. The shell commands Claude runs during a Code session execute on the workstation's own operating system under the user's own account.
On macOS, those shell commands run inside an operating-system-level sandbox that the application builds from your organization's **Allowed network hosts** and **Allowed workspace folders** settings on the [Config](/docs/government/config/settings#allowed-network-hosts) page. The sandbox is in place whenever either setting restricts access, which the default configuration does. A user can exempt specific commands from this sandbox in a Claude Code settings file, and an exempted command runs outside the sandbox under the permission mode the user selects for the session.
On Windows, there is no operating-system-level sandbox for Code sessions. Shell commands run directly on the device under the permission mode the user selects for the session and under your agency's own endpoint and network controls. The **Allowed network hosts** and **Allowed workspace folders** settings do not confine what those commands can reach or change.
On both operating systems, the application starts a Code session only in a folder that **Allowed workspace folders** permits when that setting is configured. Administrators can also require a prompt on every shell command, in every permission mode, with the **Require approval for each command** sub-setting on the **Shell commands** card of the [Config](/docs/government/config/settings#tool-and-connector-cards) page.
Code sessions in Claude for Government run on the local workstation only, and the environment options for Windows Subsystem for Linux (WSL) and SSH remote hosts are not available. Commands that belong to Claude Code's terminal interface, such as `/sandbox`, are not part of Code sessions in the desktop application. See [how your configuration reaches Code sessions](/docs/third-party/claude-desktop/code). If your agency also deploys Claude Code's own managed settings to the same devices, those settings take precedence over the macOS sandbox policy described above unless they opt in to merging, as that page explains.
### Network egress, required domains, and proxies
The desktop application and the sandbox honor the operating system's proxy settings, and a single allowlist controls outbound network access from Claude's tools. You manage the allowlist with the **Allowed network hosts** setting on the [Config](/docs/government/config/settings#allowed-network-hosts) page.
<AccordionGroup>
<Accordion title="What does the egress allowlist control?">
The allowlist governs outbound network access from the shell commands and package installs of Cowork sessions, which run in the sandbox virtual machine, from the sandboxed shell commands of Code sessions on macOS (see [Code in Claude Desktop](#code-in-claude-desktop)), and from the host-side web fetch tool. It does not govern web search (which routes through the Claude for Government service) or connector traffic (covered under [Connectors](#connectors) below). When the list is empty or unset, the only hosts reachable from those tools are the Claude for Government service address and, if you have set a **Telemetry endpoint (Claude Desktop)** on the [Config](/docs/government/config/settings#telemetry-endpoint-claude-desktop) page, that collector's host, which the application adds to the allowlist automatically. Package installs and page fetches to any other host fail. The list accepts exact hostnames, wildcard patterns such as `*.example.com`, or `*` to allow all outbound traffic. See [Web search and web fetch](/docs/third-party/claude-desktop/web-tools) for the full allowlist semantics.
</Accordion>
<Accordion title="Which domains does Claude Desktop need to reach?">
For configuration and model inference, the application reaches the Claude for Government service hostname provided to your agency during onboarding. Sign-in happens in the user's default browser, which must reach that same hostname, the Claude for Government sign-in service (a separate host that your Anthropic representative provides), and your agency's identity provider; see the network prerequisites in [Connect Claude Desktop to Claude for Government](/docs/government/deploy-desktop/configure#before-you-begin). Anthropic-bound telemetry endpoints are not contacted in Claude for Government. Allow `downloads.claude.ai` for the sandbox virtual machine image and the Claude Code command-line tool, which are fetched at session start (not required if your agency uses the offline installer variant that bundles both), and `www.claudeusercontent.com` for the artifact preview frame. For automatic application updates, the required hosts depend on how your agency distributes the client; see the network-requirements table in [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) and confirm the update hosts for your deployment before finalizing your allowlist.
</Accordion>
<Accordion title="Does Claude for Government depend on claude.ai or anthropic.com?">
The core product does not. Configuration and model inference go through the dedicated Claude for Government service hostname, and sign-in goes through that hostname, the separate Claude for Government sign-in service, and your agency's identity provider, none of which are under either domain. Blocking `*.claude.ai` and `*.anthropic.com` leaves sign-in and inference working. Blocking `*.claude.ai` also blocks `downloads.claude.ai`, which prevents Cowork and Code sessions from starting and Advanced file analysis in Chat from running, unless the offline installer variant was used.
</Accordion>
<Accordion title="Does blocking claude.ai affect Claude for Government?">
Blocking `claude.ai` does not affect sign-in or inference; neither uses any host under that domain. A personal Claude account cannot sign in to Claude for Government, and a Claude for Government account cannot sign in to `claude.ai`, so there is no shared sign-in surface to restrict. If you allow automatic application updates, keep the update hosts listed in the network-requirements table reachable.
</Accordion>
<Accordion title="Is web fetch always checked against the allowlist?">
Yes. Every web page fetch is checked against your egress allowlist before the request is made, and redirects are re-checked against the allowlist on each hop. See [Web search and web fetch](/docs/third-party/claude-desktop/web-tools). Do not rely on this allowlist alone to restrict access to your private network; see **Allowed network hosts** on the [Config](/docs/government/config/settings#allowed-network-hosts) page.
</Accordion>
<Accordion title="Can all traffic route through a single proxy?">
Yes. Both the desktop application and the sandbox honor the operating system's proxy settings, including PAC URLs, and route all outbound traffic through your proxy. TLS inspection at your proxy should work; validate this in your environment before rollout. See [Proxy support](/docs/third-party/claude-desktop/telemetry#proxy-support) for details. Web search requests pass through your proxy to the Claude for Government service, and the service's onward call to the search provider originates from inside the FedRAMP High boundary.
</Accordion>
</AccordionGroup>
### Approvals and Auto mode
By default, Claude for Government prompts the user for file writes outside the attached workspace, connector actions, and each web search. In Cowork, shell commands run without a prompt because they run inside the sandbox virtual machine. Web page fetches run without a prompt in both Chat and Cowork and are checked against the egress allowlist described above. Administrators can require a prompt on every shell command or fetch with the **Require approval** sub-settings on the [Config](/docs/government/config/settings#tool-and-connector-cards) page. In Chat, every shell command prompts regardless. The reduced-approval option in Claude for Government is Auto mode, which is off by default and can be enabled through device managed configuration (it is not a setting on the Config page). Cowork does not offer a Bypass Permissions mode.
<AccordionGroup>
<Accordion title="Can write and send actions be gated behind approval?">
Yes. Administrators can set each built-in and connector tool to **ask** (approval required on every call), **allow** (pre-approved), or **blocked** (removed entirely), and users cannot override those settings. For the Microsoft 365 connector, certain irreversible write tools (sending or forwarding mail, and creating or updating calendar events) are fixed to **ask** and cannot be changed to **allow**. See the [Configuration reference](/docs/third-party/claude-desktop/configuration) for the per-tool policy options.
</Accordion>
<Accordion title="Can Auto mode be disabled when a sensitive connector is attached?">
Auto mode can be disabled by policy, but not conditionally based on which connector is attached. The Auto mode policy, delivered through device managed configuration, controls whether users see Auto mode in the Cowork and Code permission selectors, and it defaults to off in Claude for Government. You can combine that policy with per-tool policies (setting a sensitive connector's tools to **ask** or **blocked**) to achieve a similar effect.
</Accordion>
<Accordion title="Can individual shell commands be allowlisted enterprise-wide?">
No. Policy controls whole tools (shell, file read, web fetch, and so on) but not individual commands within a tool. In Chat, each shell command prompts the user with no standing approval. For analyses that take many steps, Cowork runs shell commands in the sandbox without prompting; you make Cowork available to members under **Product availability** on the [Config](/docs/government/config/settings#product-availability) page.
</Accordion>
<Accordion title="Can users suppress approval prompts with an Always allow choice?">
For most tools, users who see an approval prompt can choose **Always allow**, which suppresses that prompt for them going forward. Administrators can remove that option by setting the tool's policy to **ask**, which forces a fresh prompt on every call. The create-artifact prompt and code execution in Chat are exceptions: neither offers a standing approval. See the [Configuration reference](/docs/third-party/claude-desktop/configuration) for the full tool-policy options.
</Accordion>
<Accordion title="Why does Chat prompt on every analysis step?">
Chat is designed for user-guided interaction, so each analysis step (including opening an attachment in the sandbox) runs as a shell command with a one-time Allow or Deny prompt and no standing approval. For analyses that take many steps, Cowork runs the same work in the same sandbox without a prompt on each shell command. See [Chat in Claude Desktop](/docs/third-party/claude-desktop/chat).
</Accordion>
</AccordionGroup>
### Connectors
In Claude for Government, connectors fall into three main categories: built-in tools (Web search, Web fetch, and Shell commands), the built-in Microsoft 365 connector, and connectors an administrator adds on the Connectors card of the [Config](/docs/government/config/settings#tool-and-connector-cards) page.
<AccordionGroup>
<Accordion title="Where do connectors run, and where are tokens stored?">
Connectors are called from the desktop application, outside the sandbox. The built-in Microsoft 365 connector and administrator-added connectors call their endpoints directly from the user's device, through the system proxy where one is configured. OAuth tokens for both are stored encrypted on each user's device using operating system encryption (macOS Keychain on Mac, DPAPI on Windows). For administrator-added connectors, the bearer header entered on the Config page is delivered to each user's desktop. A plugin package can include skills, slash commands, sub-agents, and hooks, which run on the member's machine. The Config page asks the administrator to confirm trust before adding a plugin that declares components that can run code on the member's machine, for example hooks or an MCP server. A plugin's declared local MCP server is disabled in Claude for Government and does not run, and a connector declared inside a plugin package does not become available as an organization connector unless the plugin was delivered through device management. End users cannot add their own connectors. End users can upload their own plugin files in Claude Desktop; a user-uploaded plugin's skills, commands, sub-agents, and hooks run on that user's machine, and any connector it declares does not become available as an organization connector. Administrators distribute plugins to members on the Config page with a per-plugin choice of automatic installation or member opt-in. See [Connectors](/docs/government/connectors/overview) and the Plugins card under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards).
</Accordion>
<Accordion title="Do connectors follow the sandbox egress allowlist?">
No. The built-in Microsoft 365 connector calls Microsoft Graph directly from the user's device; see the [Microsoft 365 connector](/docs/government/connectors/microsoft-365) page. Administrator-added connectors connect directly from the user's device to the address configured for that connector. Both pass through the system proxy where one is configured. Web search is a built-in tool rather than a connector and routes through the Claude for Government service; see [Web search and web fetch](#web-search-and-web-fetch) below.
</Accordion>
<Accordion title="Can artifacts be blocked from calling connectors?">
Artifacts honor the same per-tool approval policy as Claude's direct connector calls: tools set to **blocked** are refused and tools set to **ask** require user confirmation. There is no single switch to disable artifact-to-connector calls while keeping connectors available to Claude directly.
</Accordion>
</AccordionGroup>
### Telemetry and logging
In Claude for Government, Anthropic-bound error and usage telemetry is always disabled. The OpenTelemetry export to your own collector is a separate setting and sends data only to the endpoint you configure.
<AccordionGroup>
<Accordion title="Is there an inline DLP or inspection point?">
No. Claude for Government does not include an inline content-inspection or DLP gate. The available inspection points are your own network proxy, which sees all endpoint traffic, and the desktop's OpenTelemetry export, which sends tool-call metadata (tool name, connector, outcome, duration, and approval status) to your collector for after-the-fact review. You set the OpenTelemetry endpoint with **Telemetry endpoint (Claude Desktop)** on the [Config](/docs/government/config/settings#telemetry-endpoint-claude-desktop) page. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry).
</Accordion>
<Accordion title="What is logged for connector actions and outbound requests?">
Chat, Cowork, and Code sessions write a local audit log to the user's disk recording tool invocations, permission decisions, and file operations; that log never leaves the device. The desktop can also export OpenTelemetry events to a collector you specify: tool name, connector, outcome, duration, and approval status are sent. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) for what the export can include. Server-side, the [Compliance API](/docs/government/org-admin/compliance-api) records identity and configuration events but never tool calls or conversation content.
</Accordion>
</AccordionGroup>
### Data storage and retention
In Claude for Government, conversation content stays on the user's device. Model requests are proxied through the Claude for Government service to the model endpoint inside the FedRAMP High boundary, and the service records only per-request metadata, not content.
<AccordionGroup>
<Accordion title="Can Anthropic view conversations?">
No. Chat transcripts are stored only on the user's workstation, and the Claude for Government service does not log request or response bodies. Inference requests pass through the service to the model endpoint but are not retained. See [User identity and local data](/docs/third-party/claude-desktop/data-storage) for where conversation content is stored.
</Accordion>
<Accordion title="Where on the device is conversation content stored?">
Conversation content lives under the owner-only application data directory (`%LOCALAPPDATA%\Claude-3p` on Windows, `~/Library/Application Support/Claude-3p` on macOS). User-visible outputs such as artifacts are written separately to the user files directory (default `~/Claude`). See [User identity and local data](/docs/third-party/claude-desktop/data-storage) for the full list of what each location holds.
</Accordion>
<Accordion title="Where are files added to a project stored, and are they indexed?">
A project in Claude for Government is stored in the application data directory on the user's own device, together with any instructions, links, and folder references the user adds to it. Files added to a project stay on the user's local disk; there is no service-side project store, and files are not vectorized or indexed. Claude reads them directly from disk on demand with its file tools. Content Claude reads from those files is handled like the rest of the conversation: inference requests pass through the Claude for Government service to the model endpoint but are not retained. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access).
</Accordion>
<Accordion title="Can the local data location be changed for backup or sync?">
No. The location is fixed to the per-user application data directory, and the application avoids the roaming profile because the sandbox image cache can be large. Chat history exists only on the device that created it, so back up the application data directory through your endpoint management tools if you need to preserve it. Artifacts and project folders are separate locations on the same device; see the question above. See [User identity and local data](/docs/third-party/claude-desktop/data-storage) for the folder layout.
</Accordion>
</AccordionGroup>
### Web search and web fetch
<AccordionGroup>
<Accordion title="How does web search reach the internet?">
Web search is operated by Anthropic inside the Claude for Government FedRAMP High boundary, and the search provider's API is the one case where traffic egresses that boundary. Before search is enabled, an administrator must acknowledge a disclosure covering this data flow when enabling the **Web search** card on the [Config](/docs/government/config/settings#tool-and-connector-cards) page. By default, users approve each query before it is sent, and Claude transforms it into a generic, de-identified search request and shows the user the exact text. Anthropic has a zero-data-retention agreement with the search provider. The [Web search and web fetch](/docs/third-party/claude-desktop/web-tools) page covers how web search is configured in other Claude Desktop deployments; the Claude for Government search path described here is specific to this deployment.
</Accordion>
<Accordion title="How do administrators enable web search?">
Web search is built in and does not require obtaining a separate connector. An organization owner opens the [Config](/docs/government/config/settings#tool-and-connector-cards) page, finds the **Web search** card, turns it on, and acknowledges the data-flow notice. The **Require approval for each search** setting is on by default.
</Accordion>
<Accordion title="Why does Chat's web fetch fail with an empty allowlist?">
Chat includes a web fetch tool, and every fetch is checked against the same egress allowlist that governs Cowork. With the allowlist empty or unset, a fetch to anything other than the Claude for Government service address (or, when configured, the **Telemetry endpoint (Claude Desktop)** collector host) returns an error. Add hosts to **Allowed network hosts** on the [Config](/docs/government/config/settings#allowed-network-hosts) page to let Chat fetch from them, or turn off the **Web fetch** card on the same page if you prefer Claude not to see the tool. See [Web search and web fetch](/docs/third-party/claude-desktop/web-tools).
</Accordion>
</AccordionGroup>
### Chat and Cowork differences
<AccordionGroup>
<Accordion title="Are projects available in both Chat and Cowork?">
Yes. Chat and Cowork share one list of projects, and users can start a Chat conversation or a Cowork session inside a project. A project in Claude for Government is stored only on the user's device. There is no service-side project store, and projects are not shared between users. A Chat conversation inside a project does not gain access to the project's folders, while Cowork sessions in a project use the same execution model as the rest of Cowork. Chat conversations in a project can read the project's [memory](/docs/third-party/claude-desktop/data-storage#memory) but cannot add to or change it. See [Data storage and retention](#data-storage-and-retention) for where project contents are stored.
</Accordion>
<Accordion title="Are artifacts available in Chat?">
Yes. Artifacts are available in both Chat and Cowork. Claude creates an artifact by calling a tool when the output suits an interactive view, and the artifact opens in a side panel next to the conversation. Artifacts do not depend on the sandbox, so they remain available in Chat even when **Advanced file analysis** is disabled.
</Accordion>
</AccordionGroup>
## More information
Assurance materials including the security architecture overview, SOC 2 Type 2 report, and penetration testing summary are available on request through the [Anthropic Trust Center](https://trust.anthropic.com).
government/tenant-admin/admins First recorded · 40 lines, first recorded
# Admins ## How tenant admin access works ## The admin list ## Adding a tenant administrator ## Removing a tenant administrator ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Admins > Use this page to view, add, and remove the people who can use the tenant admin portal. > **Who this is for:** Tenant administrators who manage who else has tenant-level administrative access. Use this page to view, add, and remove the people who can use the tenant admin portal. ## How tenant admin access works **Tenant administrator** is a specific membership list, separate from any role someone holds inside an organization. Being on this list grants access to every page in the tenant admin portal: creating organizations, configuring sign-in and provisioning, writing routing rules, distributing seats, setting spend caps, and setting tenant-wide configuration. It also lets the person open any organization's admin view and act on that organization's behalf. Tenant admin membership is not tied to any organization role. Adding someone here doesn't make them an owner of any organization, and making someone an organization owner doesn't put them on this list. > **For organization owners:** Being an organization's owner does not make you a tenant administrator, and being a tenant administrator doesn't grant any particular role inside an organization. The two are independent. ## The admin list The table lists every current tenant administrator with their email and which organization they belong to. A tenant administrator doesn't have to belong to any organization; those rows show *No organization*. This is common for the initial administrator Anthropic sets up during onboarding. ## Adding a tenant administrator In the **Add admin** section, start typing a name or email address and select the person from the results, then click **Grant admin**. The change takes effect immediately; the next time that person loads the portal, the tenant admin view is available to them. The search covers organization owners across every organization in your tenant, plus any existing tenant staff who don't belong to an organization. The person must already exist in your tenant, meaning they have signed in at least once or have been provisioned through your directory. ## Removing a tenant administrator Click **Remove** next to a name to revoke their tenant admin access. The change takes effect immediately. The person keeps their account and whatever organization role they have; only the ability to open this portal is removed. <Warning> You can't remove the last remaining tenant administrator. The button is disabled when only one is left. This protects your tenant from losing all administrative access. </Warning> ## Things to know * Adding tenant administrators is self-service and does not require any action from Anthropic. See [Adding a tenant administrator](#adding-a-tenant-administrator) above. * You cannot remove yourself from the list. If your own access needs to be removed, ask another tenant administrator to do it. * There is no upper limit on the number of tenant administrators, but because the access is broad, keep the list as short as your operational needs allow. * If the only person on this list leaves your agency or loses account access, contact Anthropic to have a new tenant administrator appointed.
government/tenant-admin/configuration First recorded · 21 lines, first recorded
# Config at the tenant level ## What is specific to the tenant level
The first capture of this source. The page was already there, and this is what it said.
# Config at the tenant level > Set tenant-wide defaults for product behavior, lock settings so organizations can't change them, and preview how a change affects each organization. > **Who this is for:** Tenant administrators who set and enforce product settings across every organization in their tenant. Use this page to set tenant-wide defaults for product behavior, lock settings so organizations can't change them, and preview how a change would affect each organization. The Config page works the same way at the tenant and organization levels, with the same list of settings. See [How Config works](/docs/government/config/overview) for the levels model, locks, groups, comparing across levels, and looking up one person's settings, and [Available settings](/docs/government/config/settings) for what each setting does. This page covers only what is specific to the tenant level. ## What is specific to the tenant level **Previewing impact across organizations.** After you change a setting here, a **Preview impact** button appears next to **Save changes**. It shows every organization with its current effective value and what it would become after your change. See [Previewing impact](/docs/government/config/overview#previewing-impact). This button does not appear at the organization level. **Two settings that only tenant administrators can change.** [Let organizations manage their own seat tiers](/docs/government/config/settings#let-organizations-manage-their-own-seat-tiers) and [Compliance API](/docs/government/config/settings#compliance-api) are always read-only for organization owners, regardless of whether they are locked. **Group priority order.** You set the priority order between directory groups on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page by dragging the groups into the order you want. Organization owners see this order for reference but cannot change it. See [When someone belongs to more than one group](/docs/government/config/overview#when-someone-belongs-to-more-than-one-group). **Managing any organization's config.** As a tenant administrator you can open any organization's Config page and act on that organization's behalf, using the scope bar above the settings list. Organization owners see only their own organization. **Resetting a tenant setting** removes only the tenant's value. Organization values are unaffected and remain in effect once your value is gone.
government/tenant-admin/credits First recorded · 56 lines, first recorded
# Billing ## How billing works ## What the page shows ## Setting a spend cap ## When you can't set caps ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Billing > Use this page to see each billing account's balance and to set per-organization spend caps. > **Who this is for:** Tenant administrators who monitor billing-account balances and set spend caps on organizations. Use this page to see each billing account's balance and to set spend caps that limit how much any one organization can draw from it. <Note> The **Billing** tab appears in the navigation only when credits apply to your tenant, which means at least one organization can use credits or there is a credit balance on any billing account in your tenant. If neither is true, the tab is hidden and **Seats** appears on its own in the navigation. This page is still reachable from a direct link and shows a short explanation. The tab appears automatically once Anthropic configures billing for your tenant. </Note> ## How billing works A **billing account** is a funding pool that Anthropic sets up for your tenant. It holds a dollar balance of credit, and Anthropic adds credit to the account as part of your agency's procurement. Each organization is linked to exactly one billing account, and several organizations may share the same one. Usage by any organization draws directly from its billing account's balance. Because organizations share the balance, one organization's usage can reduce what is available to the others on the same account. To control that, you can set a **spend cap** on each organization. A spend cap limits how much one organization can spend from its billing account in a rolling window. It is a policy limit, not a transfer of money. Nothing moves when you set or change a cap, and the billing account's balance is always the ultimate limit regardless of what caps are set. Spend caps apply to usage on self-managed seat tiers. Usage on Anthropic-managed seat tiers is covered by the seat price rather than drawn from the account balance, so it is not counted against a cap. ## What the page shows <Note> Billing account cards only appear once Anthropic has set up at least one billing account for your tenant. Until then, the page shows a message asking you to contact Anthropic. </Note> Each billing account appears as its own card showing: * The **available balance**, which is the credit remaining in the account. Every organization on the account draws from this one balance. * How many organizations the account funds. * A **Spend caps** section listing each organization on the account with its current caps. If every organization on an account uses only Anthropic-managed seat tiers, a banner explains that the balance and spend caps do not limit usage right now. They take effect once an organization starts using self-managed tiers. ## Setting a spend cap In a billing account's **Spend caps** section, click an organization's row to expand the editor, enter a dollar amount for the **5-hour cap**, the **7-day cap**, or both, and click **Save caps**. * Leave a cap blank for no limit on that window. The billing account's balance is still the ultimate limit. * Both caps apply at the same time. An organization's usage is refused once either cap is reached, until that window rolls forward. * Amounts can be from \$0 to \$1,000,000,000, and you can use cents. * A cap of \$0 pauses the organization. Requests billed to the account are refused until you raise or clear the cap. Changes take effect immediately. Raising or clearing a cap admits the organization's next request. Lowering a cap below the organization's current window usage refuses its next request until the window rolls forward. ## When you can't set caps If an account is **deactivated**, its organizations' requests are refused and you cannot edit caps. Contact Anthropic to move the organizations to an active account. ## Things to know * Spend caps are set by tenant administrators. Organization owners can see their own caps on their organization's Billing page, but cannot change them. * Adding credit to a billing account is arranged with Anthropic as part of your agency's procurement. There is no form on this page to add credit. * An organization that hits a spend cap does not affect other organizations on the same account. An account running out of balance affects every organization on it.
government/tenant-admin/identity-and-access First recorded · 200 lines, first recorded
# Identity and access ## Status banners ## Domains ## Single sign-on ### Registering in your identity provider ### Connecting with OIDC ### Connecting with SAML ### Attribute mapping (advanced) ## SCIM provisioning ### SCIM secret token ## Directory groups ## Routing rules ### When rules move people ### Sign-in rules ### Provisioning rules (SCIM) ### Adding and removing rules ## Preview routing ## Unplaced users ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Identity and access > Connect single sign-on, manage SCIM provisioning, and write the routing rules that place users into organizations. > **Who this is for:** Tenant administrators who connect the deployment to their agency's identity provider and control which organization each person belongs to. Use this page to connect single sign-on, manage the SCIM provisioning token, write the routing rules that place users into organizations, preview how a specific person would be routed, and review people who haven't been placed yet. Identity and access are configured once here and shared by every organization in your tenant. The page is laid out top to bottom in the order you'll usually work through it: connect single sign-on, optionally connect directory provisioning, then write routing rules, then use the preview and the waiting lists to confirm everyone is being placed where you expect. ## Status banners Three banners can appear at the top of the page: * **Still being provisioned** appears while Anthropic is finishing initial setup of your tenant. Sign-in is disabled for everyone until provisioning completes, but you can configure everything on this page in the meantime so that it takes effect as soon as the tenant goes live. * **No routing rules configured** appears when no routing rules exist. Until at least one rule is added, no new person can sign in. * **Last SCIM push** shows when your directory most recently pushed an update. It appears only after your directory has completed at least one sync. ## Domains Claude for Government routes users to your tenant by the domain of their email address, so at least one domain must be registered before anyone can sign in. The **Domains** section lists every domain registered to your tenant, along with whether it is verified and whether it was registered by Anthropic or by you. Domains that Anthropic registered on your behalf during onboarding are already verified. To add one yourself, enter the domain in the **Claim a domain** field and click **Claim**. You will be shown a DNS TXT record to publish on that domain; once the record is live, click **Verify now** and the domain becomes active. Until at least one domain is verified, the Single sign-on section's Connect button and the SCIM provisioning section's **Generate token** button are both unavailable, and each section shows a banner explaining why. Existing tenant administrators can still sign in by email link during this time. ## Single sign-on Every user signs in through your agency's identity provider (for example, Microsoft Entra, Okta, or ADFS). You register Claude for Government as an application in your identity provider, then enter your provider's connection details here. Once connected, every sign-in is redirected to your provider. <Note> You need at least one verified domain before you can connect single sign-on. Until then, the Connect button is unavailable and a banner prompts you to verify a domain first. If single sign-on was already connected before your last domain was removed, the existing connection stays editable. </Note> The card header shows a **Connected (OIDC)**, **Connected (SAML)**, or **Not configured** badge so you can see the current state at a glance. Only one protocol is active at a time. Use the **OIDC** and **SAML** tabs to switch between the two forms; saving one replaces the other. ### Registering in your identity provider Copy the following values from the card into your identity provider when you create the application there: * **Redirect URI / ACS URL** is where your identity provider sends the user back after authentication. The same value is used whether you choose OIDC (where it's called the Redirect URI) or SAML (where it's called the Assertion Consumer Service URL). * **SP Entity ID / Audience** is the unique identifier your identity provider uses to recognize this application. Providers label this field differently; it may appear as Identifier, Entity ID, or Audience URI. For SAML, a **More values your IdP may ask for** expander below these fields lists the remaining details some providers request: the Name ID format, whether assertions and requests are signed, and the default RelayState. After you save a SAML connection, an **SP metadata URL** appears alongside these values. Most identity providers can import this address to fill in the other values automatically if you need to reconfigure. ### Connecting with OIDC If your identity provider supports OpenID Connect, fill in the OIDC section: * **Client ID** is the application ID your identity provider assigned when you registered the app. * **Client secret** is the secret your identity provider generated for that application. It is stored securely and never shown again after you save. * **Authorization URL**, **Token URL**, **Issuer**, and **JWKS URL** are your identity provider's OIDC endpoints. Most providers show these on the application's overview or endpoints page, and some providers publish all four together on an OpenID Connect discovery document. ### Connecting with SAML If your identity provider uses SAML, fill in the SAML section instead: * **IdP metadata XML** is the federation metadata document for your identity provider. Download the XML file from your provider (in Microsoft Entra it's under Single sign-on → SAML → Federation Metadata XML; in ADFS it's under Endpoints) and paste the full document into the field. The metadata is read from what you paste; it is never fetched from a URL. Once SAML is active, the card shows the Entity ID and SSO URL extracted from your metadata so you can confirm the connection is pointing where you expect. ### Attribute mapping (advanced) Both the OIDC and SAML sections include an **Attribute mapping** panel that's collapsed by default. Open it if the email, first-name, or last-name fields arrive under different names than the defaults. Each field offers a short list of common names for your chosen protocol; you can pick one or type your own. For OIDC the defaults are the standard `email`, `given_name`, and `family_name` claims; for SAML the defaults cover the common attribute names most providers use. Leave a field blank to use its default. <Warning> Saving a new single sign-on configuration takes effect immediately and applies to everyone, including you. Before saving, confirm you can authenticate with the new provider in another browser window so that you don't lock yourself out. </Warning> ## SCIM provisioning SCIM is the standard protocol identity providers use to push users and groups to a connected service automatically, so that accounts are created, updated, and deactivated in step with your agency's directory. Connecting SCIM is optional; without it, users are created the first time they sign in. <Note> You need at least one verified domain before you can generate a SCIM token. Until then, **Generate token** is unavailable and a banner prompts you to verify a domain first. </Note> * **SCIM base URL** is the address your identity provider pushes user and group updates to. A copy button sits next to it. You'll paste this value into your identity provider's provisioning settings (Okta and Microsoft Entra call this the *Tenant URL*). ### SCIM secret token Your identity provider authenticates to the SCIM address with a bearer token that you generate here. Click **Generate token** to create one, then paste the value into your identity provider's *Secret Token* (or equivalent) field. <Warning> The full token value is shown **only once**, immediately after you create it. Copy it into your identity provider before clicking Done. If you lose the value, generate a new token and revoke the old one. </Warning> The token table lists every token with its created date, a short hint (the last few characters) so you can tell them apart, and a status of **Active** or **Revoked**. You can keep more than one token active at a time, which lets you rotate without an outage: generate a new token, update your identity provider to use it, confirm a sync succeeds, and then revoke the old one. Revoking a token takes effect immediately. Once a token is active and your directory completes its first sync, the provisioning-rule list and the **Synced, not routed** waiting list become available further down the page. ## Directory groups Once your identity provider has pushed groups over SCIM, they appear here with their member counts. Drag the groups into the order you want; this priority is used for group-level configuration on the [Config](/docs/government/config/overview#group-specific-settings) page. ## Routing rules A **routing rule** is an instruction of the form "if a person matches this condition, place them in this organization." Routing rules are the **only** way a new person gets into your deployment; there is no default organization and no fallback. Before any rule runs, the sign-in flow first checks that the person's email domain is one of your tenant's **verified domains** (listed in the Domains section above). An address outside your verified domains never reaches your tenant at all, regardless of what rules you've written. There are two separate rule lists, because there are two ways a person can arrive: * **Sign-in rules** run each time a person signs in through single sign-on. They apply on every sign-in, not just the first one, so changing a sign-in rule can move an existing member to a different organization the next time that person signs in. * **Provisioning rules** run when your directory creates or updates someone through SCIM. They match on synced directory groups, and changes take effect at the next directory sync. ### When rules move people Because sign-in rules run every time, a rule change has these effects on people who already exist: * If a person now matches a rule that points to a different organization, they are moved on their next sign-in. Their active sessions and API keys are revoked as part of the move, so they land cleanly in the new organization. * If a person no longer matches any rule (for example, you removed the only rule that covered them), they keep their current organization and can still sign in. The no-match refusal applies only to people who have never been placed. * If a person's account is managed by your directory (that is, it was created or linked through SCIM), sign-in rules do **not** move them. Directory-managed accounts are moved only by provisioning rules, so that your directory remains the single source of truth for where they belong. Because the Claude desktop app stores conversations on each person's own device, a move does not affect desktop chat history. <Tip> When you add or edit a rule that would move people, a confirmation dialog shows how many existing members would be affected and a sample of their email addresses. Review that list before confirming. </Tip> > **For organization owners:** A member being moved out of your organization by a rule change loses their seat and role in your organization. Their account itself is kept, and they are reseated in the destination organization according to its available seats. ### Sign-in rules Each sign-in rule reads as a sentence, for example *"Anyone with email domain `example.gov` → place in OEO."* A rule matches on one of the following: * An **email domain** rule matches the domain of the user's email address exactly. You choose from your tenant's verified domains; you cannot type an arbitrary domain. Subdomains are not matched automatically, so `sub.example.gov` needs its own rule if you want it routed. * An **identity provider (IdP) group** rule matches a value in the group membership list that your identity provider includes in the sign-in token. You type the exact value your provider sends, and matching is exact and case-sensitive. Rules are evaluated from top to bottom, and the first match wins. When you have more than one rule, drag the handle next to a rule (or focus the handle and press the up or down arrow key) to reorder the list. Only one rule can exist for any given condition. If you pick a domain or group that already has a rule, a message below the form shows which organization it currently routes to and asks you to remove that rule first. Each rule shows a status line with diagnostics: * **Last matched** (or **Never matched**) tells you when the rule most recently placed or moved someone. * A **matches broadly** badge marks a domain rule that sits above one or more group rules. Because it matches everyone on that domain, group rules below it can never win for those users; move it lower if that's not what you intended. * A **target deactivated** badge means the rule points at an organization that has been deactivated. The rule is skipped during evaluation. * A **stale value** badge means the condition refers to something that no longer exists, such as a domain removed from your verified list. The rule is skipped during evaluation. ### Provisioning rules (SCIM) <Note> This section only appears when SCIM is connected (you have an active SCIM token or your directory has synced groups) or when provisioning rules already exist. </Note> Provisioning rules match on **directory groups** that your identity provider has synced, and decide which organization a user is placed in when your directory provisions or updates them. You choose groups from the synced list; a group that hasn't synced yet won't appear in the picker. Provisioning rules work the same way as sign-in rules: they're an ordered list, the first match wins, and only one rule can exist per group. Because your directory re-evaluates placement on each sync, reordering or removing provisioning rules can move already-placed users at the next sync. You'll be asked to confirm before reordering. ### Adding and removing rules To add a rule, choose the match type (for sign-in rules), pick or type the value, choose the target organization, and click **Add rule**. New rules are added at the bottom of the list; reorder after adding if you need a different priority. To remove a rule, click **Remove** next to it and confirm. Removing the last sign-in rule is called out specifically: no new person can sign in until another rule is added, and existing members keep their current organization until another rule covers them. ## Preview routing Enter an email address (and, optionally, a comma-separated list of IdP groups) to see exactly how that person would be routed, without changing anything. The preview runs the same evaluation that real sign-in and provisioning use, so what you see here is what will actually happen. The result shows one panel for sign-in and a separate panel for directory provisioning. <Note> The directory provisioning panel only appears when SCIM is connected for your tenant. </Note> Each panel shows whether the person would be placed (and in which organization) or refused, and it lists every rule in order with the outcome for each: **matched**, **no match**, or **target deactivated**. If the email's domain isn't one of your tenant's verified domains, the preview explains that sign-in would never reach this tenant at all, and no rules are evaluated. <Tip> Editing any rule clears the preview result automatically so you never read a verdict that's out of date. Re-run the preview after making changes. </Tip> ## Unplaced users The unplaced-users lists collect people who have arrived but aren't in an organization yet. There are two kinds of entry: * **Rejected sign-ins** are people from one of your verified domains who tried to sign in but matched no rule and were turned away. Each entry shows who tried, when they last tried, how many times, and which IdP groups their sign-in token carried. These records are kept so you can see who's trying and failing to get in. * **Synced, not routed** entries are people your directory has provisioned through SCIM who don't yet match any provisioning rule. They exist in the sync but have not been placed in an organization, so they cannot sign in. <Note> The Rejected sign-ins list only appears when at least one sign-in has been turned away. The Synced, not routed list appears inside the provisioning-rules card and only when at least one provisioned user is waiting without a matching rule. </Note> For rejected sign-ins you can do the following: * Click **Test in preview** to load that person's email and recorded groups into the preview, so you can see exactly which rule would cover them before you add one. * Click **Clear** to delete the record, or **Clear all** to remove every entry. Clearing does not block the person; a fresh entry appears if they try again. For synced, not routed entries, add a provisioning rule that covers their group. They'll be placed automatically at the next directory sync; there is nothing to clear. Once a person is successfully placed (by signing in through a matching rule or by the next directory sync), their entries in these lists are cleaned up automatically. ## Things to know * Keep the DNS TXT record in place while you are using Claude for Government. * There is no local break-glass account or stored password. When single sign-on is unavailable, Primary Owners and tenant administrators can request an emailed single-use sign-in link from the sign-in page. * SCIM provisioning is configured entirely from this page, with no action needed from Anthropic. Use **Generate token** under [SCIM provisioning](#scim-provisioning) on this page to create a bearer token, then enter it along with the SCIM base URL shown there into your identity provider's provisioning settings. * If two administrators reorder the same rule list at the same time, the second save is rejected with a message that the rules changed in another session. The list refreshes so you can review the current order and try again. * A user who was previously deactivated cannot regain access by matching a rule; they are refused with a deactivated-user reason instead. * For users managed by your directory, the email address shown in Claude for Government is kept in step with your directory. The sign-in token's email is ignored for those users so that a provider that sends different values in different fields (a common quirk in Microsoft Entra) does not bounce the address back and forth.
government/tenant-admin/organizations First recorded · 49 lines, first recorded
# Organizations ## How organizations work ## The organization list ## Adding an organization ### After you add an organization ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Organizations > Use this page to see every organization in your tenant, open any organization's admin view, and create new organizations. > **Who this is for:** Tenant administrators who create and oversee the organizations within their agency's deployment. Use this page to see every organization in your tenant, open any organization's admin view, and create new organizations. ## How organizations work An **organization** is a workspace that holds a set of users, a set of seats, its own spend caps, and its own product settings. Users always belong to exactly one organization, and each organization is linked to exactly one **billing account** (the credit and seat pool that funds it). Organizations share the tenant's sign-in and provisioning setup. You configure single sign-on once on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page and every organization uses the same connection. What differs between organizations is who belongs to each one, and that is decided by the routing rules on that same page rather than here. ## The organization list Each organization appears with its name and ID. Clicking an organization's name opens its organization admin view. When you do this you are acting as an administrator of that organization, and you can manage its users, seats, and settings exactly as one of its own owners would. <Tip> Which organization a user joins isn't controlled on this page. That's set by the routing rules on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page. </Tip> ## Adding an organization Expand the **Add organization** section to create a new organization. You'll provide the following: * **Name** is what the organization will be called. Leading and trailing spaces are trimmed, and the name can be up to 256 characters. There is no uniqueness requirement, so you can create two organizations with the same name, but you generally shouldn't. * **Primary owner email** is the email address of the person who will be the new organization's first administrator. This person becomes the Primary Owner and can immediately manage the organization's users and settings. They do **not** become a tenant administrator; tenant-level access is granted separately on the [Admins](/docs/government/tenant-admin/admins) page. * **Billing account** determines where the organization's credits and seats come from. Choose an existing billing account from the list; the new organization draws from that account's credit balance and seat pool alongside any other organizations already on it. Only billing accounts that are active and tenant-managed appear in the list. <Note> If the list is empty, your tenant has no active tenant-managed billing accounts yet. Contact Anthropic to have one set up. </Note> ### After you add an organization The new organization appears in the list immediately and you can click through to its organization admin view. A few follow-up steps are usually needed before people can use it: * Add a routing rule on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page so that the right people are placed in the new organization when they sign in or are provisioned. Until a rule targets the new organization, nobody will land there automatically. * Give it seats on the [Seats](/docs/government/tenant-admin/seats) page. A newly created organization starts with no seats distributed to it. * If you want to limit how much the new organization can spend from its billing account, set a spend cap on it on the [Billing](/docs/government/tenant-admin/credits) page. This is optional. With no cap, the account's balance is the only limit. > **For organization owners:** Being named the primary owner of a new organization does **not** make you a tenant administrator. Tenant admin access is granted separately on the [Admins](/docs/government/tenant-admin/admins) page. ## Things to know * You cannot delete an organization from this page. If an organization is no longer needed, contact Anthropic to have it deactivated. Routing rules that target a deactivated organization stop matching, and users in a deactivated organization cannot sign in until it is reactivated or they are moved. * Organization names can be changed later from the organization's own admin view. * There is no fixed limit on the number of organizations you can create, but each one adds a row to your seat distribution and configuration surfaces, so create only as many as you need to keep administration manageable.
government/tenant-admin/overview First recorded · 62 lines, first recorded
# Tenant administration ## Tenants and organizations ## Who can use this portal ## Getting set up for the first time ## Pages in this portal
The first capture of this source. The page was already there, and this is what it said.
# Tenant administration > Manage the settings that apply across your whole agency: organizations, identity and sign-in, and how seats are distributed and spend caps are set. > **Who this portal is for:** Tenant administrators who manage their agency's overall Claude for Government deployment across every organization. If you manage a single organization, see the [Organization administration](/docs/government/org-admin/overview) guide instead. The tenant admin portal is where you manage the things that apply across every team using the service: identity, organization routing, seats, spend caps, and tenant-wide product settings. ## Tenants and organizations Your **tenant** is your agency's top-level account. Within your tenant you create one or more **organizations**, which are separate workspaces for different teams, bureaus, or programs. All organizations in your tenant share the same sign-in setup, so one connection to your identity provider covers everyone. What differs between organizations is who belongs to each one, how many seats each one is allocated and what spend caps are set on it, and which product settings each one can adjust for itself. Funding flows through **billing accounts**, which are credit and seat pools that Anthropic sets up with your agency. Every organization is linked to exactly one billing account, and several organizations may draw from the same one. The [Seats](/docs/government/tenant-admin/seats) page is where you divide each billing account's seat pool among its organizations, and the [Billing](/docs/government/tenant-admin/credits) page is where you see each account's balance and set per-organization spend caps. There are two admin portals: * The **tenant admin** portal (this one) is where you create organizations, connect your identity provider, decide which organization each user lands in, distribute seats and set spend caps, and set tenant-wide policy. Only tenant administrators can see it. * The **organization admin** portal is where each organization's own owners manage that organization's users, seats, and settings. As a tenant administrator, you can open any organization's admin view from the [Organizations](/docs/government/tenant-admin/organizations) page, or you can use the **Switch to org view** link at the bottom of every tenant admin page. ## Who can use this portal Only **tenant administrators** can open the tenant admin portal. Tenant administrators are a specific list of people that are managed on the [Admins](/docs/government/tenant-admin/admins) page, and this list is separate from any role someone holds inside an organization. > **For organization owners:** Owning an organization does *not* make you a tenant administrator. If you need tenant-level access, ask an existing tenant administrator to add you on the [Admins](/docs/government/tenant-admin/admins) page. Every page of this portal requires tenant administrator access. If you follow a link in this guide without tenant access, you'll be turned away with a permission error. ## Getting set up for the first time The [setup wizard](/docs/government/tenant-admin/setup-wizard) walks you through all of this step by step. If your tenant has just been created, work through the pages in this order: 1. **[Identity and access](/docs/government/tenant-admin/identity-and-access).** Connect single sign-on so that people can authenticate with their agency credentials, optionally connect SCIM provisioning so that your directory syncs users and groups automatically, and add at least one routing rule so that users are placed in an organization when they sign in. Until a rule exists, nobody else can sign in. 2. **[Seats](/docs/government/tenant-admin/seats) and [Billing](/docs/government/tenant-admin/credits).** Distribute seats from your billing account to the organizations that will use them, and optionally set spend caps. 3. **[Admins](/docs/government/tenant-admin/admins).** Add at least one more tenant administrator so that you are not the only person with tenant-level access. <Warning> There is a short setup period after Anthropic first creates your tenant. During that period, a banner appears on the Identity and access page and nobody at your agency can sign in yet, including people who would normally be routed to an organization. You can still use that time to configure your single sign-on connection and routing rules, and they will start working automatically as soon as the setup period ends. </Warning> ## Pages in this portal The navigation groups the pages into three sections. **Organizations and identity** * The **[Organizations](/docs/government/tenant-admin/organizations)** page lets you see every organization in your tenant, open any organization's admin view, and create new organizations. * The **[Identity and access](/docs/government/tenant-admin/identity-and-access)** page lets you connect single sign-on (using either the OIDC or SAML protocol, whichever your identity provider supports), manage the SCIM provisioning token, write the routing rules that place users into organizations, preview how a specific person would be routed, and review people who haven't been placed yet. **Seats and billing** * The **[Seats](/docs/government/tenant-admin/seats)** page lets you distribute the seats in each billing account's pool to the organizations that account funds. * The **[Billing](/docs/government/tenant-admin/credits)** page shows each billing account's balance and lets you set spend caps that limit how much each organization can draw from it. **Settings** * The **[Config](/docs/government/tenant-admin/configuration)** page lets you set product settings that apply to every organization, and optionally lock them so organizations can't override them. * The **[Admins](/docs/government/tenant-admin/admins)** page lets you manage who has access to this tenant admin portal. * The **[Readiness](/docs/government/tenant-admin/readiness)** page shows what is blocking your organizations from using Claude and where each item is resolved. The [setup wizard](/docs/government/tenant-admin/setup-wizard) is not a page in this list; you reach it through the **Resume setup** banner that appears above the navigation until your tenant is fully set up.
government/tenant-admin/readiness First recorded · 50 lines, first recorded
# Readiness ## How the checklist is presented ## Tenant-level checks ## Organizations ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Readiness > Use this page to see everything that is blocking your organizations from using Claude, and to find the one place where each blocker is resolved. > **Who this is for:** Tenant administrators who are setting up a deployment, or who need to find out why users in any organization are unable to use Claude. Use this page to see everything that is blocking your organizations from using Claude, and to find the one place where each blocker is resolved. A deployment is ready when a user in each organization can sign in, be placed in that organization, hold a seat, and send a message to a model. This page runs that check for the whole tenant and lists every step that is complete, blocked, or waiting on someone. You would normally work through it once during initial setup and then return whenever the **Settings** menu shows a notification dot, which appears whenever anything on this page needs attention. ## How the checklist is presented Each step sits on a vertical track with a status marker. * A **green check** means the step is complete. The label is struck through and you can ignore it. * A **filled circle** marks the step you should act on next. It expands to show why it is blocked and offers an **Open** button that takes you to the page where the fix is made. * A **clock** means the step is blocked but you are not the person who can clear it. A line underneath tells you whether it is waiting on Anthropic, on an organization owner, or on the owner of a shared billing account. * A **hollow circle** is a step still to come. It stays collapsed until the steps ahead of it are cleared. Below a divider is an **Optional** section. These items do not stop anyone from using Claude, but the page surfaces them because they usually matter, such as setting up SCIM provisioning or reviewing sign-in attempts that were turned away. Use **Refresh** at the top right after you make a change elsewhere to see the updated state without leaving the page. ## Tenant-level checks These are the items that appear in the top card. They cover the things every organization in your tenant depends on. * **Activate the tenant** appears on its own when Anthropic has not yet finished provisioning your tenant, or when the tenant has been deactivated. Nothing else can be configured until this clears, and only Anthropic can clear it, so the page shows a waiting state. * **Fund the billing account** checks that at least one billing account linked to an active organization has a positive balance. This is advisory because the blocking state is shown on each organization's own readiness check. Funding is arranged with Anthropic. * **Configure the seat pool** checks that at least one billing account has a seat pool set. This is also advisory. Without a pool, seat allocations on the [Seats](/docs/government/tenant-admin/seats) page are accepted without any cap. The pool is configured by Anthropic as part of your contract. * **Register a domain** is required. Claude for Government routes users to your tenant by the domain of their email address, so until at least one domain is registered nobody can start a new sign-in. Use **Open Identity and access** to go to the [Identity and access](/docs/government/tenant-admin/identity-and-access) page and add one. * **Set up SCIM provisioning** is optional. SCIM lets your directory push users and groups into Claude for Government automatically. If you plan to use it, generate a provisioning token on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page. * **Add a routing rule** is required. Routing rules decide which organization each user joins when they sign in. Until at least one rule points at an active organization, every new sign-in is turned away. Use **Open Identity and access** to add a rule. If your tenant has no active organizations yet, the button instead opens the [Organizations](/docs/government/tenant-admin/organizations) page so you can create one first. * **Review sign-in failures** is an optional summary of people who tried to sign in and were turned away. The description tells you how many need a routing rule, how many need their email domain registered, and how many conflict with an existing account. Use **Open Identity and access** to resolve them. If your tenant has a single organization, that organization's own checks (credits, spend caps, seats, seat tiers, and products) appear directly in this card below the tenant-level items, so you can work through the whole deployment from one list. ## Organizations When your tenant has more than one organization, a second card lists each one with a one-line summary: **Ready**, a named blocker with **(fix available)**, or a named blocker with who it is waiting on. The marker beside each row uses the same colors as the checklist above. Expanding a row loads that organization's full checklist inline. The steps are the same ones described on the [organization Readiness page](/docs/government/org-admin/readiness), and any buttons you click here act on that organization, not the one you are currently viewing in the organization admin portal. This lets you clear an organization's blockers without switching context. Deactivated organizations appear here with their reactivation status. An organization whose billing account is retired cannot be reactivated until the account has settled and Anthropic has assigned a new one, so those rows show a waiting state instead of a button. ## Things to know * Every **Open** button goes to the page where the fix belongs, with the right organization already selected when one applies. You make the change there and return here to see it reflected. * When a step is something only Anthropic can do, such as funding a billing account or reactivating an organization, the page shows **Waiting on Anthropic**. Contact your Anthropic representative to move it forward. * Hover the help icon next to any step's label for a one-line explanation of what the check looks for.
government/tenant-admin/seats First recorded · 56 lines, first recorded
# Seats ## How seats are organized ## What the page shows ## Changing an organization's seats ## How seats affect new users ## When you can't edit ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Seats > Use this page to divide each billing account's seat pool among the organizations that account funds. > **Who this is for:** Tenant administrators who distribute purchased seats to the organizations in their deployment. Use this page to divide each billing account's seat pool among the organizations that account funds. ## How seats are organized A **seat** is what entitles one person to use Claude. Every seat belongs to a **seat tier**, which is a named level of access that determines how much a person in that seat may use (for example, different usage limits per tier). Seats live in **billing accounts**, which are the credit and seat pools Anthropic sets up with your agency. Anthropic grants each billing account a pool of seats, broken down by tier. Every organization is linked to exactly one billing account, and on this page you divide each account's pool among the organizations it funds. For each tier, the totals you hand out across those organizations can't exceed what's in the pool. Seat distribution is a two-step process. On this page you give each organization a number of seats per tier. Organization owners then assign those seats to individual people in the organization admin portal. ## What the page shows <Note> Billing account cards only appear once Anthropic has set up at least one billing account for your tenant. Until then, the page shows a message asking you to contact Anthropic. </Note> Each billing account appears as its own card, and each card contains the following: * The **seat pool** table shows each seat tier with the pool size, how many seats have been distributed across organizations, and how many remain. A negative **Remaining** number (shown in red) means the pool was reduced after seats were distributed; contact Anthropic to adjust the pool, or reduce some organizations' allocations. * The **organizations** section lists every organization funded by this account, and each one has a number field per tier showing its current allocation. ## Changing an organization's seats Edit the number fields next to an organization's name and click **Save**. Saving replaces that organization's allocation across all tiers at once. Changes take effect immediately: newly added seats are available for the organization's owners to assign right away. The save will be rejected in a few cases: * If the totals you entered across all of an account's organizations would exceed the pool for any tier, you'll see an error explaining which tier is over. * If you try to reduce a tier below the number of people (and service accounts) already seated on it in that organization, you'll see an error. Ask the organization's owners to unassign people from that tier first, then reduce the allocation. * Similarly, you cannot remove a tier from an organization entirely (by setting it to zero) while anyone is still seated on it there. ## How seats affect new users When a new person is placed in an organization (by a routing rule on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page), they're automatically given a seat if one is free. Tiers are filled in a fixed order, so the first tier is filled before the next is started. If every tier the organization has is completely full, the new person is placed in the organization without a seat. They can sign in and see the portal, but cannot send messages to Claude until an owner assigns them a seat or you distribute more seats here. An organization that has no seat allocation at all is treated as uncapped. New users can join and use Claude, but this is unusual; normally every active organization has at least one tier allocated. ## When you can't edit You'll see a note instead of the editor in a few situations: * If the billing account is **deactivated**, its seats can't be redistributed. Contact Anthropic to move its organizations to an active account. * If the account is **managed by one organization's administrators** rather than by tenant administrators, you won't be able to edit it here; the owning organization controls its own distribution. * If the account has **no seat pool yet**, contact Anthropic to set one up. ## Things to know * Reducing an organization's allocation never unassigns anyone automatically. The reduction is refused until enough people have been moved off the tier. * You can freely move seats between organizations on the same billing account by lowering one and raising another, as long as neither change violates the rules above. You may need to save the reduction first to free the pool, then save the increase. * Seat pools are set by Anthropic. If you need more seats in a tier, or a new tier added, contact Anthropic.
government/tenant-admin/setup-wizard First recorded · 104 lines, first recorded
# Tenant setup wizard ## Step 1: Welcome ## Step 2: Domains ## Step 3: Single sign-on ## Step 4: Provisioning (optional) ## Step 5: Organizations ## Step 6: Seats and spend caps ## Step 7: Routing ## Steps 8 and 9: Seat tiers and Products (single-organization tenants only) ## Final step: Finish ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Tenant setup wizard > Walk through the guided setup that takes a brand new tenant from first sign-in to ready for users. > **Who this is for:** Tenant administrators who have just been given access to a new Claude for Government deployment and need to get it ready for the rest of their agency. When Anthropic first hands over your tenant, only you and any other administrators invited by email can sign in. The setup wizard walks you through the handful of things that need to be in place before everyone else can use Claude: a verified email domain, a connection to your identity provider, at least one organization, seats for that organization, and a routing rule that places people in it. Until setup is complete, a **Resume setup** banner appears at the top of the tenant and organization admin pages so you can pick up where you left off. The wizard has a step list on the left and the current step on the right. Completed steps are ticked, and you can click any step in the list to jump to it. Every step has a **Continue later** link at the bottom that takes you back to the tenant admin portal; nothing is lost, and the **Resume setup** banner brings you back when you are ready. Steps marked **Optional** in the list can be skipped without blocking sign-in. ## Step 1: Welcome The first step is a read-only summary of what Anthropic has already set up for you: your tenant's name, any email domains that Anthropic verified on your behalf during provisioning, and how many organizations already exist. There is nothing to fill in here. It is simply a chance to confirm that the tenant name is what you expect before you continue. If a detail looks wrong (for example, the tenant name is misspelled), contact Anthropic before going further, because the tenant name cannot be changed from the portal. ## Step 2: Domains Claude for Government looks at the domain of a person's email address to decide which tenant they belong to, so at least one verified domain must be registered before anyone else can sign in. The table at the top of this step lists the domains already on your tenant, along with whether each one is verified and whether it was added by Anthropic or by you. If Anthropic already verified the domain you plan to use, you can move straight on to the next step. To add another domain, type it into the **Claim a domain** field and click **Claim**. You will be shown a DNS TXT record to publish on that domain. Once the record is live, click **Verify now** next to the pending claim and the domain becomes active. DNS changes can take anywhere from a few minutes to an hour to propagate, so try again shortly if verification does not succeed on the first attempt. For more detail on how domains work and how to remove one later, see the [Domains section of the Identity and access page](/docs/government/tenant-admin/identity-and-access#domains). ## Step 3: Single sign-on This step connects Claude for Government to your agency's identity provider (for example, Microsoft Entra, Okta, or ADFS) so that everyone signs in with their existing agency credentials. A **Connected** or **Not connected** badge next to the heading shows the current state. This step is unavailable until you have verified at least one domain on the previous step. A banner on this step says so, because sign-in routes people to your tenant by the domain of their email address. Setting this up is a two-way exchange: 1. Copy the values shown on this step and register a new application in your identity provider using them. **Redirect URI / ACS URL** is where your provider sends the user back after authentication (providers call it the Redirect URI for OIDC, or the Assertion Consumer Service URL for SAML). **SP Entity ID / Audience** is the identifier your provider uses to recognize this application. 2. Choose the **OIDC** or **SAML** tab to match what your provider supports, then fill in the form with the values your provider gives you for the new application. For OIDC these are the Client ID, Client secret, Authorization URL, Token URL, Issuer, and JWKS URL. For SAML this is a single IdP metadata XML document: paste the federation metadata from your provider, and the Entity ID and SSO URL are read from it and shown back to you once connected. 3. Save the form. The badge changes to **Connected** once the connection has been verified. After you save a SAML connection, an **SP metadata URL** appears with the other values; most providers can import it to fill in the values automatically if you need to reconfigure. Until single sign-on is connected, only owners who were invited directly by email can sign in. The full field reference for both protocols is on the [Identity and access](/docs/government/tenant-admin/identity-and-access#single-sign-on) page. ## Step 4: Provisioning (optional) This step is optional. If your identity provider supports SCIM, which is a standard way for directory systems to push users and group memberships into other applications, you can connect it here so that accounts are created automatically rather than at first sign-in. Like single sign-on, this step is unavailable until you have verified at least one domain on Step 2. Copy the **Tenant URL** shown on this step into your identity provider's SCIM connector, then click **Generate token** and paste the token into the connector's secret token field. The token is shown only once, so copy it before closing the page. If you need to rotate it later, generate a new one and revoke the old one with the **Revoke** button. You do not have to finish the provider-side setup before moving on. Once your provider has pushed at least one group, you can come back to the Routing step (or the [Identity and access](/docs/government/tenant-admin/identity-and-access#scim-provisioning) page) and add rules that place people by group membership. ## Step 5: Organizations An organization is a workspace with its own members, its own seat allocation, its own spend caps, and its own settings. You need at least one before you can route anyone anywhere, and many agencies only ever need one. You would add more if different bureaus or programs need separate usage reporting, separate budgets, or different product settings. Any organizations that already exist are listed at the top. To create one, fill in the **Add organization** form: * **Name** is the display name shown throughout the portal. * **Primary Owner email** is the person who will manage this organization's members and seats. They will be invited by email and land in the organization admin view when they sign in. * **Billing account** is the account this organization draws from for seats and billed usage. Several organizations can share one account if they should be funded from a single budget. Click **Add** and the new organization appears in the list. You can create as many as you need now and add more later from the [Organizations](/docs/government/tenant-admin/organizations) page. ## Step 6: Seats and spend caps This step lets you give each organization seats and, optionally, a spend cap. Seats control how many people in each organization can use Claude. The table shows each organization with a seat-count field for the first seat tier. Enter the number of seats each organization should have and save. For per-tier control, use the full [Seats](/docs/government/tenant-admin/seats) page after setup. Each organization's usage spends directly from its billing account's balance, and you can add a spend cap to limit how much any one organization can use in a rolling window. Caps are optional. If you leave them blank, the billing account's balance is the only limit. You can adjust both seats and caps later from the tenant [Seats](/docs/government/tenant-admin/seats) and [Billing](/docs/government/tenant-admin/credits) pages. ## Step 7: Routing Routing rules decide which organization a person lands in when they sign in. A new person who does not match any rule cannot sign in at all, so you need at least one rule that covers your users. A single rule that maps your main email domain to your main organization is enough to get started. Each rule reads like a sentence: a condition on the left, an arrow, and the target organization on the right. To add one, use the form at the bottom: * In the **If** field, choose **Anyone with email domain** to match on the domain of the person's email address, or **Anyone with IdP group** to match on a group claim from your identity provider. * In the second field, pick the domain or type the group name. * In the **Then place in** field, pick the organization. * Click **Add rule**. Rules run from top to bottom and the first match wins, so drag more specific rules above broader ones. Rules that match directory groups pushed over SCIM are managed on the full [Identity and access](/docs/government/tenant-admin/identity-and-access#routing-rules) page, which also has a preview tool for testing where a specific email address would land. ## Steps 8 and 9: Seat tiers and Products (single-organization tenants only) If your tenant has exactly one organization, the wizard includes two extra steps so that you can finish the organization-level setup without switching portals. You will only see these two steps in the step list if your tenant has a single organization. Tenants with more than one organization skip straight to the Finish step, and each organization's owner completes these two steps in their own [organization setup wizard](/docs/government/org-admin/setup-wizard) instead. * **Seat tiers** lists the seat tiers available to the organization. A seat tier bundles together which Claude models a user may access and how much they may spend. Anthropic-managed tiers are set up for you during provisioning; if your organization is allowed to create self-managed tiers, you can add one here. See the organization [Seat tiers](/docs/government/org-admin/seat-tiers) page for the full editor. * **Products** lets you choose which Claude products the organization's members can sign in to, for example Claude Desktop, Claude Code, and Claude for Microsoft 365. This is optional, and a product that is not available on your deployment is shown grayed out with a note to contact Anthropic. ## Final step: Finish The last step shows a live readiness checklist. Each row is something that has to be in place before people can sign in, and it is ticked or crossed out as soon as you complete it. Items under the **Optional** heading do not block sign-in. If anything required is still outstanding, a yellow banner tells you so, and the button at the bottom reads **Continue later** so you can come back. Once every required item is ticked, the button changes to **Go to tenant** and your deployment is ready. As colleagues sign in they will start appearing on each organization's Users page. There is no separate "mark complete" action. The wizard reads the live state of your tenant, so if something changes later (for example, you remove your only routing rule), the **Resume setup** banner reappears on the tenant admin pages until the checklist is satisfied again. ## Things to know * You can leave the wizard at any point using **Continue later**. Everything you have entered is saved, and the **Resume setup** banner on the tenant and organization admin pages brings you back to where you left off. * Every step in the wizard edits the same settings as the matching page in the full tenant admin portal. You can use either one, and changes made in one place show up in the other. * Steps tick automatically when the underlying condition is met. The **Provisioning** and **Products** steps are optional and never block the Finish step. * Single sign-on and at least one routing rule are the two things that actually gate sign-in for everyone else. If you only have a few minutes, do those two first and come back for the rest.
government/tenant-admin/tenant-restrictions First recorded · 100 lines, first recorded
# Tenant restrictions ## How it works ## Configure your network proxy ## Header format ### Finding your tenant ID ## What a blocked user sees ## How invalid headers are handled ## Verifying the configuration ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Tenant restrictions
> Restrict which Claude for Government tenants can be reached from your agency's network by having your network proxy inject an allowlist header.
> **Who this is for:** IT and network administrators who operate their agency's outbound web proxy or secure web gateway and want to prevent users on that network from signing in to Claude for Government with a different agency's account.
Tenant restrictions let you limit which Claude for Government tenants can be reached from your network. Your network appliance adds a header to every outbound request listing the tenants you allow, and Claude for Government refuses any request that authenticates as a tenant not on that list.
This is useful when people on your network may hold accounts in more than one agency's tenant (for example, a contractor who supports several agencies) and you need to ensure that work done from your network stays within your own tenant.
There is nothing to enable on the Claude for Government side. The restriction is activated entirely by the presence of the header on the request, so it takes effect the moment your proxy begins injecting it and only for traffic that passes through that proxy.
## How it works
Your agency's network appliance (a forward proxy, secure web gateway, or similar device that can inspect and modify HTTPS traffic) injects an `Anthropic-Allowed-Tenant-Ids` header on every request it forwards to Claude for Government. The header value is a comma-separated list of tenant IDs.
On each request, Claude for Government compares the authenticated user's tenant against the list in the header. When the header is present and the user's tenant is not on the list, the request is refused. When the header is absent, no restriction applies.
The check covers every way a user can reach Claude for Government:
* The web application, including the tenant and organization admin portals
* The desktop application
* Claude Code
* The Claude for Microsoft 365 add-ins
* Direct API calls
* SCIM directory provisioning and the [Compliance API](/docs/government/org-admin/compliance-api)
The same check applies at sign-in, so a user signing in to a tenant that is not on the list sees the refusal at the sign-in screen rather than after authentication completes.
<Note>
A tenant restriction can only narrow access. A user still needs valid credentials for a tenant on the list; the header never grants access to a tenant the user does not already belong to.
</Note>
## Configure your network proxy
Configure your appliance to do both of the following on every request to your Claude for Government domains:
1. **Remove** any `Anthropic-Allowed-Tenant-Ids` header that arrived from the client.
2. **Set** a single `Anthropic-Allowed-Tenant-Ids` header to your allowlist value.
<Warning>
Your appliance must remove the incoming header before setting its own. If the appliance only appends, ordinary traffic still works, so the misconfiguration is not obvious. A client that supplies its own value can then reach the server with both values, which either bypasses the restriction or causes that client's requests to fail, depending on how the appliance merges the two. Most secure web gateway products have a distinct "set" or "overwrite" action that removes and replaces in one step; use that rather than "append" or "add".
</Warning>
Apply the rule to requests for the Claude for Government domains provided to you during onboarding, as well as your agency's own custom domain if you have one. Because Claude for Government is served over HTTPS, your appliance must perform TLS inspection for these hosts so that it can add the header to the encrypted request.
Requests that do not pass through your appliance (for example, from a device that is off your network) do not carry the header and are not restricted. Pair this feature with your existing controls that ensure managed devices route through the appliance.
## Header format
The header name is `Anthropic-Allowed-Tenant-Ids`. Header names are not case-sensitive, so your appliance may send the name in any casing.
The value is one or more tenant IDs separated by commas. A tenant ID has the form `umb_` followed by a lowercase UUID with dashes. The `umb_` prefix is optional, and whitespace around each ID is ignored. The UUID must be lowercase; an uppercase or mixed-case value is rejected as invalid.
```text theme={null}
Anthropic-Allowed-Tenant-Ids: umb_00000000-0000-4000-8000-000000000000
```
For more than one tenant, separate the IDs with commas:
```text theme={null}
Anthropic-Allowed-Tenant-Ids: umb_00000000-0000-4000-8000-000000000000, umb_11111111-1111-4111-8111-111111111111
```
### Finding your tenant ID
Anthropic provides your tenant ID during onboarding. If you do not have it on hand, contact Anthropic support and ask for the tenant ID for your deployment.
## What a blocked user sees
A user who tries to sign in to a tenant that is not on your allowlist sees a refusal page titled **This account isn't permitted from this network**, with guidance to sign in with an authorized account or contact their IT administrator.
A user who is already signed in when the restriction takes effect, or whose application makes a request in the background, receives an error in the product reading **Your organization restricts which accounts can be used from this network. Contact your IT administrator.** Direct API calls return HTTP 403 with the error code `tenant_restriction_violation` and the message `Access restricted by network policy. Contact your IT administrator.`
The refusal does not tell the user which tenants are permitted. Keep a record of your allowlist alongside your proxy configuration so that your help desk can answer user questions without inspecting the appliance.
## How invalid headers are handled
Claude for Government rejects malformed headers so that a misconfigured proxy fails visibly rather than silently allowing everything through. A request is rejected with HTTP 400 and the error code `tenant_restriction_header_invalid` when any of the following is true:
* The header is present but empty, or contains only whitespace or commas.
* Any value in the list is not a valid tenant ID.
* The list contains more than 64 tenant IDs.
* The request carries more than one `Anthropic-Allowed-Tenant-Ids` header.
A request with no `Anthropic-Allowed-Tenant-Ids` header at all is not restricted.
## Verifying the configuration
You can confirm the restriction is working before rolling it out broadly.
To confirm a block, temporarily set the proxy's allowlist to a tenant ID you do not own (any validly formatted ID works), then sign in to your own tenant from a browser that routes through the proxy. You should see the **This account isn't permitted from this network** refusal page. A direct API request in the same configuration should return HTTP 403 with the error code `tenant_restriction_violation`.
To confirm normal access, set the proxy's allowlist to your real tenant ID and repeat the request. It should succeed.
To confirm the appliance is overwriting rather than appending, have the test client send its own `Anthropic-Allowed-Tenant-Ids` header with your real tenant ID while the proxy's allowlist is set to an ID you do not own. The request should still return 403 (the proxy's value wins), not 400 (two headers reached the server) or 200 (the client's value reached the server).
## Things to know
* Personal Claude accounts use `claude.ai`, which is a separate host from the Claude for Government service. A personal account cannot sign in to Claude for Government, and a Claude for Government account cannot sign in to `claude.ai`. The header-based restriction on this page applies only to Claude for Government traffic; it does not govern access to `claude.ai`.
index First recorded · 383 lines, first recorded
# Welcome
The first capture of this source. The page was already there, and this is what it said.
# Welcome
> Connect Claude to your tools, teach it how your team works, and put it to work in Slack, on your desktop, in Microsoft 365, or through the Claude API.
<div className="home-landing">
<section className="hl-hero">
<div className="hl-hero-inner">
<p className="hl-eyebrow">Claude.ai documentation</p>
<h1 className="hl-hero-title">What do you want to do with Claude?</h1>
<div className="hl-chips">
<a className="hl-chip" href="/docs/docs/connectors/overview"><span className="hl-chip-task">Connect my apps and data</span> <span className="hl-chip-name" translate="no">Connectors</span></a>
<a className="hl-chip" href="/docs/docs/skills/overview"><span className="hl-chip-task">Teach Claude to do tasks my way</span> <span className="hl-chip-name" translate="no">Skills</span></a>
<a className="hl-chip" href="/docs/docs/cowork/overview"><span className="hl-chip-task">Give Claude a goal and check back</span> <span className="hl-chip-name" translate="no">Cowork</span></a>
<a className="hl-chip" href="/docs/docs/claude-tag/overview"><span className="hl-chip-task">Put Claude to work in my Slack</span> <span className="hl-chip-name" translate="no">Claude Tag</span></a>
<a className="hl-chip" href="/docs/docs/claude-science/overview"><span className="hl-chip-task">Analyze literature and data</span> <span className="hl-chip-name" translate="no">Claude Science</span></a>
<a className="hl-chip" href="/docs/docs/office-agents/overview"><span className="hl-chip-task">Draft decks, emails, and docs</span> <span className="hl-chip-name" translate="no">Claude for M365</span></a>
</div>
<p className="hl-hero-note">To start a chat or get back to your chats, open <a href="https://claude.ai">claude.ai</a>.</p>
<a className="hl-hero-more" href="#products">Browse all products <svg className="hl-arrow hl-arrow-down" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></a>
</div>
</section>
<div className="hl-main">
<section className="hl-section hl-products" id="products">
<h2 className="hl-sr-only">All products</h2>
<div className="hl-grid">
<a className="hl-card" href="/docs/docs/connectors/overview">
<svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M12 22v-5" />
<path d="M9 8V2" />
<path d="M15 8V2" />
<path d="M18 8v5a4 4 0 0 1-4 4h-4a4 4 0 0 1-4-4V8Z" />
</svg>
<span className="hl-card-body"><span className="hl-card-title" translate="no">Connectors</span><span className="hl-card-desc">Give Claude access to your tools and data in Google Drive, GitHub, Slack, Microsoft 365, or any MCP server.</span></span>
<span className="hl-card-cta">Browse connectors <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
</a>
<a className="hl-card" href="/docs/docs/skills/overview">
<svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M9.937 15.5A2 2 0 0 0 8.5 14.063l-6.135-1.582a.5.5 0 0 1 0-.962L8.5 9.936A2 2 0 0 0 9.937 8.5l1.582-6.135a.5.5 0 0 1 .962 0L14.063 8.5A2 2 0 0 0 15.5 9.937l6.135 1.581a.5.5 0 0 1 0 .964L15.5 14.063a2 2 0 0 0-1.437 1.437l-1.582 6.135a.5.5 0 0 1-.962 0z" />
<path d="M20 3v4" />
<path d="M22 5h-4" />
<path d="M4 17v2" />
<path d="M5 18H3" />
</svg>
<span className="hl-card-body"><span className="hl-card-title" translate="no">Skills</span><span className="hl-card-desc">Teach Claude how to do something your way with reusable instructions, scripts, and resources it loads when relevant.</span></span>
<span className="hl-card-cta">Learn about skills <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
</a>
<a className="hl-card" href="/docs/docs/plugins/overview">
<svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M15.39 4.39a1 1 0 0 0 1.68-.474 2.5 2.5 0 1 1 3.014 3.015 1 1 0 0 0-.474 1.68l1.683 1.682a2.414 2.414 0 0 1 0 3.414L19.61 19.39a1 1 0 0 1-1.68-.474 2.5 2.5 0 1 0-3.014 3.015 1 1 0 0 1 .474 1.68l-1.683 1.682a2.414 2.414 0 0 1-3.414 0L8.61 19.61a1 1 0 0 0-1.68.474 2.5 2.5 0 1 1-3.014-3.015 1 1 0 0 0 .474-1.68L2.707 13.707a2.414 2.414 0 0 1 0-3.414Z" />
</svg>
<span className="hl-card-body"><span className="hl-card-title" translate="no">Plugins</span><span className="hl-card-desc">Bundle skills, connectors, and more into shareable packages for Cowork and Claude Code.</span></span>
<span className="hl-card-cta">Explore plugins <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
</a>
<a className="hl-card" href="/docs/docs/cowork/overview">
<svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<rect width="20" height="14" x="2" y="3" rx="2" />
<path d="M8 21L16 21" />
<path d="M12 17L12 21" />
</svg>
<span className="hl-card-body"><span className="hl-card-title" translate="no">Cowork</span><span className="hl-card-desc">Hand Claude a goal on your desktop and come back to completed work, from polished documents to organized files and synthesized research.</span></span>
<span className="hl-card-cta">Get Cowork <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
</a>
<a className="hl-card" href="/docs/docs/claude-tag/overview">
<svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M14 9a2 2 0 0 1-2 2H6l-4 4V4a2 2 0 0 1 2-2h8a2 2 0 0 1 2 2z" />
<path d="M18 9h2a2 2 0 0 1 2 2v11l-4-4h-6a2 2 0 0 1-2-2v-1" />
</svg>
<span className="hl-card-body"><span className="hl-card-title" translate="no">Claude Tag</span><span className="hl-card-desc">Add Claude to Slack channels as a teammate your whole team can see, steer, and hand work to.</span></span>
<span className="hl-card-cta">Set up Claude Tag <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
</a>
<a className="hl-card" href="/docs/docs/claude-science/overview">
<svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M14 2v6a2 2 0 0 0 .245.96l5.51 10.08A2 2 0 0 1 18 22H6a2 2 0 0 1-1.755-2.96l5.51-10.08A2 2 0 0 0 10 8V2" />
<path d="M6.453 15h11.094" />
<path d="M8.5 2h7" />
</svg>
<span className="hl-card-body"><span className="hl-card-title" translate="no">Claude Science</span><span className="hl-card-desc">Run literature reviews, data analyses, and computational workflows in a desktop research workbench.</span></span>
<span className="hl-card-cta">Set up Claude Science <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
</a>
<a className="hl-card" href="/docs/docs/office-agents/overview">
<svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<rect width="7" height="7" x="3" y="3" rx="1" />
<rect width="7" height="7" x="14" y="3" rx="1" />
<rect width="7" height="7" x="14" y="14" rx="1" />
<rect width="7" height="7" x="3" y="14" rx="1" />
</svg>
<span className="hl-card-body"><span className="hl-card-title" translate="no">Claude for M365</span><span className="hl-card-desc">Use Claude inside Word, Excel, PowerPoint, and Outlook, with answers based on your organization's documents.</span></span>
<span className="hl-card-cta">Set up Claude for M365 <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
</a>
<a className="hl-card" href="/docs/docs/third-party/claude-desktop/overview">
<svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M17.5 19H9a7 7 0 1 1 6.71-9h1.79a4.5 4.5 0 1 1 0 9Z" />
</svg>
<span className="hl-card-body"><span className="hl-card-title">Claude on third-party platforms</span><span className="hl-card-desc">Get the full Claude Desktop experience, including Cowork, with model inference through Google Cloud's Agent Platform, Amazon Bedrock, Microsoft Foundry, or a gateway you operate.</span></span>
<span className="hl-card-cta">Deploy Claude Desktop <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
</a>
<a className="hl-card" href="/docs/docs/government/overview">
<svg className="hl-card-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M3 22L21 22" />
<path d="M6 18L6 11" />
<path d="M10 18L10 11" />
<path d="M14 18L14 11" />
<path d="M18 18L18 11" />
<path d="M12 2 20 7 4 7Z" />
</svg>
<span className="hl-card-body"><span className="hl-card-title" translate="no">Claude for Government</span><span className="hl-card-desc">Set up and manage Claude for your agency, with tenant, organization, seat, and credit administration.</span></span>
<span className="hl-card-cta">Manage Claude for Government <svg className="hl-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.75" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></span>
</a>
</div>
<p className="hl-changelogs"><strong className="hl-changelogs-label">What's new:</strong> the <a href="/docs/docs/cowork/changelog">Cowork changelog</a>, the <a href="/docs/docs/claude-science/changelog">Claude Science changelog</a>, and the <a href="/docs/docs/third-party/claude-desktop/configuration-changelog">Claude Desktop configuration changelog</a>.</p>
</section>
<section className="hl-section hl-disambig">
<h2 className="hl-h2">Which product do you need?</h2>
<p className="hl-lede">Start from what you're trying to do:</p>
<div className="hl-rows">
<a className="hl-row" href="/docs/docs/connectors/overview">
<span className="hl-row-q">“I want Claude to see my files, Slack messages, calendar, or codebase”</span>
<svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M5 12h14" />
<path d="m12 5 7 7-7 7" />
</svg>
<span className="hl-row-a"><span className="hl-row-name" translate="no">Connectors</span><span className="hl-row-note">access to your tools and data</span></span>
</a>
<a className="hl-row" href="/docs/docs/connectors/microsoft/365">
<span className="hl-row-q">“I want Claude to read my Outlook mail and OneDrive files”</span>
<svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M5 12h14" />
<path d="m12 5 7 7-7 7" />
</svg>
<span className="hl-row-a"><span className="hl-row-name">Microsoft 365 connector</span><span className="hl-row-note">your Microsoft 365 data in chat, not the Office apps</span></span>
</a>
<a className="hl-row" href="/docs/docs/office-agents/overview">
<span className="hl-row-q">“I want to turn a document into a slide deck”</span>
<svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M5 12h14" />
<path d="m12 5 7 7-7 7" />
</svg>
<span className="hl-row-a"><span className="hl-row-name" translate="no">Claude for M365</span><span className="hl-row-note">drafting decks, docs, and email inside the Office apps</span></span>
</a>
<a className="hl-row" href="/docs/docs/skills/overview">
<span className="hl-row-q">“I want Claude to do this task the way my team does it”</span>
<svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M5 12h14" />
<path d="m12 5 7 7-7 7" />
</svg>
<span className="hl-row-a"><span className="hl-row-name" translate="no">Skills</span><span className="hl-row-note">instructions and scripts for a task</span></span>
</a>
<a className="hl-row" href="/docs/docs/plugins/overview">
<span className="hl-row-q">“I want to share a ready-made setup with my whole team”</span>
<svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M5 12h14" />
<path d="m12 5 7 7-7 7" />
</svg>
<span className="hl-row-a"><span className="hl-row-name" translate="no">Plugins</span><span className="hl-row-note">bundled skills and connectors for Cowork and Claude Code</span></span>
</a>
<a className="hl-row" href="/docs/docs/claude-tag/overview">
<span className="hl-row-q">“I want my whole channel to see and steer Claude’s work”</span>
<svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M5 12h14" />
<path d="m12 5 7 7-7 7" />
</svg>
<span className="hl-row-a"><span className="hl-row-name" translate="no">Claude Tag</span><span className="hl-row-note">Claude in your team’s Slack</span></span>
</a>
<a className="hl-row" href="/docs/docs/third-party/claude-desktop/overview">
<span className="hl-row-q">“I want Claude to run through my own cloud provider”</span>
<svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M5 12h14" />
<path d="m12 5 7 7-7 7" />
</svg>
<span className="hl-row-a"><span className="hl-row-name">Claude on third-party platforms</span><span className="hl-row-note">Claude Desktop through your cloud provider</span></span>
</a>
<a className="hl-row" href="/docs/docs/connectors/building/mcp">
<span className="hl-row-q">“I want to build or publish a connector”</span>
<svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M5 12h14" />
<path d="m12 5 7 7-7 7" />
</svg>
<span className="hl-row-a"><span className="hl-row-name" translate="no">MCP</span><span className="hl-row-note">build on the open protocol and submit to the directory</span></span>
</a>
<a className="hl-row" href="https://code.claude.com/docs" target="_blank" rel="noopener noreferrer">
<span className="hl-row-q">“I’m using Claude Code in my terminal”</span>
<svg className="hl-row-arrow" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M7 7h10v10" />
<path d="M7 17 17 7" />
</svg>
<span className="hl-row-a"><span className="hl-row-name" translate="no">Claude Code<span className="hl-sr-only" translate="yes"> (opens in a new tab)</span></span><span className="hl-row-note">Claude in your terminal and IDE</span></span>
</a>
</div>
</section>
<section className="hl-section hl-getstarted">
<div className="hl-gs-col">
<h2 className="hl-h2">Create an account</h2>
<div className="hl-steps">
<div className="hl-step"><span className="hl-step-num">1</span><span className="hl-step-text">Go to <a href="https://claude.ai" target="_blank" rel="noopener noreferrer">claude.ai<span className="hl-sr-only"> (opens in a new tab)</span></a></span></div>
<div className="hl-step"><span className="hl-step-num">2</span><span className="hl-step-text">Select <strong>Continue with Google</strong> or enter your email address</span></div>
<div className="hl-step"><span className="hl-step-num">3</span><span className="hl-step-text">Follow the prompts to complete registration</span></div>
</div>
<div className="hl-tip">
<svg className="hl-tip-icon" aria-hidden="true" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M15 14c.2-1 .7-1.7 1.5-2.5 1-.9 1.5-2.2 1.5-3.5A6 6 0 0 0 6 8c0 1 .2 2.2 1.5 3.5.7.7 1.3 1.5 1.5 2.5" />
<path d="M9 18h6" />
<path d="M10 22h4" />
</svg>
<div className="hl-tip-text">
<p>All plans have access to the <a href="/docs/docs/connectors/directory">Connectors Directory</a>. Free plans can also add one <a href="/docs/docs/connectors/custom/remote-mcp">custom connector</a>. Compare <a href="https://claude.com/pricing" target="_blank" rel="noopener noreferrer">Claude plans and pricing<span className="hl-sr-only"> (opens in a new tab)</span></a>.</p>
<p>Claude for Government access is set up by your agency's administrators, so you don't need to create an account. See the <a href="/docs/docs/government/overview">Claude for Government guide</a>.</p>
</div>
</div>
</div>
<div className="hl-gs-col">
<h2 className="hl-h2">Building with Claude</h2>
<div className="hl-dev-list">
<a className="hl-dev-card" href="https://platform.claude.com" target="_blank" rel="noopener noreferrer">
Cut at 300 lines. The page has the rest.
office-agents/connectors-and-skills First recorded · 55 lines, first recorded
# Connectors and Skills ## Connectors ## Skills ## Related
The first capture of this source. The page was already there, and this is what it said.
# Connectors and Skills > Extend Claude for Excel, PowerPoint, Word, and Outlook with external context and reusable task recipes. Connectors and Skills work the same way across Claude for Excel, PowerPoint, Word, and Outlook. Both are enabled in your Claude settings. <Note> Connectors and Skills are available when you sign in with your Claude account directly. When connecting through a third-party platform such as Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway, these capabilities may not be available. See the feature comparison in [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms) for the current status by connection mode. </Note> ## Connectors Connect external tools to give Claude context beyond what's in the file or email you have open. In any Claude for M365 add-in, click the **+** button below the chat input and select **Connectors** to see available options. Common connectors used with Claude for M365 include S\&P Global, LSEG, and Daloopa for financial data, plus any custom connectors your organization has enabled. <Warning> Custom connectors can introduce security risks. Before enabling one, review [Get started with custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) for guidance on what to consider. </Warning> ## Skills Skills you've enabled in your Claude settings are available in all Claude for M365 add-ins. Claude applies relevant Skills automatically based on what you're doing. You can also invoke a Skill directly: type `/` in the sidebar to see Skills available for the app you're in, then select one, such as `/deck-check` in PowerPoint. Skills that aren't relevant to the current app are excluded from this list. See [Use Skills in Claude](https://support.claude.com/en/articles/12512180-use-skills-in-claude) for details on enabling and managing Skills. ## Related See the per-app guides for setup and feature details. * [Use Claude for Excel](/docs/office-agents/excel) * [Use Claude for PowerPoint](/docs/office-agents/powerpoint) * [Use Claude for Word](/docs/office-agents/word) * [Use Claude for Outlook](/docs/office-agents/outlook)
office-agents/data-storage First recorded · 229 lines, first recorded
# Data storage and retention ## Every Claude add-in shares one store ## What Claude for M365 stores ## Sign-in and credentials ## Where the data sits on Windows ## Where the data sits on macOS ## What chat history is keyed to ## Data retention ## What leaves the device ## Export a user's data before a device is rebuilt ## Related
The first capture of this source. The page was already there, and this is what it said.
# Data storage and retention > Where Claude for M365 stores chat history, skills, and credentials on each user's device, why reinstalling or switching add-ins keeps that data, and how long it is kept. Claude for M365 stores chat history, uploaded skills, connector registrations, and sign-in credentials on each user's own device, in the browser storage of the webview that Office provides. Anthropic holds no copy of this data, and nothing syncs between devices or browsers. A device that is rebuilt, reimaged, or handed to someone else loses this data unless you export it first. ## Every Claude add-in shares one store Users run more than one Claude add-in over time: the per-app store listings, an enterprise sideload, or a custom manifest that points the add-in at your own cloud. All of them are served from `https://pivot.claude.ai`, and browser storage is keyed to that address. They therefore read and write the same store on a given device. <img src="https://mintcdn.com/claude-ai/eVVCEXIWAP0OYny8/images/office-agents/data-storage/storage-shared.png?fit=max&auto=format&n=eVVCEXIWAP0OYny8&q=85&s=ce3348a4909a88501ddad9de36cfd151" alt="Separate Claude add-in installs, each with its own add-in ID, all served from pivot.claude.ai and sharing one store that holds five IndexedDB databases and local storage" width="2506" height="856" data-path="images/office-agents/data-storage/storage-shared.png" /> The reason is the ordinary web rule. Office reads the manifest, finds the `<SourceLocation>` URL, and opens it in an embedded browser. From that point the browser behaves as any browser does: it hands storage to the page's address, meaning its scheme, host, and port. The add-in's ID, version, and display name never enter the lookup, so a manifest is closer to a bookmark than to a container. Deleting a bookmark does not delete the site's cookies. Two consequences follow: * A query string is not part of an address. A third-party manifest is built for one organization and carries that organization's configuration in a query string, so no two are alike. All of them still land in the same store as every other install. * Changing the address does create a new, empty store. Serving the add-in from a different host, a different port, or over `http` instead of `https` gives it somewhere else to read and write. The previous store still exists, but nothing reads it. The table below gives the result for each change users and administrators actually make. | Change | Result | | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Uninstall and reinstall the same add-in | Data intact | | Move to a different store listing, or to one published with a new ID | Data intact. A new listing means a new add-in ID, not new storage | | Move from a sideloaded manifest to a store listing, or the reverse | Data intact | | Swap the standard manifest for the custom third-party manifest, or the reverse | Storage intact, but the history list changes, because the connection mode change is an identity change. See [what chat history is keyed to](#what-chat-history-is-keyed-to) | | Run a store install and a sideloaded manifest at the same time | Shared storage. Two entries in Office, one history. Remove one to avoid confusion | | Bump the manifest version, or issue a new ID to clear an Admin Center cache | Data intact | | Serve the add-in from a different host or port, or over `http` | A new empty store | | Rebuild, reimage, or wipe the profile on the device | Data destroyed. Export first | ## What Claude for M365 stores The add-in uses five IndexedDB databases and one local storage store, all inside the signed-in user's operating system profile. The table below lists each one and what it is scoped to. | Store | Contents | Scoped to | | ------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------ | | `claude-chat-history` | Conversation transcripts, titles, timestamps, and the contents of attached files | One user, one organization, one Office app | | `claude-local-skills` | Skills the user uploaded, including any templates bundled with them | The device profile, not the individual user | | `claude-mcp-gateways` | Client registrations for connectors the user has authorized | The connector's address, not the individual user | | `claude-mail-style` | Claude for Outlook only: learned writing style, draft preferences, and scratchpad | One user | | `claude-office-snipped-results` | Working scratch for long conversations, cleared at the start of every session | Nothing, transient | | Local storage | Settings, onboarding and terms flags, and the active sign-in profile | The browser profile | Conversations and the Outlook writing style guide are scoped to the individual user. Uploaded skills and connector registrations are scoped to the storage location instead, so anyone who reaches the same store shares them. The Windows and macOS sections below describe what splits a store on each platform. This only applies where people share a single operating system account. That arrangement already shares the browser profile, saved sessions, and local files between them, so the guidance is the same as for any browser-based tool: give each person their own operating system account. Claude for M365 also writes one value into the Office document itself: an opaque identifier that lets the add-in recognize the same file after a rename or a Save As. It holds no user information and no conversation content, and it travels with the file if the document is shared. ## Sign-in and credentials Every store above holds only content, with one exception. Local storage also holds the signed-in user's identity: the credential the add-in presents to the model endpoint you configured. Cloud provider sign-ins use short-lived tokens that the add-in renews automatically. A gateway token or API key that you configure yourself is held until you change it. This sits in the browser profile unencrypted, in the same way a saved web session does. The boundary protecting it is the operating system account: another account on the same machine cannot read it, and disk encryption covers the device at rest. Where the deployment signs in to a cloud provider, the credential is obtained on the device and used from the device. A gateway token or API key that you issue centrally is distributed to every user's device, so treat it as you would any other shared secret. <Warning> An export of a user's add-in data contains these credentials as well as conversation text, because the export copies local storage. Treat an export folder as a secret, or delete the local storage folder from it before the export leaves the device. A rebuilt machine signs in again regardless. </Warning> ## Where the data sits on Windows On Windows the store is split by signed-in Office account. Local storage is one database for the whole browser profile rather than one per address, which is the main difference from macOS. <img src="https://mintcdn.com/claude-ai/eVVCEXIWAP0OYny8/images/office-agents/data-storage/storage-windows.png?fit=max&auto=format&n=eVVCEXIWAP0OYny8&q=85&s=f07c4d2142ac466c8b26b3520e15b8fe" alt="Windows layout: the webview2 folder contains one folder per signed-in Office account, each holding an IndexedDB folder named after the add-in address and a Local Storage folder shared by every address" width="2506" height="1148" data-path="images/office-agents/data-storage/storage-windows.png" /> If chat history looks missing on Windows, check the signed-in Office account before anything else. Signing back in to the original account restores the history with nothing to copy or repair. ## Where the data sits on macOS On macOS the store is split by Office app instead. Each app runs in its own sandbox container, so Excel, Word, PowerPoint, and Outlook always keep separate histories, and local storage sits inside the folder for a single address. <img src="https://mintcdn.com/claude-ai/eVVCEXIWAP0OYny8/images/office-agents/data-storage/storage-macos.png?fit=max&auto=format&n=eVVCEXIWAP0OYny8&q=85&s=4653f674b1a4b6466e35f4df36f7c6d9" alt="macOS layout: each Office app has its own container holding one folder per address, each with an IndexedDB SQLite file and a per-address LocalStorage SQLite file" width="2506" height="1028" data-path="images/office-agents/data-storage/storage-macos.png" /> Office on the web behaves differently again. The add-in runs in a cross-origin frame, so browsers treat its storage as third-party. Tracking prevention, policies that block third-party cookies, and similar controls partition or evict it. Browsers evict third-party storage on their own schedule, so treat chat history on Office on the web as temporary. ## What chat history is keyed to Sharing a store is not the same as sharing a history list. Each conversation is stored against a user identity, an organization, and the Office app it was created in. The list shows only the conversations that match all three for the session in use. When users sign in with a Claude account, that account is the identity. In third-party platform deployments there is no Claude account, so the identity comes from the Microsoft Entra ID sign-in already present in Office, as a one-way hash of the directory object ID. Nothing about the user is stored in readable form, and the hash is not sent to Anthropic. Office builds without support for nested app authentication cannot supply the Entra ID sign-in the add-in reads. On those builds Claude for M365 falls back to a per-installation identifier. Conversations still persist on that device; they are tied to the installation rather than to the directory account. The table below gives the result for each case. | Situation | Result | | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A user signs out of Claude and signs back in | The same conversations. Signing out does not change the identity | | A different person signs in to Office on that device | They see their own conversations, not the previous user's. On Office builds that fall back to a per-installation identifier, both people resolve to the same identity and share one list | | The same person opens the add-in on a second device | No conversations. Storage is per device and does not sync | | A user's organization changes, such as joining or leaving a team plan | Earlier conversations stop appearing. They remain on disk under the previous organization | | A deployment moves between a Claude account sign-in and a third-party platform, in either direction | Earlier conversations stop appearing. They remain on disk under the previous identity, and the add-in has no path to reach them | Changing connection mode is not a data loss event, because nothing is deleted, but it is an identity change and the history list follows the identity. One store derives identity differently from chat history. The Outlook writing style guide has no per-installation fallback. On Office builds where the Entra ID identity cannot be read, it falls back to a single shared key, so one learned writing style is shared by everyone using that browser profile. ## Data retention Claude for M365 bounds local storage in two ways, and users can clear it themselves at any time. | Store | Retention | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | `claude-chat-history` | The 50 most recent conversations per user, per organization, per Office app. Older conversations are deleted automatically | | Any store | When the browser profile runs out of storage quota, the oldest conversations are deleted to make room | | `claude-office-snipped-results` | Cleared at the start of every session | | Everything else | Kept until the user deletes it or the browser profile is wiped | Users clear their own conversations from the add-in's settings. Under "Chat history", "Delete all" removes every saved conversation for that user in that Office app and starts a new chat. There is no expiry by age and no administrator-configurable retention window. Claude for M365 also does not inherit custom data retention settings configured for your organization. If your policy requires a retention limit on this data, the practical control is the device profile lifecycle, such as roaming-profile cleanup or reimaging, rather than a setting in the add-in. ## What leaves the device The table below covers each category and its destination, so you can scope a review to the paths that carry content off the endpoint. | Data | Where it goes | | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Conversation text, attachments, and the document content Claude is asked to work with | The model endpoint your deployment is configured for. In third-party platform deployments that is your own Vertex AI, Bedrock, Azure, or gateway endpoint | | Chat history, uploaded skills, connector registrations, and the Outlook writing style guide | Nowhere. Local only, no sync, no server-side backup | | Sign-in credentials | Only to the identity provider they belong to | | Usage telemetry sent to Anthropic | Counts, durations, and error categories. Anthropic's collector is allowlist-filtered, so it excludes conversation text, document contents, file names, and the names of your connectors and their tools | | Telemetry sent to a custom OpenTelemetry collector you configure | The full audit trail, including prompt content and tool inputs and outputs. That path bypasses the allowlist filter by design. See [Audit and observability](/docs/office-agents/enterprise-readiness#audit-and-observability) | ## Export a user's data before a device is rebuilt The `claude-for-msft-365-install` plugin includes read-only export scripts for macOS and Windows. They read Office's storage and write only to the folder you name, and running them with no arguments reports what was found without copying anything. See [Deploy the add-in for your organization](/docs/office-agents/third-party-platforms#deploy-the-add-in-for-your-organization) for installation, then run `/claude-for-msft-365-install:export-data`. Export before any of the following: * A device is rebuilt, reimaged, or handed to another person. * Anyone clears the Office add-in cache on Windows. The storage sits inside the same `Wef` folder as the manifest cache, so deleting that folder destroys chat history along with the manifest. * Roaming-profile or FSLogix cleanup runs against the user's profile. * A browser policy such as `ClearBrowsingDataOnExit` is applied to the device. ## Related The pages below cover the deployment and security topics that reference this data. * [Security, admin auditability, and analytics](/docs/office-agents/enterprise-readiness) * [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms)
office-agents/dictation First recorded · 62 lines, first recorded
# Use dictation in Claude for M365 ## Use dictation ## How it works ## Why dictation is not available with third-party authentication
The first capture of this source. The page was already there, and this is what it said.
# Use dictation in Claude for M365
> Speak your prompts instead of typing them in Claude for Excel, PowerPoint, Word, and Outlook.
Dictation lets you speak prompts instead of typing them. Click the
microphone icon in the chat input, speak, and see your words appear in
the composer in real time.
<Note>
Dictation requires the desktop version of Excel, PowerPoint, Word, or
Outlook. It is not available in Office on the web because browser-hosted
add-ins cannot access the microphone. On the web, use your operating
system's built-in dictation or your Office application's dictation
feature instead.
Dictation is also available only for organizations using direct Claude
authentication. It is not supported when Claude for M365 connects through
a third-party platform such as Amazon Bedrock, Google Cloud Vertex AI,
Azure AI Foundry, or an LLM gateway. See
[Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms)
for platform support details.
</Note>
## Use dictation
<Steps>
<Step title="Start listening">
Click the microphone icon on the right side of the chat input. The
placeholder changes to "Listening..." and the button highlights.
</Step>
<Step title="Speak your prompt">
Words appear in the composer as you talk.
</Step>
<Step title="Stop or send">
Click the microphone again to stop, or press Enter to stop and send
in one step.
</Step>
</Steps>
To select a different microphone, hover over the microphone icon and
click the arrow that appears.
## How it works
When you start dictating, the add-in streams your audio to Anthropic's
transcription service, the same infrastructure that powers dictation in
the Claude apps. The transcribed text displays in real time in the
composer.
Nothing is transcribed on your device. Audio is streamed to Anthropic,
which uses a contracted speech-to-text subprocessor to generate the
transcript. Audio is not retained after transcription; only the
resulting text remains in your composer.
## Why dictation is not available with third-party authentication
In third-party environments, Claude for M365 does not send prompts to
Anthropic directly. Spoken audio is effectively a prompt, so dictation
is not offered there. Use your operating system's built-in dictation or
your Office application's dictation feature instead.
office-agents/enterprise-readiness First recorded · 102 lines, first recorded
# Security, admin auditability, and analytics ## Security architecture ## Audit and observability ## Usage analytics ## Spend tracking ## Related
The first capture of this source. The page was already there, and this is what it said.
# Security, admin auditability, and analytics > Security architecture diagrams, OpenTelemetry audit, usage analytics, and spend tracking for enterprise admins deploying Claude for M365. Enterprise administrators deploying Claude for Excel, PowerPoint, Word, and Outlook can review the security architecture for their chosen deployment mode and connect audit logs, usage analytics, and spend tracking to existing enterprise tooling. ## Security architecture The Trust Center publishes architecture diagrams that show how user prompts, document content, and responses flow between the Office add-ins, Claude, and your infrastructure. Review the diagram that matches your deployment mode before rollout. * **Anthropic first-party**: users sign in with their Claude accounts and requests go directly to Claude. See the [first-party architecture overview](https://trust.anthropic.com/resources?s=e3n7pvyjnxjyahmdmqujcx\&name=claude-for-excel,-powerpoint,-word:-architecture-overview-%28anthropic-first-party%29). * **Third-party platforms**: requests route through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway. The companion third-party architecture diagram is listed alongside the first-party one in the [Trust Center resources](https://trust.anthropic.com/resources?s=e3n7pvyjnxjyahmdmqujcx); filter for "Claude for Excel, PowerPoint, Word". [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms) has per-mode request-flow diagrams for the [LLM gateway](/docs/office-agents/third-party-platforms#llm-gateway) and [Bedrock, Vertex AI, or Foundry direct](/docs/office-agents/third-party-platforms#bedrock-vertex-ai-or-foundry-direct) paths, plus deployment guidance. ## Audit and observability Forward Claude for M365 activity to your existing observability stack with a custom OpenTelemetry collector endpoint. When a custom collector is configured, spans are exported unfiltered to that endpoint and include the full audit trail: session identifiers, surface, tool inputs and outputs, prompt content, and document references. Treat the endpoint as containing prompt and document content when scoping access controls and retention. Only spans sent to Anthropic's own collector are allowlist-filtered to strip sensitive attributes; that path is bypassed entirely when a custom endpoint is set. The add-in exports its telemetry from each user's browser: the taskpane at `https://pivot.claude.ai` posts directly to the custom collector endpoint, so every export is a cross-origin request and the endpoint must support CORS. The endpoint must answer the `OPTIONS` preflight with `Access-Control-Allow-Origin` covering `https://pivot.claude.ai` and `Access-Control-Allow-Headers` covering `Content-Type` plus any headers you configure for the export, such as `Authorization`. It must also return the same `Access-Control-Allow-Origin` header on the `POST` response. The [CORS requirements for an LLM gateway](/docs/office-agents/third-party-platforms#cors-requirements) describe the same browser behavior in more detail. Managed OTLP ingest endpoints such as Grafana Cloud are designed for server-to-server export and generally do not answer browser CORS preflights, so the browser blocks the export before it sends any authentication header. Point the collector endpoint at an OpenTelemetry Collector that you run, configure the `cors` block on its OTLP HTTP receiver, and have the collector forward to your backend. The collector makes the authenticated call to your backend, so no credential needs to appear in the export headers, which reach every signed-in user's browser. See [Configure a custom OpenTelemetry collector for Claude for M365](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents) for the manifest parameters and endpoint requirements. <Note> The usage analytics and spend tracking sections below apply when users sign in with their Claude accounts directly. When connecting through a third-party platform such as Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway, usage and spend are tracked through your cloud provider's billing console and your gateway's logging instead. </Note> ## Usage analytics Pull Claude for M365 usage into your own BI or reporting pipeline through the Claude Enterprise Analytics API. The API exposes per-user, per-surface, and per-organization aggregates. See [Claude Enterprise Analytics API reference guide](https://support.claude.com/en/articles/13703965-claude-enterprise-analytics-api-reference-guide) for endpoints, request shapes, and aggregation windows. ## Spend tracking Download CSV exports of Team and Enterprise plan usage from the usage analytics dashboard in your admin console. Exports include per-seat and per-surface spend, making them suitable for chargeback and financial reconciliation. See [View usage analytics for Team and Enterprise plans](https://support.claude.com/en/articles/12883420-view-usage-analytics-for-team-and-enterprise-plans) for the steps to generate and download a report. ## Related The pages below cover deployment paths and plugins relevant to enterprise admins. * [Data storage and retention](/docs/office-agents/data-storage) * [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms) * [Install financial services plugins for Cowork](/docs/office-agents/fsi-plugins)
office-agents/excel First recorded · 289 lines, first recorded
# Use Claude for Excel ## What you can do ## Get started with Claude for Excel ### Supported versions ### Install for yourself ### Deploy to your organization ### Connect through a third-party platform ## Key features ### Understand complex models ### Update values safely ### Build templates and models ### Debug errors ### Native Excel operations ## 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
The first capture of this source. The page was already there, and this is what it said.
# Use Claude for Excel
> An Excel add-in that integrates Claude into your spreadsheet workflow, for Pro, Max, Team, and Enterprise plans.
Claude for Excel is an add-in that brings Claude into Excel. Ask questions
about open workbooks, adjust assumptions while preserving formula
relationships, debug errors, and build or populate models, all without
leaving Excel.
<Note>
Claude for Excel is generally available to Pro, Max, Team,
and Enterprise plans.
</Note>
## What you can do
With Claude for Excel, you can:
* Ask questions about your workbook and get answers with cell-level
citations.
* Adjust assumptions while keeping formula relationships intact.
* Identify and resolve errors and their root causes.
* Generate new spreadsheet models or populate existing templates.
* Work across multi-tab workbooks.
* Pull external context through connectors such as S\&P Global, LSEG,
and Daloopa.
* Apply enabled Skills automatically while you work.
## Get started with Claude for Excel
### Supported versions
Claude for Excel runs on the following Excel builds.
* Excel on the web
* Excel on Windows with a Microsoft 365 subscription, build 16.0.13127.20296 or later
* Excel on Mac, version 16.46 or later, build 21011600 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 Excel, activate the add-in, and sign in with your Claude account.
</Step>
</Steps>
### Deploy to your organization
Organization admins can deploy Claude for Excel 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.
For environments where "Let users access the Office Store" is disabled,
deploy using the custom manifest XML file instead. Download the
[Excel manifest XML file](https://pivot.claude.ai/manifest-excel.xml),
then follow
[Deploy with a custom manifest](/docs/office-agents/word#deploy-with-a-custom-manifest)
for the upload steps. The flow is identical apart from which manifest
file you upload in Step 1.
### 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
### Understand complex models
Ask Claude to trace assumptions, explain formulas, or walk through how a
number was derived. Answers include cell-level citations you can click
to navigate to the referenced cell.
Example prompts:
* "Walk me through how the revenue number in cell C42 is calculated."
* "What assumptions drive the gross margin forecast?"
### Update values safely
Claude updates cell values while keeping formula relationships intact,
so downstream cells recompute correctly.
Example prompts:
* "Change the discount rate to 8% and update dependent calculations."
* "Flex the growth rate from 5% to 10% and show me the impact on terminal
value."
### Build templates and models
Populate an existing template or generate a new model from a natural
language description.
Example prompts:
* "Populate this LBO template with a \$500M purchase price and 6x
leverage."
* "Build a three-statement model from this trial balance."
### Debug errors
Locate the root cause of calculation errors and suggest fixes.
Example prompts:
* "Find the source of the #REF! error in the summary tab."
* "Trace why cell H15 is returning #DIV/0."
### Native Excel operations
Claude can sort, filter, edit pivot tables, apply conditional
formatting, and create data validation dropdowns. Ask for these
directly.
## Connectors and Skills
Claude for Excel supports connectors for pulling external context into
your workbook, 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 Excel. Instructions are useful for
formatting conventions such as "format numbers with thousand separators"
or "always bold column headers", currency or locale preferences, or
recurring context about your workflow.
Instructions you set in Excel only apply to Excel. They are separate
from Instructions you set in PowerPoint or Word.
## Work across M365 apps
Claude for Excel shares context with Claude for PowerPoint, Word, and
Outlook, so a single conversation can span your open workbook,
presentation, document, and inbox. See
[Work across M365 apps](/docs/office-agents/work-across-apps).
## Context and session management
The add-in handles long sessions and protects against accidental
overwrites for you.
* **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).
* **Overwrite protection**: Claude warns you before overwriting existing
data to avoid accidental data loss.
Your use of Claude for Excel 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 workbooks.
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 Excel 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 Excel is not recommended for:
* Final client deliverables without human review.
* Audit-critical calculations without verification.
* Models containing highly sensitive or regulated data without proper
controls.
Unsupported capabilities:
* Data tables.
* Macros and VBA operations.
### Unsupported versions
The add-in does not run on these Excel versions.
* Excel 2016 and 2019 perpetual or volume license.
* Excel on iPad. The add-in requires SharedRuntime support, which iPad
does not provide.
* Excel on Android.
* Older builds of Microsoft 365 Excel below the SharedRuntime threshold.
## Prompt injection risk
<Warning>
Only use Claude for Excel with trusted spreadsheets. 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, and data
imports can contain prompt injections that try to trick Claude into
taking unintended actions. Testing has identified scenarios where Claude for
Excel can be manipulated to extract sensitive information, modify
critical data, or perform destructive actions if allowed to act without
verification.
When Claude proposes a risky operation, you are asked to confirm before
it runs. Review confirmations carefully, especially for files from
external sources.
## Best practices
Follow these guidelines to use Claude for Excel safely and effectively.
* Always review changes before finalizing your work.
* Start with a trusted copy of the workbook before asking Claude to edit
widely.
* Be specific about what you want changed.
* Verify that outputs match your organization's standards and your own
judgment.
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
<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 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.
<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-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
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
### 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.
* **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 Word 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)
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.
third-party/claude-desktop/feature-matrix First recorded · 72 lines, first recorded
# Features ## Key differences ## User features ## Admin features
The first capture of this source. The page was already there, and this is what it said.
# Features > Feature comparison between Claude Enterprise and Claude Desktop on third-party (3P) The tables below compare the feature set of Claude Desktop on third-party (3P) to Claude Enterprise. ## Key differences **Configuration.** Claude Enterprise uses a web-based admin console. Claude Desktop on 3P is configured entirely via [MDM](/docs/third-party/claude-desktop/mdm) (Jamf, Intune, Group Policy) or a [bootstrap server](/docs/third-party/claude-desktop/bootstrap), with no Anthropic-hosted admin interface. **Telemetry.** Claude Desktop on 3P sends usage and debugging metrics only, and these can be fully disabled via managed configuration. Claude Enterprise does not offer telemetry toggles. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry). **Inference.** Claude Desktop on 3P routes all inference through the provider you configure. For Google Cloud's Agent Platform and Amazon Bedrock, data handling is governed by Google Cloud and Amazon Bedrock respectively. For Microsoft Foundry deployments hosted on Azure, prompts and completions remain within Azure; only usage metadata and content flagged by Anthropic's safety systems egress to Anthropic. Deployments hosted on Anthropic run on Anthropic's infrastructure. See the [Microsoft Foundry page](/docs/third-party/claude-desktop/foundry) for details. **Pricing.** Claude Desktop on 3P is token-based consumption billed by your cloud provider, with no seat licensing. **Features not available in 3P.** Features marked with — are absent from the UI. Users see a clean interface without error states for unavailable features. ## User features | Feature | Claude Enterprise | Claude Desktop on 3P | | --------------------------------------------------- | :---------------: | :------------------: | | Chat | ✓ | ✓ (admin opt-in) | | Cowork | ✓ | ✓ | | Code | ✓ | ✓ | | Auto mode (Code) | ✓ | ✓ (admin opt-in) | | Automatically approve / Skip all approvals (Cowork) | — ¶ | ✓ (admin opt-in) | | Projects | ✓ | ✓ | | Code execution for analysis | ✓ | ✓ | | Web search | ✓ | ✓ § | | File access, upload, and export | ✓ | ✓ | | Local MCP | ✓ | ✓ | | Remote MCP | ✓ | ✓ | | Skills, plugins, and hooks | ✓ | ✓ | | Artifacts | ✓ | ✓ | | Memory | ✓ | ✓ † | | Scheduled tasks | ✓ | ✓ | | Global languages | ✓ | ✓ | | Project and plugin sharing | ✓ | — | | Plugin marketplaces | ✓ | ✓ | | Mobile | ✓ | — | | claude.ai web-based access | ✓ | — | | Voice mode | ✓ | — | | Claude in Chrome | ✓ | — | | Claude Design | ✓ | — | | Claude Security | ✓ | — | | Claude Tag | ✓ | — | | Computer use | — | — | § Amazon Bedrock deployments (and gateways that do not forward Anthropic server tools) need a web search provider configured first; see [Web search options](/docs/third-party/claude-desktop/web-tools#web-search-options). † Memory in Claude Desktop on 3P is stored on the device, not on Anthropic infrastructure. Users can review, delete, or pause it under **Settings → Cowork → Memory**; see [Memory](/docs/third-party/claude-desktop/data-storage#memory). Chat-history search and nightly summary generation are not available in Chat on 3P. ¶ Cowork's Automatically approve and Skip all approvals modes are not available for Claude Enterprise organizations. ## Admin features | Feature | Claude Enterprise | Claude Desktop on 3P | | --------------------------------------------- | :----------------: | :------------------: | | Endpoint / gateway configuration | — | ✓ | | Skills, hooks, and plugins distribution | ✓ | ✓ | | MCP server allowlist | ✓ | ✓ | | Feature toggles (web search, local MCP, etc.) | ✓ | ✓ | | Auto-updates | ✓ | ✓ (configurable) | | Per-user spend caps | ✓ (differentiated) | ✓ (blanket only) | | Compliance API | ✓ | — ‡ | | Analytics API | ✓ | — ‡ | | OpenTelemetry export | ✓ | ✓ | | User management via UI | ✓ | — | | RBAC | ✓ | via MDM | ‡ Many of these capabilities can be achieved via OpenTelemetry export to your own collector. See [Monitoring](/docs/cowork/monitoring).
third-party/claude-desktop/foundry First recorded · 150 lines, first recorded
# Deploy Claude Desktop on 3P with Microsoft Foundry ## Choose an authentication approach ## Set up Azure ## Prepare devices ### API key ### In-app Entra ID sign-in #### Allow network egress ## 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 Microsoft Foundry
> Set up Microsoft Foundry, choose an authentication path for your organization, and configure Claude Desktop on 3P to use Claude models on Microsoft Foundry
This page walks an IT administrator through a Microsoft Foundry deployment: creating the Microsoft Foundry resource, choosing the authentication path that fits your organization, and pushing the managed configuration. If you only need the list of configuration keys, skip to [Configure the app](#configure-the-app).
<Note>
Claude models in Microsoft Foundry are available in two hosting options, Hosted on Azure and Hosted on Anthropic. Anthropic acts as an independent processor for Microsoft, and customers are subject to Anthropic's data use terms. For deployments hosted on Azure, prompts and completions remain within Azure; only usage metadata and content flagged by Anthropic's safety systems egress to Anthropic. Deployments hosted on Anthropic run on Anthropic's infrastructure. See [Claude in Microsoft Foundry](https://platform.claude.com/docs/en/build-with-claude/claude-in-microsoft-foundry#hosting-options) for details.
</Note>
## Choose an authentication approach
| Scenario | Use | Per-user identity | Notes |
| --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Proof of concept, single team | [API key](#api-key) (`inferenceFoundryApiKey`) | No (shared key) | A long-lived secret distributed in the managed profile. Simplest to start. |
| Broad rollout with per-user identity | [In-app Entra ID sign-in](#in-app-entra-id-sign-in) (`inferenceFoundryTenantId`, `inferenceFoundryClientId`, `inferenceFoundryAuthFlow`) | Yes | Users sign in with their Entra ID account inside the app, through a device code, the system browser, or the OS identity broker. The device-code flow requires app version 1.9255.0 or later; the browser flow requires app version 1.19367.0 or later. |
| Your organization already has tooling that obtains a Microsoft Foundry credential | [Credential helper](/docs/third-party/claude-desktop/configuration#inferencecredentialhelper) (`inferenceCredentialHelper`) | Depends on what the helper obtains | An executable that prints the credential to stdout at runtime. |
## Set up Azure
These steps are performed once per Azure subscription. You need permission to create resources and, for in-app sign-in, to register an application in Microsoft Entra ID.
<Steps>
<Step title="Create a Microsoft Foundry resource">
In the Azure portal, create a Microsoft Foundry resource in your subscription. Record the **resource name**; the app constructs the endpoint as `<resource-name>.services.ai.azure.com`.
</Step>
<Step title="Deploy the Claude models">
In the Microsoft Foundry portal for your resource, deploy the Claude models you intend to serve. Record each **deployment name**; you will list these in `inferenceModels`.
</Step>
<Step title="Obtain an API key (API-key approach only)">
If you chose the API-key approach, copy one of the resource's keys from the Azure portal. You will place it in the managed configuration in [Configure the app](#configure-the-app).
</Step>
<Step title="Register an Entra ID application (in-app sign-in only)">
If you chose in-app Entra ID sign-in, register an application in the [Microsoft Entra admin center](https://entra.microsoft.com) under **Identity → Applications → App registrations → New registration**. On the registration:
* Under **API permissions**, select **Add a permission**, find **Azure Cognitive Services** in the API picker, and add the **Delegated** permission **user\_impersonation** so the issued token is accepted by your Microsoft Foundry resource. (The app requests this permission as the scope `https://cognitiveservices.azure.com/.default`.) All three sign-in flows need it. After adding the permission, select **Grant admin consent**; in tenants that disable user consent, sign-in fails with error code `AADSTS65001` until consent is granted.
* Under **Authentication**, complete the setup for the sign-in flow you plan to use (see [In-app Entra ID sign-in](#in-app-entra-id-sign-in) for how the flows differ):
* For the device-code flow (the default), enable **Allow public client flows**. Entra ID rejects device-code sign-in without it.
* For the browser flow (`inferenceFoundryAuthFlow` set to `browser`), select **Add a platform → Mobile and desktop applications** and add the redirect URI `http://127.0.0.1/callback`. Use the literal address `127.0.0.1`, not `localhost`: Entra ID matches the scheme, host, and path exactly and ignores only the port. The browser flow completes sign-in without **Allow public client flows**. Conditional Access policies that block the device-code authentication flow do not apply to the browser flow.
* For the broker flow (`inferenceFoundryAuthFlow` set to `broker`), enable **Allow public client flows** and add the platform's broker redirect URI under **Mobile and desktop applications**. See [Register the Entra ID application](/docs/third-party/claude-desktop/entra-broker#register-the-entra-id-application) on the OS identity broker page for the redirect URI values and why the public-client setting is required.
Record the **Directory (tenant) ID** and **Application (client) ID**.
Grant the users or groups who will sign in a role on the Microsoft Foundry resource that permits inference (for example, **Cognitive Services User**).
</Step>
</Steps>
## Prepare devices
What each end-user device needs depends on the authentication approach you chose.
### API key
No per-device preparation is required. Place the resource's API key in the managed configuration as `inferenceFoundryApiKey`.
### In-app Entra ID sign-in
Distribute `inferenceFoundryTenantId` and `inferenceFoundryClientId` in the managed configuration. To use the browser or broker flow instead of the default device-code flow, also set `inferenceFoundryAuthFlow` to `browser` or `broker`.
The device-code and browser flows need no per-device preparation. The broker flow signs in through the operating system's native Microsoft identity broker, so each device must meet the platform requirements on the [OS identity broker](/docs/third-party/claude-desktop/entra-broker#prepare-devices) page.
When the tenant and client IDs are set and `inferenceCredentialKind` is `interactive`, the app shows a **Sign in with Microsoft** page at first launch. Clicking the button starts a sign-in against `login.microsoftonline.com`; what the user sees depends on `inferenceFoundryAuthFlow`:
* **Device code** (the key is unset or `device-code`): the app displays a short verification code and opens the Microsoft sign-in page in the default browser, where the user enters the code and approves access.
* **Browser** (the key is `browser`): the app opens the Microsoft sign-in page in the default browser, where the user signs in and approves access. The browser shows a confirmation page and the user switches back to the app; there is no code to enter.
* **Broker** (the key is `broker`): the app opens the operating system's native Microsoft account picker, where the user selects or signs in to a work account. The dialog closes and the app returns to Cowork; nothing opens in the browser. Because the broker issues the token, sign-in satisfies Conditional Access policies that require a compliant or managed device or token protection, which the other two flows cannot satisfy on their own. See [Sign in through the OS identity broker](/docs/third-party/claude-desktop/entra-broker) for what the broker is and when to choose it.
On success, the app returns to Cowork. For the device-code and browser flows the app stores the refresh token encrypted with the operating system's secure storage (Keychain on macOS, DPAPI on Windows), and both flows store the same token against the same app registration, so switching between them later does not itself prompt users to sign in again. For the broker flow the operating system's broker holds the credential, and the app stores only a reference to the signed-in account.
If the app can no longer renew the credential silently, it shows a **Sign in again** prompt; clicking it reopens the configured sign-in flow. For the device-code and browser flows this happens when the stored refresh token expires or is revoked. For the broker flow it happens when the broker can no longer renew the token silently.
`inferenceFoundryTenantId` and `inferenceFoundryClientId` can be set only via an MDM profile, not via a bootstrap server. `inferenceFoundryAuthFlow` can be set via either.
<Note>
In-app sign-in and a [bootstrap server](/docs/third-party/claude-desktop/bootstrap) are separate layers that work together. In-app sign-in supplies each user's inference credential, the Entra ID token that authorizes model calls. A bootstrap server supplies per-user configuration values when the app starts. A bootstrap server does not replace sign-in: a deployment with a bootstrap server still needs each user to sign in, and signing in does not deliver configuration.
</Note>
#### Allow network egress
The sign-in flow reaches `login.microsoftonline.com` in addition to your Microsoft Foundry endpoint. Both hosts are included automatically in the **Egress** section of the in-app configuration window when these keys are set.
## Configure the app
Open the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration#open-the-configuration-window) (**Developer → Configure Third-Party Inference…**). In the **Connection** section, set **Inference provider** to **Foundry**, then fill in the **Foundry credentials** card with the values for whichever authentication approach you chose:
| Field | API key | In-app Entra ID sign-in |
| ------------------------------ | ----------------------- | ---------------------------------------------------------------------- |
| Azure AI Foundry resource name | `your-foundry-resource` | `your-foundry-resource` |
| Azure AI Foundry API key | your resource key | *leave empty* |
| Entra ID tenant ID | *leave empty* | `00000000-0000-0000-0000-000000000000` |
| Entra ID client ID | *leave empty* | `11111111-1111-1111-1111-111111111111` |
| Entra ID sign-in flow | *leave empty* | `browser` or `broker`, or leave empty for the default device-code flow |
Under **Models**, add at least one **Model list** entry using the Microsoft Foundry deployment name.
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 `inferenceFoundry*` keys is below. Set `inferenceProvider` to `foundry`, supply the resource name, and provide exactly one credential source.
| 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>
You must also set `inferenceModels` to a list of Microsoft Foundry deployment names. See the [Configuration reference](/docs/third-party/claude-desktop/configuration#inferencemodels).
## What users experience
| Approach | First launch | Re-authentication |
| ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| API key | The app opens directly; no user action. | Never, until you rotate the key in the managed profile. |
| In-app Entra ID sign-in, device-code flow | The app shows a **Sign in with Microsoft** page; the user approves a device code in the browser, and the app returns to Cowork. | When the stored refresh token expires or is revoked under your tenant's policy. The app prompts in-app. |
| In-app Entra ID sign-in, browser flow | The app shows a **Sign in with Microsoft** page; the user signs in through the system browser, with no code to enter, and the app returns to Cowork. | When the app can no longer renew the stored token. The app prompts in-app. |
| In-app Entra ID sign-in, broker flow | The app shows a **Sign in with Microsoft** page; the user picks or signs in to a work account in the operating system's native account picker, and the app returns to Cowork. | When the broker can no longer renew the token silently. The app prompts in-app. |
## 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).
If sign-in fails at the token step, confirm the **Azure Cognitive Services** permission is granted and consented on the app registration. For the device-code flow, also confirm **Allow public client flows** is enabled; Entra ID rejects device-code sign-in without it.
If sign-in fails with error code `AADSTS650057`, the **user\_impersonation** permission is missing from the app registration. Add it under **API permissions**.
If sign-in fails with error code `AADSTS65001`, the permission has not been consented. Select **Grant admin consent** on the **API permissions** page, or have the user accept the consent prompt if your tenant allows user consent.
If browser-flow sign-in fails in the browser with error code `AADSTS50011`, the redirect URI is missing from the app registration or does not match. Add `http://127.0.0.1/callback` under **Authentication → Mobile and desktop applications**, using the literal address `127.0.0.1`, not `localhost`.
If the browser shows the confirmation page but in-app sign-in still fails, with error code `AADSTS7000218` in the application logs, the redirect URI is registered under the **Web** platform. Move it under **Mobile and desktop applications**.
For broker-flow sign-in failures (error codes `AADSTS50011`, `AADSTS900971`, `AADSTS7000218`, or a message that the OS identity broker is unavailable), see [Troubleshoot](/docs/third-party/claude-desktop/entra-broker#troubleshoot) on the OS identity broker page. To unblock a device that cannot meet the broker requirements, set `inferenceFoundryAuthFlow` to `browser` for that device instead.
Each sign-in attempt has a time limit: five minutes for the device-code and broker flows and two minutes for the browser flow. If the user does not finish within the limit, the attempt fails and the user can click **Sign in with Microsoft** to start again.
third-party/claude-desktop/gateway First recorded · 302 lines, first recorded
# Deploy Claude Desktop on 3P with an LLM gateway ## Choose an authentication approach ## Prepare devices ### Static API key ### Single sign-on with your identity provider #### Set up single sign-on #### Using Okta instead #### Map users at the gateway #### Refresh tokens and session lifetime ## Configure the app ### Configuration keys ### Single sign-on configuration keys ### Models ### MCP tool search ## Troubleshoot
The first capture of this source. The page was already there, and this is what it said.
# Deploy Claude Desktop on 3P with an LLM gateway
> Configure Claude Desktop on 3P to use Claude models on a self-hosted gateway that implements the Anthropic Messages API
To use a self-hosted LLM gateway (for example LiteLLM, Portkey, or an in-house proxy) as the inference provider, set `inferenceProvider` to `gateway` and supply the base URL and credentials described below.
The gateway must implement the Anthropic [Messages API](https://docs.claude.com/en/api/messages):
* `POST /v1/messages` with [streaming](https://docs.claude.com/en/api/streaming) and [tool use](https://docs.claude.com/en/docs/tool-use) is required.
* `GET /v1/models` is optional. If the gateway implements it, Claude Desktop on 3P auto-discovers available models; if not, set `inferenceModels` explicitly.
## Choose an authentication approach
| Scenario | Use | Notes |
| -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Proof of concept, or your gateway already issues per-team keys | [Static API key](#static-api-key) (`inferenceGatewayApiKey`) | A long-lived secret distributed in the managed profile. |
| Per-user attribution and identity-provider enforcement (MFA, conditional access) | [Single sign-on](#single-sign-on-with-your-identity-provider) (`inferenceGatewayOidc`) | Each user signs in with their own work account. Requires app version 1.6889.0 or later. |
| Your organization already has tooling that obtains a gateway credential | [Credential helper](/docs/third-party/claude-desktop/configuration#inferencecredentialhelper) (`inferenceCredentialHelper`) | An executable that prints the gateway credential to stdout at runtime. |
## Prepare devices
### Static API key
No per-device preparation is required. Generate an API key in your gateway and place it in the managed configuration as `inferenceGatewayApiKey` (see [Configure the app](#configure-the-app)).
### Single sign-on with your identity provider
Instead of distributing a shared gateway API key, you can have each user sign in with their own work account. The first time a user opens Claude Desktop, the app opens their browser to your organization's normal sign-in page (Microsoft Entra ID, Okta, or any OpenID Connect provider). After they sign in, the app sends a per-user token to your gateway on every request, and your gateway checks that token to confirm who the user is.
This gives you per-user attribution in your gateway logs, lets your identity provider enforce MFA and conditional access, and means there is no long-lived credential to distribute or rotate.
You need three things in place:
* An LLM gateway that can validate JSON Web Tokens (LiteLLM, Kong, Envoy, and Azure API Management all support this)
* Admin access to your identity provider to register a new application
* A way to push managed configuration to user devices (your existing MDM)
The walkthrough below uses Microsoft Entra ID. An Okta variant follows.
#### Set up single sign-on
<Steps>
<Step title="Register an application in Entra ID">
In the [Microsoft Entra admin center](https://entra.microsoft.com), go to **Identity → Applications → App registrations** and select **New registration**. Give it a name such as `Claude Desktop gateway`, choose **Accounts in this organizational directory only**, and select **Register**.
On the overview page, copy the **Application (client) ID** and **Directory (tenant) ID**. You will use both in the next two steps.
Open the **Authentication** blade, select **Add a platform**, and choose **Mobile and desktop applications**. Under **Custom redirect URIs**, add exactly:
```text theme={null}
http://127.0.0.1/callback
```
A few details that matter here: use `127.0.0.1` (not `localhost`), include the `/callback` path, and add it under the **Mobile and desktop applications** platform specifically. That platform is the only one Entra allows to use any local port, which the app needs because it picks a free port at sign-in time. You do not need a client secret or any additional API permissions.
</Step>
<Step title="Configure your gateway to validate the token">
Tell your gateway to accept the bearer token only if it was issued by your tenant **for this application**. In LiteLLM that looks like:
```yaml theme={null}
general_settings:
litellm_jwtauth:
public_key_url: https://login.microsoftonline.com/YOUR_TENANT_ID/discovery/v2.0/keys
audience: YOUR_CLIENT_ID
user_id_jwt_field: oid
```
Replace `YOUR_TENANT_ID` and `YOUR_CLIENT_ID` with the values from step 1.
<Warning>
The `audience` line is required. Without it, your gateway accepts tokens issued to any application in your tenant, not just this one.
</Warning>
For Kong, Envoy, or Azure API Management, configure the equivalent JWT validation policy with the same JWKS URL and audience.
</Step>
<Step title="Configure in the app">
Open the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration#open-the-configuration-window) (**Developer → Configure Third-Party Inference…**). In the **Connection** section, set **Inference provider** to **Gateway** and **Credential kind** to **Interactive sign-in**. This hides the API-key field and reveals **Gateway SSO IdP (OIDC)**:
| Field | Value |
| -------------------------------------- | ------------------------------------------------------- |
| Gateway base URL | `https://llm-gateway.example.corp` |
| Credential kind | **Interactive sign-in** |
| Gateway SSO IdP (OIDC) → Client ID | `YOUR_CLIENT_ID` |
| Gateway SSO IdP (OIDC) → Issuer URL | `https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0` |
| Gateway SSO IdP (OIDC) → Scopes | *leave empty for the default* |
| Gateway SSO IdP (OIDC) → Redirect port | *leave empty* |
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.
When a user next opens Claude Desktop, they see a **Sign in to your organization** button. Clicking it opens their browser to your Entra sign-in page; once they approve, they return to the app and can start working. The app keeps them signed in and refreshes the token in the background. If the session is revoked or expires under your tenant's policy, the app shows a **Sign in again** prompt; clicking it reopens the sign-in page in the browser.
</Step>
</Steps>
#### Using Okta instead
In the Okta Admin Console, create a **Native** application with the **Authorization Code** and **Refresh Token** grant types. Okta requires the redirect URI to match exactly, including the port, so pick a fixed port (for example `53180`), register `http://127.0.0.1:53180/callback`, and set that same port in **Gateway SSO IdP (OIDC)**:
| Field | Value |
| ------------- | ----------------------------- |
| Client ID | `YOUR_CLIENT_ID` |
| Issuer URL | `https://YOUR_ORG.okta.com` |
| Scopes | *leave empty for the default* |
| Redirect port | `53180` |
<Note>
Use the **issuer** value, not the **Metadata URI**. Okta's admin console shows the metadata URI (ending in `/.well-known/openid-configuration`) prominently — that is the discovery document the app fetches *from* the issuer, not the issuer itself. If you are unsure, open the metadata URI in a browser and copy the `"issuer"` field from the JSON response. For a custom Okta authorization server the issuer is `https://YOUR_ORG.okta.com/oauth2/AUTH_SERVER_ID`.
</Note>
Point your gateway's JWT validation at `https://YOUR_ORG.okta.com/oauth2/v1/keys` with `audience` set to the Okta client ID.
#### Map users at the gateway
Claude Desktop forwards the identity provider's token to your gateway verbatim — it does not add, remove, or rewrite any claims. With the default scopes (`openid profile email offline_access`), the ID token your gateway receives contains the standard OIDC `sub`, `email`, and `name` claims, plus whatever your provider includes for the `profile` scope. You can confirm exactly what is present by base64-decoding the middle segment of the `Authorization: Bearer` value your gateway receives.
Key the gateway's user record on the provider's immutable user ID rather than email, so the record survives email or name changes:
| Provider | Stable user-ID claim |
| ---------------------------------- | -------------------- |
| Entra ID | `oid` |
| Okta and most other OIDC providers | `sub` |
If your gateway has no existing user records to preserve, the simplest setup is to auto-provision on first sign-in. For LiteLLM, extend the validation block from step 2:
```yaml theme={null}
general_settings:
enable_jwt_auth: true
litellm_jwtauth:
public_key_url: https://YOUR_ORG.okta.com/oauth2/v1/keys
audience: YOUR_CLIENT_ID
user_id_jwt_field: sub # use "oid" for Entra ID
user_email_jwt_field: email
user_id_upsert: true
```
If you need additional claims (for example, a `groups` claim for team-level budgets), add them on your identity provider's authorization server — they pass through to the gateway unchanged. To request a non-default scope, set `scopes` in `inferenceGatewayOidc` (see [Single sign-on configuration keys](#single-sign-on-configuration-keys)).
#### Refresh tokens and session lifetime
Silent token refresh requires a refresh token from your identity provider, which in turn requires the `offline_access` scope on the authorization request. Whether Claude Desktop sends that scope depends on how you set `scopes` and `bearerTokenType`:
* **`scopes` left unset** — the default (`openid profile email offline_access`) includes `offline_access`, so a refresh token is issued.
* **`bearerTokenType: "access_token"`** — Claude Desktop automatically appends `offline_access` to whatever `scopes` value you supply, unless `appendOfflineAccess` is set to `false`.
* **`bearerTokenType: "id_token"` (the default) with `scopes` set explicitly** — Claude Desktop does **not** add `offline_access` for you. Include it in your `scopes` value if you want silent refresh; without it, users are prompted to sign in again each time the ID token expires (commonly about one hour).
Per [OpenID Connect Core 1.0 §11](https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess), requesting `offline_access` signals that the client may use the refresh token while the user is not present, and the provider must obtain consent for it. Claude Desktop therefore does not add this scope to an administrator-supplied `scopes` value in the default mode, so that requesting offline access remains an explicit choice.
**Authorization servers that reject `offline_access`.** Standard OIDC providers (Entra ID, Okta, Auth0) accept `offline_access` and require it to issue a refresh token, so the automatic append is what you want. If your authorization server instead rejects unrecognized scopes with an `invalid_scope` error — for example, servers that issue refresh tokens via a provider-specific scope rather than `offline_access` — set `appendOfflineAccess` to `false` and include your provider's own refresh-token scope in `scopes` directly.
Refresh tokens govern whether users are re-prompted to sign in, not how long a sign-in may stay valid. To cap the sign-in lifetime under your identity provider's session policy, set [`inferenceSessionLifetimeSec`](/docs/third-party/claude-desktop/configuration#inferencesessionlifetimesec); Claude Desktop shows a re-authenticate banner before the session expires.
## Configure the app
Open the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration#open-the-configuration-window) (**Developer → Configure Third-Party Inference…**). In the **Connection** section, set **Inference provider** to **Gateway**, then fill in the **Gateway credentials** card:
| Field | Value |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Gateway base URL | `https://llm-gateway.example.corp` |
| Gateway API key | your gateway key (or a placeholder if your gateway has none) |
| Credential kind | **Static API key** (default), or **Interactive sign-in** for [single sign-on](#single-sign-on-with-your-identity-provider) |
| Gateway auth scheme | **Bearer** (default) or **x-api-key** |
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
| 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>
To send additional HTTP headers on every inference request (tenant routing, org IDs, and similar), set [`inferenceCustomHeaders`](/docs/third-party/claude-desktop/configuration#inferencecustomheaders). It applies to all providers, not just gateways.
### Single sign-on configuration keys
Single sign-on is enabled by setting `inferenceCredentialKind` to `interactive` **and** supplying `inferenceGatewayOidc`. Both are required — `interactive` alone (without `inferenceGatewayOidc`) selects a different mode where the gateway itself acts as the authorization server.
| Setting | MDM key | Required | Description |
| ---------------------- | ------------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Credential kind | `inferenceCredentialKind` | Yes — must be `interactive` | Selects sign-in instead of an API key. |
| Gateway SSO IdP (OIDC) | `inferenceGatewayOidc` | Yes | A **single JSON object** describing the identity provider (fields below). The resulting token is sent to the gateway as the bearer credential. |
The `inferenceGatewayOidc` value is one JSON object with these fields:
| Field | Required | Description |
| --------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `clientId` | Yes | Application (client) ID registered with the identity provider. |
| `issuer` | Yes\* | OIDC issuer URL — the base URL only, **without** `/.well-known/openid-configuration`. The app appends that path itself to discover the authorization and token endpoints. |
| `authorizationUrl` | No\* | Explicit OIDC authorization endpoint. Use together with `tokenUrl` instead of `issuer` when the identity provider does not serve `/.well-known/openid-configuration`. Ignored when `issuer` is set. |
| `tokenUrl` | No\* | Explicit OIDC token endpoint. Must be set together with `authorizationUrl`. Ignored when `issuer` is set. |
| `scopes` | No | Space-separated OIDC scopes. Defaults to `openid profile email offline_access`. Required when `bearerTokenType` is `access_token`. See [Refresh tokens and session lifetime](#refresh-tokens-and-session-lifetime) for how this field interacts with silent refresh. |
| `redirectPort` | No | Fixed local port for the loopback redirect. Leave unset to let the app choose an ephemeral port (Entra). Set when the provider requires an exact port match (Okta). |
| `bearerTokenType` | No | Which token the app sends to the gateway as the `Authorization: Bearer` value. `id_token` (the default) sends the OIDC ID token — the gateway validates it offline against the provider's JWKS with `aud` equal to the client ID. `access_token` sends the OAuth access token instead — use this for gateways that validate as an OAuth resource server rather than validating the ID token directly. When set to `access_token`, `scopes` is required. |
| `appendOfflineAccess` | No | Whether to automatically append `offline_access` to `scopes` in `access_token` mode. Defaults to `true`. Set to `false` only if your authorization server rejects `offline_access` as an unrecognized scope. See [Refresh tokens and session lifetime](#refresh-tokens-and-session-lifetime). |
\* Either `issuer`, or both `authorizationUrl` and `tokenUrl`, is required.
<Warning>
`inferenceGatewayOidc` is **one MDM key whose value is a JSON string** — not separate keys like `inferenceGatewayOidc.clientId`. See [how object-typed keys are encoded](/docs/third-party/claude-desktop/configuration#value-types). The in-app **Export** produces the correct format automatically.
</Warning>
In a macOS `.mobileconfig` payload (Okta example):
```xml theme={null}
<key>inferenceCredentialKind</key>
<string>interactive</string>
<key>inferenceGatewayOidc</key>
<string>{"issuer":"https://YOUR_ORG.okta.com","clientId":"YOUR_CLIENT_ID","redirectPort":53180}</string>
```
Earlier app versions used `inferenceGatewayAuthScheme: "sso"` to select this mode. That value is deprecated; set `inferenceCredentialKind: "interactive"` instead. Existing deployments that still send `inferenceGatewayAuthScheme: "sso"` continue to work.
### Models
When `inferenceModels` is unset, Claude Desktop on 3P populates the model picker from your gateway's `GET /v1/models` response. Auto-discovery shows only models whose IDs are recognizably Claude; if your gateway advertises models under opaque aliases, set `inferenceModels` explicitly. Set [`inferenceModels`](/docs/third-party/claude-desktop/configuration#models) to override discovery with an explicit list — the picker will show exactly the entries you provide. Use the model IDs your gateway expects (for example `bedrock/us.anthropic.claude-opus-5` for a LiteLLM-style routing prefix).
If your gateway serves a Claude model under an opaque routing alias, it can mark the model as Claude by returning an `anthropic_family_tier` field (a Claude tier name such as `sonnet` or `opus`) on that model object in its `/v1/models` response, optionally with `is_family_default: true` when several models map to the same tier. Models marked this way pass the auto-discovery filter.
If your gateway does not implement `GET /v1/models`, give every `inferenceModels` entry the full model ID your gateway accepts; bare tier aliases such as `sonnet` rely on discovery to resolve. When every entry is a full model ID, the app skips the `/v1/models` call automatically. A list that contains a bare alias keeps discovery on, so for a gateway without the endpoint, replace the alias with the full model ID; a bare alias cannot be resolved without discovery. On earlier app versions that do not skip the call automatically, also set [`modelDiscoveryEnabled`](/docs/third-party/claude-desktop/configuration#modeldiscoveryenabled) to `false` to avoid the discovery attempt. The cost of leaving discovery on without the endpoint depends on how the gateway fails: an error response makes the app fall back to the `inferenceModels` list immediately, while an endpoint that accepts the request and hangs delays the model list by up to 10 seconds at launch.
If your deployment supports the 1M-token context window for a model, set `supports1m: true` on that model's entry:
```json theme={null}
[{"name": "bedrock/us.anthropic.claude-opus-5", "supports1m": true}]
```
The model picker then shows a second entry for the model, described as **1M context window**; the standard entry has no context-size label, and the default selection is unchanged. `supports1m` is an assertion about your gateway rather than something the app can verify: if the gateway does not accept 1M-token requests for that model, requests made from the 1M picker entry fail at inference time. Only set it on models you have confirmed against your deployment. The [Models section of the configuration reference](/docs/third-party/claude-desktop/configuration#models) documents the remaining entry fields, including display labels and tier mapping.
### MCP tool search
[MCP tool search](https://code.claude.com/docs/en/mcp#scale-with-mcp-tool-search) loads MCP tool schemas on demand instead of inlining every schema into the context window. It reduces context pressure when many MCP tools are configured (sessions that otherwise compact every turn or two). Claude Desktop on 3P turns it off by default, along with Claude Code's other experimental beta features, because strict gateways reject the experimental `anthropic-beta` request headers and request fields those features add. This suppression takes precedence over the `ENABLE_TOOL_SEARCH` environment variable, so setting that variable has no effect on Claude Desktop sessions. The variable applies only to terminal Claude Code running outside Claude Desktop.
To turn tool search on for Claude Desktop, set the [`toolSearchEnabled`](/docs/third-party/claude-desktop/configuration#toolsearchenabled) configuration key. Requires app version 1.21459.0 or later.
<Warning>
Setting `toolSearchEnabled` causes sessions to send experimental `anthropic-beta` request headers, and the beta request fields that ride with them, to your gateway. Enable it only if your gateway forwards and accepts those headers and fields; when it does not, requests fail with HTTP 400. LiteLLM in passthrough mode and Cloudflare AI Gateway both forward `anthropic-beta` headers and `tool_reference` content blocks. As a preflight, run terminal Claude Code through the same gateway with `ENABLE_TOOL_SEARCH=true`: Claude Desktop sends the same request surface, so if the terminal works, Claude Desktop will too. Enabling the key also re-enables Claude Code's other experimental beta features for these sessions. Do not enable it on [Vertex](/docs/third-party/claude-desktop/vertex) deployments: Vertex rejects the tool-search beta header.
</Warning>
## Troubleshoot
**`gateway SSO: server does not advertise device_authorization_endpoint`** — The app could not read your `inferenceGatewayOidc` value, so it fell back to treating the gateway itself as the sign-in server. Almost always this means the value is not a valid JSON string (for example, separate dotted keys, or a plist `<dict>` instead of a `<string>`). Re-export from the in-app configuration window, or copy the `.mobileconfig` snippet above.
**`OIDC discovery failed (HTTP 404)` or `(HTTP 405)`** — The `issuer` value is not the issuer base URL. Most often the metadata URI (ending in `/.well-known/openid-configuration`) was pasted instead, which doubles the path. Remove that suffix so `issuer` is just `https://YOUR_ORG.okta.com` (or the equivalent for your provider).
**`no credential configured for provider "gateway": set inferenceCredentialKind or one of the credential fields`** — `inferenceCredentialKind: "interactive"` is not present in the pushed configuration.
**Browser shows "Connected" but the app reports the sign-in failed, or `Token exchange failed (HTTP 401)`** — The browser step succeeded, but the identity provider rejected the follow-up token request. This usually means the IdP application is registered as a confidential (Web) client, which expects a client secret. Claude is a public PKCE client and doesn't send one. Register a public/native client instead: **Native Application** in Okta, or the **Mobile and desktop applications** platform in Entra ID. Application type generally can't be changed after creation, so you may need to create a new one.
<Note>
Google Workspace can be used as the identity provider, but in the default `id_token` mode Google does not issue a fresh ID token on background refresh, so users are prompted to sign in again roughly once an hour. Setting `bearerTokenType` to `access_token` avoids this. Entra ID and Okta are not affected in either mode.
</Note>
**Model picker is empty or missing models.** Auto-discovery filters out model IDs that are not recognizably Claude, so models your gateway serves under opaque aliases appear only if the gateway marks them with `anthropic_family_tier` in its `/v1/models` response or you list them in `inferenceModels` (see [Models](#models)). When `/v1/models` is unreachable or returns an error, the picker falls back to the `inferenceModels` list; if that list is empty, so is the picker.
Cut at 300 lines. The page has the rest.
third-party/claude-desktop/in-app-configuration First recorded · 34 lines, first recorded
# In-app configuration ## Open the configuration window ## Apply locally or export for a fleet
The first capture of this source. The page was already there, and this is what it said.
# In-app configuration > Build, test, and export a Claude Desktop on 3P configuration from inside the app, with validation and per-provider guidance The in-app configuration window is the recommended way to configure Claude Desktop for third-party inference. It validates values as you enter them, shows exactly which fields your inference provider requires, tests the connection against your endpoint, and computes the network egress allowlist for your settings, so you don't have to hand-edit JSON, plists, or registry keys. ## Open the configuration window From the macOS menu bar (or on Windows, the application menu ☰ in the top-left of the sign-in screen), go to **Help → Troubleshooting → Enable Developer Mode**, then **Developer → Configure Third-Party Inference…**. <Frame caption="The in-app configuration window, showing the Connection section for a gateway provider."> <img src="https://mintcdn.com/claude-ai/kVj7_7KF4fI3bEAn/images/third-party/in-app-configuration-window.png?fit=max&auto=format&n=kVj7_7KF4fI3bEAn&q=85&s=c3f15a85dea85082bc6dbc9459e6a974" alt="Claude Desktop in-app configuration window with the sidebar of setting groups on the left and the Connection form on the right." width="1812" height="1462" data-path="images/third-party/in-app-configuration-window.png" /> </Frame> The sidebar groups settings the same way the [configuration reference](/docs/third-party/claude-desktop/configuration) does. Fill in **Connection** first, then work down through the sections your deployment needs. ## Apply locally or export for a fleet Use **Apply locally** to write the configuration to this device only and relaunch into it. This is the [single-machine setup](/docs/third-party/claude-desktop/installation#single-machine-setup) path for evaluation and pilots. Use the **Export** menu to generate deployment artifacts for a fleet: | Export option | Use with | | --------------------------- | --------------------------------------------------------------------------------------------------- | | `.mobileconfig` profile | Jamf or any macOS MDM | | `.reg` policy file | Intune, Group Policy, or any Windows MDM | | ADMX template (`.zip`) | Intune or Group Policy; a schema-only template, you enter values in the management console | | Profile Manifest (`.plist`) | Jamf, ProfileCreator, or similar macOS tools; a schema-only template, you enter values in your tool | | Bootstrap JSON | The response body for a [bootstrap server](/docs/third-party/claude-desktop/bootstrap) | | Egress allowlist | Your firewall or network team | See [Deploy with MDM](/docs/third-party/claude-desktop/mdm) or [Deploy with a bootstrap server](/docs/third-party/claude-desktop/bootstrap) to distribute what you exported. When a managed profile is already present on the device, the window opens in read-only mode and shows the deployed values. Author new configurations from a device without a managed profile.
third-party/claude-desktop/installation First recorded · 162 lines, first recorded
# Installation and setup ## System requirements ## Check device readiness ## Install the app ## Choose a configuration delivery model ## Single-machine setup ## Verifying the deployment ## Troubleshooting ## Endpoint security software ## Offline installation ## Updates
The first capture of this source. The page was already there, and this is what it said.
# Installation and setup > Install Claude Desktop on 3P, check device readiness, and choose how configuration reaches your devices: an MDM profile or a bootstrap server Claude Desktop on third-party (3P) is the standard Claude Desktop application plus a managed configuration that activates third-party inference mode. Setup is two pieces: install the regular Claude Desktop app, and deliver the configuration to it. ## System requirements Cowork, the agent workspace at the center of Claude Desktop on 3P, has the following device requirements: | Requirement | macOS | Windows | | ---------------- | ---------------------------- | -------------------------------------------------------------------- | | Operating system | macOS 14 (Sonoma) or later | Windows 10 build 19041 (version 2004) or later, including Windows 11 | | CPU architecture | Apple silicon or Intel (x64) | x64 or Arm64 | | Installer | `.dmg` | `.msix` | On Windows, Cowork requires the `.msix` package: fleets provisioned with the legacy `.exe` installer get Claude Desktop without Cowork, and migrating them to `.msix` enables it. Cowork also requires working hardware virtualization, which the [readiness check](#check-device-readiness) verifies along with the requirements above. ## Check device readiness Before installing Claude Desktop, you can confirm that a device supports Cowork by running the readiness check: a small standalone program that requires no installation or sign-in. | Platform | Download | | ------------- | ---------------------------------------------------------------------------------------------------------------------------- | | macOS | [Cowork readiness check for macOS](https://claude.ai/api/desktop/darwin/universal/cowork-readiness-check/latest/redirect) | | Windows (Arm) | [Cowork readiness check for Windows arm64](https://claude.ai/api/desktop/win32/arm64/cowork-readiness-check/latest/redirect) | | Windows (x64) | [Cowork readiness check for Windows x64](https://claude.ai/api/desktop/win32/x64/cowork-readiness-check/latest/redirect) | Open the downloaded program to run the check. A ready device reports **This computer is ready for Cowork**. For fleet deployments, run the check on one device of each hardware model in your fleet before the broad rollout to identify unsupported models early. ## Install the app Download the installer for your platform from [claude.com/download](https://claude.com/download). | Platform | Installer | Notes | | -------- | --------- | ----------------------------------------------------------- | | macOS | `.dmg` | Drag **Claude.app** to Applications | | Windows | `.msix` | Supports per-machine provisioning for enterprise deployment | For fleet rollouts, distribute the installer through your standard software-distribution mechanism after the configuration reaches devices; [Choose a configuration delivery model](#choose-a-configuration-delivery-model) covers how the configuration gets there. ## Choose a configuration delivery model Configuration reaches devices in one of two ways. Both typically use your MDM tooling to push a profile; the difference is what the profile contains. | | MDM profile | Bootstrap server | | -------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | What you deploy to devices | The full configuration, exported as a `.mobileconfig` or `.reg` profile | A minimal profile containing only the bootstrap keys (`bootstrapUrl`, optionally `bootstrapOidc`) | | Where settings live | In the profile, identical for every device the profile targets | On an HTTPS endpoint you operate, which returns each user's configuration at sign-in | | Per-user values | Separate profiles per device group | The server keys its response to the signed-in user | | Changing settings | Export and push an updated profile | Change your server's response; devices pick it up at the next fetch, with no profile push | Choose an MDM profile when one configuration, or a few group-scoped profiles, covers your fleet. Most MDMs support role-based distribution, so per-group configuration doesn't require a bootstrap server. Building the configuration in the app is optional. The [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration) can also export schema-only templates (an ADMX template for Windows, a Profile Manifest `.plist` for macOS) from its **Export** menu, so you can enter values directly in your management console instead. See [Export the profile](/docs/third-party/claude-desktop/mdm#2-export-the-profile) for all formats. Choose a bootstrap server when your organization doesn't use MDM, or when per-user credentials or frequently changing settings would make per-group profiles unwieldy. The tradeoff is that you operate the endpoint. The two models don't combine: when a bootstrap response is in effect, it replaces MDM-delivered values wholesale, and a few device-level keys are only available via MDM (see the Availability column in the [configuration reference](/docs/third-party/claude-desktop/configuration)). Pick your path: * [Deploy with MDM](/docs/third-party/claude-desktop/mdm) covers authoring the configuration in the app, exporting the profile, and deploying it to your fleet. * [Deploy with a bootstrap server](/docs/third-party/claude-desktop/bootstrap) covers getting the bootstrap keys onto devices and running the server. On either path, deploy the configuration before the app so users open Claude for the first time and land directly in the third-party deployment. ## Single-machine setup For evaluating before a fleet rollout, for pilots, or for organizations that don't use MDM, a single machine can be configured directly in the app. 1. Install Claude Desktop from [claude.com/download](https://claude.com/download). 2. Launch the app. **Do not sign in or create an Anthropic account.** From the macOS menu bar (or on Windows, the application menu ☰ in the top-left of the login screen), go to **Help → Troubleshooting → Enable Developer Mode**, then **Developer → Configure Third-Party Inference…** to open the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration). 3. Enter the provider, endpoint, and credential values supplied by your administrator. 4. Click **Apply locally**. The app relaunches and the sign-in screen now offers the option to start in Claude Desktop on 3P using the configuration you entered. The configuration is written to the application's local config file and applies only to that device and user account. It can be edited from the same window at any time. To return to standard Claude Desktop, choose the Anthropic sign-in option on the sign-in screen instead. If your organization runs a [bootstrap server](/docs/third-party/claude-desktop/bootstrap) but doesn't use MDM, your administrator can instead supply a small configuration file containing only the bootstrap keys. Load it with **Import configuration** in the same window; the bootstrap server supplies everything else after you sign in. When the configuration works on a single machine, roll it out to the fleet with the [delivery model you chose](#choose-a-configuration-delivery-model); on the MDM path, you can export the tested configuration as the profile you deploy. ## Verifying the deployment On any configured device, open Claude Desktop and go to **Help → Troubleshooting → Copy Managed Configuration Report**. This copies a summary showing which keys were detected, where they were read from (managed profile vs. user store), and whether the inference credentials validated successfully. Secret values are redacted. Also confirm that the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration) (**Developer → Configure Third-Party Inference…**) opens read-only on a managed device. The app reads managed keys from the profile by name and silently ignores a misspelled key rather than reporting an error. On macOS, a window that is still editable means no recognized key reached the app, even if your MDM shows the profile as delivered. On Windows, even a misspelled value under `HKLM\SOFTWARE\Policies\Claude` counts as machine policy and locks the window, so use the Managed Configuration Report to see which keys were actually read. If your profile deliberately sets [only the update keys](/docs/third-party/claude-desktop/mdm#update-keys-and-managed-precedence), an editable window is expected. If the app shows the standard claude.ai sign-in screen instead of Cowork, the configuration was not read. Common causes: * `inferenceProvider` is missing, misspelled, or set to an unrecognized value * The configuration was applied while the app was running (fully quit and relaunch) * The configuration was written to the local config file but you're checking the managed location (or vice versa) * A required key for the chosen provider is missing; check **Help → Troubleshooting** or the application log at `~/Library/Logs/Claude-3p/main.log` (macOS) / `%LOCALAPPDATA%\Claude-3p\Logs\main.log` (Windows) * On Windows (v1.19367.0 and later), the configuration is in `HKCU\SOFTWARE\Policies\Claude` but machine policy is also present: any `REG_SZ`, `REG_EXPAND_SZ`, or `REG_DWORD` value directly under `HKLM\SOFTWARE\Policies\Claude` causes the app to ignore user policy entirely. The Managed Configuration Report (**Help → Troubleshooting → Copy Managed Configuration Report**) shows which source the app read. A `REG_EXPAND_SZ` value shows as present in `reg query` output while the app reports the managed configuration as invalid or absent, because the app counts the value as machine policy but cannot read its contents ## Troubleshooting If installation or setup fails, generate a diagnostic report before requesting support: on the affected machine, go to **Help → Troubleshooting → Generate Diagnostic Report**, choose a save location, and send the resulting folder to your Anthropic representative. The report contains the configuration state, application logs, and environment details needed to investigate. It does not include user data or conversation content. ## Endpoint security software If your organization runs binary-authorization or EDR software (such as [Santa](https://santa.dev), CrowdStrike Falcon, or Microsoft Defender ASR) with path-based deny rules, the Cowork agent helper may be blocked from launching. The symptom is that Claude Desktop opens normally and reads the managed configuration, but Cowork sessions fail to start. The agent helper is a signed binary that Claude Desktop installs under its user-data directory. **Allowlist by signing identity rather than path** so the rule survives version updates. **macOS** ``` ~/Library/Application Support/Claude-3p/claude-code/<version>/claude.app/Contents/MacOS/claude ``` The helper is Developer ID signed and notarized: * Team ID: `Q6L2SF6YDW` (Anthropic PBC) * Signing ID: `com.anthropic.claude-code` For Santa, a `TEAMID` allow rule for `Q6L2SF6YDW` covers the helper across version updates. Standard (non-3P) installs use `~/Library/Application Support/Claude/` with the same subpath. **Windows** ``` %LOCALAPPDATA%\Claude-3p\claude-code\<version>\claude.exe ``` The helper is Authenticode-signed with publisher `Anthropic, PBC`. For Defender ASR or AppLocker, allowlist by publisher rather than path. Standard installs use `%APPDATA%\Claude\` with the same subpath. ## Offline installation Standard installs fetch two large runtime components from `downloads.claude.ai` at session start: the VM workspace bundle that Cowork sessions run in, and the Claude CLI binary. For networks that cannot reach `downloads.claude.ai`, Anthropic publishes an offline installer variant with both components built into the installer package and verified against checksums compiled into the application, so sessions can start without any connection to Anthropic. The offline installers are several gigabytes larger than the standard ones. Each supported platform and architecture has a fixed download URL that serves the current offline installer: | Platform | Format | Download URL | | --------------------- | ------- | -------------------------------------------------------------------- | | Windows (x64) | `.msix` | `https://claude.ai/api/desktop/win32/x64/offline/latest/redirect` | | Windows (Arm) | `.msix` | `https://claude.ai/api/desktop/win32/arm64/offline/latest/redirect` | | macOS (Apple silicon) | `.dmg` | `https://claude.ai/api/desktop/darwin/arm64/offline/latest/redirect` | | macOS (Intel) | `.dmg` | `https://claude.ai/api/desktop/darwin/x64/offline/latest/redirect` | Each URL responds with an HTTP redirect to a versioned installer file, so any HTTP client that follows redirects downloads the installer directly. New versions of Claude Desktop roll out to connected devices gradually; these URLs serve the newest version whose rollout has completed. The redirect's `Location` header contains the version number, so tooling can detect a new version by requesting the URL without following the redirect. If the offline installer for the version the URL serves is not yet available, the download fails with HTTP 404 rather than falling back to an older installer; this can happen just after a new version appears in the `Location` header. Keep the installer you last downloaded and retry later. Download the installer from a connected machine and bring it across your boundary with your usual software-distribution process. Pair the offline installer with [`disableAutoUpdates`](/docs/third-party/claude-desktop/configuration#disableautoupdates): the app cannot reach the update feed from an air-gapped network, and you update the fleet by distributing each new offline installer through your MDM. Aside from updates, the only egress an air-gapped deployment needs is your inference provider; see [Telemetry and egress](/docs/third-party/claude-desktop/telemetry#required-egress-paths). ## Updates By default, Claude Desktop downloads updates from Anthropic's update server automatically and applies them the next time the app restarts. If the app hasn't restarted within 72 hours of downloading an update, it restarts itself, waiting for 10 minutes of user inactivity before doing so. This enforcement is always on and offers no in-app prompt to defer the restart; the `autoUpdaterEnforcementHours` key tunes the 72-hour window rather than enabling it. In 3P deployments you can: * **Leave auto-update enabled** (recommended) so fixes reach users without IT intervention. Set `autoUpdaterEnforcementHours` to shorten the enforcement window (1 to 72 hours; values above 72 are rejected). Setting the key also makes the window strict: the restart fires as soon as the window elapses, without waiting for a pause in user activity. * **Disable auto-update** (`disableAutoUpdates`) and redistribute new builds through your MDM on your own cadence. This is required for [air-gapped environments](#offline-installation) but means your IT team owns the update pipeline. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) for the network paths the updater uses.
third-party/claude-desktop/legal First recorded · 43 lines, first recorded
# Legal and compliance ## Legal agreements ### License ### Commercial agreements ## Compliance ## Usage policy ## Privacy and telemetry ## Security and trust ### Security vulnerability reporting
The first capture of this source. The page was already there, and this is what it said.
# Legal and compliance > Legal agreements, compliance, and security information for Claude Desktop on 3P ## Legal agreements ### License Your use of the Claude Desktop application, including in Claude Desktop on third-party (3P) mode, is subject to Anthropic's [Commercial Terms of Service](https://www.anthropic.com/legal/commercial-terms). ### Commercial agreements Claude Desktop on 3P routes model inference through the provider you configure (Google Cloud's Agent Platform, Amazon Bedrock, Microsoft Foundry, a compatible gateway, or the Anthropic API directly). Inference usage is billed by, and subject to your agreement with, that provider. When you configure the Anthropic API as your provider, inference billing and data terms fall under your Anthropic agreement. Your existing commercial agreement with Anthropic continues to apply to your use of the Claude Desktop application, unless we've mutually agreed otherwise. ## Compliance When using Google Cloud's Agent Platform or Amazon Bedrock, conversation content is sent only to your configured inference endpoint and stored on the local device; data handling is governed by [Google Cloud](https://cloud.google.com/vertex-ai/generative-ai/docs/data-governance) and [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html) respectively, and the compliance posture of your deployment is determined by your inference provider and the device environment you control. When using Microsoft Foundry, Anthropic acts as an independent processor for Microsoft and customers are subject to Anthropic's data use terms; for deployments hosted on Azure, prompts and completions remain within Azure; only usage metadata and content flagged by Anthropic's safety systems egress to Anthropic. See the [Overview](/docs/third-party/claude-desktop/overview) for the architecture and the provider-specific data path. For Anthropic's certifications and compliance reports, see the [Anthropic Trust Center](https://trust.anthropic.com). For HIPAA, see [HIPAA](/docs/third-party/claude-desktop/overview#hipaa) on the Overview page. When using Google Cloud's Agent Platform or Amazon Bedrock, Anthropic does not interact with PHI; the BAA relationship is between you and your cloud service provider, and any remote MCP servers you connect should be reviewed for HIPAA compliance. ## Usage policy Use of Claude models, including via Claude Desktop on 3P, is subject to the [Anthropic Usage Policy](https://www.anthropic.com/legal/aup). ## Privacy and telemetry The Claude Desktop application sends operational telemetry (crash reports and product analytics) to Anthropic by default. This telemetry contains no prompt or response content and can be fully disabled via managed configuration. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) for what each category contains and how to disable it. Anthropic's [Privacy Policy](https://www.anthropic.com/legal/privacy) describes how Anthropic handles data it receives. ## Security and trust Security architecture, threat-model, and data-flow documentation for Claude Desktop and Claude Desktop on 3P is available on the [Anthropic Trust Center](https://trust.anthropic.com). ### Security vulnerability reporting Anthropic manages our security program through HackerOne. [Use this form to report vulnerabilities](https://hackerone.com/4f1f16ba-10d3-4d09-9ecc-c721aad90f24/embedded_submissions/new). *** © Anthropic PBC. All rights reserved. Use is subject to applicable Anthropic Terms of Service.
third-party/claude-desktop/local-access First recorded · 46 lines, first recorded
# Desktop and filesystem access ## Workspace folder allowlist ## Network drives on Windows ## WSL
The first capture of this source. The page was already there, and this is what it said.
# Desktop and filesystem access > How Claude Desktop on 3P reads and writes files on the user's machine, and how to constrain it Like [Cowork](/docs/cowork/overview) in standard Claude Desktop, Claude Desktop on third-party (3P) works directly with files on the user's computer. Users attach one or more **workspace folders** to a session; the agent can then read, create, and modify files anywhere inside those folders, and run code against them inside the sandbox VM. In Claude Desktop on 3P, administrators can constrain which folders users are allowed to attach. ## Workspace folder allowlist The `allowedWorkspaceFolders` configuration key restricts which paths users may attach as workspace folders. | Value | Behavior | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Unset | Unrestricted. Users can attach any folder they have OS-level access to, matching standard Claude Desktop. | | `["~/Documents/Claude", "/Volumes/Shared/Projects"]` | Users may attach only folders **inside** one of the listed roots. | | `[]` | No folders may be attached. The agent can still create files in its own sandbox scratch space, but cannot read or write the user's filesystem. | A leading `~` expands to the user's home directory, so a single profile can express per-user roots like `~/Documents/Claude` across the fleet. The check is enforced against the **resolved** path, so symlinks and `..` traversal can't be used to escape an allowed root. <Note> The allowlist controls what users can **attach**. Within an attached folder, the agent has full read/write access to every file the user's OS account can reach. To isolate sensitive data, keep it outside the allowed roots. </Note> ## Network drives on Windows Users can attach a mapped network drive (for example, `Z:\`) as a workspace folder through the folder picker. Raw UNC paths (`\\server\share`) are not supported; map the share to a drive letter first. What the agent can do on the network drive depends on whether the drive was mapped and reachable when the sandbox started: * **Mapped and reachable at sandbox start:** the sandbox mounts the attached folder alongside local folders. File tools and shell commands both work. * **Mapped later, or unreachable at sandbox start:** file tools still work, but shell commands cannot reach the drive. Copy the relevant files to a local folder before running a script or build against them. The sandbox can stay running between sessions. A drive the user maps while the sandbox is already up falls into the second case until the sandbox next restarts. The agent cannot attach a network-drive path on its own; only the user can, through the folder picker. This is a security boundary. On macOS, network mounts under `/Volumes/` are currently treated as local folders. ## WSL You do not need Windows Subsystem for Linux (WSL) to run Claude Desktop or Cowork. On Windows, Cowork's sandbox runs on the operating system's built-in virtualization, which the [readiness check](/docs/third-party/claude-desktop/installation#check-device-readiness) verifies. Install the macOS or Windows package (see [System requirements](/docs/third-party/claude-desktop/installation#system-requirements)); there is no installation path inside WSL. Run the Windows app and work with WSL files from there. Windows exposes a WSL distribution's filesystem as a UNC path (`\\wsl$\<distro>` or `\\wsl.localhost\<distro>`). Like any other raw UNC path, these cannot be attached as workspace folders directly. To attach files that live inside WSL as a workspace folder, map the share to a drive letter and attach the mapped drive, or copy the files to a local Windows folder. [Network drives on Windows](#network-drives-on-windows) describes what the agent can do on a mapped drive.
third-party/claude-desktop/mantle First recorded · 76 lines, first recorded
# Deploy Claude Desktop on 3P with Amazon Bedrock Mantle ## Choose an authentication approach ## Set up AWS ## Prepare devices ### Bearer token ## 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 Mantle
> Configure Claude Desktop on 3P to use Claude models through Amazon Bedrock Mantle's Anthropic-native API surface
Amazon Bedrock Mantle is Amazon Bedrock's Anthropic-native API surface. Unlike the standard [Amazon Bedrock provider](/docs/third-party/claude-desktop/bedrock), Mantle speaks the Anthropic Messages API directly and authenticates with a bearer token rather than the AWS SigV4 credential chain, so no AWS CLI, named profile, or IAM Identity Center setup is needed on the device. In practice, Mantle is the Amazon Bedrock provider with a different runtime endpoint and a single bearer-token credential path.
## Choose an authentication approach
Mantle supports a bearer token only. There is no in-app AWS sign-in or named-profile support for this provider; if you need per-user IAM Identity Center authentication, use the standard [Amazon Bedrock provider](/docs/third-party/claude-desktop/bedrock) instead.
| Scenario | Use | Notes |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| Any Mantle deployment | [Bearer token](#bearer-token) (`inferenceBedrockBearerToken`) | A long-lived token distributed in the managed profile. |
| Token must not be stored statically | [Credential helper](/docs/third-party/claude-desktop/configuration#inferencecredentialhelper) (`inferenceCredentialHelper`) | An executable that prints the bearer token to stdout at runtime. |
## Set up AWS
Enable Claude models in Amazon Bedrock for the region you will set as `inferenceBedrockRegion`, and obtain a Mantle bearer token for that account. See [Set up AWS](/docs/third-party/claude-desktop/bedrock#set-up-aws) on the Amazon Bedrock page for the model-access step; the IAM Identity Center steps there are not needed for Mantle.
## Prepare devices
### Bearer token
No per-device preparation is required. Place the Mantle bearer token in the managed configuration as `inferenceBedrockBearerToken`.
The app reaches `bedrock-mantle.<region>.api.aws` (or the host in `inferenceBedrockBaseUrl` if you set one). This host is included automatically in the **Egress** section of the in-app configuration window. The `.api.aws` zone has no FIPS endpoint variant.
## Configure the app
Open the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration#open-the-configuration-window) (**Developer → Configure Third-Party Inference…**). In the **Connection** section, set **Inference provider** to **Bedrock Mantle**, then fill in the credentials card:
| Field | Value |
| ---------------- | ------------------------ |
| AWS region | e.g. `us-east-1` |
| AWS bearer token | your Mantle bearer token |
| Bedrock base URL | *optional* |
If you set **Bedrock base URL**, provide the full SDK base URL including the `/anthropic` path (for example `https://bedrock-mantle.us-east-1.api.aws/anthropic`); it replaces the default `bedrock-mantle.<region>.api.aws/anthropic` endpoint.
Under **Models**, add at least one **Model list** entry. Mantle has no model-list endpoint, so model discovery is not available and `inferenceModels` is required.
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
Mantle reuses the `inferenceBedrock*` key names. Only `inferenceBedrockRegion`, `inferenceBedrockBearerToken`, and `inferenceBedrockBaseUrl` apply; the other keys below (`inferenceBedrockProfile`, `inferenceBedrockSso*`, `inferenceBedrockAwsDir`, `inferenceBedrockAwsCliPath`, `inferenceBedrockServiceTier`) are ignored for this provider.
| 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>
You must also set `inferenceModels`. As with the standard Amazon Bedrock provider, server-side Web Search is not supported. See the [Configuration reference](/docs/third-party/claude-desktop/configuration#inferencemodels).
## What users experience
The app opens directly on first launch with no user action. Users are never prompted to sign in; re-authentication happens only when you rotate the bearer token in the managed profile.
## 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/mdm First recorded · 150 lines, first recorded
# Deploy with MDM ## Recommended rollout ## 1. Build a configuration in the app ## 2. Export the profile ### Creating profiles for multiple user groups ## 3. Allow required network egress ## 4. Deploy the configuration ### Update keys and managed precedence ## 5. Distribute the app ## 6. Deploy organization plugins (optional) ## Next steps
The first capture of this source. The page was already there, and this is what it said.
# Deploy with MDM
> Author a full configuration in the app, export it as a profile, and deploy it fleet-wide with Jamf, Intune, Group Policy, or any MDM
On the MDM delivery model, the profile you deploy carries your organization's full configuration, and every device the profile targets gets the same settings. This page covers the workflow end to end: build the configuration in the app, export it, open the firewall, and deploy the profile and installer to your fleet.
Before you start, install Claude Desktop on an admin workstation; see [Installation and setup](/docs/third-party/claude-desktop/installation). If you deliver configuration from a [bootstrap server](/docs/third-party/claude-desktop/bootstrap) instead, follow that page; your profile then carries only the bootstrap keys, but it is exported and deployed the same way described here.
## Recommended rollout
Roll out in this order; the numbered sections on this page cover each step in detail.
<Steps>
<Step title="Build a configuration in the app">
An admin builds and tests a working configuration in the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration) on their own device.
</Step>
<Step title="Export the profile">
Export the validated configuration in the format your MDM expects.
</Step>
<Step title="Allow required network egress">
Open the hostnames your configuration requires on your perimeter firewall; the configuration window lists them for the exact settings you chose.
</Step>
<Step title="Deploy the configuration, then the app">
Distribute the profile through your MDM, then push the installer. Deploying the configuration first means users open Claude for the first time and land directly in the third-party deployment, with no opportunity to sign in to claude.ai by mistake.
</Step>
</Steps>
## 1. Build a configuration in the app
Launch Claude Desktop. **Do not sign in or create an Anthropic account**; stay on the login screen. From the macOS menu bar (or on Windows, the application menu ☰ in the top-left of the login screen), go to **Help → Troubleshooting → Enable Developer Mode**, then **Developer → Configure Third-Party Inference…** to open the configuration window.
The window is organized into sections in the left sidebar. Work through them in order; each maps to a group of [configuration keys](/docs/third-party/claude-desktop/configuration), and the window validates values as you enter them.
| Section | What you set |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Connection** | Inference provider (Gateway, Anthropic API, Google Cloud's Agent Platform, Bedrock, or Foundry) and its credentials<br />Model list<br />Organization UUID<br />Optional credential-helper script |
| **Workspace** | Which of Cowork, Code, and Chat are available<br />Allowed egress hosts for the sandbox<br />Disabled built-in tools<br />Allowed workspace folders |
| **Connectors** | Managed MCP servers pushed to all users<br />Whether users can add their own local MCP servers<br />Whether desktop extensions (`.mcpb`) are allowed<br />Whether the extension directory is shown<br />Whether unsigned extensions are rejected |
| **Telemetry & updates** | OpenTelemetry collector endpoint<br />Whether auto-updates are blocked, and the enforcement window if not<br />The three Anthropic-bound telemetry toggles (essential, nonessential, nonessential services) |
| **Limits** | Per-device token cap and its window length |
| **Appearance** | Persistent banner shown across the app window |
| **Plugins** | [Plugin marketplaces](/docs/third-party/claude-desktop/extensions#plugin-marketplaces-admin), added by GitHub repo or git URL<br />Shows the org-plugins folder path for your platform; plugin bundles are mounted to that folder via your MDM, not through this window |
| **Egress** | A read-only firewall allowlist derived from everything you've entered above, grouped by feature<br />**Copy hostnames**, **Download .txt**, and **Test connectivity** actions |
| **Source** | The bootstrap keys, if you are using the [bootstrap server](/docs/third-party/claude-desktop/bootstrap) delivery model instead of a full MDM profile<br />Bootstrap-delivered configuration takes priority over MDM-delivered values: it replaces them wholesale rather than merging key by key |
<Note>
When a managed (MDM-delivered) configuration is already present on the device, the configuration window opens read-only: it shows what the admin deployed, marks the configuration as organization-managed, and directs users to their IT administrator. To author a new configuration, use a device without a managed profile, or temporarily remove the profile. Profiles that set [only the two update keys](#update-keys-and-managed-precedence) leave the window editable.
</Note>
## 2. Export the profile
Once your configuration tests successfully, click **Export** and choose a format:
| Format | Platform | Deploy with |
| --------------------------- | -------- | --------------------------------------------------------------------------------------------------------------- |
| `.mobileconfig` | macOS | Jamf, Kandji, Mosyle, Workspace ONE, or any Apple MDM |
| `.reg` | Windows | Group Policy (import into a GPO), Intune (via custom ADMX or script), or any MDM that can write registry policy |
| `.zip` (ADMX template) | Windows | Schema-only template for Intune or Group Policy; you enter values in the management console |
| `.plist` (Profile Manifest) | macOS | Schema-only template for Jamf, ProfileCreator, or similar macOS tools |
The two actions in the configuration window do different things:
* **Apply locally** writes the selected configuration to your own machine's Claude settings and relaunches the app, so you can test it end to end before deploying it.
* **Export** writes a deployment file in the format you choose and leaves your local settings untouched.
### Creating profiles for multiple user groups
Many organizations deploy distinct configurations to different populations: for example, a permissive profile for an engineering pilot group and a restricted profile for the broader rollout, or per-region profiles that point at different inference endpoints.
The configuration window can hold multiple named configurations. Use the picker in the top-right of the window:
* **New configuration** creates an empty configuration.
* **Duplicate** copies the current configuration as a starting point for a variant.
* **Rename** and **Delete** manage the list.
* **Reveal in Finder** opens the on-disk location where saved configurations are stored.
Selecting a configuration in the picker loads it for editing; the **applied** badge marks the one currently active on your machine. **Apply locally** and **Export** each act on whichever configuration is selected, so you can test each one locally and export them independently.
In your MDM, scope each exported profile to the corresponding device or user group. Targeting is handled by your MDM's assignment rules; the configuration name is for your authoring workflow and is not part of the deployed profile.
<Note>
On Windows, check which registry hive your assignment rules write to. If your assignment rules deliver a profile in user context, it lands in user policy (`HKCU`), and the app ignores user policy entirely when machine policy is present; see [Deploy the configuration](#4-deploy-the-configuration). To vary configuration per user group on Windows, deliver every profile through user policy and keep `HKLM\SOFTWARE\Policies\Claude` empty, or serve per-user configuration from a [bootstrap server](/docs/third-party/claude-desktop/bootstrap).
</Note>
## 3. Allow required network egress
The hosts the app needs to reach depend on the configuration you built: your inference provider's endpoint is always required, and each telemetry, update, and service setting you leave enabled adds its own hosts. The configuration window shows the exact allowlist for your settings and can export it as a text file for your network team.
<Warning>
`downloads.claude.ai` is required to run the app regardless of your configuration: it serves the VM workspace bundle and the latest Claude Code binary, fetched at session start. Without it, Cowork sessions cannot start. The [offline installer variant](/docs/third-party/claude-desktop/installation#offline-installation) builds both components into the installer package and does not need this host.
</Warning>
Open these hosts on your perimeter firewall before rolling out to devices. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry#required-egress-paths) for the full list of hosts grouped by the setting that controls each one, and for the distinction between the perimeter firewall and the in-app sandbox allowlist.
## 4. Deploy the configuration
Push the exported configuration through your MDM. The app reads from these locations:
<Tabs>
<Tab title="macOS">
| Source | Path | Precedence |
| ------------------ | -------------------------------------------------------------------------- | ---------- |
| Managed (per-user) | `/Library/Managed Preferences/<user>/com.anthropic.claudefordesktop.plist` | Highest |
| Managed (machine) | `/Library/Managed Preferences/com.anthropic.claudefordesktop.plist` | |
| Local (user) | `~/Library/Application Support/Claude-3p/configLibrary/` | Lowest |
A `.mobileconfig` profile delivered by MDM lands in the Managed Preferences locations automatically. Both managed paths are read; where a key appears in both, the per-user value wins.
</Tab>
<Tab title="Windows">
| Source | Path | Precedence |
| -------------- | ----------------------------------------- | ---------- |
| Machine policy | `HKLM\SOFTWARE\Policies\Claude` | Highest |
| User policy | `HKCU\SOFTWARE\Policies\Claude` | |
| Local (user) | `%LOCALAPPDATA%\Claude-3p\configLibrary\` | Lowest |
A Group Policy Object or Intune configuration profile writes to the registry policy paths. The hives are not merged: when machine policy is present (any `REG_SZ`, `REG_EXPAND_SZ`, or `REG_DWORD` value directly under `HKLM\SOFTWARE\Policies\Claude`, including an empty string, and the key's unnamed default value when set), the app ignores `HKCU\SOFTWARE\Policies\Claude` entirely. Deploy the complete configuration to one hive; machine policy (`HKLM`) is the recommended location.
<Warning>
Values must sit directly under `HKLM\SOFTWARE\Policies\Claude` or `HKCU\SOFTWARE\Policies\Claude`. The app never reads values nested in a subkey, as some ADMX-based and Policy CSP tooling writes them: they do not apply as configuration and do not count as machine policy being present. Write values as `REG_SZ` (`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 as machine policy being present but cannot read its contents, so a single `REG_EXPAND_SZ` value under `HKLM` disables user policy without supplying any configuration. The app cannot see `REG_QWORD`, `REG_MULTI_SZ`, or `REG_BINARY` values at all.
</Warning>
<Note>
In releases before v1.19367.0, the app read both hives and merged them key by key, with the `HKLM` value winning where a key appeared in both. Fleets that split keys across both hives must consolidate the full configuration into one hive before updating to v1.19367.0 or later.
</Note>
</Tab>
</Tabs>
When a managed source sets any key other than the two update keys, the managed configuration owns the device: it takes effect, the in-app configuration window becomes read-only, and locally authored values in `configLibrary/` are ignored.
### Update keys and managed precedence
The update keys `disableAutoUpdates` and `autoUpdaterEnforcementHours` are treated specially, so you can set an update policy from MDM without managing the whole configuration. When a managed source sets only these keys (one or both), the device keeps its locally authored configuration and the configuration window stays editable. The update keys themselves are still enforced as a pair: both are resolved from the managed source alone, so a locally set value for either key is ignored even if the profile only sets the other one.
If the managed profile sets any other recognized key, the normal rule above applies and the whole configuration is managed.
## 5. Distribute the app
Deploy the Claude Desktop installer to enrolled devices using your standard software-distribution mechanism. On launch, the app reads the managed configuration, detects the configured inference provider and credentials, and the sign-in screen offers users the option to start in Claude Desktop on 3P.
## 6. Deploy organization plugins (optional)
If you're distributing [organization plugins](/docs/third-party/claude-desktop/extensions#organization-plugins-admin), push the plugin bundles to the org-plugins directory on each device alongside the configuration profile. Plugins are picked up at the next app launch.
## Next steps
After deployment, confirm devices picked up the configuration with the checks in [Verifying the deployment](/docs/third-party/claude-desktop/installation#verifying-the-deployment).
third-party/claude-desktop/overview First recorded · 85 lines, first recorded
# Overview ## Who it's for ## Architecture ### Security posture ## Data residency and international deployment ## Public sector and highly regulated environments ## HIPAA ## Next steps
The first capture of this source. The page was already there, and this is what it said.
# Overview
> Run Claude Desktop against your own cloud inference provider
Claude Desktop on third-party (3P) is a deployment mode of Claude Desktop that routes all model inference through a provider you configure: Google Cloud's Agent Platform, Amazon Bedrock, Microsoft Foundry, any compatible gateway you operate, or the Anthropic API directly. The app runs from a bundled local web application, and conversation history is stored on the user's device.
You get the full Claude Desktop experience (Chat, Cowork, and Code, including file creation, multi-step research, and sub-agent coordination) with inference and billing handled by the provider you choose.
## Who it's for
Claude Desktop on 3P is designed for organizations whose security, regulatory, or contractual requirements prevent them from sending data to Anthropic's first-party infrastructure. Typical deployments include:
* **Highly regulated enterprises on 3P only:** organizations that use third-party inference for regulatory or security reasons
* **International enterprises with data residency requirements:** organizations that require in-region data residency and cannot send conversation data to the United States
If your organization can use Anthropic's first-party products directly, standard Claude Desktop with [Cowork](/docs/cowork/overview) on a Team or Enterprise plan is simpler to deploy, offers an in-app UI for user management, analytics, and RBAC, and releases new features more quickly than Claude Desktop on 3P. Choose Claude Desktop on 3P when routing inference through Anthropic's API is not an option.
## Architecture
Claude Desktop on 3P keeps the standard feature set and relocates inference to the provider you configure.
| Component | Standard Claude Desktop | Claude Desktop on 3P |
| ---------------------- | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Model inference | Anthropic API | Your configured provider endpoint (Google Cloud's Agent Platform, Amazon Bedrock, Microsoft Foundry, or gateway), or the Anthropic API |
| Web application | Loaded from claude.ai | Bundled inside the desktop app |
| User identity | Anthropic account | Local device identity only |
| Conversation storage | Anthropic backend | Local disk on the user's machine |
| Code execution sandbox | Local VM | Local VM (identical) |
| Configuration | Admin console at claude.ai | OS-native configuration (MDM-managed or per-user) |
The desktop app detects 3P mode at launch from the configured inference provider. When a provider and its credentials are present, the sign-in screen offers the option to skip Anthropic authentication and start the app using your inference-provider configuration instead.
### Security posture
* **Conversation content goes only to your configured endpoint.** Prompts, responses, files, and tool outputs are sent only to your configured inference endpoint and stored only on the local machine; data handling at the provider is governed by your inference provider. For Microsoft Foundry deployments hosted on Azure, prompts and completions remain within Azure; only usage metadata and content flagged by Anthropic's safety systems egress to Anthropic.
* **Sandboxed tool execution.** Shell commands run in the hardened Cowork VM; file access is scoped to your allowed folders and web fetches to your egress allowlist.
* **Auditable telemetry.** Crash reports and product analytics are scrubbed of conversation and user data before being sent to Anthropic, and can be fully disabled via configuration keys. Independently, you can export session activity to your own OpenTelemetry collector. The export is metadata only by default, with prompt and tool content available as an explicit opt-in.
* **Centrally managed.** All configuration is delivered via your existing MDM (Jamf, Intune, Workspace ONE, Group Policy) and cannot be overridden by end users when an admin profile is present.
For a detailed treatment of the threat model, sandbox boundaries, and data flows, request access to the [Claude Cowork Desktop Security Architecture Overview](https://trust.anthropic.com/resources?s=2a7bbzo1lyymvdt551q7kl\&name=claude-cowork-desktop-security-architecture-overview) on Anthropic's Trust Center. For architecture, telemetry, and controls information specific to Claude Desktop on 3P, see the [Claude Desktop Security Overview (Third-party platforms)](https://trust.anthropic.com/resources?s=0c8rx4s7mm5ierz8ppetfs\&name=claude-cowork-security-overview-\(third-party-platforms\)) on the Trust Center.
## Data residency and international deployment
**Google Cloud's Agent Platform and Amazon Bedrock:** Inference requests go directly from the user's machine to the regional endpoint you configure. Conversation data goes only to that endpoint, to local disk, and optionally to your configured OpenTelemetry collector. Residency is determined by:
1. The cloud region you select for inference
2. The physical location of the user's device, where conversations are persisted
For multi-region organizations, deploy distinct MDM configuration profiles per geography so each user population points at an in-region endpoint. Google Cloud's Agent Platform and Amazon Bedrock each offer Claude models in the EU, UK, and Asia/Pacific regions; consult your provider's model-availability documentation for the current list.
## Public sector and highly regulated environments
This section applies when using Google Cloud's Agent Platform or Amazon Bedrock.
Because inference runs in your cloud tenant, Claude Desktop on 3P operates inside whatever compliance boundary your provider and region give you. The desktop application itself contacts Anthropic-operated hosts only to download the VM workspace bundle and Claude CLI binary (always required), and for crash reporting, product analytics, non-essential services (connector favicons, artifact previews, and the MCP registry), and auto-updates. Each of the latter four can be disabled independently via managed configuration.
With Anthropic-bound telemetry, non-essential services, and updates all disabled, the only remaining Anthropic-operated egress is `downloads.claude.ai` for the VM bundle at session start. Beyond that, the compliance posture of your deployment is determined by your inference provider. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) for the full set of network paths and how to lock them down.
## HIPAA
This section applies when using Google Cloud's Agent Platform or Amazon Bedrock.
Claude Desktop on 3P does not process user data, prompts, or completions. As such, Anthropic does not interact with PHI the user may upload to Claude Desktop on 3P; that data is transmitted only to the customer's cloud service provider or any remote MCP servers they optionally choose to configure. For a HIPAA-compliant solution, customers should ensure they have a BAA in place with their CSP and review any MCP servers for HIPAA compliance before connecting them to Claude Desktop on 3P.
Disabling telemetry is not required to run Claude Desktop on 3P in a HIPAA-compliant way, since Anthropic's telemetry does not collect user data, prompts, or completions, only redacted crash reporting and aggregated usage metrics that do not reveal sensitive data.
## Next steps
<Columns cols={2}>
<Card title="Installation and setup" icon="download" href="/docs/third-party/claude-desktop/installation">
Roll out Claude Desktop on 3P to your organization with MDM, or configure a single machine for evaluation.
</Card>
<Card title="Configuration reference" icon="sliders" href="/docs/third-party/claude-desktop/configuration">
Every managed-configuration key, what it does, and recommended security profiles.
</Card>
<Card title="Extensions" icon="puzzle-piece" href="/docs/third-party/claude-desktop/extensions">
Deploy MCP servers, plugins, skills, and hooks across your fleet.
</Card>
<Card title="Telemetry and egress" icon="shield-halved" href="/docs/third-party/claude-desktop/telemetry">
What the app sends to Anthropic, how to turn it off, and the firewall allowlist you'll need.
</Card>
</Columns>
third-party/claude-desktop/telemetry First recorded · 254 lines, first recorded
# Telemetry and egress ## Telemetry categories ### Essential telemetry ### Non-essential telemetry ### Non-essential services ### Auto-updates ## Sending telemetry to your own collector ### Collector endpoint and headers ### User attribution ### Exporter protocol ### Content capture ### Traces (beta) ## Required egress paths ### Always required ### Inference provider ### Auto-updates (`disableAutoUpdates: false`) ### Essential telemetry (`disableEssentialTelemetry: false`) ### Non-essential telemetry (`disableNonessentialTelemetry: false`) ### Non-essential services (`disableNonessentialServices: false`) ### Optional features ## Disabling all Anthropic-bound connections ## Proxy support ### TLS-intercepting proxies on macOS
The first capture of this source. The page was already there, and this is what it said.
# Telemetry and egress
> What Claude Desktop on 3P sends to Anthropic, how to disable it, and the network paths your firewall needs to allow
When Claude Desktop on third-party (3P) is configured with Google Cloud's Agent Platform, Amazon Bedrock, or Microsoft Foundry, the app sends conversation content only to your configured inference endpoint. For Microsoft Foundry, how data is handled beyond that endpoint depends on the deployment's hosting option; see [Claude in Microsoft Foundry](/docs/third-party/claude-desktop/foundry). The app does, by default, send a small amount of operational telemetry (crash reports and product analytics) that helps Anthropic diagnose issues and improve the product. Each category can be disabled independently via managed configuration.
This page covers what each category contains, how to turn it off, and the complete set of outbound hostnames the app uses so you can configure your perimeter firewall.
## Telemetry categories
### Essential telemetry
Crash reports, error stack traces, and performance timings. Contains diagnostic metadata (app version, OS, error type, redacted stack frames) but **never prompt or response content**. Attributed to your organization via `deploymentOrganizationUuid` so Anthropic support can find issues you report.
| Setting | Default | Effect when `true` |
| --------------------------- | ------- | ----------------------------------------- |
| `disableEssentialTelemetry` | `false` | No crash or error data leaves the device. |
<Warning>
Disabling essential telemetry opts you into a **manual support model**. Anthropic will have zero remote visibility into failures on your fleet, so to get help with an issue your team will need to collect application logs from affected machines and send them to Anthropic directly. Leave this enabled during initial rollout.
</Warning>
### Non-essential telemetry
Product-usage analytics: feature adoption, session counts, UI interactions. Used to understand how Claude Desktop is used in aggregate. Contains no prompt or response content. Also gates the **Send** button in Help → Generate Diagnostic Report; with this disabled, diagnostic bundles can only be saved locally.
| Setting | Default | Effect when `true` |
| ------------------------------ | ------- | -------------------------------------- |
| `disableNonessentialTelemetry` | `false` | No product analytics leave the device. |
Leaving this enabled also adds `api.anthropic.com` to the [agent egress allowlist](#required-egress-paths) automatically, so Claude Code can deliver its usage telemetry from inside the sandbox. Allow that host at the perimeter too; it appears in the non-essential telemetry table below.
### Non-essential services
Cosmetic third-party fetches: favicons for connectors shown in the UI, the MCP connector directory lookup, the sandboxed iframe that renders interactive artifact previews, and the sandboxed iframes that render [MCP Apps](/docs/connectors/building/mcp-apps/getting-started), the interactive widgets connectors can display. Disabling these degrades the UI (generic icons, no directory suggestions, static artifact previews, and connector tool results shown as text instead of widgets) but doesn't affect functionality.
| Setting | Default | Effect when `true` |
| ----------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `disableNonessentialServices` | `false` | Favicon, artifact-preview, and MCP App widget fetches are blocked. Connectors that return MCP Apps show the tool's text result instead of the widget. |
### Auto-updates
Checks Anthropic's update feed and downloads new builds.
| Setting | Default | Effect when `true` |
| -------------------- | ------- | ----------------------------------------------------------------------------------------- |
| `disableAutoUpdates` | `false` | The app never checks for or downloads updates. Your IT team must redistribute new builds. |
## Sending telemetry to your own collector
Independently of what's sent to Anthropic, you can export session activity to your own OpenTelemetry collector by setting `otlpEndpoint`. This is the recommended way to retain an audit trail in environments that disable Anthropic-bound telemetry.
For third-party deployments, the export includes session metadata (event names, durations, token counts, result counts, errors) by default, but not message content. It also identifies the signed-in user; see [User attribution](#user-attribution). See [Monitoring](/docs/cowork/monitoring) for the event schema and the [`otlp*` keys](/docs/third-party/claude-desktop/configuration#otlpendpoint) in the configuration reference.
The export carries logs and metrics. Cowork sessions, Code sessions, and the desktop application's own events arrive under the `service.name` values `cowork`, `claude-code-desktop`, and `claude-desktop` respectively. The app adds the collector host to the sandbox egress allowlist automatically, so `otlpEndpoint` does not need an entry in `coworkEgressAllowedHosts`; your perimeter firewall still needs to allow the host.
For collector authentication headers, extra resource attributes, and the log level of the desktop application's own event stream, see [`otlpHeaders`, `otlpResourceAttributes`, and `otlpDesktopLogLevel`](/docs/third-party/claude-desktop/configuration#otlpheaders) in the configuration reference.
### Collector endpoint and headers
Set [`otlpEndpoint`](/docs/third-party/claude-desktop/configuration#otlpendpoint) to the base address of your collector's OTLP/HTTP receiver, for example `https://otel-collector.example.com:4318`. The app appends the OpenTelemetry request paths itself (`/v1/logs`, `/v1/metrics`, and `/v1/traces` when [traces](#traces-beta) are enabled), so enter the address without those suffixes. A path prefix in front of them, such as `https://observability.example.com/otlp`, is kept.
The receiver must implement the OpenTelemetry protocol (OTLP) over HTTP in both its protobuf and JSON encodings, as an OpenTelemetry Collector does by default. If your logging or SIEM platform accepts only its own HTTP ingestion format, run an OpenTelemetry Collector that receives OTLP and forwards to that platform, and set `otlpEndpoint` to the collector's address. Each device opens its own connection to the collector, so the collector must present a TLS certificate the operating system trusts. See [Proxy support](#proxy-support) if a TLS-intercepting proxy sits in between.
[`otlpHeaders`](/docs/third-party/claude-desktop/configuration#otlpheaders) is a JSON object that maps each header name to its value, for example `{"Authorization":"Bearer <token>","X-Tenant":"agency"}`. As with the other object-typed keys described under [Value types](/docs/third-party/claude-desktop/configuration#value-types), write it as a JSON string rather than a native plist dictionary or registry structure.
The app reads both keys at launch, so users must restart it after a change. If the collector refuses requests or cannot be reached, the app keeps working, shows no error, and drops the affected telemetry batches. Check the collector's own request logs to confirm data is arriving.
### User attribution
Every record sent to your collector carries the user's identity as two resource attributes, on all three `service.name` streams:
* `enduser.id` — the signed-in user's identity. With an interactive sign-in flow (for example, Workforce Identity Federation or Google sign-in on Google Cloud's Agent Platform), this is the identity from the provider's claims, normally the user's email address. With credential methods that carry no identity claims (a static key, a credential helper, or an application default credentials file), it is the operating-system login name.
* `process.owner` — the operating-system login name.
`enduser.id` is the same identity the app shows in the sidebar and account menu, and is controlled by the [`endUserAttribution`](/docs/third-party/claude-desktop/configuration#enduserattribution) key: set it to `false` to remove the identity from both the app and the export. `process.owner` is not gated by that key — it is standard OpenTelemetry process metadata and is always present. A static value set under [`otlpResourceAttributes`](/docs/third-party/claude-desktop/configuration#otlpresourceattributes) overrides either attribute: a static `enduser.id` is always passed through — taking precedence over the signed-in identity, and surviving `endUserAttribution: false` — and a static `process.owner` replaces the login name.
These attributes are attached only to the OpenTelemetry export; the Anthropic-bound telemetry described earlier on this page does not carry them.
### Exporter protocol
The `otlpProtocol` key selects the transport for the telemetry export to your collector: `http/protobuf` (the default), `http/json`, or `grpc`. The protocol applies per session type:
* [Code](/docs/third-party/claude-desktop/code) sessions export over the protocol as configured, including `grpc`.
* Cowork sessions do not support gRPC export. When `otlpProtocol` is set to `grpc`, Cowork sessions export over `http/protobuf` instead; other protocol values apply as configured.
* The desktop application's own event stream (`claude-desktop`) always exports over `http/json`, whatever `otlpProtocol` is set to.
The fallback changes the protocol only, not the endpoint. When `otlpProtocol` is `grpc`, the Cowork and desktop-application exports go to the same `otlpEndpoint` over HTTP; if that address is your collector's OTLP/gRPC receiver (conventionally port 4317), that telemetry never reaches the collector. To receive all three streams with one collector, set `otlpProtocol` to `http/protobuf` and point `otlpEndpoint` at the collector's OTLP/HTTP receiver (conventionally port 4318).
### Content capture
To include content in the export, set `otlpContentCapture` to an array of categories:
| Category | Captures |
| -------------------- | --------------------------------------------------------------- |
| `userPrompts` | User message text |
| `assistantResponses` | Model response text |
| `toolDetails` | Tool input arguments (for example, the web-search query string) |
| `toolContent` | Tool output content |
| `rawApiBodies` | Full inference request and response bodies |
On Claude Desktop version 1.17377 or later, enabling `userPrompts` also captures model responses, even if `assistantResponses` is not listed. On those versions, no `otlpContentCapture` configuration captures user prompts without model responses.
Content is exported only to your configured `otlpEndpoint`. Anthropic does not receive it.
### Traces (beta)
The export carries logs (events) and metrics; it does not include traces unless you enable them. To export OpenTelemetry traces as well, set `otlpTracesEnabled` to `true`. Cowork and Code sessions then record a trace for each user interaction, with spans for model requests and tool executions, and every event emitted during a span carries that span's `trace_id` and `span_id`. This lets your backend correlate a prompt's events end-to-end natively, with no transformation on ingest.
Traces use the same `otlpEndpoint` and `otlpProtocol` as the rest of the export, including the Cowork gRPC fallback described in [Exporter protocol](#exporter-protocol). Span and span-event content is gated by the same `otlpContentCapture` categories as events: with no categories enabled, traces carry metadata only (timing, tool names, durations, token counts). Captured content appears primarily on events; spans stay close to metadata.
Two scope notes:
* The metrics in this export don't carry trace context, so trace-based correlation covers traces and events. Correlate metrics with a session via the `session.id` attribute.
* Trace export uses Claude Code's session-tracing beta, and the span structure may change while the feature is in beta.
`otlpTracesEnabled` requires Claude Desktop **1.22209.0** or later.
## Required egress paths
Claude Desktop on 3P has **two** independent network boundaries:
1. **Perimeter firewall:** your corporate network controls what the device can reach. The hostnames below are what you allowlist here.
2. **Agent egress allowlist:** the [`coworkEgressAllowedHosts`](/docs/third-party/claude-desktop/configuration#coworkegressallowedhosts) key controls what the agent's web-fetch and shell tools can reach. This is independent of, and stricter than, the perimeter.
<Note>
The **Egress** section of the in-app configuration window is the authoritative source for your deployment. It computes the exact allowlist from your current settings, updates as you change them, and can export the list as a text file for your firewall team. Use the tables below as a static reference; defer to the configuration window for the precise set your build requires.
</Note>
All traffic is HTTPS on port 443. Allowlist by hostname (SNI); path-level rules aren't required.
### Always required
| Host | Purpose |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `downloads.claude.ai` | VM workspace bundle and Claude CLI binary, fetched at session start. **Without this, Cowork sessions cannot start**, unless the app was installed with the [offline installer variant](/docs/third-party/claude-desktop/installation#offline-installation), which includes both components in the installer package. |
### Inference provider
The host(s) for your configured provider. These carry conversation content.
<Tabs>
<Tab title="Google Cloud's Agent Platform">
| Host | Purpose |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `<region>-aiplatform.googleapis.com` | Model inference for single regions. The `global` region uses `aiplatform.googleapis.com`, and the `eu` / `us` multi-regions use `aiplatform.eu.rep.googleapis.com` / `aiplatform.us.rep.googleapis.com`. Replaced by the host of `inferenceVertexBaseUrl` if set. |
| `oauth2.googleapis.com` | Google auth token exchange |
| `sts.googleapis.com` | Google auth token exchange |
| `accounts.google.com` | Google auth token exchange |
| `iamcredentials.googleapis.com` | Google auth token exchange |
</Tab>
<Tab title="Amazon Bedrock">
| Host | Purpose |
| ------------------------------------------------------------------ | -------------------------------------------------------------------------- |
| `bedrock-runtime.<region>.amazonaws.com` | Model inference. Replaced by the host of `inferenceBedrockBaseUrl` if set. |
| `bedrock.<region>.amazonaws.com` | Control plane (model discovery) |
| `sts.amazonaws.com`, `sts.<region>.amazonaws.com` | STS token exchange (profile auth only) |
| `portal.sso.<region>.amazonaws.com`, `oidc.<region>.amazonaws.com` | AWS SSO (profile auth only) |
With `inferenceBedrockBearerToken` set, the runtime and control-plane hosts are required.
For AWS GovCloud regions (`us-gov-*`), the app automatically uses the FIPS endpoints instead: `bedrock-runtime-fips.<region>.amazonaws.com` and `bedrock-fips.<region>.amazonaws.com`.
</Tab>
<Tab title="Microsoft Foundry">
| Host | Purpose |
| ---------------------------------- | ---------------------------------------- |
| `<resource>.services.ai.azure.com` | Model inference |
| `login.microsoftonline.com` | Entra ID auth (interactive sign-in only) |
</Tab>
<Tab title="Gateway">
| Host | Purpose |
| --------------------------------- | --------------- |
| Host of `inferenceGatewayBaseUrl` | Model inference |
</Tab>
</Tabs>
### Auto-updates (`disableAutoUpdates: false`)
| Host | Purpose |
| --------------------- | ---------------------------------------- |
| `claude.ai` | Update feed |
| `api.anthropic.com` | Update feed |
| `downloads.claude.ai` | Update binaries (already required above) |
### Essential telemetry (`disableEssentialTelemetry: false`)
| Host | Purpose |
| ---------------------------------- | ----------------------------------------------------------------------------------------------- |
| `sentry.io` | Crash and error reporting (apex; some firewalls don't match it under `*.sentry.io`) |
| `*.sentry.io` | Crash and error reporting |
| `*.ingest.us.sentry.io` | Crash and error reporting (listed separately for firewalls that match wildcards one label deep) |
| `browser-intake-us5-datadoghq.com` | Performance timing. The configuration window lists additional regional Datadog intake hosts. |
### Non-essential telemetry (`disableNonessentialTelemetry: false`)
| Host | Purpose |
| --------------------- | --------------------------------------------------------------- |
| `a-cdn.anthropic.com` | Analytics SDK |
| `api.anthropic.com` | Claude Code usage telemetry, sent from inside the agent sandbox |
| `a-api.anthropic.com` | Analytics events |
| `claude.ai` | Analytics events |
### Non-essential services (`disableNonessentialServices: false`)
| Host | Purpose |
| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `api.anthropic.com` | MCP connector directory |
| `www.claudeusercontent.com` | Artifact preview iframe |
| `*.claudemcpcontent.com` | [MCP Apps](/docs/connectors/building/mcp-apps/getting-started), the interactive widgets connectors can render. Each widget loads in a sandboxed iframe on its own generated subdomain, so allowlist the wildcard. |
| `assets.claude.ai` | Fonts loaded by MCP App widget iframes |
| `cdnjs.cloudflare.com`, `cdn.jsdelivr.net`, `fonts.googleapis.com` | Artifact preview asset CDNs |
| `www.google.com`, `*.gstatic.com` | Connector favicons |
### Optional features
| Host | Required when |
| --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| Host of `otlpEndpoint` | OpenTelemetry export is configured |
| `github.com`, `objects.githubusercontent.com`, `pypi.org`, `files.pythonhosted.org` | Python-based desktop extensions are enabled |
| Hosts of each entry in `managedMcpServers` (server URL, plus `oauth.authorizationServer` and `login.microsoftonline.com` if configured) | Managed MCP servers are configured |
| Hosts in `coworkEgressAllowedHosts` | Sandbox web access is configured |
## Disabling all Anthropic-bound connections
With `disableEssentialTelemetry`, `disableNonessentialTelemetry`, `disableNonessentialServices`, and `disableAutoUpdates` all set to `true`, the desktop application makes **no outbound connections to Anthropic-operated hosts at runtime**. The only required egress is `downloads.claude.ai` (for the VM bundle at session start) and your inference provider. With the [offline installer variant](/docs/third-party/claude-desktop/installation#offline-installation), `downloads.claude.ai` is not needed either, and your inference provider is the only required egress. This describes the application's own connections; what happens to conversation content after it reaches your inference provider is governed by that provider; see the [Overview](/docs/third-party/claude-desktop/overview).
See the [Locked down profile](/docs/third-party/claude-desktop/configuration#recommended-security-profiles) for a complete configuration.
## Proxy support
The Cowork sandbox honors the host operating system's proxy configuration, including PAC (proxy auto-configuration) files. If the device routes HTTPS through a corporate proxy, the sandbox will too, with no additional configuration required.
### TLS-intercepting proxies on macOS
If your proxy performs TLS interception, it presents its own certificate authority. Claude configures its CLI processes to trust the macOS System keychain in addition to the bundled CA roots, so a corporate CA installed there normally works without extra setup.
If inference or tool requests still fail certificate verification, the CA was likely added with policy-restricted trust: certificates installed via `security add-trusted-cert -p ssl …` are trusted by Safari and Chrome but are not picked up by the CLI runtime's keychain reader. Re-add the CA with full root trust (omit `-p`):
```bash theme={null}
sudo security add-trusted-cert -d -r trustRoot \
-k /Library/Keychains/System.keychain /path/to/corp-ca.pem
```
If the certificate is MDM-managed and you cannot change how it is installed, set `NODE_EXTRA_CA_CERTS` as a fallback, then quit and relaunch Claude:
```bash theme={null}
security find-certificate -a -p /Library/Keychains/System.keychain > ~/corp-ca.pem
launchctl setenv NODE_EXTRA_CA_CERTS "$HOME/corp-ca.pem"
```
`launchctl setenv` makes the variable visible to apps launched from Finder or the Dock (shell-profile exports only reach terminal sessions). It applies until the next reboot; to make it permanent, run the command from a LaunchAgent at login.
third-party/claude-desktop/vertex First recorded · 312 lines, first recorded
# Deploy Claude Desktop on 3P with Google Cloud's Agent Platform ## Choose an authentication approach ## How the two sign-in flows compare ### Workforce Identity sign-in ### Google sign-in (OAuth) ### Side by side ## Set up Google Cloud ## Prepare devices ### Credentials file ### In-app Google sign-in #### How it works #### Create the OAuth client #### Federate to a third-party identity provider #### Notes and limitations ### In-app Workforce Identity sign-in ## 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 Google Cloud's Agent Platform
> Set up Google Cloud, choose an authentication path for your organization, and configure Claude Desktop on 3P to use Claude models on Google Cloud's Agent Platform
This page walks an IT administrator through a complete deployment on Google Cloud's Agent Platform (formerly Vertex AI): enabling Claude in your Google Cloud project, 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
Google Cloud's Agent Platform authenticates with Google Cloud Application Default Credentials, which can be supplied several ways. The right one depends on whether your users have Google identities and whether you need per-user attribution in Cloud Audit Logs.
| Scenario | Use | Per-device prerequisite | Per-user Cloud Audit Logs identity | Notes |
| --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------ | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Proof of concept, single team | [Service-account key](#credentials-file) (`inferenceVertexCredentialsFile`) | The key file on each device | No (shared service account) | A long-lived secret distributed to every device. Simplest to start; not recommended for broad rollout. |
| Users have Google Workspace or Cloud Identity accounts | [In-app Google sign-in](#in-app-google-sign-in) (`inferenceVertexOAuth*`) | None | Yes | Users sign in with their Google account inside the app. See the session-control warning below. |
| Users authenticate with a third-party IdP (Entra ID, Okta, Ping, …) and you don't want to provision Google identities | [In-app Workforce Identity sign-in](#in-app-workforce-identity-sign-in) (`inferenceVertexWorkforce*`) | None | Yes (workforce-pool principal) | Users sign in with their corporate identity inside the app. The app runs PKCE against your IdP and exchanges the ID token at Google STS. |
| Your organization already has tooling that obtains a bearer token accepted by Google Cloud's Agent Platform | [Credential helper](/docs/third-party/claude-desktop/configuration#inferencecredentialhelper) (`inferenceCredentialHelper`) | The helper executable on each device | Depends on what the helper obtains | The helper's stdout is sent as the bearer on each inference request. |
| You already operate an LLM proxy | [Gateway provider](/docs/third-party/claude-desktop/gateway) instead of Google Cloud's Agent Platform | None | At your gateway | The proxy holds the Google Cloud credentials; the app authenticates only to the proxy. |
<Warning>
If your Google Workspace or Cloud Identity organization enforces a **Google Cloud session length** of a few hours or less (Admin console → Security → Google Cloud session control), the in-app Google sign-in stores a refresh token that is subject to that policy, and users will be prompted to sign in again each time it expires. For short session policies, either mark your OAuth client as a [trusted app exempt from reauthentication](https://support.google.com/a/answer/9368756), or use a service-account key, Workforce Identity sign-in, or the gateway provider instead.
</Warning>
## How the two sign-in flows compare
The [in-app Google sign-in](#in-app-google-sign-in) and [in-app Workforce Identity sign-in](#in-app-workforce-identity-sign-in) approaches both open the system browser for a one-time consent and then renew in the background (or, for Workforce Identity, re-prompt in the browser when your IdP does not issue a refresh token). They differ in which party issues the refresh token, whether Google's Security Token Service is involved, and whether an Application Default Credentials file is written. The diagrams below show each flow end to end, and the table that follows summarizes the differences.
### Workforce Identity sign-in
Claude Desktop runs authorization code with PKCE directly against **your** IdP. The IdP's ID token is then exchanged at Google's Security Token Service for a short-lived Google Cloud access token. Google STS is stateless and never issues a refresh token, so every renewal starts at your IdP.
```mermaid theme={null}
sequenceDiagram
autonumber
participant App as Claude Desktop
participant Browser as System browser
participant IdP as Your IdP<br/>(Entra ID, Okta, Ping, ...)
participant GCP as Google Cloud<br/>(STS and Vertex AI)
App->>App: Generate PKCE verifier and challenge,<br/>listen on http://127.0.0.1:PORT/callback
App->>Browser: Open IdP /authorize<br/>(client_id, redirect_uri, code_challenge, scope)
Browser->>IdP: Authorization request
IdP-->>Browser: Sign-in page (password, PIV/CAC, MFA)
Browser->>IdP: User authenticates
IdP-->>Browser: 302 to http://127.0.0.1:PORT/callback?code=...
Browser->>App: Deliver authorization code on loopback
App->>IdP: POST /token<br/>(code, code_verifier, client_id, no client secret)
rect rgba(235, 219, 188, 0.4)
IdP-->>App: id_token (+ refresh_token if the<br/>Refresh Token grant is enabled)
Note over App,IdP: IdP-issued tokens.<br/>The refresh_token, when present, belongs to your IdP.
end
App->>GCP: POST sts.googleapis.com/v1/token<br/>(grant_type=token-exchange,<br/>subject_token=id_token, subject_token_type=...:id_token,<br/>audience=//iam.googleapis.com/.../workforcePools/POOL/providers/PROVIDER)
rect rgba(191, 219, 254, 0.4)
GCP-->>App: Google Cloud access_token<br/>(the pool's session duration, 1 hour by default,<br/>capped at the id_token's remaining lifetime, no refresh_token)
Note over App,GCP: Google-issued token. STS is stateless and never returns a refresh_token.
end
App->>GCP: Vertex AI request (Authorization: Bearer access_token)
GCP-->>App: Model response
Note over App,GCP: No ADC file is written. The IdP tokens are stored encrypted with the<br/>operating system's secure storage (Keychain on macOS, DPAPI on Windows).
alt Silent renewal (IdP issued a refresh_token)
App->>IdP: POST /token (grant_type=refresh_token)
IdP-->>App: Fresh id_token
App->>GCP: Repeat STS exchange for a fresh access_token
else No IdP refresh_token
App->>Browser: Repeat the full browser flow when the id_token expires
end
```
### Google sign-in (OAuth)
Claude Desktop runs authorization code with PKCE against **Google's** OAuth endpoints. Google issues the refresh token, and the app writes it to an `authorized_user` Application Default Credentials file that the Google Cloud client library consumes. Your corporate IdP may appear inside Google's sign-in page (if Cloud Identity is federated via SAML), but the app never talks to it directly.
```mermaid theme={null}
sequenceDiagram
autonumber
participant App as Claude Desktop
participant Browser as System browser
participant Goog as Google OAuth<br/>(accounts.google.com,<br/>oauth2.googleapis.com)
participant Vertex as Vertex AI
App->>App: Generate PKCE verifier and challenge,<br/>listen on http://127.0.0.1:PORT/callback
App->>Browser: Open accounts.google.com/o/oauth2/v2/auth<br/>(client_id, redirect_uri, code_challenge,<br/>scope=openid email cloud-platform,<br/>access_type=offline, prompt=consent)
Browser->>Goog: Authorization request
opt Cloud Identity is SAML-federated to your IdP
Goog-->>Browser: Redirect to your corporate IdP
Browser->>Goog: Return with SAML assertion
Note over Browser,Goog: Happens inside Google's page.<br/>Claude Desktop never sees this hop.
end
Goog-->>Browser: 302 to http://127.0.0.1:PORT/callback?code=...
Browser->>App: Deliver authorization code on loopback
App->>Goog: POST oauth2.googleapis.com/token<br/>(code, code_verifier, client_id, client_secret)
rect rgba(191, 219, 254, 0.4)
Goog-->>App: access_token + refresh_token
Note over App,Goog: Google-issued tokens.<br/>The refresh_token belongs to Google.
end
App->>App: Store authorized_user ADC<br/>{client_id, client_secret, refresh_token}<br/>encrypted with the operating system's secure storage<br/>(Keychain on macOS, DPAPI on Windows)
Note over App,Vertex: At each session start
App->>App: Write the ADC JSON to a per-session file,<br/>set GOOGLE_APPLICATION_CREDENTIALS
App->>Goog: google-auth-library reads ADC and<br/>POSTs oauth2.googleapis.com/token (grant_type=refresh_token)
Goog-->>App: Fresh access_token
App->>Vertex: Vertex AI request (Authorization: Bearer access_token)
Vertex-->>App: Model response
Note over App,Vertex: Silent renewal: google-auth-library refreshes against Google using the ADC file.<br/>Your corporate IdP is not contacted on renewal.
```
### Side by side
| | Workforce Identity sign-in | Google sign-in (OAuth) |
| ------------------------------------------ | ------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
| OAuth peer the app talks to | Your IdP's OIDC endpoints | Google's OAuth 2.0 endpoints |
| Where your corporate IdP appears | Directly (the app opens it) | Inside Google's sign-in page, via Cloud Identity SAML federation (optional) |
| Refresh token issued by | Your IdP (when the Refresh Token grant is enabled on the client) | Google |
| Google STS (`sts.googleapis.com`) involved | Yes, on every access-token renewal | No |
| ADC file written | No | Yes (`authorized_user` JSON, pointed to by `GOOGLE_APPLICATION_CREDENTIALS`) |
| Registered on the Google side | Workforce pool and OIDC provider (IAM & Admin) | Desktop-app OAuth 2.0 client (APIs & Services → Credentials) |
| Per-user prerequisite | An account at your IdP | A Google Workspace or Cloud Identity account |
| Client registered at your IdP | Public (native) OAuth client, PKCE required, loopback redirect URI | None (your IdP is federated to Cloud Identity, not to the app) |
## Set up Google Cloud
These steps are performed once per Google Cloud project, regardless of which authentication approach you chose. You need a project with Owner or Editor access.
<Steps>
<Step title="Enable the Vertex AI API">
In the [Google Cloud console](https://console.cloud.google.com/apis/library/aiplatform.googleapis.com), enable the **Vertex AI API** for your project.
</Step>
<Step title="Enable Claude models in Model Garden">
In the [Model Garden](https://console.cloud.google.com/vertex-ai/model-garden), locate the Claude models you intend to deploy and click **Enable** on each. Model availability varies by region; enable them in the region you will set as `inferenceVertexRegion`.
</Step>
<Step title="Grant users access to Google Cloud's Agent Platform">
Each authenticated principal needs permission to call the model. On the project's **IAM** page, grant the **Vertex AI User** role (`roles/aiplatform.user`) to:
* the service account, if using a service-account key file
* the Google group containing your users, if using in-app Google sign-in
If your organization uses a narrower custom role, it must include at minimum `aiplatform.endpoints.predict`.
</Step>
<Step title="Create an OAuth client (in-app Google sign-in only)">
If you chose in-app Google sign-in, create a Desktop-app OAuth client in your project. See [In-app Google sign-in](#in-app-google-sign-in) below for the full procedure, including consent-screen setup.
</Step>
<Step title="Federate to your IdP (optional)">
If your users authenticate with Microsoft Entra ID, Okta, or another identity provider and do not already have Google accounts, you have two options:
* **Workforce Identity Federation** (recommended). Create a workforce pool with an OIDC provider, and use the [in-app Workforce Identity sign-in](#in-app-workforce-identity-sign-in) approach. Users sign in directly with their corporate identity; no Google identity is provisioned.
* **Cloud Identity with SAML SSO.** Provision a free Cloud Identity tenant and configure SAML single sign-on to your IdP. Users then sign in through the in-app Google sign-in approach with a Google identity that is backed by your IdP. See [Set up SSO with a third-party IdP](https://support.google.com/cloudidentity/answer/12032922) in the Cloud Identity documentation.
</Step>
</Steps>
## Prepare devices
What each end-user device needs depends on the authentication approach you chose.
### Credentials file
Create a service account in your project, grant it the **Vertex AI User** role, and download its JSON key. Distribute the key file to a fixed path on each device through your device-management tooling and set `inferenceVertexCredentialsFile` to that path.
`inferenceVertexCredentialsFile` accepts any Application Default Credentials JSON format, so if your environment already produces an `authorized_user` file (from `gcloud auth application-default login`) or an `external_account` Workforce Identity Federation configuration, you can point at that file instead. For `external_account` files, the `credential_source` must be of type `file` or `url` (`executable` sources are not supported), and separate tooling on the device must obtain the IdP token and write it to the configured location; Claude Desktop does not perform that step.
### In-app Google sign-in
No per-device preparation is required. The sign-in experience uses a Google OAuth client that **you create in your own Google Cloud project**; Anthropic does not provide or operate an OAuth client for this flow. Distribute the OAuth client ID and secret in the managed configuration (see [Configure the app](#configure-the-app)).
#### How it works
When `inferenceVertexOAuthClientId` and `inferenceVertexOAuthClientSecret` are both set, the app shows a **Sign in with Google** page at first launch. Clicking the button opens the system browser for a standard Google consent flow, and the app listens on a loopback address for the redirect. On success, the app stores the user's Google refresh token encrypted with the operating system's secure storage (Keychain on macOS, DPAPI on Windows) and returns to Cowork.
At the start of each Cowork session, the app writes an `authorized_user` Application Default Credentials file (the same format produced by `gcloud auth application-default login`) into the session sandbox and points `GOOGLE_APPLICATION_CREDENTIALS` at it. The Google Cloud client library inside the sandbox handles access-token minting and refresh automatically.
If the stored refresh token is revoked or expires, the app shows a **Sign in again** prompt; clicking it reopens the Google consent flow in the browser. If you deploy a new OAuth client ID, the app clears the stored token and shows the sign-in page on next launch.
#### Create the OAuth client
<Steps>
<Step title="Configure the OAuth consent screen">
In the Google Cloud Console, in the project where you enabled Claude models, open **APIs & Services → OAuth consent screen**.
If your project belongs to a Google Workspace organization, select the **Internal** user type. Internal apps are limited to users in your Workspace and do not require Google verification, regardless of which scopes they request.
If the project is not in a Workspace organization, you must use the **External** user type. Because this flow requests the `https://www.googleapis.com/auth/cloud-platform` scope, Google classifies the app as using a sensitive scope, and publishing it beyond test users requires Google's OAuth verification process. For that reason, Internal is strongly recommended for enterprise deployments.
</Step>
<Step title="Create a Desktop OAuth client">
In **APIs & Services → Credentials**, choose **Create credentials → OAuth client ID**, and select **Desktop app** as the application type.
Record the generated **Client ID** (ending in `.apps.googleusercontent.com`) and **Client secret**. For installed applications, Google does not treat the client secret as confidential; the flow is protected by PKCE and by the loopback redirect, so it is safe to distribute the secret in a managed configuration profile.
You do not need to add redirect URIs. Desktop-app clients permit loopback (`http://127.0.0.1:<port>`) redirects automatically.
</Step>
<Step title="Allow network egress">
The sign-in flow and subsequent token refreshes reach `accounts.google.com` and `oauth2.googleapis.com` from the user's device. These hosts are already included in the standard egress requirements for Google Cloud's Agent Platform, so if you allowed egress based on the **Egress** section of the configuration window, no additional firewall changes are needed.
</Step>
</Steps>
#### Federate to a third-party identity provider
The in-app sign-in always opens Google's authorization endpoint, because Google Cloud's Agent Platform only accepts Google-issued access tokens. To have users authenticate with your organization's own identity provider (Microsoft Entra ID, Okta, Ping, or an in-house SAML IdP) instead of a Google password, configure Cloud Identity as a broker:
1. In the Google Admin console, set up [SSO with a third-party IdP](https://support.google.com/cloudidentity/answer/12032922) and assign the SSO profile to your Claude Desktop users' organizational unit.
2. Provision those users into Cloud Identity (via SCIM from your IdP, or Google Cloud Directory Sync) so IAM grants resolve.
3. Optionally set `inferenceVertexOAuthLoginHint` so Google skips its own account chooser and routes straight to your IdP with the user's identity pre-filled.
With this in place, clicking **Sign in with Google** opens the browser, Google immediately redirects to your IdP, the user authenticates there (including smart-card or PIV authentication if your IdP supports it), and Google issues the tokens on return. Claude Desktop is unchanged; the federation is configured entirely in Google Admin and your IdP.
#### Notes and limitations
* **Precedence.** When both `inferenceVertexOAuthClientId` and `inferenceVertexCredentialsFile` are set and `inferenceCredentialKind` is not, Google sign-in takes precedence and the credentials file is ignored (the app logs a multi-credential warning). To force the credentials file, set `inferenceCredentialKind` to `vendor-profile` or remove the OAuth client keys.
* **Both keys required.** If only one of `inferenceVertexOAuthClientId` or `inferenceVertexOAuthClientSecret` is set, the app logs a warning and falls back to standard Application Default Credentials discovery.
* **Client rotation.** If you replace the OAuth client in Google Cloud and push the new client ID via MDM, existing users are automatically signed out and prompted to sign in again on next launch.
### In-app Workforce Identity sign-in
No per-device preparation is required. In Google Cloud, create a [workforce pool](https://cloud.google.com/iam/docs/workforce-identity-federation) with an OIDC provider pointing at your organization's IdP, and grant the pool's principals the **Vertex AI User** role on the project.
In your IdP, register a native OAuth client for the app. The app does not send a client secret in this flow, so the client must be public (no client authentication) with PKCE required. The sign-in redirect lands on `http://127.0.0.1:<port>/callback`, where the operating system chooses `<port>` on each sign-in:
* If your IdP permits loopback redirect URIs on any port (the [RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) native-app pattern, supported by Microsoft Entra ID under the **Mobile and desktop applications** platform), register `http://127.0.0.1/callback` and leave `redirectPort` unset.
* If your IdP requires an exact registered redirect URI (such as Okta or PingFederate), set the `redirectPort` field of `inferenceVertexWorkforceOidc` to a fixed port and register the resulting URI exactly, for example `http://127.0.0.1:53180/callback`.
Use `127.0.0.1`, not `localhost`; most IdPs do not treat them as interchangeable.
Distribute the workforce-pool provider audience and the IdP OIDC client in the managed configuration; the app shows a **Sign in** page on first launch, runs an authorization-code-with-PKCE flow against your IdP in the system browser, exchanges the returned ID token for a Google Cloud access token at `sts.googleapis.com`, and stores the IdP refresh token encrypted with the operating system's secure storage. No `gcloud` CLI, helper script, or Google identity is required.
The app always requests the `offline_access` scope so that the IdP returns a refresh token for silent renewal. If your IdP rejects `offline_access` on this client (for example, a PingFederate public client without the Refresh Token grant type enabled), set the `omitOfflineAccess` field of `inferenceVertexWorkforceOidc` to `true`. Without a refresh token the app cannot refresh silently, so users will be prompted to sign in again each time the IdP's ID token expires, typically about once an hour.
## Configure the app
With Google Cloud 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 **Vertex AI** and fill in the **Vertex AI credentials** card with the values for whichever authentication approach you chose:
| Field | Service-account key | In-app Google sign-in |
| -------------------------- | ---------------------- | ---------------------------------------------- |
| GCP project ID | `your-gcp-project` | `your-gcp-project` |
| GCP region | e.g. `us-east5` | e.g. `us-east5` |
| GCP credentials file path | `/path/to/sa-key.json` | *leave empty* |
| Vertex OAuth client ID | *leave empty* | `1234567890-abc123.apps.googleusercontent.com` |
| Vertex OAuth client secret | *leave empty* | `GOCSPX-xxxxxxxxxxxxxxxxxxxx` |
| Vertex OAuth scopes | *leave empty* | *leave empty for the default* |
| Vertex AI base URL | *optional* | *optional* |
Under **Models**, add at least one **Model list** entry using the publisher model ID, for example `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 `inferenceVertex*` keys is below. Set `inferenceProvider` to `vertex`, supply a project and region, and provide exactly one credential source.
The region can be a single region such as `us-east5`, the `eu` or `us` multi-region, or `global`. The app routes inference to a different endpoint host for multi-regions and `global`; if you allowlist egress by hostname, see the [inference provider egress hosts](/docs/third-party/claude-desktop/telemetry#inference-provider).
| 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.
The GCP STS token-exchange step is unchanged in either flow; only how the Entra id\_token is acquired differs.
</Accordion>
<Accordion title="inferenceVertexWorkforceOidc details">
| 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. |
| `scopes` | `string` | — | Space-separated scopes. Defaults to openid profile email offline\_access. |
| `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. |
| `omitOfflineAccess` | `boolean` | — | Only enable if your IdP rejects the offline\_access scope on this client. Without it the app prompts for sign-in each time the token expires. |
| `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>
If none of `inferenceVertexCredentialsFile`, the OAuth client keys, the Workforce Identity keys, or `inferenceCredentialHelper` is set, the Google client library falls back to the standard Application Default Credentials search path on the device (`~/.config/gcloud/application_default_credentials.json`, then the environment's metadata server).
You must also set `inferenceModels` to a list of publisher model IDs, for example `claude-sonnet-5`. See the [Configuration reference](/docs/third-party/claude-desktop/configuration#inferencemodels).
## What users experience
Cut at 300 lines. The page has the rest.
third-party/claude-desktop/web-tools First recorded · 153 lines, first recorded
# Web search and web fetch ## Web Search ### Web search options #### Provider-native search #### Built-in web search #### Gateway-side search #### Remote search MCP #### Data handling ## Web Fetch ## Disabling web tools
The first capture of this source. The page was already there, and this is what it said.
# Web search and web fetch
> How Claude Desktop on 3P reaches the internet, which providers support search, and how to control or disable web access
Claude Desktop includes two built-in tools for reaching the web:
* **Web Search** runs a search-engine query and returns ranked results.
* **Web Fetch** retrieves the contents of a specific URL.
In Claude Desktop on third-party (3P), both are subject to your configuration: search depends on your inference provider, and fetch is gated by the sandbox network allowlist.
## Web Search
Web Search is a **server-side tool** executed by your inference provider, not by the desktop app. Availability depends on which provider you've configured:
| Provider | Web Search |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Google Cloud's Agent Platform | Available |
| Microsoft Foundry | Available |
| Amazon Bedrock | Not available natively; use the [built-in web search](#built-in-web-search) below |
| Anthropic API | Available |
| Gateway | Available if your gateway implements Anthropic's `web_search` server tool, passes it through to a provider that does, or runs the search itself; see [Gateway-side search](#gateway-side-search) |
Because the search runs on the provider's infrastructure, queries and results travel over the same path as model inference and are subject to your provider's data-handling terms. No additional firewall rules are needed beyond the inference endpoint itself.
<Note>
`coworkEgressAllowedHosts` governs client-side egress (Web Fetch and in-sandbox shell network activity). The SDK Web Search tool in the table above executes server-side at your inference provider, so the allowlist does not apply to it. The built-in `websearch` server under [Web search options](#web-search-options) runs in the desktop app and does count as client-side egress. To let the agent fetch pages it finds via search, add the relevant hosts to `coworkEgressAllowedHosts` or set it to `["*"]`. To disable provider-side search, add `"WebSearch"` to `disabledBuiltinTools`.
</Note>
### Web search options
If your inference provider supports native search (Google Cloud's Agent Platform, Microsoft Foundry), that's the simplest path and no additional configuration is required. For Amazon Bedrock or a custom gateway, or whenever you want to choose the search backend, use the built-in `websearch` server.
| Option | Best for | Where you configure it | Search backend |
| ------------------------------------------ | ---------------------------------------------------------------------------------------------- | ----------------------------- | -------------------------------------- |
| [Provider-native](#provider-native-search) | Google Cloud's Agent Platform, Microsoft Foundry | Your cloud provider's console | The provider's |
| [Built-in](#built-in-web-search) | Amazon Bedrock or a custom gateway; or any provider when you want to choose the search backend | `managedMcpServers` | Brave, Tavily, Exa, or your own server |
| [Gateway-side](#gateway-side-search) | A custom gateway you already run | Your gateway's configuration | Whatever your gateway is wired to |
| [Remote search MCP](#remote-search-mcp) | A search MCP you already run, or Amazon Bedrock AgentCore | `managedMcpServers` | Whatever that MCP exposes |
#### Provider-native search
Google Cloud's Agent Platform grounding and Microsoft Foundry execute search inside the model call. There's nothing to configure in Claude Desktop; enable search on the cloud provider's side. Amazon Bedrock has no native equivalent (Amazon Bedrock AgentCore is a remote MCP server; see [Remote search MCP](#remote-search-mcp)).
#### Built-in web search
Add the bundled `websearch` server to [`managedMcpServers`](/docs/third-party/claude-desktop/configuration#managedmcpservers). Search runs in the desktop app itself, so it works on every inference provider, including Amazon Bedrock.
You can add it from the [in-app configuration window](/docs/third-party/claude-desktop/in-app-configuration): under **Connectors**, add a **Web search** server, choose the search provider, and supply the vendor key as a header or through a headers helper script.
<Frame caption="The Web search server in the Connectors section of the in-app configuration window, with the search provider menu open.">
<img src="https://mintcdn.com/claude-ai/iVbkJluVpijKTo5a/images/third-party/config-window-web-search.png?fit=max&auto=format&n=iVbkJluVpijKTo5a&q=85&s=19cf4844972d9fd47addec8690db09c8" alt="Web search server card in the in-app configuration window with fields for name, tool policy, headers, and headers helper script, and a search provider menu offering brave, tavily, exa, and custom." width="1428" height="1330" data-path="images/third-party/config-window-web-search.png" />
</Frame>
In the exported configuration, set `provider` to a hosted search vendor (`brave`, `tavily`, or `exa`) for the lowest setup, or to `custom` with `customUrl` to point at a search server you run.
Hosted vendor:
```json theme={null}
{
"managedMcpServers": [
{
"name": "Web search",
"server": "websearch",
"provider": "tavily",
"headersHelper": "/opt/org/bin/tavily-headers",
"toolPolicy": { "web_search": "allow" }
}
]
}
```
<Note>
A hosted-vendor key configured in `headers` or returned by `headersHelper` is the same key on every device, and a local user can extract it. The exposure is limited to billing abuse on that key (it grants no data access). For regulated environments, set spend caps and rotate the key on a schedule, or have `headersHelper` fetch a per-user key: Tavily and Exa support per-user or per-team keys; see their key-management docs.
</Note>
Your own server:
```json theme={null}
{
"managedMcpServers": [
{
"name": "Web search",
"server": "websearch",
"provider": "custom",
"customUrl": "https://search.internal.example.com/v1/search",
"headersHelper": "/opt/org/bin/search-headers",
"toolPolicy": { "web_search": "allow" }
}
]
}
```
Set the per-entry `toolPolicy` to `"allow"` so users aren't prompted to approve each search. `headersHelper` is an executable that prints the auth header as a JSON object to stdout; it follows the same execution model as [`inferenceCredentialHelper`](/docs/third-party/claude-desktop/credential-helper) (run with no arguments, exit 0, stdout read as JSON), but the output here is a flat header map, not the `{token, headers}` shape `inferenceCredentialHelper` uses.
| Provider | Header your script should output |
| -------- | ----------------------------------- |
| `brave` | `{"X-Subscription-Token": "<key>"}` |
| `tavily` | `{"Authorization": "Bearer <key>"}` |
| `exa` | `{"x-api-key": "<key>"}` |
| `custom` | Whatever your search server expects |
You can use a static `headers` object instead if you don't need a secrets manager.
#### Gateway-side search
If your inference gateway can execute search itself, the search key stays server-side and never reaches end-user devices.
For LiteLLM proxy server, enable [`websearch_interception`](https://docs.litellm.ai/docs/tutorials/claude_code_websearch) in `callbacks` and configure a search backend in the proxy. The gateway intercepts the model's `web_search_20250305` request, runs the search, and returns results to Claude Desktop.
If your gateway translates between API formats (for example, Anthropic to OpenAI chat completions), note that `web_search_20250305` is an Anthropic server tool with no chat-completions equivalent. The translation layer needs to handle it explicitly: run the search when the model requests it and emit `server_tool_use` and `web_search_tool_result` blocks in the response. Reach out to your account team for a reference implementation.
#### Remote search MCP
Connect a search MCP server as a remote `managedMcpServers` entry: either one you host, or Amazon Bedrock AgentCore Gateway with the Web Search target enabled (configure AgentCore for JWT authentication through your identity provider). Whether this stays inside your boundary depends on where the server is hosted; AgentCore is available in commercial AWS regions.
#### Data handling
Search queries go to whichever backend you configure. In every option, the query is also visible to your inference provider as part of the conversation, because the model emits the search call. Anthropic does not receive search queries in any third-party configuration. For audit, the desktop app emits search events to your OTLP collector regardless of which option you choose; add `toolDetails` to [`otlpContentCapture`](/docs/third-party/claude-desktop/telemetry#content-capture) to capture the query text. To keep queries entirely inside your network, use `provider: "custom"` (or a self-hosted MCP) pointed at a search index that itself runs inside your boundary.
<Note>
If you previously routed inference through a LiteLLM proxy to add search, the built-in `websearch` server with `provider: "custom"` is an alternative that removes the proxy from the search path; gateway-side interception remains a valid choice if you prefer the search key to stay server-side.
</Note>
## Web Fetch
Web Fetch runs in the Claude Desktop main process on the user's device. The model supplies only the target URL; it cannot set headers, a request body, or credentials. Every fetch, including redirect targets, is checked against `coworkEgressAllowedHosts` before the request is sent.
By default, the sandbox can reach only your inference provider's endpoint, so Web Fetch will fail for any other host unless you've allowed it. To permit fetches:
| Goal | Set `coworkEgressAllowedHosts` to |
| -------------------------------------- | --------------------------------------------------- |
| Allow specific domains | `["docs.example.com", "*.example.corp"]` |
| Allow all hosts (no sandbox filtering) | `["*"]` |
| Block all fetches | `[]` and add `"WebFetch"` to `disabledBuiltinTools` |
Wildcards match one or more leading subdomain labels (`*.example.com` matches `a.example.com` and `a.b.example.com`, but not `example.com`).
<Note>
`coworkEgressAllowedHosts` controls what the agent's tools can reach. Your perimeter firewall is a separate, outer layer, so a host allowed by this key still won't be reachable if your corporate network blocks it. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry#required-egress-paths) for the distinction.
</Note>
The same allowlist governs other in-sandbox network activity (for example, `curl` or `pip install` from the agent's shell), not just the Web Fetch tool.
## Disabling web tools
To remove web tools entirely, add them to `disabledBuiltinTools`:
```json theme={null}
["WebSearch", "WebFetch"]
```
With both disabled and `coworkEgressAllowedHosts` empty, the agent has no path to the public internet from inside the sandbox. It can still read and write local files, run code against them, and call any MCP servers you've provisioned. See the [Locked down profile](/docs/third-party/claude-desktop/configuration#recommended-security-profiles).