Copilot in Teams: How a Bug Report in Chat Becomes a Pull Request – and Who Approves It

It is Tuesday morning, shortly after eight. In the Teams channel of your software department, a message from a customer appears: the application crashes when an invoice is generated. Someone replies, “I’ll take a look.” Then the usual route begins: the error is copied into a ticket, the ticket lands in a queue, a developer opens it, searches for the spot in the code, writes a correction, and a colleague reviews it. Between the message in the chat and the first code proposal, hours or days often pass, and a large share of that time is copying and waiting, not developing.

This is exactly where an announcement comes in that GitHub published in its changelog on October 23, 2026. The title reads “Turn notifications into code with GitHub Copilot in Teams.” This article shows what the source says, what it does not say, what it means for a company with its own software development, and which preparation before November 16 makes sense.

What GitHub announced

The primary source is GitHub’s changelog entry of October 23, 2026, classified as an “Improvement,” that is, not as a preview or beta feature. We read the entry in full. It is short, so the key statements are easy to summarize:

• A new app in Microsoft Teams: The GitHub app in Teams connects notifications with Copilot. Teams are meant to turn issues into fixes faster without leaving the conversation.
• Where it works: Notifications are possible in channels, in group chats and in private chats.
• How it is triggered: By mentioning @GitHub, updates can be turned into actions.
• The name change: The app in Teams is now called “GitHub.” It used to be called “GitHub notifications.”
• The deadline: The previous app is renamed “GitHub (deprecated)” and retired on November 16. Anyone who wants to keep using Copilot in Teams has to install the consolidated app.

A note on the date: the source says “November 16” and does not state the year explicitly. From the context (published on October 23, 2026), the next November 16 is the obvious reading; we therefore reproduce it as “November 16” and claim no further details.

The example from the source: from bug report to pull request

GitHub describes an example flow in three steps. We reproduce it as it appears in the source and then put it in context.

1. Notification: A bug report appears in Teams.
2. Action: @GitHub investigates the problem, fixes the bug and creates a pull request.
3. Review and delivery: The team reviews the proposal, tests it and merges it.

For readers without a development background: a pull request is a proposal for a change to the program code. At first it is only an offer. The actual software changes only when someone accepts the proposal, that is, merges it. This intermediate step is the core of the whole construction: the agent may propose, but not decide alone.

The decisive sentence of the example is in the third step: the team reviews, tests and merges. The agent delivers the draft, the human carries the decision.

This is remarkably unspectacular, and that is a good thing. It means the news value does not lie in an agent writing code. That was possible before. What is new is the place of the trigger. The bug report no longer has to be copied into another tool first, but is handled where the team is already talking.

Availability: what the source says and what stays open

With any news about AI agents, it is worth asking whether you can use it today or whether it has only been announced. For this case, the following can be said:

• Status: The entry is marked as an improvement. It contains no beta or preview notice. It describes the app and its installation as existing. The retirement of the old app is already scheduled.
• Region: The source names no restriction to particular countries. Whether and from when the feature is reachable in every country and for every account type, it does not document. For Germany, Austria and Switzerland, the source gives neither a commitment nor an exclusion.
• Prerequisites: Named are a GitHub account that you connect in the app and a repository that you select. Whether using Copilot in Teams requires a particular Copilot license or plan is not stated in the source.

This last gap matters in practice. If your company has no Copilot license today, you do not learn from this source whether the feature is available at no extra cost. That can only be clarified by reading GitHub’s documentation or trying the app in a test environment. We therefore name no price and no license condition, because we have checked none.

The concrete deadline: November 16

The most tangible point of the announcement is neither the new feature nor the example, but the deadline. Anyone who has the previous notification app in Teams in use receives a deprecation notice: the old app is retired, and the new, consolidated app replaces it. According to the source, existing notification features are kept if you switch to the latest version.

What follows can be said in three sentences. First: if your development team uses GitHub notifications in Teams, there is something to do by November 16, regardless of whether you want to use the Copilot feature. Second: anyone who simply installs the new app along the way should first decide who may use it where. Third: the deadline is a good occasion to clarify the question of approvals now and not after the first unplanned pull request.

We cannot judge how many companies use the old app. The source gives no figures on users or installations. That, too, is among the things we do not claim.

What this means for a mid-sized company

Many mid-sized companies have a small IT or development department, some only a few people who look after the web shop, interfaces, customer portal or production software. For them, the paths between “something is broken” and “it is fixed” are especially long, because the same people look for errors, build new features and answer requests. An agent that takes in bug reports and prepares a correction proposal can shorten these paths, but only if the review at the end reliably takes place.

What we can derive from the source is limited, so we phrase it carefully. The source says that teams are meant to turn issues into fixes faster. It names no time savings, no success rate and no measurement. How often a proposed pull request is actually correct, how much review effort it causes and for what kind of errors the flow works, you do not learn from the entry. You have to observe that in your own code, with your own errors.

A few considerations that are worthwhile for any rollout, independent of the source:

• Chat is a wide door. In a Teams channel, many people often read and write along. If a mention can become an action in the code, the question arises who may mention at all. In a channel with colleagues from sales, that is a different situation from a channel used only by the development team.
• The trigger is unchecked text. A bug report may come from a customer, a colleague or an automated system. It can be incomplete, ambiguous or wrong. An agent that changes code on the basis of such a text also takes over its vagueness. That is no reason not to use it, but a reason not to accept the proposal blindly.
• A pull request is only as good as its review. If pull requests in your team have so far been merged without a second pair of eyes, an agent that delivers more proposals will rather enlarge this problem than solve it.
• Access must be granted deliberately. The source describes that you connect an account and select a repository. That is the moment at which you determine which code the agent gets access to at all. Choose deliberately, and start with a non-critical repository.

