If your team already argues about bugs and features inside Slack, GitHub just gave that conversation a way to turn straight into code.

GitHub announced that the agentic parts of GitHub Copilot, the same ones behind Copilot CLI (the version you run by typing commands instead of clicking through an app) and its standalone app, are now available inside Slack in public preview. Mention @GitHub in a direct message, a channel, or a thread, and Copilot starts an agent session using that conversation as its briefing.

GitHub Copilot working with teammates in a Slack code channel to implement and review a code change

What actually changed

Once you bring Copilot into a Slack conversation, it can do more than answer questions. According to GitHub, it can:

  • Answer questions about your code and recent GitHub activity.
  • Triage bug reports, update existing issues, or file and label new ones.
  • Investigate a failure, make the code change, and check its own work inside a secure cloud sandbox (an isolated, temporary copy of your project GitHub spins up so Copilot can test changes without touching your real, live code).
  • Open a pull request, GitHub’s term for a proposed code change that sits and waits for someone to review and approve it before it becomes part of the project, and link back to the Slack conversation that started it.

The session keeps running while you’re in a meeting or off doing something else, and you can check in on it, redirect it, or pick up the resulting pull request later from your terminal, the Copilot app, or your code editor.

GitHub also says it’s a launch partner for something Slack calls Slack Code, a new kind of channel built specifically for agent work. When Copilot needs more room, it can spin up a dedicated code channel off the original thread so your team can watch the plan and the changes take shape without cluttering the conversation where the request started. Anyone can join that channel from the thread that spawned it.

Who can actually turn this on, and who can set it off

This isn’t available to everyone yet. GitHub says it’s limited to Copilot Business and Enterprise plans, and it needs setup before anyone can use it: an organization administrator has to turn on the Copilot cloud agent policy, install or upgrade the GitHub app for Slack, and each person who wants to use it has to link their own GitHub account.

Once that’s done, though, the trigger itself is wide open by design. Any teammate who can message a shared channel or DM the bot can start a session, because that’s the point, turning a normal Slack conversation into a coding task without anyone switching tools. GitHub says Copilot’s actions stay “bounded by existing GitHub permissions and controls,” but its own writeup doesn’t spell out exactly which permissions apply to a session started from Slack, so don’t assume it’s identical to what you’d get running Copilot directly in your editor.

That’s the part worth pausing on if your team runs on Business or Enterprise Copilot. A wide-open trigger for something that can open pull requests means the meaningful safety check isn’t who can start a session, it’s what happens after Copilot proposes a change.

The one setting to check before your team starts using this

GitHub says repository administrators can require an additional approval step for any pull request opened under the Copilot app’s own identity, on top of your normal review process, before that pull request is allowed to merge. That’s the setting that keeps a person in the loop even when the request that kicked off the work came from a casual Slack message rather than someone deliberately sitting down to write code.

If you administer a repository on a Business or Enterprise Copilot plan, check whether that approval requirement is already turned on before you tell your team to start mentioning @GitHub in Slack. If it isn’t, turn it on. Using Copilot in Slack also draws from the same usage allowance and any spending caps your org already set for Copilot’s cloud agents, so if your org limits how much cloud agent time people can use, this adds another door into that same limit.

What builders should do next

Try it on something low-stakes first. Pick a real but small bug report already sitting in a Slack thread, mention @GitHub, and let it investigate and propose a fix. Compare the result against what you’d get asking the same question directly in the Copilot app: does the Slack version correctly scope its change to the repository the bug actually lives in, does it open a pull request that links back to the right conversation, and does your required-approval setting actually block the merge until a person signs off. If any of those checks fail, that’s the gap to close before your wider team relies on this for real work.

Where this fits

Bringing a coding agent into the tool your team already uses to coordinate work, instead of asking everyone to open a separate app first, is the same pattern showing up across coding agents this year: meet builders in the conversation they’re already having. The part that actually decides whether that’s safe isn’t the convenience, it’s whether your approval and permission settings caught up to match. Check yours before this becomes the default way your team files a bug.


End of article