GitHub Copilot now works across multiple repositories in Slack and Teams

GitHub Copilot in Slack and Microsoft Teams can now answer questions across several repositories in the same conversation. GitHub’s [October 15 release](https://github.blog/changelog/2026‑10‑15‑copilot‑in‑slack‑and‑teams‑adds‑model‑and‑repository‑updates/) gives examples such as listing open pull requests that need attention, summarizing merged work across repositories and investigating an issue that crosses frontend and backend codebases. The change removes a conversation‑level boundary. Users no longer need to start a separate thread for each repository when the question itself spans a portfolio or service boundary. GitHub also says `@GitHub` can appear anywhere in a message, repository switching is smoother, Slack conversation context is better and task recovery is more reliable. The practical gain is synthesis: a maintainer can ask one question about related repositories and receive a combined answer. The safe rollout still needs a bounded repository set and a repeatable answer check, because a fluent multi‑repo summary can omit a project, mix time windows or reflect the permissions of the connected identity rather than the organization’s intended reporting boundary.

Multi‑repo support does not create new repository access. GitHub’s [Slack integration documentation](https://docs.github.com/en/copilot/how‑tos/copilot‑integrations/integrate‑cloud‑agent‑with‑slack) says direct‑message actions use the linked personal GitHub account, while shared‑context artifacts can be created under the app identity. Users need write access to start cloud‑agent work, and enterprise administrators decide which repositories the Slack app can access. The [Teams documentation](https://docs.github.com/en/copilot/how‑tos/copilot‑integrations/integrate‑cloud‑agent‑with‑teams) describes the same core boundary: the GitHub connection, Copilot plan and cloud‑sandbox policy must be in place, and only users with write access can trigger agent changes. Other conversation participants may still add context. Administrators should therefore test retrieval and action separately. A user may be able to summarize an issue without being allowed to open a pull request. An app installation may cover only a subset of repositories even when the human account has broader rights. Record the acting identity, selected repositories and resulting artifact owner in acceptance evidence.

The release highlights better use of shared Slack messages and threads as context. GitHub’s Slack and Teams guidance says the entire conversation can inform the agent’s work and that this context is stored in the artifacts the agent produces. That becomes more consequential when one conversation also spans several repositories. A thread may contain customer details, incident notes or plans that are appropriate for one project but should not be copied into an issue or pull request in another. Repository access control does not automatically classify every message in the collaboration channel. Use a fresh thread for a bounded task, name the repositories explicitly and remove unrelated sensitive discussion before invoking the app. For narrower context, GitHub recommends a direct message. Teams should also inspect the generated artifact for copied conversation material before sharing or merging it.

A useful acceptance test starts with a known set of pull requests or issues across two or three repositories. Ask for a time‑bounded summary, then compare the cited items with GitHub’s native repository views. Verify that private and archived repositories behave as expected and that a denied repository is not silently represented as having no matching work. For issue investigation, require links to the exact issue, pull request, commit or workflow run supporting each conclusion. Treat “no activity” as a claim that needs a denominator: which repositories, branches and dates were searched? If the answer cannot establish that scope, narrow the prompt rather than using it as an operational report. Reliability improvements in the release may reduce startup and interruption errors, but they do not prove semantic completeness. Measure successful task starts, cited‑object accuracy, missing repositories and human correction rate separately.

The lowest‑risk use is cross‑repository retrieval: open pull requests, recent merges, linked issues and project activity. Begin with repositories that share an owner and data classification, then confirm that Copilot respects the intended access and produces traceable links. Only after that evidence is stable should a team test issue creation or cloud‑agent work. Preserve normal rulesets and code‑owner review, and distinguish a summary response from an artifact‑changing action. In shared Slack or Teams contexts, check whether the personal identity or app identity will own the result before starting. GitHub’s update makes collaboration tools a broader interface to repository portfolios. Its usefulness depends on explicit scope, permissions and context hygiene rather than the number of repositories mentioned in one chat. Follow related releases on the [GitHub organization page](https://opentools.ai/organizations/github). *Image: Documentary screenshot of GitHub’s official October 15 multi‑repository Copilot release page, captured at 1600 × 900 without generative alteration or artificial upscaling.*