One read of Claude Documentationclaude-docs-20260814T092040Z
213 pages moved out of 213 read.
Pages moved
213
significant first
Pages read
213
in this capture
Captured
09:20 UTC
Corpus hash
dfa3e64bc187
full baseline · baseline
What this read moved
26-50 of 213, page 2 of 9This capture is too large to show at once. Changes 26-50 of 213 are below, significant first; the rest are on the following screens.
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