GitHub takes Slack and Teams coding agents to general availability GitHub takes Slack and Teams coding agents to general availability

The discussion stays beside the work

The latest release lets the integration infer a repository from a message rather than asking for the same selection again. GitHub also adds the requesting username and originating chat platform to descriptions of issues and pull requests it creates. Those details serve different purposes: one reduces setup friction, while the other gives reviewers a clearer account of where the work began. A shared review surface matters because the person who describes a bug is not necessarily the person who evaluates its implementation.

Coding from chat predates this release

GitHub introduced the newer Slack experience in public preview on August 21. That version already supported investigating failures, changing code and validating work in a cloud sandbox. It could continue asynchronously, with teammates contributing context or redirecting a session in a dedicated code channel. Existing GitHub permissions still bounded its actions. Repository administrators could require an additional approval for pull requests attributed to the Copilot app. General availability therefore should not be read as the invention of chat-based coding, or as permission to bypass a repository’s review rules. The change is a release milestone for an established workflow, with a new Teams review interface.

More context arrived during preview

The September 25 update expanded the material available to the agent. Slack gained support for files, attachments and message links. Teams supported inline images, forwarded messages and conversation history. The integration also checked for similar issues before creating new work and linked results back to their originating discussion. These additions address a practical failure mode: a ticket can lose the screenshot, qualification or later correction that made the original conversation useful. Keeping those inputs connected reduces the amount a person must reconstruct, although it does not establish that the resulting code is correct.

One conversation can span repositories

On October 15, GitHub added multi-repository work within a single conversation. Its examples included investigating a problem across frontend and backend code and finding pull requests across repositories. That changes the unit of collaboration from a single checkout to the discussion around a task. A team tracing a frontend symptom into a backend service can keep that investigation together instead of opening another chat for each repository. The benefit is continuity of context. The corresponding review task is still concrete: identify which repository each proposed change affects and which maintainers own it.

Attribution is part of the handoff

Taken together, the releases move more of the handoff into the place where a team discusses work. Conversation context, repository selection and review are separate steps, even when the interface places them side by side. A visible origin helps a maintainer recover the request; a working preview helps evaluate a proposed result. Neither substitutes for tests or an authorized merge. For builders, the useful distinction is between making it easier to start a coding task and making its finished change acceptable to ship.