🚀 New: chi (χ) — an open-source autoresearch harness for fleets of LLM coding agents. Read the announcement.

GitHub Copilot Moves Into Slack, and Governance Becomes the Interesting Part

GitHub shipped a public preview that brings its Copilot coding agent into Slack, with shared multiplayer sessions and dedicated 'Slack Code' channels. The interesting engineering problem is not the chat UI, it is the permission model that decides whether an agent-authored PR can merge unattended. A runnable simulator walks through it.

Contents

Yesterday GitHub shipped something that looks, on the surface, like a chat integration: you can now mention @GitHub in a Slack conversation and have the Copilot coding agent triage a bug, investigate a failure, and open a pull request, all without leaving the thread where your team was already talking. That is a nice convenience. The part worth an engineer’s attention is underneath it, GitHub is quietly asking every organization to decide, explicitly, how much autonomy an agent gets before a human has to sign off.

That question was easy to dodge when coding agents lived inside a single developer’s IDE or terminal. One person, one agent, one set of local permissions, and any bad output just sat in their own branch. Putting the same agent into a shared Slack channel, reachable by anyone on the team, in the flow of ordinary conversation, changes the blast radius. It is the same shift every team goes through the first time they give a CI bot write access to main, except this bot writes its own code first.

Three things worth understanding

The agent session is shared, not personal. Mentioning @GitHub in a DM, channel, or thread starts a session anyone in that conversation can see and redirect. GitHub calls this “multiplayer,” and the framing is deliberate, teammates can watch how a colleague prompts the agent, add missing context mid-run, or stop a session that is heading the wrong way. It is a genuinely different interaction model from a private Copilot CLI session, closer to pairing than to delegating.

Slack Code channels give agent work its own space without losing the thread. Rather than flooding the original conversation with diffs and tool output, Copilot spins up a dedicated code channel scoped to that task. Inside it your team can inspect the plan, review the diff, look at rendered previews of what changed, and keep iterating, then jump back to the original thread once there is something to review. It is a small UX decision, but it solves the real problem of agent output drowning out human conversation in a shared channel.

Every action stays bounded by GitHub’s existing permission model, and merges get an extra gate. Issues and pull requests the agent creates are attributed to the Copilot app identity, not to whoever typed the mention, and everything it does is still constrained by that identity’s actual GitHub permissions. The detail that matters most operationally: repository admins can require an additional human approval specifically for any pull request attributed to Copilot before it can merge, on top of whatever review rules already apply. That is the lever that decides whether this is “agent proposes, human disposes” or something looser.

Try it: will a given setup let the PR merge unattended

The outcome of an @GitHub session in Slack depends on three independent settings your org controls. Toggle them to see what actually happens.

About the demo

This models the governance rules described in GitHub’s own changelog announcement. It runs entirely in your browser and does not call the GitHub API.
Set the toggles and click Check outcome.

Where this leaves anyone rolling it out

The chat surface is the least interesting part of this release, teams already put bots in Slack. What is new is that GitHub is shipping the governance primitives alongside the convenience feature instead of bolting them on later: app-identity attribution, policy gating at the org level, and a merge-time approval override that is separate from normal branch protection. If you are an engineering lead evaluating this, the rollout checklist is not “does the agent write good code,” it is “who can flip the cloud agent policy on, and did we turn on the extra PR approval before the first person in a busy channel tries it.” My take is that as agents move from personal tools into shared, always-visible team surfaces like Slack and Teams, this pattern, capability plus an explicit, auditable approval gate, becomes the template every vendor converges on, because the alternative is an agent quietly merging to main while everyone assumed someone else was watching the channel.