Evidence note: This article rests almost entirely on GitHub’s own changelog posts — primary vendor announcements published on The GitHub Blog. What those posts say, GitHub says; that is a fact about the announcement, not an independently verified fact about the software. No third-party testing, no hands-on run, and no independent corroboration of the feature behaviour described below was available at the time of writing. Specific capabilities, dates and model names are marked at the point they appear with the source that attests them. Where a claim rests on something weaker than a vendor announcement, that is said in the sentence itself.
What GitHub published on September 25, 2026
GitHub published a changelog post titled "Updates to GitHub Copilot for Slack and Microsoft Teams," dated 2026-09-25 on The GitHub Blog (GitHub changelog, 2026-09-25). The post concerns Copilot as it appears inside two chat products rather than inside an editor — the assistant that answers in a Slack channel or a Teams thread, not the one that completes a line of code.
That distinction is the whole story of the release. Nothing in the announcement changes what Copilot does in a repository. It changes where the conversation with Copilot can start, and what material that conversation is allowed to see.
The three things the changelog claims: more context, more control, a clearer path to GitHub work
According to GitHub’s own announcement, the update gives Copilot in Slack and Microsoft Teams three things: more context, more control, and a clearer path from a conversation to actual work in GitHub (GitHub changelog, 2026-09-25). Those are GitHub’s framings, and they are broad by design.
Read them as a shape rather than a specification. "More context" means the assistant can draw on more of what is in the channel. "More control" implies configuration over that — though the changelog’s summary does not, in the material reviewed here, spell out which controls, at what scope, or who administers them. "A clearer path from conversation to GitHub work" points at the handoff: a thread in chat becoming an issue, a pull request, or a task an agent picks up. Which of those transitions are covered, and how much of the path is automated, is not settled by the announcement’s summary and remains open.
Files shared in Slack become Copilot context — the one concrete capability the post names
The single specific capability GitHub names is that files shared in Slack are handled as context for Copilot (GitHub changelog, 2026-09-25). A log someone drops into a channel, a stack trace pasted as a snippet, a configuration file attached to a bug report — that material becomes something the assistant can reason over in place.
This is the most operationally interesting line in the post and the one with the least documentation behind it. The announcement establishes that the capability exists. It does not, in what is available here, establish which file types are accepted, what size limits apply, whether the content is retained after the conversation, or whether channel-level or workspace-level policy governs which files are eligible. Those are exactly the questions a security review would ask first, and none of them are answered by the changelog. They are open.
The surface already existed: GitHub’s Microsoft Teams integration
This update lands on an existing surface rather than opening a new one. GitHub lists an official Microsoft Teams integration in its integrations directory, presented as a way of bringing code and work into Teams conversations (GitHub integrations directory). That the integration is officially maintained by GitHub, and that its current scope matches that description, is not corroborated here by any source independent of GitHub itself — the listing and the vendor are the same party, and no third-party confirmation was located. Treat the existence and the framing as GitHub’s representation.
What matters for reading the September 25 post is the direction of travel: the chat integration is not being introduced, it is being deepened.
The rest of that week’s Copilot releases
The Slack and Teams changes were part of a larger set. GitHub’s weekly release post covering that period — titled for September 21 — groups the chat updates with the rest of the week’s Copilot work (GitHub Copilot weekly releases, September 21). Per that post, the same week added new models to Copilot, including Claude Opus; introduced local sandboxing in the Copilot app; and shipped updates to Copilot in JetBrains and in VS Code.
That is four distinct surfaces in one week — two editors, one desktop application, two chat platforms — plus a model-roster change. All of it is attested by GitHub’s own roundup and none of it by an independent source. The weekly roundup as a format is itself a recurring object worth watching; an earlier look at how a multi-model router arrived inside one of these weekly posts found the series carries substantive changes in a summary wrapper, and that the series had a missing week.
Why a chat-surface change lands differently than an editor change
An editor update reaches whoever updates the extension. A chat-surface update reaches whoever is in the channel.
That difference is not cosmetic. In an editor, the user invoking Copilot has already chosen the repository, the file, and the moment. In a Slack channel, the context is whatever the last forty messages happened to contain, contributed by people who were not thinking about an assistant when they typed. Adding shared files to that context set widens it again — and the people sharing files into a channel are frequently not the people who configured the integration.
For a team that runs its incident response, its triage, and its informal design argument in Slack, this is where the assistant becomes ambient rather than invoked. The upside is obvious: the material is already there, and someone has to read it anyway. The governance question follows just as directly, and the changelog does not answer it.
Reading the two posts side by side: the roundup arrives before the announcement it covers
Here the record gets strange. The Slack and Teams changelog is dated 2026-09-25. The weekly roundup that covers it carries "September 21" in its title — yet is published at an address dated 2026-09-25, the same day (weekly roundup, Slack and Teams post). Both appeared first on The GitHub Blog.
The most economical explanation is that "September 21" labels the week the releases belong to, not the day the post went up, and that the roundup and the individual changelog were published together on the 25th. That reading is inference, not something either post states, and it is not confirmed here. A second reading — that the roundup was backdated or that the release week is being labelled by its Monday — is equally consistent with what is visible. The same dating oddity has surfaced before in an earlier account of this Slack and Teams update, which suggests a convention rather than a one-off slip, though the convention has not been confirmed by GitHub.
What that ordering means for treating the weekly posts as a dated record
If a title date names a week and a URL date names a publication day, then the weekly posts cannot be read as a timeline of when features became available. They are a record of when GitHub chose to describe them.
This matters concretely for anyone reconstructing a change history — during an incident review, a compliance audit, or a rollback investigation. The question "when did file context become active in our Slack workspace?" is not answered by either date on the page. Deprecation notices have the same property: GitHub’s schedule for retiring selected Copilot models on October 19th, 2026 sat above a table carrying its own, different dates. The lesson generalises: on these posts, check which date a date is.
Two releases in one week pulling opposite ways
The most interesting thing about that week is the tension inside it, and it is visible without any speculation about intent.
One release widens the inbound channel: files shared in Slack become material the assistant reads (GitHub changelog, 2026-09-25). Another release draws a boundary in the opposite direction: local sandboxing in the Copilot app, per the same week’s roundup (weekly releases, September 21).
One adds a path for untrusted content to enter. One adds an isolation boundary around what the assistant does with content it has. Whether these were coordinated as a single posture, or simply shipped by different teams in the same seven days, is not stated in either post and is open. But the pairing is a reasonable signal that content trust is being treated as a live problem on both sides — inbound and outbound — rather than on one.
Developer takeaway
What the posts settle: Copilot in Slack and Microsoft Teams received a context, control and workflow update on 2026-09-25; files shared in Slack are now handled as Copilot context; that change shipped alongside new models including Claude Opus, local sandboxing in the Copilot app, and JetBrains and VS Code updates; and the roundup covering all of it is titled for September 21 while published at a September 25 address. Every one of those is GitHub’s own statement, unverified independently.
What neither post answers: what happens to a file after Copilot has read it. Retention, scope, administrative control over which channels and which file types are eligible, and whether an organisation can turn the file-context behaviour off without removing the integration — none of it is addressed in the material reviewed here.
The practical follow-up for a team already running Copilot in Slack is narrow and answerable without waiting for GitHub: audit which channels the integration is installed in, and ask whether any of them routinely receive files that would not be allowed in a repository. That list is the actual blast radius of this release, and it is knowable today. A controlled test of what the assistant does and does not retain from a shared file would settle the rest — that test has not been run here, and is proposed, not reported.