The distinction is more than semantic for engineering teams. A pull request is an artifact for review; deployment still depends on whatever branch protections, CI checks, GitHub Actions workflows, release gates, and environment approvals a repository already enforces. Neowin’s report correctly identifies the new Teams integration, but its “write and deploy” framing overstates what GitHub has actually announced.
GitHub says the feature lets a Teams participant mention @GitHub in a direct message, channel, or thread, provide a task, and start a Copilot cloud-agent session. The agent can use the conversation as working context, operate asynchronously in a secure cloud sandbox, create code changes, and return a pull request for the team to examine. The company calls the model shared agentic work: other people in the conversation can add context, inspect progress, and redirect the task while it runs.
This is a meaningful expansion of the GitHub app for Teams preview first introduced in September 2025. That earlier integration already allowed users to ask Copilot coding agent to generate a pull request from a Teams conversation. The August 21 release makes the collaborative mechanics more explicit: Copilot can create a dedicated Teams code channel for the work, preserve the original conversation as task context, and let several participants steer one session instead of making the interaction feel like a private bot command issued by a single developer.
A Teams thread now becomes the agent’s requirements document
The headline feature is not merely that Copilot appears inside Teams. Developers could already paste a discussion into an issue, open an editor, prompt an agent, and create a pull request. The new workflow removes that handoff by treating the Team conversation itself as the input record.
GitHub’s documentation says the agent captures the entire thread when it is mentioned in Teams. That means a typical engineering exchange—an incident report, competing theories about the failure, a decision on the likely fix, links to logs, and agreement on a rollout path—can become the basis for an agent task without a developer having to reconstruct that context in a separate prompt.
That also means Teams threads need to be treated with more care than ordinary chat. GitHub says that conversation context is stored in the artifacts the agent generates. Teams discussions frequently include details that do not belong in an issue description or PR: customer information, production identifiers, credentials mistakenly pasted into a chat, architectural alternatives that were rejected, or operational discussions that should remain confined to the group.
For sensitive work, GitHub recommends using a direct message to the GitHub app to constrain the context. That is sensible advice, but it changes the collaboration model. Teams administrators and engineering leads should decide which channels are appropriate for agent invocation before encouraging developers to use @GitHub as a routine shortcut.
The agent’s context is also broader than the sentence that triggers it. A request such as “implement the agreed fix” is only as safe and accurate as the preceding thread is clear. Teams conversations that contain abandoned ideas, contradictory directions, or casual speculation can make a poor substitute for a properly scoped issue.
The new code channel is the real collaborative change
According to GitHub’s release notes, an agent session launched from Teams can create a dedicated code channel where participants follow its progress and provide additional direction. That is the substantial change over the earlier “mention the bot, receive a pull request” model.
A dedicated channel can keep an active agent task from burying the original incident or planning discussion beneath status updates. It also gives the team a visible place to review what the agent believes it is doing before the resulting pull request becomes the only engineering record. GitHub says participants can monitor progress there and continue steering the session after the original chat or meeting discussion has moved on.
The arrangement makes Teams a front end for GitHub Copilot cloud agent rather than a replacement for normal development tools. GitHub explicitly says users can pick up the agent-generated artifacts later in a terminal, the GitHub Copilot app, or their preferred IDE. Teams starts and coordinates the work; GitHub remains where the code, branch, pull request, checks, and merge history live.
That split should be reassuring to teams worried that Microsoft is moving code review into chat. The announced workflow does not eliminate GitHub’s normal review surface. It does, however, make it easier for a task to begin before a developer has opened an IDE, which may be useful for small fixes, test additions, documentation work, refactoring, and investigations that emerge during stand-ups or incident discussions.
Repository permissions still decide who can act
GitHub’s security model is stricter than the promotional language around “anyone can help direct” may suggest. Everyone in the Teams conversation can contribute context, but only users with write access to the target repository can trigger Copilot to make code changes. Workspace guests and outside repository collaborators cannot start or steer a Copilot session through Teams.
The identity used for a task also depends on where it begins. In a direct message with the GitHub app, Copilot takes actions under the linked user’s GitHub permissions. In a shared context such as a channel or group thread, GitHub says the agent creates artifacts under the integration’s app identity rather than an individual developer’s account.
That has an operational consequence that organizations should check now: a PR opened from a shared Teams conversation may not look like it was authored by the engineer who requested the work. It will instead be attributed to the Microsoft Teams Copilot integration identity. Audit trails, CODEOWNERS rules, automated policy checks, and incident-review processes should be tested against that identity before the feature is made broadly available.
GitHub has added a compensating control. Repository administrators can require one extra approval for PRs created by the Teams Copilot integration. If a repository normally requires two approvals, a Copilot-created PR can be configured to require three. GitHub says this extra-approval behavior is enabled by default where a repository already requires at least one approval.
That additional approval is a merge safeguard, not a code-quality guarantee. Teams participation can improve the completeness of an agent prompt, but it does not verify that generated changes meet performance, security, compatibility, or business requirements. Existing CI, dependency scanning, secret scanning, test coverage expectations, and deployment approvals remain essential.
Preview access has technical and financial gates
The integration is in public preview, not general availability. GitHub says it is available on paid Copilot plans, but organization and enterprise users may need an administrator to enable both Copilot cloud agent and cloud sandboxes before it can be used.
There is also a Teams-side prerequisite that the Neowin report leaves out: GitHub’s current setup documentation requires Microsoft Public Developer Preview to be enabled in the Teams client. That is an important limitation for businesses that restrict preview software on managed endpoints. A team cannot assume that installing the GitHub app from Teams is enough.
Costs are another omitted detail. GitHub says Teams-started cloud-agent sessions consume AI credits, and cloud sandbox use is billed separately. Organizations can govern agent-credit usage through usage-based billing budgets, while sandbox spending can be controlled with product-level or SKU-level budgets. The feature therefore belongs in the same capacity and cost-governance discussion as any other cloud agent, rather than being treated as a no-cost extension of ordinary Teams chat.
The setup sequence is straightforward but should be owned by the right administrators:
- An organization must enable Copilot cloud agent and cloud sandboxes before managed users can start Teams-based sessions.
- A Teams administrator or authorized user installs the GitHub app for the team, after which individual members connect their GitHub accounts.
- Developers select or specify the repository and branch, then mention
@GitHubwith a scoped task. - Repository administrators should verify that the integration identity is covered by branch rules, required checks, approval rules, and audit processes.
GitHub has not announced a general-availability date. For now, the practical takeaway is narrower than the headline suggests: Teams can become the place where an engineering discussion turns into a visible, reviewable Copilot task, but the pull request—not the chat—is still the boundary before code can move toward production.