Skip to main content
Claude Tag’s behavior is shaped by four layers, each set in a different place: Connections and plugins decide what Claude can do; instructions and memory shape how it does it.

​
Settings admins control

Access and organization-wide behavior are set at claude.ai/admin-settings/claude-tag, per scope (a scope is a channel, a workspace, or your whole organization), so the same agent can work differently in different channels. Most controls below need the Owner role or, on the Enterprise plan, the Claude Tag Admin permission.

​
Channel connections are separate from personal connectors

An Owner or a Claude Tag admin configures Claude’s connections, plugins, and skills, and they apply per scope. They are separate from the connectors, skills, or MCP servers an individual user has set up in their own claude.ai or Claude Desktop account. A user’s personal connectors are not part of a channel’s configuration, and the channel’s connections are not listed among that user’s personal connectors in claude.ai. Claude can use a user’s personal connectors in a channel for that user’s own tasks, after the user allows it. That work runs with the user’s permissions and is recorded under their name. Projects in claude.ai are separate too. Claude doesn’t read a Project’s instructions or knowledge in Slack, and a channel can’t be pointed at a Project. Put standing guidance for a channel in its custom instructions. To give Claude access to a tool that is not in the built-in connection list, including a custom MCP server, see add a custom connection.

​
Change behavior from the channel

Everything in the table below is open to channel members, with no admin involved. Changes in the table above are saved to channel memory; verify one stuck by asking what it remembers. Members can also tailor how Claude works in the channel from its Configure page on claude.ai. The Configure link in the footer of any Claude reply in the channel opens it, and if a member sends @Claude !configure in the channel, Claude replies with a link to it. Anyone in the channel who is also a member of your Claude organization can edit settings for that channel there, unless an admin has restricted editing to admins. The Channel instructions field on that page holds standing guidance that outranks memory. See configure Claude for a channel. The Configure page also shows the channel’s resolved access. Its Tools and access tab lists the channel’s resolved connections and any allowed domains. Members can see those lists but not change them there. The same tab’s Plugins card lists the plugins available to Claude in the channel; members can add plugins there unless an admin has restricted editing to admins. The card groups plugins Added by your admin, which members can’t remove, separately from plugins Added by members, which members can remove. The Configure page’s Routines tab lists the channel’s routines with each one’s schedule, status, and last run. On the Enterprise plan, an Owner can name channel managers for a channel, and so can a Claude Tag admin whose role also sets Identity & Access to Can manage. Channel managers set the channel’s default model, repositories, connections, and plugins from the same page.

​
Choose the model for a scope

Each scope carries a Default model setting in its Advanced section, alongside the environment and guest controls. It sets the model new channel sessions in that scope start on. The options are the models your organization allows, such as Opus and Sonnet models, regardless of any individual member’s own model access. The picker also lists model families. A scope set to a family option starts sessions on the newest model of that family your organization allows, and moves to a newer one when your organization gets it, without you changing the setting. A scope without its own setting inherits from its parent, and a channel’s setting overrides its workspace’s. The Inherit option shows which model the scope resolves to. To keep sessions on a model you chose, set a specific model at the organization scope rather than leaving the setting unset; every scope without an override then follows it. When you change the setting, new sessions start on the new model. A thread already underway switches to it at the next message anyone posts there, unless someone in that thread has already had Claude switch models. The footer of each Claude reply in Slack names the model that handled it, so you can confirm what a scope is running. Channel members can also change the model from Slack. Asking Claude in a thread switches that thread, and asking it to make a model the channel default changes this setting for the channel, unless the scope’s Channel member edits setting is Block. See choose the model Claude Tag uses.

​
Models your organization allows

On the Team plan, Claude Tag doesn’t apply the availableModels allowlist from your Claude Code server-managed settings, and on the Enterprise plan it applies the allowlist in only some organizations.
  • Where the allowlist doesn’t apply: Claude offers your organization’s full Claude Tag model list, both when someone asks it to switch and in the model selector for direct messages. It starts sessions on a scope’s Default model without checking that model against the allowlist. The Default model picker in admin settings still lists only allowed models.
  • Where the allowlist applies: sessions in a channel run as the agent identity you provisioned and without your server-managed settings. When someone in a channel asks Claude to switch models, Claude may decline a model outside the allowlist, though that check doesn’t always run. In one-to-one direct messages from a member whose linked Claude account belongs to your organization, Claude runs on that member’s own account, which receives your allowlist; see Restrict model selection for what happens to a model the allowlist blocks.
In either case, Claude Tag offers only the models it supports, so a model your allowlist includes can be absent in Slack. On the Enterprise plan, turning a model off for the whole organization on your Models page removes it from the lists in Slack, and Claude declines requests to switch to it. If you turn off the model a scope’s Default model is set to, Claude still starts sessions there on a fallback model that’s still on, and declines only when every fallback is off too. The footer of the first reply names the model that served it.

​
Allow fast mode

