Slack Code: multiplayer coding also means a multiplayer prompt

On 20 August 2026 Slack shipped a new channel type, and it is the agent that spins one up. Tag Claude, Devin, Copilot or a Vercel agent in any conversation, a code channel appears, and the plan, the diffs and a live preview land in a place your whole team can read. The pitch is that coding stops being a private tab. That part is real. The part worth thinking about before you switch it on is what a shared channel does to the two things that decide whether an agent is safe to run: who can talk to it, and what counts as the record of what it did.

• What it is. A project-scoped Slack channel created by a coding agent, holding the conversation, the plan, code diffs and live previews, which archives itself when the work ends.
• Who can use it. Live for Claude, Devin, GitHub Copilot and Vercel, ChatGPT soon, on any Slack plan. You still pay for the agent separately.
• The permission model. It inherits Slack's, which means your agent's blast radius is now the channel member list, and adding someone to a channel is not a change-controlled action.
• The part I would gate first. Anything a person pastes into that channel is agent input. Slack has already been burned by that class of problem, in 2024.
• The verdict: WATCHING. I have read Slack's two announcement pages and the developer docs, not run it, and the two do not read the same on which agents shipped.

The harness doing the real work here is still Claude Code in a terminal, and the last two times a vendor moved the agent somewhere new I wrote up Meta's Muse Code and DeepSeek's harness. This one is not a harness. It is a room.

What is Slack Code?

Slack Code is a channel type built for agent work. You mention a coding agent in a normal project channel, it creates a dedicated code channel for that one task, and everyone invited can follow the work in separate tabs: the conversation, the plan, the code diffs with the old line struck through next to the new one, and a live preview of HTML output running in the channel. When the task is done the channel archives itself and stays searchable as a record.

Slack's announcement says it is "live today for teams using Claude (Anthropic), Devin (Cognition), GitHub (Copilot), and Vercel integrations, with OpenAI (ChatGPT) available soon". Slack's longer piece on X reads as though ChatGPT is already in, listing it among the founding partners the release "connects seamlessly with", and adds the line that matters for budgets: available on any Slack plan, access to each partner agent required.

Two pages from the same company on the same day, one saying ChatGPT is coming, the other reading like it is here. Small thing, and worth knowing before you promise a team a tool it does not have yet.

One number carries further than the rest: "over 70% of code channels spin up and close within a single day, from idea to merged PR". Slack does not say what that is measured on, and it cannot be your workspace on day one. Read it as design intent rather than a benchmark. Code channels are built for one task that finishes, not for a project that lives for a quarter.

The channel is the log, and that is the actual product

Strip the collaboration language and Slack Code is a readable audit trail with a chat window attached. The self-archiving is the tell. A channel that closes itself and stays searchable is not a workspace, it is a record with a lifecycle.

I have written about this twice from the other direction. Meta's Muse Code put an append-only event log at the centre of its harness. DeepSeek went further and made it a rule: model-visible means logged, so anything that reaches a model request has to be reconstructable from the log, and a message that cannot be logged cannot be sent. That is an invariant. It holds on the day everything breaks, which is the only day a log matters.

A Slack channel is a different artefact, and the word audit is doing heavy lifting in the marketing. The right-hand column below is read off the launch material, not off a run of my own.

You want both. The channel tells you a human approved the merge at 14:12 and who it was. Nothing Slack has published says it tells you which files the agent read to get there, or what came back from a tool call the agent did not mention. If your agent touches anything that spends money or writes to production, the harness-side log is still the one that answers the incident question. I go through what that instrumentation looks like in practice in the monitoring post.

What Slack adds is the thing engineering logs are terrible at: a record a product manager will actually open. Every approval, objection and change of direction lands in the same place as the diff, in a tool the whole company already reads. That is worth something on the day someone asks why the pricing page changed.

Your agent's permission model is now the channel member list

Slack's own words: agents in code channels "inherit Slack's built-in security model, permissions, and admin controls from day one, without any additional IT lift". The first half is true and useful. The second half is where I would push back.

Inheriting a permission model means adopting its granularity. In Slack, the unit of access is channel membership, and adding someone to a channel is the most casual administrative act in the company. Nobody files a ticket. Nobody reviews it a quarter later. That was fine when the worst outcome was a person reading a thread. It is a different proposition when the channel contains an agent that can open a pull request, and when the channel itself was created by that agent rather than by a human who thought about who belongs in it.

The audit question does not disappear, it moves. Here is where I would go looking for answers before turning this on for a team, and what the announcement does and does not settle.

None of that is an argument against code channels. It is an argument for treating a code channel as a production surface with a member list, which is exactly the framing that "without any additional IT lift" discourages. The twelve gates I run before an agent gets real access apply here unchanged, and gate one has always been the same question: who can make this thing act.

Slack's model is genuinely good on one point. High-stakes moves, pushing to production among them, get packaged for an expert to sign off on inside the channel, and that sign-off is visible to everyone watching. Approval as a property of the setup rather than a habit of the operator is the right shape. It is the same reason every campaign my automation creates through the Meta Ads API arrives paused. The gate does not depend on anyone remembering it.

Multiplayer coding also means a multiplayer prompt

