Claude Tag
How Claude Tag puts a shared, admin-governed @Claude into your team's Slack channels, and how it maps onto what you already know from Claude Code.
Claude Tag is Anthropic's organisation-level Slack integration. Instead of each person linking their own account (the model described in Claude Code in Slack), an Owner pairs the Slack workspace with the Claude organisation once, gives Claude its own service accounts in the tools your team uses, and then anyone in a channel can tag @Claude into a problem. Claude works in a cloud sandbox, keeps a live checklist in the thread, and posts the result where the whole channel can see it.
Under the hood each thread is a Claude Code session running on the same infrastructure as Claude Code on the web. If you already use Claude Code, most of this page is about what carries over and what moves into admin settings.
Note: Claude Tag is in public beta. Behaviour and limits may change before general availability.
Who can use it
| Question | Answer |
|---|---|
| Which plans? | Team and Enterprise, on Anthropic's own service. Not Free, Pro or Max, and not third-party cloud deployments. |
| Does everyone need a seat? | No. Anyone in the paired workspace can tag Claude in a channel unless an Owner restricts it to organisation members (or, on Enterprise, to specific roles). |
| Who pays for channel work? | The organisation, from a funded usage balance, capped by a monthly spend limit. There is no per-seat charge for adding Claude to Slack. |
| What about one-to-one DMs? | A DM from someone who has connected a Claude account runs on that person's own account and seat, so the org spend limit does not apply. |
| Any organisations excluded? | Yes: organisations using Zero Data Retention, customer-managed encryption keys, or the HIPAA configuration for local Claude Code and Cowork. Claude Tag stores channel memory and transcripts, which those modes rule out. |
How it differs from your other Claude tools
| Claude Tag | Cowork | Claude Code | |
|---|---|---|---|
| Where you talk to it | Slack channels and threads | claude.ai | Terminal, IDE, desktop app |
| Whose credentials | Service accounts an admin assigns per channel | Your own connectors | Your own machine and credentials |
| Who sees the work | The whole channel | You | You |
| Sweet spot | Shared work the team should watch and steer | Personal research and drafting | Hands-on coding in your checkout |
My rule of thumb: if the result belongs to the team, start it in a channel. If it is my own exploration, I keep it in the terminal.
Anatomy of a session
Imagine this in #platform-eng:
Priya: @Claude the nightly export job has failed three nights running.
Check the job logs, find the cause, and open a draft PR if it's ours.
What happens next:
- A session starts. A top-level mention is picked up by the channel's own session, which spins off a dedicated working session in a thread under the message for anything that needs tools or investigation.
- A sandbox builds. Each thread gets its own isolated environment. Two threads in the same channel never share state directly.
- Claude works. For longer jobs its first reply is a checklist that it edits in place. Slack does not notify on edits, so a thread can look idle while items are ticking off. Open it before assuming it is stuck.
- The result lands in the thread. That could be a reply, an attached file or chart, a message it keeps updating, a hosted page on claude.ai, or (for code) a draft pull request opened by the Claude GitHub App.
- The sandbox is released. A few minutes after a turn finishes, the compute goes away, but the conversation does not. The next reply rebuilds a fresh sandbox and the same session carries on.
Steering and stopping
- Anyone in the channel can steer a running session by replying in its thread. No need to re-mention Claude.
- Stop appears on the working indicator in a channel thread. Claude halts, keeps the context, and names who stopped it. Mention it again to resume.
- Edits to earlier messages reach Claude only as a before-and-after note and do not start a new task. Deleting a reply does not notify Claude at all. Deleting the thread's first message closes the session.
- Say corrections in a new reply. That is the only reliable way to change direction.
What survives a quiet period
| Thing | Kept? |
|---|---|
| The thread conversation and its context | Yes |
| Channel memory | Yes |
| Branches pushed, PRs opened, messages posted | Yes, in those external systems |
| Files that only existed in the sandbox | No; ask Claude to recreate them |
For long tasks, ask Claude to push branches and post drafts as it goes so progress is never only in the sandbox.
The channel's top-level session lives longer than a thread session, but it is replaced after about an hour of inactivity, when the channel's configuration changes, or once it is roughly a day old and things have gone quiet. Claude also stops reading top-level messages after roughly 100 have arrived since it last spoke; a fresh mention wakes it up.
What Claude can see and reach
Out of the box, with nothing connected, every session can:
- read its thread and the channel history, including pinned items;
- search workspace content (except in channels with guests, and an admin can restrict search to channels Claude is in);
- write and run code in the sandbox, which is how a CSV pasted in the channel turns into a chart.
Mentioning Claude partway through a long thread gives it a window of recent messages rather than the whole history, with other bots filtered out. Restate anything important.
Everything beyond that comes from connectors that an Owner or Claude Tag admin attaches to all of Slack, one workspace, or a single channel, either directly or via a reusable bundle. So the same request can achieve more in one channel than another. To find out, ask:
@Claude what can you access from this channel?
Members can also allow Claude to use their personal claude.ai connectors for their own requests in a channel. Those are separate from the channel's connectors.
Channels, group DMs and one-to-one DMs
| Where you ask | External access | Actions attributed to |
|---|---|---|
| A channel | That channel's connectors | Claude's own service accounts |
| A group DM | Connectors set for the workspace and organisation | Claude's own service accounts |
| A one-to-one DM | Your personal claude.ai connectors | You (except PRs, which still come from the Claude GitHub App) |
A DM is the closest thing to running Claude Code on your own credentials.
Posting into other channels
From a public channel you can ask Claude to post a summary into another public channel it belongs to. It adds an attribution line such as "Sent by Claude in #team-eng on behalf of @priya". From private channels and group DMs it can read other channels but not post. From a one-to-one DM it can create new top-level posts after you click Approve and post. It never posts into Slack Connect channels or channels shared across Enterprise Grid workspaces.
Bringing your Claude Code habits across
When a session clones a repository that has been granted to the channel, it loads the repository's own configuration: CLAUDE.md, .claude/CLAUDE.md, .claude/rules/*.md and the skills in .claude/skills/. Nothing from your machine reaches it. Hooks in the repo's .claude/settings.json do not run.
| What you do locally | What replaces it in Claude Tag |
|---|---|
/model | Admins set a per-channel default; you can ask Claude to switch model in a thread |
/fast | @Claude !fast in a thread, once an Owner allows fast mode |
| Effort level | Not configurable; sessions use the model default |
.mcp.json servers | Ignored, even if committed; use channel connectors |
| API keys in your shell | Provisioned as connectors; the raw secret is attached at the network layer and never enters the sandbox |
| Environment variables | Set by an admin on the environment the channel uses (readable by every session there, so keep secrets in connectors) |
| Setup scripts | Admin-defined on the environment, or CLAUDE.md install steps for repo-specific setup |
Personal settings.json | Not loaded |
| Permission prompts | Sessions run in auto mode; admins pre-approve routine actions with auto mode allow rules |
--continue, /resume | Not needed: replying in the thread continues the session |
Parallel work maps to parallel threads, much like separate terminal tabs. For standing channel conventions, use memory instead of repeating yourself:
@Claude remember for this channel: incident summaries always lead with customer impact
Memory
Memory belongs to places, not people. Each channel has its own notes that Claude reads whenever it works there. From a public channel Claude can also save workspace notes, which every channel in the workspace reads. Private channels read workspace notes but only write to their own. Ask @Claude what do you remember about this channel? to inspect it; anyone in the channel can correct or remove entries.
Commands
A command is @Claude followed straight away by a ! word. Most must stand alone; add extra words and the message becomes an ordinary prompt.
| Command | What it does |
|---|---|
!help | Lists the commands enabled in your workspace |
!configure | Replies with a link to the channel's Configure page (in a DM, the admin settings page) |
!restart | Archives the current session and starts fresh. In a thread it replaces the thread's session; at top level it replaces the channel's session |
!status | A private note telling you whether Claude is still working here, without interrupting it |
!mute / !unmute | Silences Claude in one thread. There is no channel-wide mute; turn off Respond automatically for that |
!fast, !fast on, !fast off | Toggles fast mode for the thread (or the channel's session at top level). May switch a non-Opus session to the newest available Opus model |
!feedback [text] | Opens a feedback form, prefilled with any text you add |
!routines [#channel] | Lists the routines set up in this channel, or privately for another channel you belong to |
!fork [#channel] prompt | Continues the thread in a new thread, here or in another public channel, with the original as background. Public-channel threads only |
Clicking the thumbs-down button on a reply also mutes that thread. A thumbs-down emoji reaction does not.
Routines
Claude Tag can run work without a person typing: on a schedule, by watching a channel, or by following a pull request and acting when it changes. A routine uses the same channel access as a typed request. !routines lists what is set up. For cloud routines outside Slack, see Routines.
Setting it up (Owners)
Setup lives in the Claude Tag section of claude.ai admin settings. You need:
- the Owner role in the Claude organisation being set up;
- Routines enabled under the organisation's remote session capabilities (until then Claude replies that it is unavailable);
- a Slack workspace admin, because only they can run the pairing command and usually install the app;
- usage credits on Team plans, since nothing runs on an empty balance;
- at least one public channel for Claude to join at launch.
The flow:
- Pair the workspace. Install the Claude app from the Slack Marketplace (reinstalling over an existing install keeps settings). In any channel,
/invite @Claude, then send@Claude connectwith no other text. A Slack admin receives a private pairing code that startsworkspace_and expires after 15 minutes. On Enterprise Grid, an org admin also receives anenterprise_code that pairs the whole grid. Paste the code on the setup page. - Connect GitHub (offered if the Claude GitHub App is not installed; skippable).
- Buy usage credits (shown only for card-paying organisations in US dollars with no balance).
- Launch. Pick a monthly spend limit (preset amounts, Unlimited, or Custom up to US$1,000,000; US$2,500 is preselected unless you already have one), select the public channels Claude should join, and decide whether Claude should DM members to say it has arrived. Until you click Launch Claude Tag, mentions get a "Claude isn't on in this channel yet" notice.
Afterwards, give Claude its own identity in each tool: create a mailbox such as claude@yourcompany.example, invite it to the tool with the narrowest role that works, sign in as Claude to create an API key, and add it as a connector. Actions then show up in each tool's audit log under Claude's name.
To verify, mention Claude in a channel it joined and check that the reply ends with a footer naming the model and a Configure link. Then ask what it can access and request something small from each connected tool.
Tip: If any of your services filter traffic by IP address, raise the allowlist request with your network team on day one. It is usually the slowest part of rollout.
Coming from the earlier Slack app
Organisations that used the per-user Claude in Slack keep the same app and @Claude handle; Claude Tag replaces it in place, and the version is chosen per channel, per workspace or as an organisation default. If people see "The legacy Claude in Slack bot is retired", the earlier version is still selected somewhere in your Claude Tag settings. See Claude Code in Slack.
You can also install the Slack app from a Claude Code session with /install-slack-app, which opens a browser to finish the OAuth flow.
What admins can and cannot see
There is no admin view or export of individual messages people send Claude. Owners get spend by channel and kind of work on the analytics page, and an Activity page listing scheduled work, memory files and network events. Thread content is visible to whoever is in the channel, and Anthropic keeps a transcript of each session.