On data protection questions, such as which chat contents are transmitted to which service, the source gives no information, and we have not checked it. Clarify these points before use with your data protection officer and on the basis of the documents from GitHub and Microsoft, above all if customer data or personal details can appear in your channels.

Why the review step is the core

The announcement can be read from two angles. In the first, it is a convenience: you no longer have to switch tools. In the second, it is a shift of responsibility: a task that a human used to accept deliberately can now be triggered by a mention in a chat. Both readings are correct, and the second is the one a managing director should keep in view.

In this flow, the pull request is the place where responsibility moves back to the human. You can imagine it as a draft lying on the desk that has not yet been sent. Whether a draft is good is only recognized when someone reads it. Four things therefore belong to a sound flow:

• Readability: The proposal must be small and clear enough for a human to judge it in a reasonable time.
• Tests: The source explicitly states that the team tests the proposal. Without automated tests and a look at the result, the review is merely reading.
• Named responsibility: Someone confirms the merge and is thereby responsible for the change, not the agent.
• Traceability: It remains visible who triggered the process, what was proposed and who accepted it.

Whether the feature in Teams supports all of these points, the source does not say. It describes the flow up to the pull request and the review by the team, not roles, logs or permission models. How you configure branch protection, mandatory reviews and permissions in GitHub is a matter of your configuration, and these settings exist regardless of whether a human or an agent makes a proposal.

Which agent at Amazing Agents would be responsible: the Code-Operator

On amazing-agents.com, the Code-Operator is one of the eight agents. Its description reads: “Bugs, fixes, pull requests with your approval.” That is exactly the profile the GitHub announcement touches: taking in errors, preparing corrections, creating pull requests, and the human approves.

We want to separate carefully here. GitHub’s feature in Teams is a product of GitHub and Microsoft, not a product of Amazing Agents. We do not claim it is part of our offering. Classifying it as a Code-Operator task serves to describe the job: what an agent in this area can do and where its limit should lie. A bug report is taken in, a correction proposal is created, a human decides.

We describe an approach, not a result from a customer project. In an audit, we would clarify with you which kinds of errors an agent may touch at all, such as spelling mistakes in texts or small, well-tested functions, and which not, such as payment flows, permissions or interfaces to customer systems. This includes defining who reviews proposals, how quickly that should happen and what happens when nobody has time. A proposal that stays open for weeks is not progress but a new queue.

The website states generally for all agents: every agent runs within a defined framework with approval steps for critical actions. This framework is what makes an agent acceptable for a company. It is not a brake but the precondition for being allowed to give it tasks at all.

Agent with limits and an approval step: the difference

To make the difference tangible, we set two flows side by side. They are thought experiments, not reports from projects.

Without an approval step: An agent receives a bug report from the chat, changes the code and applies the change directly to the running software. If the report is imprecise or the fix incomplete, a follow-up error arises that is only noticed when a customer reports it. Nobody has seen the change, and afterwards it is unclear who initiated it.

With an approval step: The agent creates a pull request. A human reads it, runs the tests, looks at the context and only then merges it. If the proposal does not fit, it is discarded or improved. The decision has a name, and the path is traceable. That costs time per proposal, but saves the time an unnoticed follow-up error would cause later.

An agent with limits and an approval step works in this sense not against you but for you, and it is the counter-design to the promise that software repairs itself. The source itself describes the second variant, because the pull request and the review by the team are part of the example.

What we do not know

• The license: Whether Copilot in Teams requires a particular Copilot license or plan is not stated in the source.
• The region: The source names no restriction, but also does not document availability for Germany, Austria or Switzerland.
• The quality: How often the proposed fixes are correct and for which kinds of errors is not in the source.
• The permissions: Who in Teams may instruct the agent and which rights apply in the repository, the entry does not describe.
• Data protection: Which contents from chats are processed, we have not checked.
• The year of the deadline: The source gives November 16 without a year.

What you should do this week: three steps

Because, according to the source, the feature is already available but the prerequisites are open, the steps consist of clarifying and testing, not of use in day-to-day business.

1. Check what you have: Ask your development team or IT service provider whether the previous GitHub notification app is in use in Teams. If so, plan the switch to the new app before November 16 and decide who carries it out.
2. Set the rules: Write down who may use @GitHub in which channels, which repositories should be accessible, and that every pull request is reviewed and tested by a second person before it is merged. Check whether branch protection and mandatory reviews are active in GitHub.
3. Test small: Choose a non-critical repository and a handful of simple errors. Observe for two weeks how many proposals are usable, how long the review takes and what you notice. Put it in writing so that you can decide afterwards on the basis of your own experience.

Conclusion

GitHub moves the starting point of a correction proposal into the chat: from a bug report in Teams, a mention can produce a pull request that the team reviews, tests and merges. That is a useful shortening of the path, as long as the last step stays with the human. According to the source, what is documented is the flow, the name change of the app and the retirement of the old app on November 16. Not documented are license questions, regional availability, quality of the proposals and data protection.

For your company this means: use the deadline as an occasion to clarify responsibilities, and try the feature on a small scale before you rely on it. An agent with limits and an approval step is a relief. An agent without both is a risk that merely happens not to be noticed.

Source: GitHub Changelog, “Turn notifications into code with GitHub Copilot in Teams,” October 23, 2026 (github.blog/changelog/2026-10-23-turn-notifications-into-code-with-github-copilot-in-teams).