Fast mode gives a thread faster output at a higher cost per token. Claude in Slack and Claude Code share one fast mode setting, so turning it on allows fast mode in both. The setting is off by default on the Team and Enterprise plans. To allow fast mode, an Owner goes to Admin settings > Claude Code and turns on the Fast mode toggle under Capabilities. Fast mode draws from usage credits, so also turn those on at Admin settings > Usage. For an organization billed through AWS Marketplace, the toggle is locked. Turning the toggle on has these effects in Slack:
  • Speed: every session starts at standard speed until someone turns fast mode on for it, and no per-channel setting starts sessions in fast mode
  • Who turns it on: any member who can message Claude in a channel can turn fast mode on for a thread there by sending @Claude !fast
  • Model: when a thread is on a model other than Opus, such as Sonnet, !fast moves it to the newest Opus model among the models your organization allows, and the thread stays on that model after !fast off
  • Where: sessions stay at standard speed in a channel that runs with channel-only access because a guest is present, and in a channel shared with another company
  • Cost: a channel thread in fast mode bills to your organization like other channel work, at the fast mode rates

​
Configure the environment for a scope

Claude runs every channel session in a sandbox that starts with a standard set of tools. When a channel’s work needs something that sandbox doesn’t have, such as a language runtime, a database client, a set of environment variables, or broader web access, give the channel an environment. An environment is an organization-shared cloud environment: you create it once, then choose it on a scope, meaning a channel, a workspace, or Default Slack access. Both steps take an Owner; a channel manager can’t change a channel’s environment.

​
Decide what goes in the environment

An environment carries a setup script, environment variables, and a network access level. Not everything a channel needs belongs there, so match each need to its place before you create one: Keep credentials out of environment variables because every session on the environment reads them and Claude can print them. There is no separate secrets store. A connection stores the credential outside the sandbox and attaches it to matching requests at the network layer, so Claude uses the service without holding the raw value. Agent Proxy describes how. A connection also travels with the access bundle, so you choose channel by channel which sessions can use it. Repository-specific setup goes in CLAUDE.md so the people who maintain the repository keep it current. Claude reads it when it starts work in that repository.

​
Create the environment and choose it on a scope

Creating the environment and choosing it on a scope happen on two different admin pages. Choose it on a channel to change only that channel’s sessions, on a workspace to cover every channel in the workspace where you haven’t chosen one, or on Default Slack access to cover every workspace.
1

Create the environment

From the Cloud environments page in admin settings, add an organization-shared environment and fill in its setup script, environment variables, and network access level.
2

Set the scope's environment

The picker is at claude.ai/admin-settings/claude-tag > Claude Tag’s access > Slack > the scope (Default Slack is the organization-wide scope) > Advanced > Environment. Pick the environment there.
3

Confirm the environment in a new thread

Start a fresh thread in the channel and ask Claude to use what you added, such as running the tool your setup script installed. Threads already underway keep the environment they started on, so an existing thread won’t show the change.

​
Which environment a channel’s sessions use

When a session starts, Claude uses the first environment it finds, in this order:
  1. The channel’s Environment setting
  2. The workspace’s Environment setting
  3. The Environment setting on Default Slack access
  4. The organization’s default environment, which an Owner chooses under Cloud sessions at 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 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.

​
Auto mode allow rules

Sessions run in auto mode, where Claude’s permission checker reviews each action Claude is about to take and can flag or stop it. When you add an auto mode allow rule to a scope, you pre-approve one action in that scope’s sessions, so Claude runs it there without the checker stopping it. The checker keeps reviewing every other action. A rule is a plain sentence that describes work you approve in the scope, such as “Deploying to our staging cluster from a session in this channel is a normal, approved workflow.” To add one:
  1. On claude.ai/admin-settings/claude-tag, open the Slack tab under Claude Tag’s access and find the scope you want to change (the organization-wide Default Slack row, a workspace, or a channel). The Default Slack row opens as Default Slack access.
  2. Open the scope’s Advanced section and find Auto mode allow rules, below the Default model setting.
  3. Select Add rule and write the rule as one plain sentence.
The rules list has three properties:
  • Limits: a scope holds up to 50 rules, and each rule can be up to 1,024 characters
  • Inheritance: rules you set on a workspace or on Default Slack access (the organization-wide root) carry down to the channels beneath, the way custom instructions stack. A channel’s own rules add to those and never replace them, so put a rule on a single channel’s scope to pre-approve an action there without changing any other channel.
  • Access: you edit the list with the same admin access as the scope’s other Advanced settings
Once you add an allow rule, Claude runs the actions it names in every channel the scope covers without anyone approving them in the moment. Keep each rule narrow: name the tool, the action, and the environment it allows, and put rules that unlock sensitive systems on the narrowest scope that needs them.

​
Name, handle, and avatar of the Claude app

The Claude app’s name, @-handle, and avatar in Slack are the same in every workspace; there is no rename or rebrand setting.