An agent in a channel reads the channel. That is the whole feature: it picks up the conversation, the screenshots and the docs already shared, which is why the product manager in Slack's own example gets a useful fix without writing a spec. The same mechanism means every message in that channel is agent input. Not just instructions addressed to it. The pasted bug report from a customer. The stack trace copied out of a log viewer. The forwarded email. The screenshot of a web page with text in it.

In a terminal, my agent's context is something I assemble. In a code channel, the context is assembled by whoever is in the room, plus whatever they paste from outside it.

This is not a hypothetical, and it is not new to Slack. In August 2024 PromptArmor showed that Slack AI could be turned into an exfiltration path through indirect prompt injection. The attacker never touched the data. They posted instructions in a public channel of their own, one the victim had never joined, and Slack AI pulled those instructions in while answering a question the injection had been written to match. The answer came back with a link that shipped the victim's own API key, held in a private channel, to the attacker's server the moment someone clicked it. Simon Willison's write-up has the payload and the mechanics. Slack shipped a patch and said it had no evidence of unauthorized access to customer data. The response that came first is the one I keep coming back to: messages posted to public channels can be searched and viewed by every member of the workspace whether or not they joined the channel, and that is intended behaviour. Beside the point once a model is reading those messages and acting on them.

Code channels do not reintroduce that bug. They do put a more capable agent in the same kind of room, two years later, with a pull request at the end of the conversation instead of a summary. So three practical consequences, all cheap:

1. Treat a code channel as untrusted input to your agent, the same way you treat an MCP server you do not own. Content pasted from outside the team is the highest-risk thing in the room.
2. Keep the destructive capability behind the sign-off step, not behind channel etiquette. Etiquette does not survive a busy Friday.
3. Do not let the convenience of one channel become one channel with everyone in it. The blast radius of an agent is the set of people who can talk to it, and code channels make that set easy to grow by accident.

Slack says anyone in the channel can pause, redirect or stop the agent if it drifts off track. That is a real control, and it assumes the person doing the redirecting meant to.

The wider reach point holds too. A coding agent stops being a coding tool the moment it can touch your files, analytics, hosting and email through MCP servers. Putting that agent in a channel does not change its reach. It changes how many people can aim it.

Who can actually build on this today

Short answer: four agents today, five when ChatGPT lands. If yours is not one of them, you are waiting, and this is where what shipped and what was promised come apart.

Slack says the code channel APIs let partners shape agent behaviour, auto-provision accounts, authenticate users and automate parts of the workflow, and that they will open to the broader developer community soon, so any custom agent doing any kind of work can join a code channel. Soon has no date attached.

I checked what a developer can reach right now. Slack's agent documentation does not mention code channels or Slack Code at all. What it does document is the agent surface underneath: turning on the Agents feature adds the assistant:write scope, every DM with a user becomes a thread, and two session methods, agents.sessions.setStatus and agents.sessions.rename, require chat:write. That is the platform layer, and it is real. The code channel layer is not public, which is the concrete evidence that this release is partner-shaped rather than platform-shaped.

So the launch splits cleanly in two. The agent experience across Slack, named identities, real thread titles, an Agents tab where you can see sessions and stop one mid-task, and one-click installs for agents built on tools like n8n, LangChain and Vercel, is available to build against today. Code channels are a founding-partner product with a documentation page that does not exist yet.

That distinction decides whether this belongs on your roadmap. If you run one of the partner agents, it is a setting. If you were hoping to put your own agent in a code channel this quarter, there is nothing to write against, and I would not plan around soon.

Does Slack Code replace a terminal?

For me, no, and I do not think that is what it is for.

Everything I run that matters is a long session against a repo with rules that took months to tune: deny lists, approval prompts, directories that stay off limits. Those rules are the switching cost of any harness, and they do not travel by moving the conversation into Slack. The 70% figure points the same way. A surface where most work is born and buried inside a day is aimed at the small task that never got done because it needed an engineer's attention for twenty minutes.

Which is the actual unlock, and it has nothing to do with engineers. The person who benefits from Slack Code is the one who currently writes a ticket and waits: the PM with a bug report, the designer with a copy fix, the marketer who wants a landing page section changed. They get a reviewed change with a preview instead of a place in a queue. Every one of those tasks is a task an engineer was never going to enjoy.

The risk on that same path is obvious once you say it out loud. Lower the cost of asking for code and you raise the volume of code that arrives without anyone owning it afterwards. The channel archives itself. The change does not.

For events delivered into an existing terminal session, native Claude Code Channels have their own sender controls, session lifetime and permission relay.

Should you turn on Slack Code?

Turn it on if you already run one of the partner agents and your team argues about builds in Slack anyway. Build a process on it, not yet.

The verdict is WATCHING, which on this site means it looks promising and has not carried real work here. TESTED means it did a job end to end at least once. The rules are in the field notes post, and the honest position today is that I have read Slack's blog post, its longer piece on X and the developer docs, and that is all.

What I would do with the first hour, if you have access: get a code channel opened for something trivial, then add one person who was not in the original conversation and watch what they can do to the agent without anyone signing anything off. That answers the only question I care about here. Everything else in the announcement is a better version of something that already worked.