Claude in Slack: what it is, what it costs, and what it cannot see

Quick answer

Three different products get called “Claude in Slack”: Anthropic’s own Claude app for Slack, Claude Code driven from a channel, and third-party agents that live in your workspace. They’re billed differently and they reach different things. The question that separates them isn’t what they can do, it’s whose permissions the agent uses when it answers, and most teams don’t find out until after they’ve installed one.

Three different things share the name “Claude in Slack”

It’s worth being exact, because the names blur in nearly every thread on this. Each row below is a different product, with a different owner and a different reach.

The third row is where the surprises live, and it isn’t a fault of any particular vendor. It’s structural, and it applies to ours too.

A Slack agent in a shared channel widens permissions by default

A bot in a channel is one identity answering everyone in the room. That’s the whole appeal. It holds the thread, anyone can tag it, and it can work in the background with nobody waiting on it. But it means the agent can’t act as the person asking, because there isn’t a single person asking. Whoever connected an app set the floor for every other member of that channel, quietly, at install time.

The uncomfortable version: if one person in a 40-person channel connects a Google Drive they have broad access to, every one of the other 39 can now ask questions that read through it. Nobody did anything wrong. Nobody was told either.

There are only 3 ways to answer the permissions question

Every product in this space picks one, and each choice has a cost that arrives later rather than at install.

• Act as the asker. Exact, and it means every person connects every app themselves. Scheduled or ambient work has nobody to borrow credentials from, so it can’t run at all.
• Sync the source systems. One admin connection crawls each app, the index stores per-document permissions, and results are filtered per asker. This needs a connector per app that can read permissions, plus a re-sync loop that never stops. It gives you search and never actions.
• Share one connection. An admin connects once and everyone borrows it. Nothing to build, and you pay for it in permission widening.

Most products pick one of these and apply it everywhere. That’s the decision I want to argue with, because the right answer isn’t the same in a DM as it is in a channel.

We split it by surface, after arguing ourselves out of it once

Gus is our own agent. In a channel it runs as itself: an identity that belongs to your organisation, with its own connections and a view you choose rather than one it inherits. In a one-to-one DM it runs as you: your Slack user resolves to your account, and it reaches your shared space, your personal space, and the apps you connected yourself.

We rejected exactly this split the first time we designed it. The argument against was that a mixed model is unpredictable, because the same question answers differently depending on where you asked it. That objection is real and I still think it’s the strongest one available.

Two things changed our minds. We built the Slack-user-to-account map anyway for another feature, so the expensive half stopped being expensive. And personal spaces shipped, which created the private case we’d claimed didn’t exist: there really is content that belongs to one person, and in a DM there’s exactly one person it could belong to.

That’s the whole justification for the split. In a DM the asker is unambiguous, so acting as them is the precise answer. In a channel there is no single asker, so an identity with a deliberately chosen view is the honest answer. The unpredictability objection survives, and the mitigation is that the boundary is a surface you can see rather than a rule you have to remember.

What the split costs us

In a channel, an answer is the same answer for everyone in the room. It isn’t tailored to the asker’s own access, so a person with broader reach than the agent won’t get more from it than anyone else. Some teams will find that limiting, and they’re not wrong to.

It also means we can’t offer per-user permission mirroring in a channel, which is what people usually mean when they ask for “each person sees their own view”. That needs a connector per app that can read permissions and a permanent re-sync loop. We deliberately don’t have that, and a vendor who does is genuinely offering something we aren’t.

Shopify landed near the same place from a different direction. Their internal agent works in the open by design, and their stated reason is that a private window teaches only the person at the keyboard. They run it at a scale we don’t, which is the best evidence available that the constraint buys something.

What to ask before you install any Slack agent

One question, and it should be easy for a vendor to answer: when the agent replies, whose permissions is it using? If the answer is a shared connection, the follow-up is which account holds it and what that account can reach. If nobody can tell you, that’s the answer.

Two more worth asking, because they only show up after you’ve committed. What happens when a deploy briefly runs two copies of the bot and both see the same mention? And how long is a cold first reply, measured rather than estimated, because in chat the cold case is the common one. Those need numbers, so they’re their own posts.

Frequently asked questions

Is Claude in Slack the same thing as Claude Code? No. Anthropic’s Claude app for Slack is a chat assistant inside your workspace. Claude Code is a coding agent that runs against your repository, and it can be driven from Slack through an integration you set up and host. They have different reach and different billing.

Can a Slack agent see private channels? Only the ones it’s been invited to. The more useful question is what it can reach through the apps someone connected to it, which is usually broader than the channel list and is not visible from inside Slack.

Does each person get their own permissions? In a DM with Gus, yes: the turn runs as you. In a channel, no, and that’s true of every shared-channel agent. One identity answers everyone, so the reach is whatever that identity was given.

What happens to what I say in a channel? It’s in the channel, which is where it was already. The thing worth checking is what the agent writes back into, and whether anyone can read that later without going through Slack.

Do I need a separate agent for Codex or Cursor? Not if the context lives somewhere all of them can read. That’s the case we make for keeping it in your own repository rather than inside one vendor’s assistant, and it’s the subject of the next few posts.

References

• Under the River · Shopify Engineering, 28 May 2026, on running an agent only in public channels.
• Slack API: chat.postMessage · the scopes a channel agent needs, and what each one grants.
• Slack OAuth scopes · the full list, worth reading before approving an install.
• How we handle your data · what Craftspace stores and where.