Picture this: an engineer asks Claude a question in a Slack channel, Claude starts digging through the codebase, running tests, pushing branches. Halfway through, a product manager realizes the requirements are wrong and types directly into the same thread, “Wait, don’t merge that yet, change it to X” — Claude catches it, pivots immediately.

This isn’t science fiction. It’s Claude Tag’s default behavior. And here’s the part that breaks your intuition: Claude isn’t anyone’s personal secretary. It’s a shared teammate for the entire channel. Whoever speaks in the thread, Claude listens to them. As for how to work with an AI teammate without it making a mess, SD-23 covered that — this post focuses on the official product itself.

Mogu inner monologue:

Mogu thinks Anthropic got this right: first-generation Claude in Slack was a search box that talked back. The second generation finally admits someone in the channel will change the requirements mid-run. “Tag” comes from Slack @ mentions, but what it actually sells is a work session that lives in the channel. Anyone still treating this as a private chatbot is volunteering for chaos.

Thread = Work Session, and Anyone Can Steer

The core operating unit of Claude Tag is the thread. Once you @Claude in a Slack channel, that thread becomes a persistent work session. Anyone can reply directly in the same thread to change what Claude is working on, no need to @ again.

Mogu whispers:

This design turns Claude into a “shared microphone.” The upside: team collaboration flows smoothly. The downside: if someone says something dumb, the whole thread’s direction gets dragged along. There’s no such thing as “this is Mogu’s Claude session, everyone else keep out.” Think about it: if the office intern can redirect the assistant at any moment, is that a feature or a bug? (⁠¬⁠‿⁠¬⁠)

This also means Claude Tag isn’t suited for tasks that “only certain people should know about” — everyone in the channel can see the thread contents and the output. If a thread goes too long without new messages, its session state expires; next time someone replies, Claude rebuilds context from thread history, but won’t perfectly pick up discussion details from weeks ago. This is the physical limits of the context window. (SD-22 explains what context windows are and why they have limits.)

The Sandbox Evaporates, the Thread Persists

Claude Tag runs in an Anthropic-managed sandbox, the same compute environment as Claude Code on the web. This sandbox is ephemeral: leave it idle long enough and it gets released, and the next time Claude responds, it gets a brand new instance. Branches not pushed, output not posted back to Slack — gone by next time.

How does Claude “remember” what it was doing in a fresh instance? Thread context (the verbatim transcript of everything in that Slack thread) and memory (a cross-session notebook searchable by channel and time). The sandbox can be thrown away and restarted anytime because thread and memory are separate — but this means Claude’s workflow has to be “finish and post back”: write the code, push it; finish the research, post the conclusion.

Mogu murmur:

Mogu likes how ruthless this is: every wake-up gets a fresh machine, which is Anthropic saying “nothing in the sandbox is trustworthy, and nothing there deserves to be missed.” Thread is long-term memory; the sandbox is scratch paper that gets collected. Leaving half-finished work there isn’t forgetting to push — it’s dating a hard drive that evaporates. ╰⁠(⁠°⁠▽⁠°⁠)⁠╯

Credentials Never Enter the Sandbox

Claude Tag can hit external APIs, connect to GitHub, read private repos — but there are no credentials whatsoever inside the sandbox. This is the core of the Agent Proxy design: when Claude needs to call an API, the request goes through Anthropic’s proxy layer, and credentials get injected only at the network boundary. The code running in the sandbox never touches a token.

Mogu murmur:

Mogu’s stance: this is the correct default. Even if someone hides a prompt injection in a document trying to trick Claude into printing an API key, Claude can’t — the token never entered the sandbox. Anyone still stuffing tokens into environment variables and hoping the agent behaves is running last decade’s threat model. (⁠◕⁠‿⁠◕⁠)

Permission management is per-channel: admins bundle credentials, repo access, and domain allowlists into an Access bundle. Network is default-deny; only allowlisted endpoints can be reached. Credential rotation is painless — update once in Anthropic’s admin panel, no sandbox redeployment needed.

Wrapping Up

The design assumes you’re okay with Slack-only and letting Anthropic manage credentials. Build your own, and all of that becomes your responsibility — but you also get to choose: LINE, Teams, intranet, self-managed keys, different models.

Mogu chimes in:

Mogu is not reciting the feature list again. The entry requirements are the product stance: Team or Enterprise, Anthropic org owner plus Slack workspace admin, no ZDR (Zero Data Retention). Channels bill against org quota; DMs against personal accounts. This was never meant to be a private toy. ʕ⁠•⁠ᴥ⁠•⁠ʔ — ShroomDog

Next post, we start building our own. LINE first, then Teams and the security crisis. With tools like OpenClaw, the same concept moves to any platform, any model, any network environment.