Slack Code Channels for Coding Agents, Explained

Published September 18, 2026 · by the AQ team

Slack Code, announced by Slack on August 20, 2026, turns an AI coding task into a shared Slack channel. Tag a coding agent such as Claude Code or Devin from any conversation and it spins up a dedicated code channel around that task, organized into tabs: one for the conversation, one for the agent's plan, one showing line-by-line code diffs, and one with a live preview of the running output. Everyone in the channel can follow the work, leave feedback the agent incorporates, and sign off before anything ships. It is available on every Slack plan; access to each partner agent is a separate purchase. This guide explains how code channels work, which agents connect as of September 2026, what a code channel is genuinely good at, and where it stops: you are in a conversation around the agent, not inside the live session where the agent is working.

How a code channel works

The mechanics, as Slack describes them: when you mention a coding agent on real work (a feature request in a product channel, a bug report in a support triage thread), Slack provisions a project-specific code channel for that task, visible to the whole team rather than just the person who kicked it off. Inside, the work is split into dedicated tabs so a reviewer can jump straight to what they care about:

• Conversation. The running discussion between the team and the agent. Anyone in the channel can add context or redirect the agent.
• Plan. The agent's proposed approach, visible before the code lands.
• Diffs. Line-by-line code changes as the agent proposes them, in the channel rather than a wall of pasted text.
• Preview. A live preview of the running output (real HTML, per Slack), so the team can catch something broken before it ships.

Governance is built into the container. For high-stakes actions, such as pushing code to production, the agent packages its work for a designated expert to approve right in the channel. When the task completes, the channel archives itself and leaves a searchable audit log. Slack Code inherits Slack's existing permissions and admin controls, so IT does not have to configure a new surface.

Which agents connect, as of September 2026

Slack Code is a surface, not an agent: each coding agent arrives through its vendor's integration, and you need your own access to that agent. Per Slack's launch materials (August 2026):

That framing matters for expectations. The agent's execution (where it clones your repository, runs commands, and builds) belongs to the partner's own product, with that product's setup, repository access, and limits. Slack Code standardizes the collaboration wrapper: the channel, the tabs, the approvals, and the audit trail.

Why a team layer around coding agents matters

Slack's bet is that AI coding has been a story of individual productivity, one developer alone with an agent, and that the next chapter belongs to whoever owns the collaboration around the agents. The data says the solo default is real: a July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans.

A code channel attacks that from the review side. The plan is visible before the diff, the diff is visible before the merge, and the person who approves the production push is named in the channel. For the people around the engineering work (product managers describing what they want, designers checking the preview, a lead signing off), that is a genuinely better surface than screenshots of a terminal pasted into a thread. If those are your people, coding agents for product managers covers what non-engineers can and cannot drive.

What a code channel is not

A code channel is chat around the agent. It is not the agent's working environment, and the difference shows up the moment something goes sideways:

• There is no terminal. You see the plan, the diffs, and the preview: the artifacts the agent chooses to surface. You do not see the shell where it is actually running commands, and you cannot drop into that shell when the agent misreads an error, loops on a failing test, or needs a database migration run by hand.
• Steering is asynchronous. You redirect the agent by writing messages and approving or rejecting packaged work. That is the right interface for review checkpoints, and a slow one for mid-run correction, where watching the live session and interrupting at the right moment is the skill. Steering coding agents mid-run covers why the correction loop matters more than the prompt.
• The environment is the partner's. Each agent runs wherever its vendor runs it, with that vendor's repository access model. The channel cannot give a teammate access to the running environment itself: for a hands-on-keyboard debugging session, someone still needs wherever the code actually executes. Debugging together shows what that looks like when two people share one live session.
• One task, one channel. The model is a channel per task with an archive at the end. An engineer running several agents in parallel across a sprint is managing sessions, worktrees, and branches, which is a workspace problem more than a messaging one.

None of this is a knock on Slack Code. It is a deliberate design: Slack built the review-and-approval wrapper and left the execution environment to the agent vendors. The practical question for a team is which seats need which surface.

Using code channels well

Three patterns follow from the design:

• Pick tasks whose output previews well. The preview tab is the non-engineer's window into the work, and Slack's launch materials center it on running HTML output. A landing page tweak, a dashboard widget, a copy change: strong fits. A backend refactor with no visual output leaves reviewers with only the diff tab.
• Put the deciders in the channel, not just the doers. The channel's advantage over a solo agent session is named sign-off. If the approval for a production push lands on whoever happened to tag the agent, you have recreated the solo pattern with more notifications.
• Decide in advance where escalation goes. When the agent stalls or the diff is wrong in a way that takes hands-on investigation, the channel thread is not where that gets fixed. The handoff (who opens the real environment, where it is, how the fix flows back) is worth agreeing on before the first stuck run, not during it.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ is the other side of the escalation handoff: the place where the agent actually runs, made shareable. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser. Teammates open the same workspace and watch the same live session, terminal included; the owner can approve a control request in one click when a teammate should type, and keeps their own input otherwise. Sessions survive a closed laptop and resume from any device.

The two surfaces split cleanly by seat. A PM or reviewer who needs the plan, the diff, and a sign-off button is well served in a chat channel. The engineer responsible for the run needs the session itself: the terminal when the agent wedges, an editor on the worktree, and a live dev-server preview with shareable links that work without an account for viewing. On AQ, comments pinned on that preview can be sent to the agent as prompts, each workspace gets its own isolated git worktree so parallel tasks never collide, everyone logs into the CLIs with their own Claude or OpenAI accounts (AQ never marks up usage on your own subscriptions), and agents commit, push, and open PRs with per-user GitHub auth.

Pricing is two plans: Free is a personal sandbox for one person (AQ creates a private machine in an isolated network, nothing to install, no time limit), and Team is $50 per user per month early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, with the rate locked for your first 12 months.

Plainly: if your team's need is visibility and sign-off around agent work inside the tool everyone already lives in, Slack Code is a real answer, and it costs nothing beyond the agent access you already pay for. The live session layer is the part it leaves to others, and that is the part AQ builds.