Ideas that connect.
Work that moves forward.

From conversation to a reviewable change

GitHub has announced a consolidated Teams app: a notification can lead to a request for Copilot to investigate and prepare a pull request. GitHub announcement.

The documentation describes sessions that teammates can steer through conversation: adding context, correcting assumptions, and examining outputs. Copilot in Teams remains in public preview and subject to change. Using GitHub in Teams.

Nexo's editorial assessment is that this integration could shorten the path from identifying a problem to having a proposed change. Its usefulness will depend on clear instructions and subsequent review; we have not measured that potential saving.

Which app needs updating

The announcement distinguishes two transition paths. The stated retirement date is November 16, 2026. Migration instructions.

Availability and requirements

The agent integration supports all paid GitHub Copilot plans and requires a Teams account connected to GitHub. Copilot in Teams requirements.

The installation guide requires permission to install apps and Microsoft Public Developer Preview enabled in the Teams client. Cloud sandboxes must also be enabled; organizations and enterprises may need an administrator to activate the relevant policies. Setting up GitHub in Teams.

Budget also deserves attention: GitHub documents usage-based billing for cloud sandboxes. Having a Copilot plan should not be interpreted as unlimited execution at no extra cost. Sandboxes and billing.

Permissions, repositories, and context

Only users with repository write access can trigger changes. Workspace guests and outside repository collaborators cannot start or steer sessions. The agent takes the entire thread as context, which is stored in the generated artifacts. Session permissions and context.

App authorization includes reading code and other resources, plus write access to actions, issues, and pull requests. Copilot adds content write access and workflow read/write access. Repository owners should understand these permissions before enabling the workflow. GitHub permissions in Teams.

On October 15, GitHub announced support for working across several repositories in one conversation, for example to investigate a bug affecting both frontend and backend. That capability does not remove the need to check access to each repository. Multi-repository support.

Review remains the team's responsibility

Pull requests created in a shared context use the app's identity. GitHub documents an additional approval when repository rulesets already require at least one approval; this behavior is enabled by default. Review rules in Teams.

Our editorial recommendation is to evaluate changes through their tests and scope: reproduce the bug, confirm that the fix addresses it, and check for side effects. An open pull request is material to assess, not proof that an issue has been resolved.

A hypothetical example for a limited evaluation

Suppose a team discovers a bug when saving an empty form. In a test repository, it could use the following Nexo-written prompt. It has not been executed and does not represent an observed result.

• Before starting: identify the installed app, confirm permissions, and choose a thread containing only the necessary context.
• When the result arrives: review the changed files, run the regression test, and check valid and invalid cases.
• To assess the experience: record manual corrections, review time, and usage, without extrapolating one test to the entire team.

@GitHub Investigate why this form allows an empty value to be saved in the specified test repository. Propose a minimal fix and a regression test. Explain your assumptions and prepare a pull request for review.