Capture
One read of Claude Documentation
8 pages moved out of 218 read.
claude-tag/admins/restrict-access Changed · +13 / -50 lines
### Externally shared channels #### How Channel only works ### Slack Connect channels
from line 1
# Restrict where Claude Tag operates -> Claude Tag responds only where it has been added and addressed. See who can invoke it, what changes in guest and Slack Connect channels, the per-scope version setting, how to limit it to chosen channels, how to delegate a channel's setup, and how to quiet or remove it. +> Claude Tag responds only where it has been added and addressed. See who can invoke it, guest and externally shared channel limits, the per-scope version setting, how to limit it to chosen channels, how to delegate a channel's setup, and how to quiet or remove it. export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;
from line 103
DMs, guest channels, and shared channels sit outside the version setting: * **DMs.** The version setting doesn't cover them. To close those off too, turn off [Allow direct messages](#allow-or-disable-direct-messages). -* **Guest channels.** By default Claude is off in any channel that includes a Slack guest. If a chosen channel has guests, also set [Allow Claude to work in channels with guests](#restrict-guest-channels) to **Allow** or **Channel only** on its scope. -* **Shared channels.** A [channel shared across workspaces in your Enterprise Grid](#channels-shared-across-workspaces-in-your-enterprise-grid) takes its settings from **Default Slack access** only and can't serve as a chosen channel. In a [Slack Connect channel](#externally-shared-channels), Claude replies only where the guest setting allows it. +* **Guest channels.** By default Claude is off in any channel that includes a Slack guest. If a chosen channel has guests, also set [Allow Claude to work in channels with guests](#restrict-guest-channels) to **Allow** on its scope. +* **Shared channels.** A [channel shared across workspaces in your Enterprise Grid](#channels-shared-across-workspaces-in-your-enterprise-grid) takes its settings from **Default Slack access** only, and Claude [doesn't operate in Slack Connect channels](#externally-shared-channels) at all; neither can serve as a chosen channel. To control who can use Claude in the allowed channels, turn on the [restriction toggle](#restrict-who-can-use-claude); to cap what a channel spends, [set a per-channel spend limit](#set-spend-limits).
from line 121
### Restrict guest channels -By default, Claude is disabled in any channel that includes a Slack guest. The **Allow Claude to work in channels with guests** setting changes that per scope. It's at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, in the scope's collapsed **Advanced** section, and it has three values: +By default, Claude is disabled in any channel that includes a Slack guest. To allow it there, set **Allow Claude to work in channels with guests** to **Allow** for the scope covering the channel; **Restrict** (the default) keeps it off wherever a guest is present. The setting is at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, in the scope's collapsed **Advanced** section. -| Value | What Claude does in a channel that includes a guest | -| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Restrict** (default) | Doesn't reply. When someone mentions it, Claude posts a short notice that it doesn't respond in channels that include guests, with a link to this setting. | -| **Channel only** | Replies, but while a guest is present it runs with channel-only access. Bundles, connectors, and instructions from the workspace or from **Default Slack access** don't reach the channel, and neither do repositories, memory, or skills. The channel's own instructions and any access bundle attached directly to the channel still apply. | -| **Allow** | Replies with the full access the scope gives it, as in any other channel. | +**Allow** applies to every guest channel the scope covers, and guests in those channels can see Claude's replies and interact with it. To open one channel rather than a whole workspace, set it on the channel's own scope. -A channel without its own value shows **Inherit** and takes the value from its workspace, or from **Default Slack access**. Changing this setting requires an organization owner. The setting applies to every guest channel the scope covers; to open one channel rather than a whole workspace, set it on the channel's own scope. +**Allow** controls whether Claude replies, not what it can search. Workspace search is unavailable in any channel that includes a guest, even when the setting is **Allow**. Search results could include content from channels the guests can't see, the same reason Claude doesn't search private channels. To run a search that covers the workspace, ask from a channel without guests. -Under every value, guests in the channel can read what Claude posts there. In any channel that includes a guest, even under **Allow**, Claude won't search the workspace, look up people or channels, or read channels other than the one it's in, because the results could include content the guests can't see in Slack. That is the same reason Claude doesn't search private channels. To do any of that, ask from a channel without guests. +### Externally shared channels -#### How Channel only works +Claude doesn't operate in Slack Connect channels, the ones shared with another company. It's off in those channels regardless of scope or bundle, and this isn't configurable. -**Channel only** lets a team keep using Claude in a channel shared with contractors, clients, or agency partners without exposing the rest of the organization's setup to that conversation. While a guest is in the channel, Claude keeps what is set on the channel itself and drops what it would inherit: - -* No [access bundles](/docs/claude-tag/admins/attach-to-scope) from the workspace or from **Default Slack access**. A bundle attached directly to this channel's scope still applies, with its connections, instructions, and plugins, so attach to a guest channel only what you're comfortable having used in front of guests. -* No repositories, including any in a bundle attached to the channel, and no connectors set directly on the channel. -* No instructions set on the workspace or the organization. Instructions set on the channel itself still apply. -* No memory, including this channel's own, and no skills. -* No [environment set on the scope](/docs/claude-tag/admins/customize#configure-the-environment-for-a-scope). The session runs on the standard environment, so that environment's setup script, environment variables, and network access level don't apply while a guest is present. - -Claude decides this when a conversation starts. When no guest is in the channel, new conversations get its usual full access, as under **Allow**. A guest can talk to Claude by mentioning `@Claude` or by replying in a thread Claude started after a guest was in the channel, and Claude answers them. In a thread Claude began before the first guest joined, Claude stops replying while a guest is present, and a guest who writes there gets the same notice as under **Restrict**; start a new thread instead. While a guest is present, Claude replies only to mentions and to threads it's already part of; it doesn't pick up other channel messages on its own, even where [**Respond automatically**](/docs/claude-tag/users/when-claude-responds#turn-automatic-replies-on-or-off) is on. A guest can't approve a tool or permission request, or restart, mute, fork, or stop the session. If a guest clicks approve, nothing is granted and a workspace member has to ask Claude again. - -Treat a channel's instructions, and the instructions in any bundle attached to the channel, as visible to everyone in that channel, including guests. Under **Channel only** they shape replies that guests read and take part in. - -**Channel only** takes effect where the **New** version answers. On a scope where **Legacy** answers, a channel that includes a guest is treated as **Restrict**. - -<a id="externally-shared-channels" /> - -### Slack Connect channels - -In a Slack Connect channel, one shared with another company, Claude treats everyone from the other company as a guest, and the [guest setting](#restrict-guest-channels), **Allow Claude to work in channels with guests**, decides whether it replies. Under **Restrict**, the default, Claude stays silent and posts no notice, unlike in a channel with a Slack guest. To let Claude answer, set the guest setting to **Channel only** on the channel's scope, or on a scope it inherits from; **Allow** behaves the same there, because in a Slack Connect channel Claude only ever runs with [channel-only access](#how-channel-only-works). - -When Claude replies in a Slack Connect channel: - -* People from the other company can ask it by mentioning `@Claude` or replying in a thread it's already in. When the [restriction toggle](#restrict-who-can-use-claude) that limits Claude to your organization's members is on, Claude doesn't answer them. Whether or not the toggle is on, they can't approve a tool or permission request. -* Claude doesn't search your workspace, look up people or channels, read other channels, or use memory. Of the [commands](/docs/claude-tag/users/commands), your organization's members can use only `!help`, `!mute`, and `!unmute`; restarting or forking a session isn't available, and neither are routines. -* Claude replies only to mentions and to threads it's already in, even where [**Respond automatically**](/docs/claude-tag/users/when-claude-responds#turn-automatic-replies-on-or-off) is on. It reads the rest of the channel as context, including what the other company's people and apps post, but never answers their apps or bots. -* You can't create a scope for a channel that's already shared; the console refuses it. A scope created before the channel was shared still applies, with its instructions and any bundle attached directly to it, so treat both as visible to the other company. -* Everyone in the channel reads what Claude posts. -* Claude stops replying in a thread it was in before the channel was shared, and posts a notice asking for a mention in a new thread. - -The guest setting controls only your organization's Claude. If the other company also uses Claude Tag, their settings decide whether their Claude answers in the channel, and you can't turn theirs off from your side. Claude never answers the other company's Claude. - -On Enterprise Grid, when Claude is installed at the organization level rather than per workspace, it replies only in Slack Connect channels that one of your own workspaces created. In a channel the other company created, it stays silent and posts no notice. - ### Channels shared across workspaces in your Enterprise Grid What happens in a channel shared across more than one workspace inside your Enterprise Grid depends on whether every workspace in it is connected to the same Claude organization. -When the workspaces all belong to your one Claude organization, Claude replies in the channel, but only with the access and settings on your organization's [Default Slack access](/docs/claude-tag/admins/attach-to-scope) scope. Bundles, instructions, and memory set on a workspace or on that channel don't reach it. Claude posts a notice in the thread explaining this, about once a month per channel at most rather than on every reply. Where guest access is **Restrict** or **Channel only**, the [guest check](#restrict-guest-channels) still runs first and can refuse the reply. +When the workspaces all belong to your one Claude organization, Claude replies in the channel, but only with the access and settings on your organization's [Default Slack access](/docs/claude-tag/admins/attach-to-scope) scope. Bundles, instructions, and memory set on a workspace or on that channel don't reach it. Claude posts a notice in the thread explaining this, about once a month per channel at most rather than on every reply. Where guest access is at its default **Restrict**, the [guest check](#restrict-guest-channels) still runs first and can refuse the reply. When the workspaces belong to different Claude organizations, each with its own settings and plan, Claude won't reply and posts a refusal message instead.
claude-tag/admins/troubleshooting Changed · +5 / -5 lines
from line 102
**What it means** -**Allow Claude to work in channels with guests** is set to **Restrict** or **Channel only** for this channel's [scope](/docs/claude-tag/concepts/glossary#scope), so Claude checks the channel for guests before replying, and this install predates the `users:read` permission that check needs. +**Allow Claude to work in channels with guests** is set to **Restrict** for this channel's [scope](/docs/claude-tag/concepts/glossary#scope), so Claude checks the channel for guests before replying, and this install predates the `users:read` permission that check needs. **How to resolve**
from line 149
Either fix works: * Remove the guests from the channel, or move the conversation to a channel with no guests; this changes no settings, so no other channel is affected. -* Or change **Allow Claude to work in channels with guests** for the scope covering this channel; changing it needs an organization owner. **Channel only** restores replies while keeping Claude to the channel's own instructions and access. **Allow** gives guests the full access the scope has. The setting is at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, in the scope's collapsed **Advanced** section. Either value applies to every guest channel that scope covers; to limit it to one channel, set it on the channel's own scope. See [restrict guest channels](/docs/claude-tag/admins/restrict-access#restrict-guest-channels) for what each value exposes. +* Or set **Allow Claude to work in channels with guests** to **Allow** for the scope covering this channel. The setting is at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, in the scope's collapsed **Advanced** section. **Allow** applies to every guest channel that scope covers, and guests there can see Claude's replies and interact with it. To limit it to one channel, set it on the channel's own scope. See [restrict guest channels](/docs/claude-tag/admins/restrict-access#restrict-guest-channels) for the full exposure picture. -Either value restores replies, not workspace search. Claude can't search the workspace from a channel that includes guests, even under **Allow**. Removing the guests restores search as well. +**Allow** restores replies, not workspace search. Claude can't search the workspace from a channel that includes guests, even when the setting is **Allow**. Removing the guests restores search as well. If the fix worked, a mention in the channel gets a reply.
from line 184
**What it means** -This message comes from the guest check, not from workspace sharing. **Allow Claude to work in channels with guests** is set to **Restrict** or **Channel only** for this channel's scope, and the channel's membership can't be verified, most often because the channel is shared across an Enterprise Grid organization, so Claude declines. +This message comes from the guest check, not from workspace sharing. **Allow Claude to work in channels with guests** is set to **Restrict** for this channel's scope, and the channel's membership can't be verified, most often because the channel is shared across an Enterprise Grid organization, so Claude declines. **How to resolve**
claude-tag/users/troubleshooting Changed · +6 / -13 lines
from line 106
**What you see** -Mentions in a Slack Connect channel, one shared with another company, get no answer, and usually no notice. +Mentions in a channel shared with another company get no answer, and usually no notice. **What it means** -By default, Claude is off in Slack Connect channels, and it posts no notice there. A Claude organization Owner turns it on with the [guest setting](/docs/claude-tag/admins/restrict-access#restrict-guest-channels), after which Claude replies with [channel-only access](/docs/claude-tag/admins/restrict-access#how-channel-only-works). If the setting is already **Allow** or **Channel only** and Claude still doesn't answer, one of two things is likely: +Claude doesn't operate in Slack Connect channels, the ones shared with another company. This holds regardless of admin settings. Messages there get no reply. See [externally shared channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels). -* The organization that runs Claude restricts it to its own members, and you're on the other side of the channel. -* That organization installed Claude at the Enterprise Grid organization level, and the other company's workspace created the channel. - -See [Slack Connect channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels). - -If the mention gets the notice "This channel is now shared with another organization through Slack Connect, so this thread's earlier session can't continue here," the thread started before the channel was shared. Mention `@Claude` in a new thread. - A channel shared across workspaces inside your Enterprise Grid isn't silent; what happens there depends on how those workspaces connect to Claude. When every workspace in the channel belongs to your one Claude organization, Claude answers, but with only your organization's default access and settings, so a repository or an instruction set up for that channel doesn't apply. A notice in the thread points this out from time to time. When the workspaces are connected to different Claude organizations, you see "This channel is shared among several Claude workspaces, so Claude cannot respond here" instead of an answer. Where guest access is restricted, you may first see "This channel is shared across multiple workspaces, and Claude can't verify whether it includes guests, so Claude can't respond here." If you ask Claude from another conversation to act in one of these channels, such as posting a message there, you see a reply that ends "Claude isn't available in channels shared across your Enterprise Grid".
from line 156
* Remove the guests from the channel. In Slack, open **Channel details** → **Members** and filter by "guests"; guests show a **guest** badge on their Slack profile. * Move the conversation to a channel with no guests. -* Ask an admin of your Claude organization to change the guest setting for this channel, and send them [the guest access setting](/docs/claude-tag/admins/restrict-access#restrict-guest-channels). They can let Claude reply with only the channel's own setup, or with full access. If you don't know who your organization's admins are, ask whoever set Claude up in your workspace. +* Ask a claude.ai organization owner to allow Claude to respond in channels that include guests, and send them [the guest access setting](/docs/claude-tag/admins/restrict-access#restrict-guest-channels). If you don't know who your organization's owners are, ask whoever set Claude up in your workspace. The guest access setting restores replies, not workspace search. Claude can't search the workspace from a channel that includes guests, even when it's allowed to respond there. Removing the guests or moving the conversation to a channel with no guests restores search as well.
claude-tag/users/when-claude-responds Changed · +1 / -1 lines
from line 116
* **Editing a message to add the mention.** An edit doesn't trigger a response. Delete the message and send a new one with `@Claude` included. * **Channels with guest accounts.** By default, Claude is off in channels that include guests; your admin can turn it on per scope. Ask whoever runs your Claude plan, or send them [the guest access setting](/docs/claude-tag/admins/restrict-access#restrict-guest-channels). * **Channels shared across workspaces connected to different Claude organizations.** Every workspace where Claude runs is connected to a Claude organization, the account a company sets up for Claude. When a channel is shared across workspaces connected to different Claude organizations, Claude won't reply there and posts a refusal message instead. You can't tell from Slack how a workspace is connected; the refusal message itself is the signal. Use a channel that belongs to one workspace, or send Claude a DM. -* **Slack Connect channels.** By default, Claude is off in channels shared with another company, and it posts no notice there. Your admin can turn it on; see [Slack Connect channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels). Claude then replies without your organization's bundles, memory, or workspace instructions. +* **Slack Connect channels.** Channels shared with another company are always off. When the workspaces sharing a channel all belong to one Claude organization, Claude replies there, but with only your organization's default access and settings. The repositories, instructions, and memory set up for that channel or its workspaces don't apply, and Claude posts a notice in the thread explaining this from time to time. The guest check above still applies first where guest access is restricted.
claude-tag/users/good-habits Changed · +1 / -1 lines
from line 138
A private channel is readable only from inside it. Inviting Claude lets it work in that channel, but Claude can't read the private channel's messages from any other channel or DM. To ask about a private channel, ask in that channel. -Channels in a different workspace stay out of reach. In a Slack Connect channel, one shared with another company, Claude works only where your admin's guest setting allows it, and then with channel-only access; see [Slack Connect channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels). +Channels in a different workspace and Slack Connect channels stay out of reach. When more than one surface would work, prefer a channel. Work that happens there compounds, because Claude can draw on it in later threads and teammates can find it, redirect it, or build on it.
claude-tag/concepts/security-and-data Changed · +1 / -1 lines
from line 83
2. Keep the channel private. A bundle on a public channel [grants its access to anyone who joins](/docs/claude-tag/admins/attach-to-scope#attach-to-a-channel). 3. Check the channel's **Access summary** on the [Slack tab in admin settings](/docs/claude-tag/admins/attach-to-scope). It shows the access the channel actually gets, including what it inherits from the workspace and Default Slack access. -In a channel shared with another company, Claude replies only if the guest setting allows it, and then with channel-only access, so nothing inherited from the workspace or **Default Slack access** reaches the channel. See [Slack Connect channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels). +Claude [doesn't operate in externally shared channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels), so a channel shared with another company never has a session to isolate. Isolating a credential doesn't isolate what Claude knows. What it learns in a public channel becomes [workspace memory](/docs/claude-tag/users/memory) that sessions in the workspace's other channels can read, and it can [search public channels by keyword](/docs/claude-tag/admins/restrict-access#controls-that-aren%E2%80%99t-available) without being added to them, the same way any workspace member can.
claude-tag/admins/for-slack-admins Changed · +1 / -1 lines
from line 23
Reading a channel's full history requires being added there. Workspace search can surface public-channel content, the same as any app with the search scope. -In a Slack Connect channel (shared with another company), Claude replies only if a Claude organization Owner allows it, and then without anything set up outside that channel; see [Slack Connect channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels). +Slack Connect channels (shared with another company) are always excluded, regardless of configuration. ## Requested scopes
claude-tag/admins/customize Changed · +1 / -1 lines
from line 122
3. The **Environment** setting on **Default Slack access** 4. The [organization's default environment](https://code.claude.com/docs/en/cloud-environments#the-default-environment), which an Owner chooses under **Cloud sessions** at [`claude.ai/admin-settings/claude-code`](https://claude.ai/admin-settings/claude-code) -If you haven't chosen an environment on a scope, its picker shows **Organization default**, but sessions there may still run on an environment you chose on the workspace or on **Default Slack access**. In a channel where Claude runs with [channel-only access](/docs/claude-tag/admins/restrict-access#how-channel-only-works) because a guest is present, sessions run on the standard environment regardless of these settings. If a channel's sessions aren't on the environment you expect, see [channel sessions use the wrong environment](/docs/claude-tag/admins/troubleshooting#channel-sessions-use-the-wrong-environment-or-can%E2%80%99t-find-one). +If you haven't chosen an environment on a scope, its picker shows **Organization default**, but sessions there may still run on an environment you chose on the workspace or on **Default Slack access**. If a channel's sessions aren't on the environment you expect, see [channel sessions use the wrong environment](/docs/claude-tag/admins/troubleshooting#channel-sessions-use-the-wrong-environment-or-can%E2%80%99t-find-one). ## Auto mode allow rules