7 Claude Tag for Claude Code users
Which parts of a Claude Code setup carry into Claude Tag, which move to admin settings, and how Slack threads map to sessions.
export const BetaNote = () => Claude Tag is in public beta. Features and behavior described here may change before general availability.;
Claude Tag runs the same engine as Claude Code. When you tag @Claude in Slack with a task, a session starts in a sandbox that Anthropic hosts and your organization configures, not on your machine. That sandbox is the same managed compute behind Claude Code on the web, described in Compute and the sandbox.
If you use Claude Code on the web, a session works the way a web session does, from a fresh clone of your repository rather than from files on your machine. The configuration you checked into that repository, such as CLAUDE.md, hooks, and skills, applies in the session as it does in a web session.
If you run Claude Code in your terminal, the settings on your own machine don’t reach a session, because the session runs in the sandbox and can’t read your machine. For most of those settings, an admin sets a channel-wide counterpart instead, and a few have no counterpart at all. This page shows what happens when a session starts, which admin settings replace your local ones, and how Slack threads map to sessions.
7.1 What happens when a session starts
A session begins with a fresh sandbox and no repository checked out. Your repository’s Claude Code configuration takes effect only after Claude clones the repository, which happens when your message names a repository that an admin has granted to the channel.
| Step | What applies |
|---|---|
You tag @Claude with a task |
Your message is the task, and Claude starts work in a sandbox with no repository |
| Your message names a granted repository | Claude clones it into the sandbox |
| The clone completes | CLAUDE.md, .claude/CLAUDE.md, .claude/rules/*.md, and the skills in .claude/skills/ load into the session |
| Claude works on the task | Hooks defined in the repository’s .claude/settings.json run as they do under Claude Code |
7.1.1 How hooks run in the sandbox
Hooks run inside the sandbox, and every session runs on the same standard sandbox image, no matter which repository it clones. If a hook calls a command that the image doesn’t include, add an install step for it to the repository’s CLAUDE.md, as described in Install project dependencies.
7.2 Local settings versus admin settings
A session reads configuration from your repository, not from your machine. The CLAUDE.md, hooks, and skills you checked into the repository load when Claude clones it, as described in What happens when a session starts.
The settings on your machine never load into a session, because a session runs in the sandbox and can’t read your machine. That includes your ~/.claude directory, your personal settings.json, your shell environment, and the MCP servers you configured locally. They still apply when you run Claude Code in your terminal.
7.2.1 Admin counterparts for local settings
The table shows what takes the place of each setting from your machine. Where a counterpart exists, an admin sets it for the whole channel.
| Claude Code setting on your machine | In Claude Tag |
|---|---|
/model |
An admin sets the default model per channel, and you can switch models in a thread |
| Effort level | Not configurable. Sessions run at the model’s default effort. |
MCP servers in .mcp.json |
Not loaded, even when .mcp.json is checked into the repository. A session reaches external services only through the connections an admin set for the channel, and each connection holds that service’s credentials. |
| Secrets and API keys in your environment | An admin provisions them as channel connections. The raw key never enters the sandbox. It is added to requests at the network layer. |
Environment variables and a personal settings.json |
No counterpart. Every session runs on the same standard sandbox image, so there is no per-person environment to customize. Put non-secret setup in CLAUDE.md as install steps, and ask an admin to add secrets as connections. |
| A setup script for your workspace | No counterpart. Use CLAUDE.md install steps instead. |
| Permission prompts | Sessions run in auto mode, where Claude’s permission checker reviews each action and can stop it. An admin pre-approves routine actions with auto mode allow rules instead of you approving in the moment. |
To change what a session can reach, ask an admin to add a connection. The change applies to every session in the channel.
7.3 How Slack threads map to sessions
You start a session by tagging @Claude in a thread with a task, and that session gets its own sandbox. Each reply in the same thread continues the session, so there is no --continue or /resume to run, and a session stays attached to the thread it started in. See the lifecycle of a request for what happens between replies.
Each thread is its own session with its own sandbox, so run parallel tasks in separate threads the way you would in separate terminal tabs. The sandbox is released after a quiet period, but the conversation stays in the thread, and a later reply continues the session. See what survives between replies.
7.4 Whose credentials a session uses
Claude Code acts with your credentials. What a session acts with depends on whether you tag Claude in a channel or in a direct message.
7.4.1 In a channel
In a channel, Claude acts with credentials of its own, service accounts that an admin provisions. A pull request comes from the Claude GitHub App rather than from you, and a query against a connected service runs with the channel’s credentials no matter who asked. Access is set per channel, not per person.
7.4.2 In a direct message
A direct message runs on your own claude.ai account, with the connectors you added to that account rather than the connections an admin set for the channel, so a DM is the closest match to a Claude Code session on your own credentials.
7.5 Steer a session in the thread
Where you would interrupt Claude Code and edit a file or reprompt, reply in the thread. Corrections and added constraints land as messages, and Claude folds them into the running task.
7.5.1 Keep instructions in channel memory
For instructions that should persist beyond one thread, use channel memory, the instructions Claude keeps for one channel and reads in every session there. Keep repository conventions in CLAUDE.md. Put channel conventions in memory by telling Claude to remember them:
text theme={null} @Claude remember for this channel: reports go out as tables
See What Claude remembers for how memory is scoped and how to correct it.