The appeal is straightforward: fewer handoffs between “someone should fix this” and an actual proposed fix. The important qualification is that a convenient chat interface does not remove the need for repository permissions, careful context handling or code review.
What changed with general availability
GitHub says @GitHub can now identify the intended repository from a message and launch a coding session without making the user select that repository again. Onboarding also handles several common stumbling blocks more smoothly: being signed out, lacking a default repository, switching repositories and granting app access.
The release also fixes a problem that could stop the agent responding to follow-up messages. That matters for an iterative workflow: requesting a change is only the beginning; correcting the agent’s assumptions is often where the useful work happens.
Issues and pull requests created through the integration now include this description text:
GitHub describes this as clearer attribution. For reviewers, it provides a useful starting point for tracing a request—but it should not be mistaken for an approval stamp.
Teams Canvas is a review surface, not an editor
GitHub’s Teams documentation adds an important detail to the announcement: Canvas is read-only. When a session starts, an Open canvas button opens a panel beside the conversation, showing the implementation plan, file changes and an overview of generated pull requests. Its contents are limited to what the viewer’s linked GitHub account is authorized to see.
To request revisions, mention @GitHub again in the same Teams thread. GitHub says the agent incorporates messages added since the previous mention. Canvas therefore helps people inspect the work; the conversation remains the place to steer it.
That distinction makes the feature easier to evaluate. Think of Canvas as the viewing window into the workshop—not a second code editor hidden inside Teams.
Getting started—and knowing where work continues
GitHub documents both integrations as available with all paid Copilot plans. For Slack, users need the GitHub integration installed and must connect their GitHub account when prompted. Organization owners can disable the relevant cloud-agent policy, so general availability does not guarantee that an employer has enabled access.
A practical Slack starting sequence is:
- Open a direct message with the GitHub app or mention
@GitHubin a thread. - Follow the account-connection prompts.
- Specify the target repository and task; direct messages cannot have default repositories.
- Once the agent creates a dedicated Slack Code channel, continue steering that task there.
Unlike the Teams side-panel experience, Slack’s documented workflow uses a dedicated channel for each task. These are integration behaviors, not features that should all be presented as newly introduced in the November announcement.
Two checks before delegating a task
First, inspect the conversation context. GitHub warns that both integrations capture the entire thread and store that context in generated artifacts. A direct message can narrow the discussion supplied to the agent. The practical lesson: choose the thread deliberately rather than summoning the agent into an sprawling conversation containing unrelated information.
Second, distinguish participation from authorization. In Teams shared conversations, generated artifacts use the app’s identity. Starting or steering code changes requires write access to every selected repository. GitHub also documents one additional approval for app-created pull requests where repository rulesets already require at least one approval.
The strongest use case is not “let chat replace engineering.” It is reducing the administrative distance between a well-scoped discussion and reviewable work. Keep the request focused, verify the repository, inspect the proposed changes and treat the resulting pull request as a proposal—not a finished verdict.